Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

CFSS_Message_Service.doc

VIEWS: 0 PAGES: 37

									          Message Service Conceptual Functional Service Specification v.0.0.8




          Conceptual Functional Service Specification


                              Message Service


                                       0.0.8


                                   06/07/2010




Architecture Inception Team          caBIG Integration Hub

Editor                               Ajay Nalamala

Authors                              Ajay Nalamala




                                         -1-
        Message Service Conceptual Functional Service Specification v.0.0.8



Document   Date               Author                   Changes
Version

0.0.1      03/30/2010         Ajay Nalamala            Initial Document

0.0.2      O4/02/2010         Ajay Nalamala            Added numbers to
                                                       Conformance Profiles

0.0.3      04/05/2010         Ajay Nalamala            Changed conformance type
                                                       for ISO datatypes from
                                                       mandatory to permission

0.0.4      04/07/2010         Ajay Nalamala            Added “Retrieve Available
                                                       Service Types” to service
                                                       capabilities

0.0.5      04/20/2010         Ajay Nalamala            Changed back conformance
                                                       type for ISO datatypes to
                                                       mandatory.

0.0.6      04/23/2010         Ajay Nalamala            Incorporated feedback from
                                                       Harsh Marwaha

0.0.7      04/29/2010         Ajay Nalamala            Incorporated feedback from
                                                       Santosh Joshi

0.0.8      06/07/2010         Ajay Nalamala            Incorporated feedback from
                                                       Brian McIndoe and Kunal
                                                       Modi




                                       -2-
                  Message Service Conceptual Functional Service Specification v.0.0.8

Table of Contents
1        OVERVIEW AND BUSINESS CASE ................................................................................................4
     1.1     SERVICE DESCRIPTION AND PURPOSE .................................................................................................4
     1.2     SCOPE .................................................................................................................................................5
     1.3     ASSUMPTIONS .....................................................................................................................................6
2        BUSINESS STORYBOARDS..............................................................................................................8
     2.1 PRIMARY ACTORS ...............................................................................................................................8
        2.1.1  People Actors............................................................................................................................8
        2.1.2  System Actors............................................................................................................................8
     2.2 STORY BOARDS ..................................................................................................................................9
        2.2.1  Overview...................................................................................................................................9
        2.2.2  MS-SB1 – Synchronous Message ...........................................................................................10
        2.2.3  MS-SB2 – Asynchronous Message with Retry and Email Notification ..................................10
        2.2.4  MS-SB3 – Federated Processing............................................................................................10
        2.2.5  MS-SB4 – Content Based Routing ..........................................................................................11
        2.2.6  MS-SB5 – Transformation Ready ...........................................................................................11
        2.2.7  MS-SB6 – Reliable Transactions............................................................................................12
        2.2.8  MS-SB7 – caGrid and non-caGrid Secure Integration ..........................................................12
        2.2.9  MS-SB8 – Auditing .................................................................................................................12
        2.2.10    MS-SB9 – Location Transparency.....................................................................................13
        2.2.11    MS-SB10 – Transport Transparency .................................................................................13
3        DETAILED FUNCTIONAL MODEL..............................................................................................15
     3.1     STRUCTURE OF THE SERVICE ............................................................................................................15
     3.2     DETAIL OF THE CAPABILITIES ...........................................................................................................15
4        PROFILES ..........................................................................................................................................22
     4.1     FUNCTIONAL PROFILES .....................................................................................................................22
     4.2     SEMANTIC PROFILES .........................................................................................................................22
     4.3     CONFORMANCE PROFILES .................................................................................................................23
5        NFORMATION MODEL ..................................................................................................................24
6        SYSTEM INTERACTION DETAILS..............................................................................................25
     6.1     IMPLEMENTATION/DEPLOYMENT CONSIDERATIONS ........................................................................26
     6.2     MESSAGE SERVICE SINGLE SITE AND MULTI-SITE DEPLOYMENT DIAGRAMS .................................27
     6.3     COMPLIANCE AND CONFORMANCE STATEMENTS .............................................................................29
7        APPENDIX A – RELEVANT STANDARDS ..................................................................................31
8        APPENDIX B - REFERENCES ........................................................................................................32
9        APPENDIX C - GLOSSARY.............................................................................................................33
10       APPENDIX D – CROSS REFERENCE TABLES ............................................................................34
     10.1        LIST OF STORYBOARDS ................................................................................................................34
     10.2        STORYBOARDS TO CAPABILITIES MAPPING .................................................................................35
     10.3        LIST OF PROFILES .........................................................................................................................37
     10.4        ACTORS ........................................................................................................................................37




                                                                              -3-
          Message Service Conceptual Functional Service Specification v.0.0.8


1 Overview and Business Case
1.1 Service Description and Purpose
The purpose of this service is to provide a set of interfaces to enable message service
functionality. The functionality provided by this service includes synchronous and
asynchronous messaging, caGrid and non-caGrid messaging, and batch messaging.
When deployed at a cancer center, the message service will eliminate the connection
explosion that point-to-point integration approaches introduce. For every connection that
is added, the number of connections grows exponentially as each service connects to
every other service. With the help of the message service, additional services and/or
applications will have only one connection point. This minimizes the connections and
provides a centralized location for administering the connections and managing
integrated systems and architectures.
The message service will provide distributed messaging, location/ transport transparency,
multiprotocol support, quality of service, content based routing, and transformation. This
service interface will be generic and can be extended to support various integration
scenarios.
This service will receive input from various external systems and/or services and routes
the input to various services that are configured to receive the message. A response will
eventually be sent back to the sender of the message. The message service will also
perform logging and auditing of all messages.
One of the many integration scenarios is in the caBIG™ Clinical Trials Suite’s (suite)
Study Creation Application (SCA) application, where, if the study coordinator creates a
study, the study creation message in BRIDG format will be routed to other services using
the message service. The message service will also be responsible for ensuring that the
services receiving this message remain in a consistent state. If the message fails to be
delivered to one or more services, a rollback will be sent to the other services and the
whole transaction will be rolled back.
Another integration scenario is in the Life Sciences Distribution (LSD) bundle’s caTissue
application, where, the data retrieved by a tissue bank user on “Edit Specimen Collection
Group" screens, Specimen Search, Specimen Details and other screens will be derived
from one or more enterprise services: Specimen Management, Subject Management, and
others using the message service.
The development of a common, reusable set of interfaces provided by this service will
facilitate standardization, integration and interoperability between various systems and
workspaces.
This Service Specification provides a key infrastructure component for NCI to support
various integration scenarios involving either just the caBIG services/ applications or
heterogeneous systems involving various applications, legacy systems, vendor specific


                                          -4-
          Message Service Conceptual Functional Service Specification v.0.0.8

applications/ services. All these integration scenarios can take advantage of the Quality of
Service and other benefits that the message service will offer. This service serves as a
backbone for integrating heterogeneous systems/components independent of platform
within the clinical domain.

1.2 Scope
The scope of the service is to facilitate integration scenarios between various caBIG
compliant enterprise services/ applications and/or heterogeneous systems involving
various applications, legacy systems, vendor specific applications/ services. The table
below provides a list of items that are in scope or out of scope.
This service will support a federated message model where message clients and message
providers may reside on different networks within different security domains.

Items                                           Scope /   Source
                                                Out of
                                                Scope

Provide ability to process requests             Scope     Message Service scope
synchronously as well as asynchronously                   document

Provide ability to support secure integration   Scope     Message Service scope
scenarios in caGrid and non-caGrid                        document and Candidate
environments. This will include integrating               NCI Enterprise Services
with Infrastructure services to provide
authentication, authorization & other
services.

Provide distributed messaging, location/        Scope     CFSS Service Description
transport transparency, multiprotocol                     and Purpose
support, quality of service

Provide transformation capability by            Scope     Message Service scope
integrating with transformation service.                  document and Candidate
                                                          NCI Enterprise Services

Provide ability to process payloads of any      Scope     Message Service scope
format including BRIDG and HL7                            document

Support for configurable mechanism for          Scope     Message Service scope
adding and modifying integration scenarios.               document
At the time of configuration, ability to call
the external dependent services to ensure
that all the pre-conditions is met.


                                             -5-
          Message Service Conceptual Functional Service Specification v.0.0.8


Provide ability for content based routing        Scope      caBIG Integration Hub
including ability to call some intermediary                 requirements
services based on the incoming message
content

Provide ability for retry attempt                Scope      Message Service scope
configuration. On failures, provide the                     document and caBIG
option to use the notification service for                  Integration Hub
sending failure notifications.                              requirements

Provide support for reliable transactions        Scope      CaBIG Integration Hub
                                                            requirements

Provide ability to validate the incoming         Scope      Candidate NCI Enterprise
payload by integrating with Validation                      Services
infrastructure service.

Provide auditing capabilities by integrating     Scope      Message Service scope
with Audit Management infrastructure                        document and Candidate
service                                                     NCI Enterprise Services

1.3 Assumptions
Assumption                            Affects                            Source

This service will require the         If one or more of these            Message Service CFSS
following supporting services to      dependencies is not available
be in place in order to provide all   this service will not be able to
functionality:                        support all of the capabilities
      Notification Management        in the scope.
      Audit Management
      Identity Management
      Authorization Management
      Validation
      Transformation

A GUI based administration tool       Configuration problems are         Message Service CFSS
will need to be provided to enable    minimized
configuration of integration
scenarios for the message service

Current integration approaches, if    As a result of use of this         Message Service CFSS
any, among applications will be       service, more standardized

                                              -6-
          Message Service Conceptual Functional Service Specification v.0.0.8

modified to use the Message            integration among applications
Service                                and services

It is assumed that this service will   If the configuration is not     Message Service CFSS
use Notification Management            present, retry and notify
service for sending any                functionality will not work.
notifications including emails,        The message service client will
thus the pre-condition of an           not know if the message was
existing notification configuration    delivered.
for a specific topic must be met.

It is assumed that this service will   If the validation service is not   Message Service CFSS
use the Validation service for         able to validate the payload
validating the incoming message        and if the message client is
payloads. The payloads received        configured to validate a certain
by the message service are             payload, an error message will
expected to be handled by the          be sent to the client.
Validation service.

It is assumed that the integration If the audit management         Message Service CFSS
with Audit Management service is service is down or if there is an
done asynchronously                error processing the audit
                                   message, the audit message
                                   will be lost




                                             -7-
         Message Service Conceptual Functional Service Specification v.0.0.8


2 Business Storyboards
2.1 Primary Actors
2.1.1 People Actors
Name                Role                           Notes

Dr. Bill Dyer       Site Coordinator               Located at MD Anderson

Dr. Andy Blair      Site Coordinator               Located at UCSF

Dr John Doe         Registrar                      Located at MD Anderson

Dr. Lisa Lesley     Registrar                      Located at UCSF

Dr. Mary Smith      Study Coordinator              Located at MD Anderson

Bob Morris          Subject

Brian Gay           Subject

Dr. Carolyn Brey Bob’s Primary Care Provider       At a clinic

Mike Benton         System Administrator           Located at MD Anderson

James Norton        System Administrator           Located at UCSF

2.1.2 System Actors
Name                 Role                          Notes

Study Creation       Used to add Studies
Application (SCA)

Subject              Used to add subject
Registration         registrations
Application (SRA)

PO                   Person and Organization
                     service used to retrieve
                     entities during study setup

Medidata Rave®       A vendor product, that
                     provides enterprise-wide

                                           -8-
         Message Service Conceptual Functional Service Specification v.0.0.8

                    electronic data capture
                    (EDC) solution



2.2 Story Boards
2.2.1 Overview
Detail       MD Anderson is coordinating a multi-site Phase II randomized lung
             cancer study. The study has been approved by the sponsor (NCI in this
             case) as well as the local IRBs (at MD Anderson and UCSF) and is
             scheduled for trial at MD Anderson and UCSF sites.
             Dr. Mary Smith who is the Study Coordinator at MD Anderson is
             responsible for creating the study. Mary delegates the responsibility of
             fulfilling some pre-requisites for the study creation to Dr. Bill Dyer who is
             the Site Coordinator at MD Anderson. Apart from fulfilling the pre-
             requisites, Bill is also responsible for overlooking all the activities related
             to the study at MD Anderson.
             When Mary is done with study creation, it is distributed to all the
             participating sites (MD Anderson and UCSF in this case). At each of the
             participating sites, all the consumers that are interested in the study
             receive a message with the study identifier.
             The study is now open for enrollment and accrual can begin at MD
             Anderson and UCSF. Mary sends a notification to Dr. John Doe, who is
             the Registrar at MD Anderson and Dr. Lisa Lesley who is the Registrar at
             UCSF, to start the subject registration process.
             After the deadline for subject registration passes, Mary runs a report to
             pull all the registrations for the study. Mary in the role of a Study
             Coordinator, has privileges to see registrations from all the participating
             sites (MD Anderson & UCSF, in this case).Andy, in the role of a
             Participating site’s Site Coordinator, has privileges that limit him to
             looking at registrations only from his participating site (UCSF, in this
             case).
             The process of Study Creation, Subject Registration, usage of Study &
             Subject Registration by the consumers, and Reporting, involves exchange
             of several messages between the consumers within the participating sites
             as well as across the participating sites and the coordinating center.
             Message exchange also happens between consumers and other enterprise
             services.




                                          -9-
          Message Service Conceptual Functional Service Specification v.0.0.8

2.2.2 MS-SB1 – Synchronous Message
Outline       During Study Creation and Subject Registration, the Service Consumers
              used by Study Coordinator, Site Coordinators, and Registrars, send
              several synchronous messages to various message endpoints. The message
              endpoints could be other service consumers and/or enterprise services
              within/ across the participating sites and/or Coordinating Center.

Detail        Mary notifies Bill that some entities that she does not have privileges to,
              need to be created for the study. Bill logs into the SCA application and
              accesses the screen where he can search/add and assign Investigators to
              the study. He performs a search by entering the last name, identifier or
              some other field. SCA then sends a synchronous search message to Person
              Organization service to find out if the Investigator he is trying to add is
              already present. If the investigator is present, Bill assigns the investigator
              to the lung cancer study. If the investigator does not exist, Bill fills out the
              form in SCA and submits. Upon submission, SCA application sends a
              synchronous create message to PO service. Upon successful creation, Bill
              assigns the investigator to the study. Similarly, Bill sets up Research Staff,
              Coordinating center (MD Anderson), and Participating sites (MD
              Anderson and UCSF).



2.2.3 MS-SB2 – Asynchronous Message with Retry and Email
      Notification
Outline       Several Asynchronous messages will be exchanged by the Service
              Consumers during study creation and subject registration.

Detail        When Mary completes Study Creation, SCA application does two things:
              sends a synchronous create message to Protocol Management service, and
              an asynchronous message containing study identifier to interested
              consumers at MD Anderson and UCSF. Mary expects an email
              notification, if the asynchronous message is not delivered to all the
              interested consumers even after a certain number of pre-configured retry
              attempts.



2.2.4 MS-SB3 – Federated Processing
Outline       After the subject registration is complete, the Coordinating Center’s Site
              Coordinator runs a report to see all the registrations for the study. He/she
              expects to see a report with registrations from all the participating sites.


                                           - 10 -
          Message Service Conceptual Functional Service Specification v.0.0.8


Detail        After the deadline for subject registration passes, Mary runs a report using
              SRA application to pull all the registrations for the study. Mary in the role
              of a Coordinating Center’s Study Coordinator, expects to see registrations
              from all the participating sites (MD Anderson & UCSF, in this case).
              When Bill runs the report, SRA sends a synchronous message and
              receives data that has registrations federated from both MD Anderson and
              UCSF sites.



2.2.5 MS-SB4 – Content Based Routing
Outline       To process the registration report run by Coordinating Center’s Site
              Coordinator, the content in the message is used to retrieve data from
              various endpoints.

Detail        Mary runs a report using SRA application to pull all the registrations for
              the study, a message is sent that contains, among other things, Mary’s
              credentials and study identifier. Mary’s credentials are used to verify if
              she has privileges to look at the registrations from all the participating
              sites. After determining that she does, the study identifier is used to
              retrieve the sites by calling PA services. For each of the site (MD
              Anderson and UCSF, in our case), the sites Subject Registration endpoint
              is retrieved by calling the Organization Service.



2.2.6 MS-SB5 – Transformation Ready
Outline       Subject Registrations performed by the Registrars at the participating
              site(s) need to be sent to a vendor product that accepts data in a different
              format.

Detail        John completes a subject registration using SRA application. Upon
              completion, SRA application sends a subject registration message. This
              message is compliant with subject registration schema. Apart from
              sending this message to Subject Registration service, it needs to be sent to
              Medidata Rave®, a vendor product that is purchased by MD Anderson.
              Medidata Rave® accepts the message data in BRIDG v2.1 format. After
              determining the source and destination data format imparities,
              Transformation Service is called to convert the Data Format.




                                          - 11 -
          Message Service Conceptual Functional Service Specification v.0.0.8

2.2.7 MS-SB6 – Reliable Transactions
Outline       If a Subject Registration performed by the Registrar at the participating
              site fails to be delivered to one or more of the consumers that is interested
              in the registrations, A Rollback should be performed. Otherwise, a commit
              should be performed.

Detail        John completes a subject registration using SRA application. Upon
              completion, apart from sending a create subject registration message to
              Subject Registration service, a second message containing the subject
              registration identifier is sent to all the interested consumers. All the
              consumers wait for a commit message before committing. If the second
              message (containing the identifier) fails to be delivered to one of the
              consumers, a rollback message is sent to all the consumers. The message
              is marked for a future retry.



2.2.8 MS-SB7 – caGrid and non-caGrid Secure Integration
Outline       A participating site may have caGrid compliant service consumers, caGrid
              compliant NCI enterprise services, and non-caGrid vendor services. In this
              scenario, all the services should be able to exchange messages in a secure
              way.

Detail        John completes a subject registration using SRA application. Different
              kinds of messages are sent to service consumers, Subject Registration NCI
              enterprise service, and Medidata Rave®. All the message exchanges
              happen on a secure channel. Service consumers and Subject Registration
              service are compliant with caGrid where as Rave® is not. But Rave® has
              a secure interface and expects authentication credentials to be passed.
              caGrid compliant services expect caGrid credentials. Clients may want to
              delegate their credentials to the message service to be used to perform
              message exchanges. SRA expects messages to be sent to a secure caGrid
              compliant service, where as Rave® expects messages to be sent to a non-
              caGrid service interface.



2.2.9 MS-SB8 – Auditing
Outline       All the message exchanges between various services at the participating
              sites need to be audited based on configuration.

Detail        John while doing a subject registration using SRA application gets an
              error message on the screen that reads “One of more systems down. Please

                                         - 12 -
          Message Service Conceptual Functional Service Specification v.0.0.8

              Retry”. John gets the same message on couple of retry attempts. To know
              exactly what was causing the issue, John reports the error to Mike Benton
              who is the system administrator at MD Anderson. John pulls out a report
              that clearly shows which service or application is down that is causing the
              error to happen with exact date and time. He also sees the actual de-
              identified message that failed. With the help of the audit report, Mike
              fixes the system and reports the fix to John. John retries the subject
              registration and completes successfully.



2.2.10        MS-SB9 – Location Transparency
Outline       When the location (physical or domain) of the service provider changes,
              and if more than one service consumer depends on it, the change of
              location should be made exactly at a single place. The service consumers
              should be unaware of the change.

Detail        Lisa (registrar at UCSF) while doing a subject registration using SRA,
              experiences a very slow final confirmation of a successful registration.
              Mary also experiences a similar issue while running a report (whose report
              depends on the data from Subject Registration service hosted at UCSF) to
              look at subject registrations for the study. Lisa informs regarding the issue
              to James Norton who is the System Administrator at UCSF and Mary
              informs about the issue to Mike. Mike after checking everything using
              audit reports, figures out that the issue is with the Subject Registration
              service at UCSF, and informs to James. James figures out that the
              hardware of the machine hosting the Subject Registration NCI enterprise
              service is out of resources and determines that it needs to be replaced.
              James orders the new Hardware, assigns a new hostname, ports the
              Subject Registration service to the new hardware and shuts down the
              slower machine. The changes performed by James should not induce any
              changes to SRA at UCSF or the reporting software at MD Anderson.



2.2.11        MS-SB10 – Transport Transparency
Outline       When the transport layer protocol of one of the destination services is
              different from the others, message sender should not need to communicate
              in different protocols with different services.

Detail        Lisa performs a subject registration using SRA application. All the
              destination services have a secure http interface except one that has a
              different interface. SRA sends the message to all destination services

                                         - 13 -
Message Service Conceptual Functional Service Specification v.0.0.8

    using the same protocol and the message service recognizes and
    accommodates the one service that has the different protocol




                              - 14 -
          Message Service Conceptual Functional Service Specification v.0.0.8

3 Detailed Functional Model
3.1 Structure of the Service
The following list of capabilities was created from an analysis of the storyboards. All the
NCI Enterprise services are exposed as a common set of services by the Message Service.

Name               Description

Send               This capability is used by the service consumers to send messages
Synchronous        Synchronously to one or more service providers that include but not
Request            limited to caGrid/ non-caGrid services, vendor provided services, and
                   legacy applications.

Send               This capability is used by the service consumers to send messages
Asynchronous       Asynchronously to one or more service providers that include but not
Request            limited to caGrid/ non-caGrid services, vendor provided services, and
                   legacy applications.

Retrieve           This capability is used by the service consumers to retrieve a
Available          collection of different service types that are configured in the Message
Service Types      Service. A detailed description of the service type is also returned.
                   Based on the configuration, each service type message may result in
                   sending message to one or more service providers
                   For example, each service type object has information about the code
                   representing the service type, name of the service type, and description
                   including the target service providers the message is sent to.
                   Message service consumers must send this information to the message
                   service during both synchronous and asynchronous requests.



3.2 Detail of the Capabilities
No.                       MS-CPB1

Name [M]                  Send Synchronous Request

Description [M]           Enables service clients to send messages synchronously.
                          Messages can be configured to participate in a transaction with
                          commits and rollbacks.
                          Reads the message type information from the metadata and
                          determines the destination route.
                          Based on the pre-configuration, calls the NCI Core and/or

                                          - 15 -
        Message Service Conceptual Functional Service Specification v.0.0.8

                       Infrastructure enterprise services and validates the message,
                       obtains identifiers, authenticates the user to obtain delegated
                       credentials, and/ or transforms the payload format.
                       If one of the calls to the Core/ Infrastructure service results in a
                       business or non-business error, Returns an error message to the
                       service client. Otherwise, invokes the destination service.
                       Uses the optional timeout value up to an allowable maximum,
                       passed by the service client in the metadata. Sends the response
                       back within the timeout period. Tracks the time spent in calling
                       the intermediate services as well as the target service providers,
                       against the timeout value specified by the service client.
                       Depending on the service provider implementation,
                       communicates with them in one or more protocols and keeps
                       this information transparent from the service client.
                       If the message type is configured such that the results from
                       multiple service providers need to be federated, calls the
                       required Business Process Services and determines the service
                       providers that need to be called. Builds a federated result set
                       from the responses of all the service providers.
                       If the message is configured to be executed in a transaction,
                       waits for the response from each service provider. If the
                       message is successfully delivered to all the service providers,
                       commits the transaction by sending a commit call to all the
                       destinations. If the message is not successfully delivered to one
                       of more of the service providers, sends a rollback call and
                       returns an error message to the service client.
                       If successful, sets a success indicator in the response metadata,
                       builds the response object and sends the response to the service
                       client.

Pre-Conditions [M]     None

Security Pre-          Access control mechanism needs to be in place by the service
Conditions [M]         consumer to ensure that the user is logged in and has valid
                       privileges to invoke the operation on the target service(s)

Inputs [M]             RequestMetadata (Contains parameters to determine routing of
                       the message, operation that needs to be executed on the target
                       service(s), identifier that is passed by the service client and
                       used exclusively by the service client, Boolean value that
                       identifies if the request is caGrid enabled and others)


                                        - 16 -
            Message Service Conceptual Functional Service Specification v.0.0.8

                           BusinessMessagePayload (Payload of the message that is
                           passed to the service provider(s). Message service uses this
                           payload for providing some of the capabilities)

Outputs [M]                ResponseMetadata (Contains identifier sent by the client)
                           ResponseMessage (Contains response message from the
                           service provider, message service in case of an exception, or
                           federated results from multiple service providers)

Post-Conditions [O]        A message is received by one or more services/ applications

Exception Conditions       Timeout getting response from one or more service providers
[M]                        (with details on which service provider is slow)
                           Cannot connect to the service provider (with details of the
                           service provider)
                           Service Provider returned business exception (details including
                           exceptions from NCI Enterprise services.)
                           Exception Parsing the message request
                           Error getting Metadata
                           Service Type is not configured
                           Error Invoking the <Service Provider>
                           Fault returned from <Service Provider>
                           Permission denied fault from <Service Provider>
                           Authentication denied fault from <Service Provider>
                           Service Type is not configured in the Message Service
                           Internal Error from <Service Provider>
                           Message Service Internal Error <Details>

Aspects left for           GUI tool is provided to configure the service type routing,
Technical Bindings         transformations, validations etc
[O]

Notes [O]



No.                        MS-CPB2

Name [M]                   Send Asynchronous Request

                                           - 17 -
         Message Service Conceptual Functional Service Specification v.0.0.8


Description [M]         Enables service clients to send messages asynchronously. The
                        messages are stored and forwarded.
                        If one of the calls to the Core/ Infrastructure service results in a
                        business or non-business error, Returns an error message to the
                        service client. If the service client implements a fire and forget
                        strategy, notification will be sent by making use of the
                        Notification NCI Enterprise service.
                        All the other capabilities that are provided by the “Send
                        Synchronous Request” are also available.

Pre-Conditions [M]      None

Security Pre-           Access control mechanism needs to be in place by the service
Conditions [M]          client to ensure that the user is logged in and has valid
                        privileges to invoke the operation on the target service(s)

Inputs [M]              AsyncHandler Object (Used by the consumers to retrieve the
                        message when the response is ready)
                        RequestMetadata (Contains parameters to determine routing of
                        the message, operation that needs to be executed on the target
                        service(s), identifier that is passed by the service client and
                        used exclusively by the service client, Boolean value that
                        identifies if the request is caGrid enabled and others)
                        BusinessMessagePayload (Payload of the message that is
                        passed to the service provider(s). Message service uses this
                        payload for providing some of the capabilities)

Outputs [M]             ResponseMetadata (Contains identifier sent by the client)
                        ResponseMessage (Contains response message from the
                        service provider, message service in case of an exception, or
                        federated results from multiple service providers)

Post-Conditions [O]     A message is received by one or more services/ applications

Exception Conditions    Timeout getting response from one or more service providers
[M]                     (with details on which service provider is slow)
                        Cannot connect to the service provider (with details of the
                        service provider)
                        Service Provider returned business exception (details including
                        exceptions from NCI Enterprise services.)



                                         - 18 -
            Message Service Conceptual Functional Service Specification v.0.0.8

                           Exception Parsing the message request
                           Error getting Metadata
                           Service Type is not configured
                           Error Invoking the <Service Provider>
                           Fault returned from <Service Provider>
                           Permission denied fault from <Service Provider>
                           Authentication denied fault from <Service Provider>
                           Service Type is not configured in the Message Service
                           Internal Error from <Service Provider>
                           Message Service Internal Error <Details>

Aspects left for
Technical Bindings
[O]

Notes [O]



No.                        MS-CPB3

Name [M]                   Retrieve Available Service Types

Description [M]            Enables service consumers to retrieve the service types that are
                           configured in the Message Service.
                           Each synchronous or asynchronous message call for a specific
                           service type may result in sending message to more than one
                           service provider that included NCI enterprise service, Vendor
                           service and others. Service consumers can use the details
                           provided by this to review the service providers that are
                           configured for this service type.

Pre-Conditions [M]         None

Security Pre-              Access control mechanism needs to be in place by the service
Conditions [M]             consumer to ensure that the user is logged in and has valid
                           privileges to invoke this capability on the Message service.

Inputs [M]                 None



                                           - 19 -
            Message Service Conceptual Functional Service Specification v.0.0.8


Outputs [M]                Array of MSTypeCode objects (Contains code, name, and
                           description for each service type).

Post-Conditions [O]        None

Exception Conditions       Exception Parsing the message request
[M]
                           No service types are configured

Aspects left for
Technical Bindings
[O]

Notes [O]



No.                        MS-CPB3

Name [M]                   Retrieve Asynchronous Message Status

Description [M]            Enables service consumers to retrieve the service types that are
                           configured in the Message Service.
                           Each synchronous or asynchronous message call for a specific
                           service type may result in sending message to more than one
                           service provider that included NCI enterprise service, Vendor
                           service and others. Service consumers can use the details
                           provided by this to review the service providers that are
                           configured for this service type.

Pre-Conditions [M]         None

Security Pre-              Access control mechanism needs to be in place by the service
Conditions [M]             consumer to ensure that the user is logged in and has valid
                           privileges to invoke this capability on the Message service.

Inputs [M]                 None

Outputs [M]                Array of MSTypeCode objects (Contains code, name, and
                           description for each service type).

Post-Conditions [O]        None

Exception Conditions       Exception Parsing the message request
[M]

                                           - 20 -
            Message Service Conceptual Functional Service Specification v.0.0.8

                           No service types are configured

Aspects left for
Technical Bindings
[O]

Notes [O]




                                          - 21 -
         Message Service Conceptual Functional Service Specification v.0.0.8

4 Profiles
4.1 Functional Profiles
Functional    Functional     Functional Profile       Capability Name
Profile No.   Profile        Description
              Name

MS-FP1        MS             This profile provides       Send Synchronous Request
              Messaging      messaging capability
                                                         Send Asynchronous Request

                                                         Retrieve Available Service
                                                          Types




4.2 Semantic Profiles
Semantic      Semantic          Constrained                Operations using the
Profile No.   Profile Name      Information Model          Semantic Profile

MS-SP1        ISO 21090 MS      ISO 21090                     Send Synchronous
                                                               Request

                                                              Send Asynchronous
                                                               Request

                                                              Retrieve Available
                                                               Service Types




                                         - 22 -
           Message Service Conceptual Functional Service Specification v.0.0.8


4.3 Conformance Profiles


No.                    MS-CP1

Name                   MS Messaging IS0 21090

Version                V1.0

Description            This is the conformance profile required for sending messages
                       to the Messaging Service

Usage Context          This profile could be used every where there is a interaction
                       between NCI Enterprise services.

Functional             MS-FP1 : MS Messaging
Profile(s)

Semantic Profile(s)    MS-SP1 : MS

Security               Yes

Other….




                                         - 23 -
         Message Service Conceptual Functional Service Specification v.0.0.8

5 nformation Model
The following diagram shows the domain model for Message Service.




                                       - 24 -
          Message Service Conceptual Functional Service Specification v.0.0.8

6 System Interaction Details
The following diagram shows the interaction between the Study Coordinator using a
service consumer (SCA, in our case) application for making a create study request and
the interaction (synchronous and asynchronous) between SCA application and the
Message Service. The interaction between Message Service, Protocol Management
Service and other NCI enterprise services is also shown.




                                         - 25 -
         Message Service Conceptual Functional Service Specification v.0.0.8




         Component view depicting major interactions of the Message Service


6.1 Implementation/Deployment Considerations
Implementation Considerations                           Impacts

Deployment and usage of this service should be          Some of the capabilities
coordinated with the deployment of other relevant NCI   provided by this service
enterprise services. There may or may not be an         depend on the availability of
Administration GUI tool available at the time of the    the other NCI Enterprise
deployment. In that case manual configuration           services and hence may not
instructions should be used.                            work.

Compliance with the NCI CBIIT Build and                 NCI systems team will not
Deployment Automation (BDA) process                     support the service unless it is
                                                        BDA compliant



                                        - 26 -
         Message Service Conceptual Functional Service Specification v.0.0.8

6.2 Message Service Single Site and Multi-Site Deployment
    Diagrams
The following diagram shows a single and multisite deployment scenario for the Message
Service.




                                        - 27 -
          Message Service Conceptual Functional Service Specification v.0.0.8




In the following multisite deployment scenario, a Site Coordinator at the Coordinating
Center makes a request to pull all the registrations for the study. In the role of a Site
Coordinator at the Coordinating Center, he/ she expect registrations for all the
participating sites. After the generation of the report, the registration data for each
participating site remains at the respective site locally.




                                           - 28 -
                                     Message Service Conceptual Functional Service Specification v.0.0.8



           6.3 Compliance and Conformance Statements
Name            Type         Viewpoint        Description                                         Test method

Multiple        Obligation   Enterprise       The Message Service is obligated to be able to      Test cases include
Jurisdictions                                 support processing across multiple jurisdictional   multiple domain
                                              domains. Implementers must provide an               scenarios
                                              implementation that supports multiple
                                              jurisdictional domains

Synchronous     Obligation   Enterprise       Synchronous message requests should return          Test cases to include
Message                                       results within the combined maximum response        performance testing.
Response                                      times published by the respective service
                                              providers called synchronously.

Conformance     Obligation   Computational    In order to claim a minimal level of conformance    Test cases to be defined
Profiles                     / Information    to the Message Service specification,               to test each specified
                                              designers/implementers are obligated to support     profile.
                                              the following mandatory Conformance Profiles
                                              (i.e. their contained functional and semantic
                                              profiles): MS Messaging

ISO             Obligation   Information      Designers/implementers are obligated to          Test cases to include
Datatypes                                     implement the support for ISO 21090 datatypes in processing of each
                                              all operations                                   relevant data type

Auditing        Obligation   Engineering      Designers/implementers are obligated to decide      Design Review
                                              on and document the approach for logging or
                                              auditing of operation calls.

Operation       Obligation   Computational    Architects/Designers/Developers are obligated to    Design Review

                                                                    - 29 -
                             Message Service Conceptual Functional Service Specification v.0.0.8


Name          Type   Viewpoint         Description                                       Test method
Behavior             / Information /   confirm (or refute) all Assumptions made in the
Issues /             Engineering       Notes for Service Realization sections of each
Assumptions                            operation and the overall Assumptions section.




                                                             - 30 -
        Message Service Conceptual Functional Service Specification v.0.0.8

7 Appendix A – Relevant Standards
Name            Description                    Location

ISO 21090       Health Informatics --          http://www.iso.org/iso/catalogue_detail
                Harmonized data types for      .htm?csnumber=35646
                information interchange




                                      - 31 -
        Message Service Conceptual Functional Service Specification v.0.0.8

8 Appendix B - References
Name        Description                          Location

ISO 21090   Health Informatics --                http://www.iso.org/iso/catalogue_detail
            Harmonized data types for            .htm?csnumber=35646
            information interchange




                                        - 32 -
       Message Service Conceptual Functional Service Specification v.0.0.8

9 Appendix C - Glossary
Term       Description

LSD        Life Sciences Distribution

PA         Protocol Abstraction

PO         Person and Organization

SCA        Study Creation Application

SRA        Subject Registration Application




                                        - 33 -
         Message Service Conceptual Functional Service Specification v.0.0.8


10 Appendix D – Cross Reference Tables
10.1 List of Storyboards
#         Name                Description                                Source

MS-SB1    Synchronous         During Study Creation and Subject       MS-SB1 –
          Message             Registration, the Service Consumers     Synchronous
                              used by Study Coordinator, Site         Message
                              Coordinators, and Registrars, send
                              several synchronous messages to
                              various message endpoints. The
                              message endpoints could be other
                              service consumers and/or enterprise
                              services within/ across the
                              participating sites and/or Coordinating
                              Center.

MS-SB2    Asynchronous        Several Asynchronous messages will         MS-SB2 –
          Message with        be exchanged by the Service                Asynchronous
          Retry and Email     Consumers during study creation and        Message with
          Notification        subject registration.                      Retry and
                                                                         Email
                                                                         Notification

MS-SB3    Federated           After the subject registration is          MS-SB3 –
          Processing          complete, the Coordinating Center’s        Federated
                              Site Coordinator runs a report to see      Processing
                              all the registrations for the study.
                              He/she expects to see a report with
                              registrations from all the participating
                              sites

MS-SB4    Content Based       To process the registration report run     MS-SB4 –
          Routing             by Coordinating Center’s Site              Content Based
                              Coordinator, the content in the            Routing
                              message is used to retrieve data from
                              various endpoints

MS-SB5    Transformation      Subject Registrations performed by         MS-SB5 –
          Ready               the Registrars at the participating        Transformation
                              site(s) need to be sent to a vendor        Ready
                              product that accepts data in a different
                              format


                                        - 34 -
         Message Service Conceptual Functional Service Specification v.0.0.8


MS-SB6    Transaction with    If a Subject Registration performed by    MS-SB6 –
          commits and         the Registrar at the participating site   Transaction
          rollbacks           fails to be delivered to one or more of   with commits
                              the consumers that is interested in the   and rollbacks
                              registrations, A Rollback should be
                              performed. Otherwise, a commit
                              should be performed

MS-SB7    caGrid and non-     A participating site may have caGrid      MS-SB7 –
          caGrid Secure       compliant service consumers, caGrid       caGrid and non-
          Integration         compliant NCI enterprise services,        caGrid Secure
                              and non-caGrid vendor services. In        Integration
                              this scenario, all the services should
                              be able to exchange messages in a
                              secure way

MS-SB8    Auditing            All the messages exchanges between        MS-SB8 –
                              various services at the participating     Auditing
                              sites need to be audited based on
                              configuration

MS-SB9    Location            When the location (physical or            MS-SB9 –
          Transparency        domain) of the destination service        Location
                              changes, and if more than one service     Transparency
                              depends on the location changed
                              service, the change or location should
                              be made exactly at a single place. The
                              dependent services should be unaware
                              of the change.

MS-       Transport           When the transport layer protocol of      MS-SB10 –
SB10      Transparency        one of the destination services is        Transport
                              different from the others, message        Transparency
                              sender should not need to
                              communicate in different protocols
                              with different services



10.2 Storyboards to Capabilities Mapping
#         Storyboard            Profiles         Actors           Capabilities

MS-SB1    Synchronous           MS               Site             Send Synchronous
                                Messaging        Coordinator,

                                       - 35 -
         Message Service Conceptual Functional Service Specification v.0.0.8

          Message               IS0 21090        Registrar,      Request
                                                 Study
                                                                 Retrieve Available
                                                 Coordinator     Service Types

MS-SB2    Asynchronous          MS               Site            Send Asynchronous
          Message with Retry    Messaging        Coordinator,    Request
          and Email             ISO 21090        Registrar,
                                                                 Retrieve Available
          Notification                           Study           Service Types
                                                 Coordinator

MS-SB3    Federated             MS               System          Send Synchronous
          Processing            Administrator    Administrator   Request, Send
                                                                 Asynchronous Request

MS-SB4    Content Based         MS               System          Send Synchronous
          Routing               Administrator    Administrator   Request, Send
                                                                 Asynchronous Request

MS-SB5    Transformation        MS               System          Send Synchronous
          Ready                 Administrator    Administrator   Request, Send
                                                                 Asynchronous Request

MS-SB6    Transaction with      MS               System          Send Synchronous
          commits and           Administrator    Administrator   Request, Send
          rollbacks                                              Asynchronous Request

MS-SB7    caGrid and non-       MS               System          Send Synchronous
          caGrid Secure         Administrator    Administrator   Request, Send
          Integration                                            Asynchronous Request

MS-SB8    Auditing              MS               System          Send Synchronous
                                Administrator    Administrator   Request, Send
                                                                 Asynchronous Request

MS-SB9    Location              MS               System          Send Synchronous
          Transparency          Administrator    Administrator   Request, Send
                                                                 Asynchronous Request

MS-       Transport             MS               System          Send Synchronous
SB10      Transparency          Administrator    Administrator   Request, Send
                                                                 Asynchronous Request




                                       - 36 -
            Message Service Conceptual Functional Service Specification v.0.0.8

10.3 List of Profiles
Functional      Functional Profile Name       Storyboard      Storyboards Supported
Profile No.                                   No.

MS-FP1          MS Messaging                  MS-SB1          Synchronous Message
                                              MS-SB2          Asynchronous Message with
                                                              Retry and Email Notification



10.4 Actors
Actors                Profile             Type          Operations used

Site Coordinator      MS Messaging        Person        Send Synchronous Request
                      ISO 21090
                                                        Send Asynchronous Request

Registrar             MS Messaging        Person        Send Synchronous Request
                      ISO 21090
                                                        Send Asynchronous Request

Study Coordinator MS Messaging            Person        Send Synchronous Request
                  ISO 21090
                                                        Send Asynchronous Request




                                          - 37 -

								
To top