Docstoc

HL7 Service Oriented Architecture - DOC

Document Sample
HL7 Service Oriented Architecture - DOC Powered By Docstoc
					                  HL7 Service Oriented Architecture
                   Special Interest Group (SOA SIG)




    SERVICES AND THE HL7 V3 DYNAMIC
                MODEL
               A DISCUSSION DOCUMENT /
                       WHITE PAPER




                            VERSION NO. 0.1
                         DATE: October xx, 2006




  Alan Honey        Kaiser Permanente

  email             Alan.P.Honey@kp.org

  Phone             (925) 324 3142 (Mobile)




Version 0.1                   Page 1                  Last Revision 3/2/2010
  Table of Contents

  SERVICES AND THE HL7 V3 DYNAMIC MODEL ....................................................1
  A DISCUSSION DOCUMENT / ........................................................................................1
  WHITE PAPER ......................................................................................................................1
  1      Introduction .....................................................................................................................4
      1.1        Purpose ..................................................................................................................... 4
      1.2        Background............................................................................................................... 4
      1.3        When to Use Services................................................................................................ 4
  2      “Prototypical” Methodology for Service Definition ....................................................5
      2.1        Requirements and Functional Specification ............................................................ 5
      2.2        Solution Specification (PIM) .................................................................................... 7
      2.3        Technical Specification (PSM) ................................................................................. 9
  3      Incorporating the HL7 Dynamic and Static Models .................................................11
      3.1        Overall meta-models of artifacts and process ........................................................ 11
      3.2        Step by Step Comparison ....................................................................................... 17
         3.2.1       Business Domain Analysis ....................................................................................................17
         3.2.2       Systems Analysis I.................................................................................................................18
         3.2.3       Systems Analysis II ...............................................................................................................19
         3.2.4       Technical/Implementation Design .........................................................................................20
  4      Conclusions ....................................................................................................................21
      4.1        Summary................................................................................................................. 21
      4.2        Recommendations................................................................................................... 21




Version 0.5                                                     Page 2                                                   Last Revision 3/2/2010
  Document Version History
  Version Number   Version Date        Revised By                  Description
 0.1               11/6/2006      Alan Honey         First draft




Version 0.5                                     Page 3                           Last Revision 3/2/2010
  1 Introduction
  1.1 Purpose
          The purpose of this document is to discuss the relationship between Service based
  analysis methodologies and the HL7 V3 Dynamic Model (and to a lesser extent, the
  Static Model), to look for possible synergies and possible convergence. Can the current /
  proposed dynamic model be used for Services in an SOA, and if not, what needs to be
  changed/ added, and can those changes / additions be applied generally, e.g. back to
  messaging?

  1.2 Background
          HL7 is in progress in redefining some aspects of the dynamic model for V3.
  Details are available on the Informatics Wiki at:
         http://informatics.mayo.edu/wiki/index.php/Dynamic_Model
          Under the banner of “SOA4HL7”, the HL7 SOA SIG has also produced a draft
  methodology for defining services based on existing HL7 V3 (or V2) Artifacts. See:
  http://hssp-infrastructure.wikispaces.com/space/showimage/SOA-
  HL7_Methodology_6.doc. A slightly later version of this document has been submitted
  for ballot as an Informative document in the January ballot.
          To date, this has led to the conclusion that there is not a good 100% deterministic
  mapping between current V3 concepts and a “good” service definition. “Good” is
  obviously subjective, but basically if you carried out top-down service analysis (e.g.
  Service Portfolio Planning as defined by CBDI Forum at www.cbdiforum.com), the
  resulting services would often not match those derived from existing message based
  artifacts whichever “deterministic” mapping method you used. To those wanting a more
  “appropriate” SOA, this is an issue. However, there is a reasonable mapping if some
  judgment is allowed into the process.
         In a discussion in the SOA SIG Implementation subgroup telcon of 10/17/2006,
  between Lloyd McKenzie, John Koisch, Jari Porasmaa, Alan Honey and others, the
  question was raised whether taking the service analysis route may be helpful in the
  emerging dynamic model work.
         This document discusses this issue.
         This document will NOT include any details of either the SOA4HL7
  Methodology or the HL7 V3 Dynamic model other than what is necessary to discuss the
  synergies. Refer to the HSSP and Informatics Wikis for that.

  1.3 When to Use Services
  See discussion in SOA4HL7 Methodology document




Version 0.5                             Page 4                           Last Revision 3/2/2010
2 “Prototypical” Methodology for Service Definition
This section will outline a “prototypical” methodology for defining services. There are many different methodologies for defining
services, and this is one. It does not claim to be the only one, but it is the one used for the sake of discussing the synergies with the
HL7 Dynamic model. It is based on the set of process steps identified in the SOA4HL7 Methodology, but is simplified and
abbreviated for the purposes of this discussion, aimed at identifying the key artifacts.
It is basically top-down, based on business process analysis, and assumes an MDA-style approach (functional spec -> PIM -> PSM).
The assumed technology is web services (SOAP/XML/WSDL etc), although this is not a pre-requisite. Not all steps or artifacts would
be produced in all cases.

2.1 Requirements and Functional Specification
This stage produces the business level definition of the service.
Step                            Description                                                Artifacts used
1) Service Portfolio            Define the overall structure of a business area and the    Service Portfolio Plan.
   Planning                     services needed. CBDIForum has an excellent
                                                                                           List of Business Service Domains
                                description of this
2) Define business problem      Describe business problem and identify the set of          Business problem statement, objectives,
   space and requirements       requirements to be included in the service. Describe the   measurable goals.
                                business process.
                                                                                           Business Process models (BPMN/UML
                                                                                           Activity Diagrams), Business Events,
                                                                                           Business Use Cases
3) Produce initial Service      Define the scope of the service and the overall name       Initial Service Definition
   definition and scope         and description
4) Describe capabilities        Functional and Information models, definition of           Updated/scoped Business Process models
   (process and                 process scope (where the process starts and ends,          (BPMN/UML Activity Diagrams).
   information)                 related users and stakeholders, inputs and outputs for
                                                                                           System Use Case Diagrams
                                each of them, different types of events and activities,


                    Version 0.1                               Page 5                           Last Revision 3/2/2010
Step                        Description                                               Artifacts used
                            conditions and synchronization).
                                                                                      Business Events
                            Identify the Business Objects that are relevant to
                                                                                      Business Roles
                            interoperability. For example, “LaboratoryOrder”,
                            “LaboratoryObservation”, “Person”, “Patient” may be       Domain Information Model (~ HL7
                            either exposed by the Service or used by the Service.     DAM)
                            For instance, Lab may expose “Order” and “Laboratory      State Transition Diagrams
                            Observation” but use the „Person” or “Patient” identity
                            information provided by the Person Service. This          Inter-Service Dependencies
                            analysis will also help identify potential dependencies
                            on other Services.
                            The Business Object definitions should already be
                            represented in Domain Models. Review the Domain
                            Models looking for those classes of interest. If the
                            object don‟t appear at all or they are incomplete,
                            ideally the Domain Models should be updated. For
                            example the “Laboratory Order” must appear as a
                            specialization of a generic “Order” or needs additional
                            components.
                            Once the business objects are identified, the behavior
                            should be described based on the state transitions in
                            scope. Similarly, any notifications triggered by those
                            state transitions must be also identified. In order to
                            determine any behavior required from other services,
                            identify dependencies on interfaces and notifications.
5) Identify and name        Identify and name Service Provider, Service Consumer, Service Provider, Service Consumer,
   service components       Service and Interfaces                                Service and Interface Names and
                                                                                  descriptions


                  Version 0.5                            Page 6                           Last Revision 3/2/2010
Step                            Description                                                  Artifacts used
6) Map requirements to          Map the identified requirements to the responsibilities      Refined Service Descriptions, including
   components                   and interfaces of the identified components. Fully           capability/feature descriptions.
                                describe the capabilities in business terms (not as
                                formal “operations”). Define features as either required
                                or optional. Define extensible features and mechanisms
                                for extensions.
7) Produce logical service      Produce a logical Service Specification. This pulls          Logical Service Specification - aka HSSP
   specification                together the business context and requirements and           Service Functional Model (SFM)
                                functional descriptions into a complete logical
                                description of the Service capabilities. The HSSP SFM
                                Template may be used for this document.



2.2 Solution Specification (PIM)
This stage defines the initial technology solution, but still at a platform independent level.


Step                            Description                                                  Artifacts Used
1) Refine interaction           Refine the interaction solution, for example the             Collaboration / Sequence Diagrams
   solution                     deployment and interaction style. Consider
                                centralization vs federation, interaction patterns
2) Refine component             Identify integration points in the architecture of the
   definitions                  participating systems.
                                Refine the responsibilities of the components, identify
                                possible extension needs and needed security features.
                                Define internal logic specification, and/or how legacy

                     Version 0.5                               Page 7                            Last Revision 3/2/2010
Step                          Description                                                 Artifacts Used
                              system logic will be used.
3) Define detailed dynamic    Specify interaction sequences, which may also contain       Refined Collaboration / Sequence
   model                      user interaction.                                           Diagrams
4) Specify operations and     Operations and Information contents and semantics           Interface, Operation and Message
   messages                   (messages) are specified as e.g. document definitions       definitions
                              in document style, parameter definitions in procedural
                              style, and functional needs as e.g. operation names and
                              document/message types.
                              The interface details should be unambiguous, well-
                              defined interfaces (inputs and outputs of service
                              operations + their functional constraints and generic
                              format)
                              Define features as either required or optional.
                              Refine extensible features and mechanisms for
                              extensions.
                              All business level exceptions should be identified and
                              described for each operation.
                              May also define further interactions that are part of the
                              service implementation, e.g. interactions with legacy
                              systems behind service facades.
5) Define QoS /               Refine the requirements for implementations or further
   implementation             technical and policy specifications.
   considerations             QoS - Policy definitions concerning security,
                              performance, reliability, scalability, availability,
                              transactional requirements, change management and


                    Version 0.5                             Page 8                            Last Revision 3/2/2010
Step                        Description                                                Artifacts Used
                            notification etc.
6) Produce Platform         Produce a Platform Independent Model / Technical           Platform Independent Service Technical
   Independent Model /      Specification. This provides a detailed level platform     Specification (PIM)
   Specification            independent representation of the service functionality.

2.3 Technical Specification (PSM)

Step                        Description                                                Artifacts Used
1) Define implementation    Select and group features from functional specification
   scope                    to be implemented
2) Technology selection     Refine the required technical capabilities of the
                            solution and link them to available technologies,
                            including necessary routing, protocol mediation and
                            other transformation mechanisms. Consider the suitable
                            technology and interfacing options of participating
                            systems or existing solutions which are to be used.
                            Select set of technologies to support the service
                            (transport (messaging, enveloping, reliability etc.),
                            interface (functionality, information), security.
3) Produce Platform         Refine functional specification with technology-         Initial Platform Specific Specification,
   Specific Model (PSM)     specific features (e.g. simple or complex types,         e.g. WSDL, XML Schema
                            messaging style such as data-oriented or rpc or process-
                            oriented)
4) Define environment       Identify technology-specific services (/consumers),        N/A
   services                 interfaces, operations and parameters; specify their


                  Version 0.5                             Page 9                             Last Revision 3/2/2010
Step                          Description                                               Artifacts Used
                              responsibilities
5) Produce technology         Create technology-specific interface specification:       Refined Platform Specific Specification,
   specific interface         e.g. for web services:                                    e.g. WSDL, XML Schema
   specification
                              1. describe service interface
                              2. specify operations and messages, including
                              exceptions
                              3. designate messaging and transport protocol
                              4. define bindings and actual service location
                              5. If applicable, publish to registry
6) Define Conformance         Define technical conformance levels


7) Produce Release            Document implementation-specific features of the
   Documentation              service, infrastructure etc, extensibility options etc.




Note on generation of physical models: Approaches such as OMGs Model-Driven Architecture (MDA) and emerging tooling are
beginning to allow the possibility of generating PSMs from detailed models. However, PSM generation is still not uniform but tool- or
project-dependent at the moment. There is no universally agreed abstraction or functionality level especially regarding what goes in
CIMs (Computationally Independent Models) and PIM (Platform Independent Models). Most of the SOA literature does not see
"generation from higher level models" among main service acquisition options to date




                   Version 0.5                              Page 10                         Last Revision 3/2/2010
  3 Incorporating the HL7 Dynamic and Static Models
  3.1 Overall meta-models of artifacts and process
  First, we present an abstract view of the overall process for creating the artifacts. Note the
  color coding in diagrams, which is explained in the diagram below.




  This breaks the overall process down into three main stages, i.e. business analysis,
  systems analysis and technical or implementation design.

Version 0.1                             Page 11                             Last Revision 3/2/2010
  The model below represents a proposed conceptual view of artifacts to be produced in the
  process, considering both Services and Messaging approaches together.




  Some sections of the above diagram are expanded in further diagrams below, for further
  clarification, namely the Business Process related artifacts and then the Interaction related
  aartifacts.




Version 0.31                            Page 12                            Last Revision 3/2/2010
Version 0.31   Page 13   Last Revision 3/2/2010
Version 0.31   Page 14   Last Revision 3/2/2010
  Another tabular view of some of this information is presented below


  Generic                   SOA / Web Services                 HL7
  Pre-work:
  Portfolio Plan (not on    Service Domains                    ~ HL7 Domain
  diagram)                                                     Committees
  Information Meta-model    -                                  RIM
  Business Domain
  Analysis:
  Business Information      Domain model, Business Object      DAM
  Model                     Model
  Business Events           Business Events                    Some Trigger Events
  Business Process Model    Business Process Model             -
  Business Scenarios        Business Use Case                  Storyboard
  Business Roles            Business Roles                     Storyboard Actors
  Business Services         Business Services                  -
  System Analysis:
  Analysis Information      Refined Domain model               DIM / D-MIM
  Model
  System Scenarios          System Use Case                    Storyboard
  Macro System              Activity/Sequence/Collaboration    CPM, CPI (Activity
  Choreography              Diagrams                           Diagrams)
  Interaction               Service Invocation / Usage         Interaction
  Interaction Participant   Service Provider, Service          Use of Application Role
                            Consumer                           wrt an Interaction?
  Event                     -                                  Trigger Event
  Actor                     Service                            ~ Application Role or
                                                               Collection of Application
                                                               Roles (Domain/Topic
                                                               level)
  Interface                 Service Interface                  ~ Application Role or
                                                               collection of Application
                                                               Roles
  Action                    Operation                          One side of an Interaction
  Action Step               Operation invocation               Dispatch or receipt of

Version 0.31                          Page 15                           Last Revision 3/2/2010
  Generic                     SOA / Web Services                HL7
                              Operation Response                message or
                                                                acknowledgement
  Interface Contract          Service Specification             ?
  Contract Condition /        Operation pre-condition, post-    Sequence Diagram for
  Action Behavior             condition, invariant, state       Interaction?
  Definition                  transition diagram for business
                              object, input message, output
                              messages, sequence diagram for
                              operation behavior
  Payload Message Type        Operation Message Type:           CIM / LIM / HMD
                              UML Class model (optional)
  Message/Event Business      N/D or in Payload                 Behavioral Contract
  Metadata                                                      Wrapper Type


  Implementation Design:
  Choreography /              Workflow, BPEL                    -
  Orchestration Script (not
  shown on diagram)
  Implementation              WSDL, Policy Files                ITS Specific (e.g. WSDL)
  Contract
  Implementation              WSDL Statement or Policy file     ITS Specific (e.g. WSDL
  Contract Condition          statement                         Statement)
  Policy                      Contractual / Declarative (e.g.   Transmission Wrapper
                              WS-policy framework)              (per message)
  Implementation              Service Message Header Type       Message Transmission
  Message Header Type                                           Wrapper Type
                                                                (also Behavioral Contract
                                                                Wrapper)
  Implementation              XML Schema                        XML Schema (non
  Message Schema                                                normative)
  Run Time Execution
  (not on diagrams)
  Endpoint                    Service Implementation            Message Handlers and
                                                                Application Logic
  Interface                   Service Interface                 Message
                                                                Source/Destination


Version 0.31                            Page 16                         Last Revision 3/2/2010
  Generic                    SOA / Web Services                 HL7
  Message                    Message                            Message
  Message Header             Message Header (e.g. SOAP          Transmission Wrapper
                             Header)                            Behavioral Contract
                                                                Wrapper

  3.2 Step by Step Comparison
  We will now walk through the process (not in excruciating detail) and discuss similarities
  and differences at each stage.

  3.2.1 Business Domain Analysis
  There has been a fair amount of discussion on Domain Analysis Models on various lists,
  and from a static model perspective, these are the only real “pure” business analysis
  deliverable in current HL7 methodology. From a Dynamic Model perspective, the
  Storyboards provide Business Scenarios (or Business Use Cases) although still appear to
  sometimes make assumptions about system solutions and boundaries. Business Roles can
  be implied in the Storyboards, but are not normatively documented as far as I can see.
  Again, Business Events are implied in the Storyboards. From a SOA perspective, it is
  better to have a more explicit business model (business processes, business services,
  business events, business roles etc), however in my view these can be taken as “nice-to-
  haves” so I have documented them as non-normative artifacts in the model.
  At this stage, i.e. the business analysis level, there should be no difference between SOA
  and messaging since no solution assumptions are made.
  A valid question that can also be asked is how much of this is the purview of Standards
  vs individual organizations. It is not an easy call. Maybe some of the additional business
  level information included in IHE profiles results from this shortcoming?
  If nothing else, the one concept that it seems to make sense to solidify in terms of the
  standard is the concept of the “Business Service”. This does equate fairly closely in
  principle to the concept of “Application Role” but is more business oriented in general
  would be a far more coarse grain concept than most current examples. It is fairly close to
  some of the “Topics” in the current V3 ballot material. This would provide what I see as
  a missing structuring mechanism for the ballot material, since the Topic is not a
  normative concept (at least as I understand it). Another way of looking at it would be a
  more detailed level breakdown of something like the EHR Functional Model (maybe a
  good place to start?)
  From an implementation perspective, you also need to allow for a finer grained structural
  concept (in the case of SOA the actual Service you would specify and implement). In
  general, there is a “1 to few” relationship between Business Service and (implementable)
  Service.




Version 0.31                           Page 17                           Last Revision 3/2/2010
  3.2.2 Systems Analysis I
  Moving on the next stage, i.e. systems analysis, we first consider the activities above the
  join in the diagram, which can be viewed as architectural activities or higher level
  analysis, or simply the first main stage.
  Let us consider each of the four main activities identified: information analysis, definition
  of system scenarios, choreography and system capabilities.

  3.2.2.1 Information Analysis
  This is the creation of the detailed domain model for the scope in question. This is
  basically the DIM / D-MIM. There is no obvious difference in an SOA scenario.

  3.2.2.2 Define System Scenarios
  This applies system constraints to the business scenarios to arrive at system scenarios or
  use cases. The current V3 deliverables are again the Storyboard and Trigger Events. Most
  SOA methods would define Use Cases for this purpose. Even though the industry fails to
  agree on a standard format for use cases and they are mainly textual descriptions, it is
  suggested that Use Cases be used as an alternate format to Storyboards if they are not
  already.
  The idea of Trigger Events and their use in V3 Messaging highlights one potential
  difference in SOA. SOA deliberately sets out to allow for flexible, dynamic behavior in
  interactions. A Service Interface is defined to respond in a particular way (behavior) to a
  given operation invocation. The reason that the client wishes to cause the invocation is
  opaque, thus promoting de-coupling. The concept of separating process and the use of
  composition and orchestration allows for services to be used in ways that were not
  envisaged when they were designed. This does not invalidate the concept of the Trigger
  Event but lessens its importance as a run time concept.

  3.2.2.3 Define Choreography and System Capabilities
  These two activities are taken together due to their inter-dependence. Choreography
  covers the sequence of interactions for a given scenario, and the capabilities are the
  individual actors, interfaces and actions.
  V3 gives us Application Roles, Interactions and the newly proposed CPM for this
  purpose. The CPM is a valuable addition that starts to make the picture complete. The
  SOA equivalents are: Service, Interface, Operation (Capabilities) and an assortment of
  collaboration, sequence and activity diagrams for the choreography.
  V3 does appear to be missing a level, in that the Application Role seems to be serving
  multiple purposes, or at best is not allowing a very clear definition of behavioral
  constructs. I sense a general discomfort about Application Roles and what they are for in
  a lot of what I have seen. This is one case where I see no reason (other than history) for
  HL7 to invent its own terminology. For whatever reason, the methodology has also
  tended to lead to roles that are too fine grained. The over-emphasis on the Message as the
  focal point of analysis has tended to lead to a lack of reasonable structures for behavior.

Version 0.31                            Page 18                            Last Revision 3/2/2010
  The general Service – Interface – Operation structure is a very good and intuitive
  structuring mechanism, and I suggest that is should be applied across the board. I have
  used a more generic term, i.e. Action instead of Operation, since operation is a very
  “servicey” term. Even for a full messaging solution, defining the Service and Interface
  works perfectly well as behavioral structuring mechanisms and each message /
  interaction would become a xxx-handler action. This provides a very clear and easy place
  to define behavior (we will get to discussion of behavior below). This maybe a radical
  shift as opposed to what is there now, but I believe is possible if handled gradually. Using
  the more generic “Action” as suggested in the meta-model allows for either Interaction or
  Operation to be used as appropriate. The interaction as defined ties back to the trigger
  event, so there are additional semantics implied here, but this is where messages and
  SOA may differ to some degree as discussed above. I believe it would be better to define
  behavior based on some interface construct and then relate that to the various interactions
  that can be consumed rather than try to explicitly define the behavior of each Interaction
  separately which seems very duplicative.
  In the model the “Action Step” (as depicted in the expanded diagram) represents each
  individual part of an action, e.g. the sending of a message, the receipt of a message, the
  sending of the response or error or acknowledgment. Another element shown is the
  “Interaction Participant”. This is really just for completeness. In SOA, this is the Service
  Provider and Consumer. This would show up in the Choreographies is Swim lanes were
  used in the activity diagrams.

  3.2.3 Systems Analysis II
  Moving on the next part of systems analysis, we define the actual messages and the actual
  behavior of the actions.
  In V3, we have the CIM/LIM or HMD to define the message and description of the
  interaction (in terms of a sequence diagram and/or another use of the CPM?) as behavior
  description. We also have the run-time message instance level behavioral contract
  wrapper (control act etc.) to provide further direction.
  In SOA, we use pre-conditions, post-conditions, invariants and state diagrams for
  behavior, optionally backed up with sequence diagrams where needed. For the payload,
  normally a UML Class diagram would be produced (or in many cases going straight to
  XML Schema) for the inputs and outputs of each Operation. There is no generally agreed
  or explicit SOA construct for the business level message/event metadata. This would be
  treated as payload, although explicit SOAP headers could be used if the application is
  SOAP aware. SOA also formalizes the concept of the Interface Contract (or Service
  Specification).
  Another variance appears in the message level acknowledgement model defined in V3. In
  SOA, at the PIM level this would not really be a factor. At the PSM level, it becomes
  relevant. One issue I have is that the acknowledgment model defined in current HL7
  literature seems to be viewed as the requirement, when I believe it belongs firmly in the
  solution, and in the ITS part at that. I assume that the real requirement is reliable delivery
  either to the communications endpoint or the actual application, plus possibly non-
  repudiation of receipt. Having an instance level switch in the message to determine

Version 0.31                            Page 19                             Last Revision 3/2/2010
  behavior is a messaging solution. It is possible to do something similar for Services, but
  this is atypical. It would be more normal to define different operations so that the
  behavior is more deterministic at design time (obviously being cautious of combinatorial
  explosions if there are multiple variables or options). In web services, the WS-
  ReliableMessaging standard uses a sequence number control which manages this without
  specific acknowledgments for each message, although this is typically for
  communications reliability. A cheaper (in terms of resources) alternative would also be to
  rely on communications reliability and provide other mechanisms at the infrastructure
  level to deal with the reliability of communications between infrastructure and
  application. If non-repudiation is the requirement, then auditing can also be used. I do not
  believe that the standard should mandate the solution mechanism (i.e. the application
  acks).
  So following on from the discussion in the first part of Systems Analysis, each receiving
  and/or responding Action needs to have its behavior defined in terms of pre-conditions,
  post-conditions, invariants and where necessary internal choreography.
  Using a CIM/LIM approach is a reasonable for service message payloads, although again
  a normal UML could be used, particularly since the end goal at implementation time is
  really the XML Schema. As an aside, I think I understand but don‟t agree with the
  rationale for not defining normative XML Schemas. In “best practice” SOA web services,
  the XML Schema (together with operation name and technical binding) is the mechanism
  for interoperability, almost everything else is really optional / fluff.

  3.2.4 Technical/Implementation Design
  From a modeling perspective, the discussion is basically complete, but for completeness,
  we will also consider some implementation / technical design issues.
  The use of the actual message (XML) Schema is discussed above, and is also the center
  of some debate and discussion within the new-ITS work in the UK, so I‟ll say no more
  about it.
  SOA uses the concept of a formal implementation contract. Again, the boundary of
  standards vs implementation becomes difficult, but this basically translates down to the
  use of message headers (wrappers), policies and orchestration mechanisms.
  HL7 defines a Transmission Wrapper as part of the “Composite Message”. The
  equivalent in SOA (at least web services) are SOAP Headers. This should be an ITS
  specific item. The dynamic model should define the requirements (actual requirements,
  not solutions) and then in the case of SOA, let WS-I and others provide the solutions. For
  the messaging solution, the explicit Transmission Wrapper may be used. This should not
  be a requirement for web services, ebxml etc.
  This may be drilled down on further in later discussions or versions, but I wanted to get
  the earlier topics out for discussion first.




Version 0.31                            Page 20                           Last Revision 3/2/2010
  4 Conclusions
  4.1 Summary
  In terms of physical implementations, the discussion si really constrained to web services,
  SOAP/XML/WSDL. Other ITS may introduce other issues.
  Basically, whether SOA or Messaging, the end products are messages going back and
  forth, i.e. the same business information, although in some cases the granularity may be
  different.
  The main differences are:
   Methodology focus:
         SOA: Process -> Service/Interface -> Operation -> Message
         HL7: Storyboard -> Info Model -> Message -> Interaction -> App Role
         In SOA, the Service is the focal point and the center of things from a definitional
         perspective. In Messaging, the Message is the focal point.
   Documentation and Deployment Packaging
         SOA: Portfolio Plan / Service Domains, Business Process Model, Service
         Specification / Definition (Logical: Service, Interface, Operation, Message,
         Behavior, Semantics, Physical: QoS, Security etc.)
         HL7: Domain / Topic, Domain Models, Application Role, Trigger Events,
         Interactions, Messages
   Infrastructure differences:
         HL7: Per message instance vs SOA: Contract / policy based
         Headers: Transmission Wrapper vs SOAP headers
   Flexibility (Interoperability vs flexibility)
         The HL7 method appears to want to lock down scenarios (i.e. behavior on both
         sides of the interaction).
         SOA/Services is about defining one side and leaving the other flexible, enabling
         business agility.

  4.2 Recommendations
  Based on the above discussion, the basic summary recommendations are as follows:
  Business Domain Analysis:
  1) Provide a more complete and better packaged way of describing the business domain.
     Although non-normative, the use of Business Process, Business Roles, Business Events
     etc. would help.
  2) One thing I believe that should become normative is the concept of a “Business Service”
     (irrespective of whether SOA or Messaging is being used). This provides a more formal
Version 0.31                            Page 21                          Last Revision 3/2/2010
     mechanism for grouping things together and organizing things. Over the last few years
     as I have waded through V3 material, I do find it fairly unintuitive and difficult to
     navigate around. I believe that formalizing this concept would add value.
  Systems Analysis:
  3) If not already done, allow Use Cases as a means to define storyboards.
  4) Recognize the “Service” and “Interface” as first class modeling constructs, again
     irrespective of SOA or messaging. Deprecate (over time) the use of Application Roles.
  5) Use Activity Diagrams for “Macro Choreographies”, basically as described for CPMs on
     the Wiki.
  6) Define an explicit behavior construct, i.e. the Action (or some other name) that allows
     for defining behavior explicitly and normatively. (see discussion above). Use pre-
     conditions, post-conditions etc and sequence/activity diagrams as appropriate for more
     complex behavior as appropriate.
  7) Formalize the Interface Contract. Maybe do a lightweight version of the HSSP SFM for
     messaging scenarios as well to package things better and make the standard more
     accessible.
  8) Define an explicit “HL7 XML Messaging” ITS and move several concepts into it,
     namely:
      The acknowledgment model solution (as opposed to requirements)
      Trigger Events as a run time mechanism (or make them optional in the behavioral
       contract wrapper if they are not)
      Transmission Wrapper
  9) Use the new Behavioral Contract Wrapper construct as being described on the Wiki (I
     need to review this again, but on first take it looks like it would work across the board)
  10) I can live with what is being proposed (the SIM/CIM/LIM etc) for the information
      model across the board but I believe that we should define normative XML Schemas. I
      am sure this has been argued before. I also would strongly prefer allowing a more
      normal UML representation of the information models. I know there are issues with this
      and also tooling too.
  Technical/Implementation Design
  11) Use an ITS specific of a formal implementation contract to match the implementation
      contract. For web services, this is WSDL plus Policy declarations.
  12) Transmission Wrapper – see 8 above.




Version 0.31                            Page 22                            Last Revision 3/2/2010

				
DOCUMENT INFO