SOA-HL7_Scratchpad.doc - Welcome to Wikispaces - Free Wikis for ...

397 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
397
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA-HL7_Scratchpad.doc - Welcome to Wikispaces - Free Wikis for ...

  1. 1. HL7 Service Oriented Architecture Special Interest Group (SOA SIG) S E RV I C E O R I E N T E D ARCHITECTURE AND HL7 V3 Architecture Approach S C R A T C H PA D Version No. 0.1 Date: 5/6/2010 I
  2. 2. Document Version History Version Number Version Date Revised By Description 0.1 Alan Honey First draft (Kaiser Permanente) Contact Information: Please direct your comments and questions to: Alan Honey (Kaiser Permanente) Address: 4460 Hacienda Drive, Pleasanton, CA Office: 925/924-5054 Mobile: 925/324-3142 E-mail: Alan.P.Honey@kp.org II
  3. 3. TABLE OF CONTENTS 1 INTRODUCTION................................................................................................................................................4 1.1 PURPOSE OF DOCUMENT ..............................................................................................................................4 1.2 OVERALL GOALS.........................................................................................................................................4 2 PROBLEM STATEMENT.................................................................................................................................5 2.1 INTRODUCTION...........................................................................................................................................5 2.2 PROBLEM STATEMENT.................................................................................................................................5 2.2.1 Discussion...............................................................................................................................................5 3 PROPOSED SOLUTION....................................................................................................................................6 3.1 INTRODUCTION...........................................................................................................................................6 3.2 SOLUTION GOALS.......................................................................................................................................6 3.3 SOLUTION SCOPE........................................................................................................................................6 3.4 SOLUTION PROJECT PRINCIPLES.....................................................................................................................7 4 SOLUTION DETAILS........................................................................................................................................8 4.1 SCOPE OF STANDARDS.................................................................................................................................8 4.2 METHODOLOGY FOR DEFINING SERVICES..............................................................................................9 4.3 SOA FRAMEWORK...................................................................................................................................10 4.3.1 SOA Principles.....................................................................................................................................10 4.4 MAPPING WS-* TO V3.............................................................................................................................10 5 APPENDIX A – EXAMPLE ENTERPRISE FRAMEWORK FOR SOA..................................................13 5.1 INTRODUCTION.........................................................................................................................................13 5.2 THE SOA REFERENCE MODEL...................................................................................................................13 5.3 CONCEPTS - DEFINITIONS AND ONTOLOGY.....................................................................................................14 5.4 CONCEPTS – META DATA...........................................................................................................................15 5.5 CONCEPTS - SERVICE DOMAINS ..................................................................................................................16 5.6 REFERENCE MODEL VIEWS.........................................................................................................................17 5.7 BUSINESS ARCHITECTURE...........................................................................................................................19 5.8 APPLICATION ARCHITECTURE......................................................................................................................19 5.9 TECHNOLOGY...........................................................................................................................................20 5.10 ZACHMAN-STYLE FRAMEWORK FOR SOA....................................................................................................20 5.11 CONCLUSIONS........................................................................................................................................23 III
  4. 4. 1 INTRODUCTION 1.1 PURPOSE OF DOCUMENT This document is intended purely as a “scratchpad”, i.e. a place to record fledgling ideas being raised during the “SOA for HL7” work under the HSSP Infrastructure Workgroup. It is NOT intended that this document will be published in its current form, although some of the content may end up in the final deliverable. 1.2 OVERALL GOALS The purpose of this effort is to describe an approach for implementing healthcare services within a Service Oriented Architecture, initially and primarily based on HL7 V3 information content. This should demonstrate how SOA and HL7 V3 can fit together without losing the major benefits of either. Background, Rationale, Outline plan etc. are all available in introductory Powerpoint decks on the HSSP Wiki, at: http://hssp-infrastructure.wikispaces.com/ and the “SOA for HL7” link. Some of the material from the referenced slide decks is included here, mainly to provide a foundation for some of the relevant sections. The current plan is to produce an “informal” deliverable or set of deliverables (white papers etc) that describe the proposed solution and present to the Infrastructure and Messaging (INM) TC within HL7. Once the overall approach has general agreement, this would be re-cast into the appropriate “formal” deliverables, an “ITS” or other mechanism. 4
  5. 5. 2 PROBLEM STATEMENT 2.1 INTRODUCTION The purpose of this section is to identify the business problem that this document is trying to address, i.e.  Why HL7 V3 Messaging alone is not enough  The need to maximize benefits of SOA 2.2 PROBLEM STATEMENT There exists a tension between creating an overall enterprise SOA (with cross-industry standard development tooling and infrastructure) where HL7 V3 is just one content type amongst others (X.12, NCPDP, Custom, etc) vs the need for HL7 to fully define an operating model for those using less complete frameworks such as basic MLLP messaging. This translates to issues of methodology and to the use of the various wrapper layers around HL7 content and the level of overlap between their functionality and that of advanced general technology frameworks such as Web Services and ebXML. 2.2.1 DISCUSSION SOA is not just about web services. SOA does not even actually "require" web services. However, web services are the technology that is being used to deliver it today by most organizations attempting to implement SOA and this will continue for the foreseeable future. Specifically SOAP, WSDL and XML (some would add UDDI, others demand HTTP only but realistically this could be SMTP, JMS, MQ or whatever). With this in mind, many organizations (such as Kaiser) are trying to introduce and use standard run time infrastructure, common development and deployment tooling and common specification artifacts, irrespective of the nature of the message content (i.e. HL7 or others). This is looking at things from an overall SOA perspective (and yes specifically a web services perspective) with HL7 as "just a content type" rather than a viewpoint of sending HL7 messages which happen to be using SOA (or web services) as a transport mechanism. Even V2 content can be another type (XML or otherwise) Some questions that need to be answered are (within a SOA context):  How far should HL7 go?  What should be covered by “general” industry standards ?  How much should be left to organizations?  How should the healthcare specific and general IT standards work together, without creating too much dependency or coupling between them ?  How do we specify enough to ensure interoperability and no more?  SOA is about enabling dynamic business change, and efficiently and cost effectively. How do we achieve this and still maximize value from existing HL7 work? 5
  6. 6. 3 PROPOSED SOLUTION 3.1 INTRODUCTION The purpose of this section is to outline a proposed solution to address the business problem identified in the previous section. Section 4 contains a more detailed drilldown in specific areas. Ideally structure the solution in an MDA style – i.e. generic (platform independent), then consider specific XML, SOAP, WS-* etc, leave placeholders for other alternatives, e.g. ebXML. 3.2 SOLUTION GOALS 1) Define an SOA Framework/Approach to enable services to be consistently identified, described and used in healthcare environments. 2) Provide a consistent technical context for HSSP RFP submissions. 3) Offer a consistent way to define and implement Services for HL7 V3 (and other healthcare?) content. 4) Define a “generic” SOA approach that is not tied to specific technology (if possible) and then specialize to specific stacks, e.g. WS-*. 5) 3.3 SOLUTION SCOPE The following is taken from the AH powerpoint deck on the Wiki:  An architecture describing how HL7 V3 content would be consumed and produced by Services  Covers transmission and transport issues  Consider role of: Current XML ITS, Control/Query infrastructure, Transmission wrappers  Approach will define generic SOA architecture and then specific technologies (e.g. XML, SOAP, WSDL and WS-* initially, subsequent versions may consider ebXML, REST etc.)  A mapping of current V3 artifacts to SOA  This should provide at least rules for deriving or transforming from SOA elements (contract or headers) to (at least) mandatory HL7 Wrapper items  Identification of those elements that should be left to other protocol and technology standards and any constraints that should be imposed on those elements (probably in the form of requirements)  Outline methodology for creating service implementations, including approaches to conformance and profiling 6
  7. 7. 3.4 SOLUTION PROJECT PRINCIPLES Key principles for the project: 1) Reuse appropriately, do not re-invent In particular, refer to / consider the following sources:  SOA Reference Model (OASIS) – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm  Web Services Architecture (W3C) – http://www.w3.org/2002/ws/arch/  WS-* various – OASIS, W3C, others tbd 2) Follow standards and practices defined by those with most expertise in any specific domain (vertical or horizontal). 3) Enable adherence to evolving cross domain / cross industry standards with minimum HL7 specific change. 4) Keep it simple as possible (apply 80/20) 5) Define the minimum that is necessary 6) Be practical – the services need to be implemented and used as cost-effectively and efficiently as possible. 7) Meet minimum HL7 interoperability requirements (be transformable to MCCI) 7
  8. 8. 4 SOLUTION DETAILS 4.1 SCOPE OF STANDARDS Here we need to cover how different standards should interoperate and overlap etc. The material below cut directly from initial slide deck. Proposed Rule - Infrastructure not specific to HL7 should not be defined by HL7 HL7 Specific General (not HL7 specific) Business Logic/Information In Scope In Scope Infrastructure In Scope Out of Scope Examples - Message Correlation, Reliable delivery, routing to system instances and security should be out of scope HL7 Specific General (not HL7 specific) Business Logic/Information Lab Order Content Routing message to a specific Pharmacy location Infrastructure OID usage? Routing to a specific system instance. Correlating message pairs. Security Scenario – A physician orders a Prescription and indicates it should be filled at a specific Pharmacy location (this is business content and in HL7 scope). The SOA infrastructure will determine that the specific pharmacy is served by a specific system instance. This is a “middleware” function not an application one, so if the mapping changes, it can be carried out once, not in every sending application, also the same logic may be needed for other content types not covered by HL7, e.g. DICOM, NCPDP SOA to V3 Mapping – Most or all of Transmission Wrapper and possibly some of Control Act is really unnecessary in SOA V3 Mapping HL7 Specific General (not HL7 specific) Business Logic/Information Most of payload (Most of) Control Act Some payload Infrastructure Not sure? (Most/all of?) Transmission Wrapper Some of Control Act 8
  9. 9. The above is just a start. We need to consider how vertical standards (such as HL7 V3) and cross industry standards can play together in the best way. How detailed do we get? – A good topic for discussion! 4.2 METHODOLOGY FOR DEFINING SERVICES HSSP will define some service standards. It would be valuable to have a standard approach where HSSP has not defined an explicit standard, e.g. within an SOA framework that enables  Use of HL7 V3 content in a consistent way (this is not just a “transport” profile – maybe an ITS or something else)  Service definitions to be driven from business service requirements, not always directly from message descriptions  Uses standard (web services) tooling I believe that we can do SOA and make appropriate use of some of the excellent work done in MCCI and related areas. But SOA is NOT messaging – the development process and infrastructure are different. One potential mapping is:  Service = Collection of related Application Roles  Interface = Application Role (usually)  Operation = Interaction  Operation input/output = message content or message content part (note the latter option, not necessarily tied to granularity of specific HL7 message)  Process Orchestration handles some of dynamics / interaction  Interaction Contract handles some of the Transmission concepts The use of the emerging HSSP conformance and profiling mechanisms could also help in the overall solution. Question – Should we define just one? Maybe several options, but this may lead to confusion. My aim is to provide some guidance to healthcare software vendors, who currently will just go their own way, and interop will be harder / more costly. 9
  10. 10. 4.3 SOA FRAMEWORK 4.3.1 SOA PRINCIPLES Some examples:  Enable dynamic behavior / agility for organizations (e.g. allow for unforeseen dynamic intermediary actions)  Maintain Separation of concerns (keep layers separate – e.g. business logic, business process logic, syntax and format of messages, technology platforms). Technology platform and business logic (semantics) should be able to change independently without unduly impacting the other.  Well defined contract of interaction – explicitly defines information and behavior model and quality of service  Explicitly defines behavior, information, security and quality of service policies (client should not require additional knowledge of the service implementation)  Wherever possible should use strong typing at the interface level  Automated system management can manage to SLAs against the contract  For Web Services, WSDL provides a machine-readable form of SOME of this (although WSDL 2.0 may extend the coverage)  Often structured into separate parts for logical (information and behavior) and physical (transport bindings and location)  Coarse-Grained Services - Services should be coarse-grained to reduce network traffic and to more closely align with the business processes which they serve.  Loose Coupling  Separate interface from implementation. Interactions are based on the interface definition only and not technology or structure of the service implementation.  Minimize Coding - Drive processing decisions by automated reference to explicit policies and metadata rather than in-line application coding.  Advertise and discover services using standards-based service registries.  Use a model driven approach 4.4 MAPPING WS-* TO V3 Although many of the details discussed in this deck have not yet been fully thought through, some initial analysis has been carried out. 10
  11. 11. A summary is given here of how a SOA infrastructure (specifically Web Services) may provide the same functionality as some of the HL7 Transmission items. Only the “message” class itself is covered here, but it is believed that analysis of “device” and others would yield similar results. Batch considerations have also not yet been addressed in this section (may or may not be relevant). At this stage, this is NOT intended to be definitive, just to identify possible options. In some cases, there may be several different ways of achieving the same purpose within SOA. Message Class - Mandatory Items: Transmission SOA Comments Wrapper Item Message ID WS-Addressing message id WS-Addressing message id is globally unique other than re-transmission Creation time WS-Security Timestamp Interaction ID Probably map directly to Operation Processing Code Not needed May be an issue in messaging paradigm. This is a function of the environment, not service call level Processing Mode Not needed May be an issue in messaging paradigm. Code This is a function of the environment, not service call level Accept Ack Code Inherent in operation or This is rarely (ever?) an instance level controlled by process selection, i.e. should be at contract level choreography Message Class - Optional Items: Transmission SOA Comments Wrapper Item Security Text WS-Security and associated This is unspecified in current HL7 specifications documentation Version Code Service Version Implied by version of service. Profile ID Inherent in Operation definition Usage unclear. Should be inherent in operation behavior definition. Sequence Number WS-ReliableMessaging Sequence Need to clarify usage and intent Number Attachment Text SOAP Attachment 11
  12. 12. 12
  13. 13. 5 APPENDIX A – EXAMPLE ENTERPRISE FRAMEWORK FOR SOA The purpose of this section is SOLELY to give an example of one view of a SOA Framework. This one is from CBDI Forum. PLEASE DO NOT SHARE BEYOND THE GROUP. Not sure what copyright is. Kaiser has a corporate subscription, but now sure how it extends beyond. There is also the OASIS SOA Reference Model and W3C Web Services Architecture, both of which are public domain and are available on the HSSP Wiki. THIS SECTION IS REPRODUCED IN ENTIRITY FROM A CBDI FORUM REPORT entitled: “The Enterprise Framework for SOA” PUBLISHED IM MARCH 2005 The enterprise architecture framework is widely used as a mechanism to manage the development and evolution of architectures. In this article we introduce a generic approach to integrating the SOA framework requirements with existing frameworks. 5.1 INTRODUCTION Conventional enterprise architecture describes an information system in terms of structural properties of the system. The architecture identifies components, building blocks, standards, policies and products which form the basis for planning and guiding systems delivery. Not surprisingly SOA introduces change to the structural properties. There are new and different building blocks, standards etc. These don’t necessarily replace the existing properties, mostly they complement and extend. However there are also areas where fundamental differences apply, for example in areas such as scoping and applicability, security models, reuse policies and so on, and we need a delta framework that combines the old and new in a cohesive whole. In this article we will provide an introduction to the SOA Framework and point out areas where differences exist, and anticipate this will provide a useful guide for architects to update their existing framework. 5.2 THE SOA REFERENCE MODEL We first introduced the concept of the SOA Reference Model in March 20041. The Reference Model shown in Figure 1 is a foundational component of the architectural framework that provides a constant frame of reference – providing definitions of relevant concepts, models, patterns and processes. In addition to concepts, process and patterns the reference model should map models/deliverables onto commonly used architecture views such as business, application and technology. While it might be a great way to spend a few months discussing and developing a custom model, the basic elements of the Reference Model will almost certainly be acquired from an external source such as CBDI. However the model will inevitably require customizing so that it is specific to the organization or entity. 13
  14. 14. Figure 1 – The Reference Model 5.3 CONCEPTS - DEFINITIONS AND ONTOLOGY It’s a good idea to have consensus on exactly what is a service. We won’t attempt to repeat the technical aspects of service definition here, but refer you to prior reports on the topic2. However it is equally important to have clarity on different types of service. In Figure 2 we suggest there are several quite discrete classes of service that will have varying characteristics requiring standardization. We first introduced this concept in May 20033 with examples of business service ontology. In Figure 2 we generalize and extend this to cover infrastructure services. In the architecture framework the classes of service establish layers that have the effect of increasing reusability and shareability as you go down the layers. They may, but not always encapsulate the lower layers and contain change within a layer. Some enterprise may choose to omit some layers. Some may choose to subdivide our suggested layers into further layers. The layers we suggest are starting point for the Architects/Planners. However we do caution against getting carried away with the concept and introducing more compulsory layers - in general, the fewer operations called to satisfy some business need, the better the response time. So fewer layers are better. 14
  15. 15. Figure 2 – Service Ontology 5.4 CONCEPTS – META DATA We discussed that SOA is essentially an overlay to existing architecture frameworks, and the reader who concludes this means extra complexity will not be wrong. The major platform providers such as IBM and Microsoft, as well as the myriad smaller service oriented vendors are making serious efforts to increase the levels of automation in the development and runtime tools and platforms. One of the prime areas of investment is the imminent delivery of comprehensive meta models and metadata supporting the entire life cycle. For example SDM from Microsoft and EMF from IBM/Eclipse. This very significant change in the platform capability will allow common views right across the life cycle eventually enabling much tighter collaboration (not necessarily integration) between conventional phases such as development and deployment. But equally it will facilitate a life cycle view of service (and other asset types of course) that is intended to allow direct traceability between the business perspective and the deployed physical assets. In Figure 3 we illustrate how the business view – the service, can now be directly linked to each layer of the architecture – business, application and technology, and artifacts that are conventionally held in separate repositories for these very separate three functional domains can now be seen as a single set of relationships. It would seem to make sense to arrange at least one view of the architectural framework such that for a given service type, the related architectural decisions can be easily managed. 15
  16. 16. Figure 3 – Service Meta Model 5.5 CONCEPTS - SERVICE DOMAINS In the early stages of SOA rollout services will be focused primarily on implementing a better form of application integration. But the objective of the SOA in the medium, longer term is to introduce service based interfaces throughout all architecture layers, such that all significant operations, technical and business are offered and consumed using service interfaces. This includes not just lose coupled interfaces, but also what today would generally be implemented as tight coupled interfaces. This will require layer specific service definitions including models, standards compliance and profiles. In Figure 4 we suggest a simple approach using service domains, where domain specific definitions are developed as required. This approach can be usefully extended for domain instances, for example to support: • A business entity’s involvement in several federated ecosystems, where use of specific profiles and industry standards and conventions may be required. 16
  17. 17. • Varying conventions for standard and profile implementations, for example varying divisional policies relating to security/trust standards • Platform specific behaviors for tightly coupled component services Figure 4 – Service Domains 5.6 REFERENCE MODEL VIEWS If you model your framework on widely used models such as Zachman4 or TOGAF5 , or you rolled your own, you will be familiar with the idea of layered architecture. Typically this is going to include Business, Application, Technology, or better still Conceptual, Logical and Physical. One of the aspects of Zachman that we like a lot is the Scope or Contextual View and in the SOA this becomes absolutely crucial. 17
  18. 18. As has been well rehearsed at this stage, the SOA is all about trusted, contract based units of capability that can be used in many different contexts, hence delivering genuine adaptability at business and technology levels. The prime issue for the enterprise architect therefore is to provide some guidance for how these units of capability might be used, and to establish a system for making architectural and policy decisions that make this possible without having to redevelop the individual service capabilities or infrastructure every time. In Figure 5 we make a rather simple, but incredibly important suggestion that what’s needed is three dimensional matrix that allows the detailing of the conventional architecture layers to be extended to cover potentially many situations. We envisage a straightforward system of policy and decision inheritance which allows the architect to tick applicability to appropriate service domains, say on a spreadsheet, or better still in the metadata driven repository. In the diagram we show generic domains, but in an enterprise architecture these domains will be specific instances of geographies, product groups, supply chains, divisions, enterprise applications and technical platforms. Figure 5 – Architecture Coordination 18
  19. 19. 5.7 BUSINESS ARCHITECTURE CBDI has developed the concept of the Business Service Bus as a logical architecture for business and technical services. The principle of the bus is that policies are established for sets of services that guide the management (investment, collaborations, use and reuse) and the design (semantics, schemas, rules, generalized behaviors) that ensure overall business objectives are not sub-optimized by project constrained objectives. The decoration of the bus with policy decision attributes is a primary SOA deliverable at the conceptual level, and in Figure 6 we show how the architecture coordination is used to document policy/governance decisions. Figure 6 – Business Service Bus 5.8 APPLICATION ARCHITECTURE We have already commented that in the short term services will be adopted primarily as a better form of application integration. Consequently the requirement for architectural change is low. But in the CBDI Maturity Model and Roadmap6 we show how a reengineering phase inevitably follows the integration phase. • The formal identification of a service operational layer that exposes all significant functional capabilities regardless of whether tight or loose coupled. • A strong motivation to create component architectures that mirror the service architecture, and cluster assets and resources in integrity units that have greater internal cohesion and independence. 19
  20. 20. 5.9 TECHNOLOGY Ultimately the Business Services and other elements of the SOA will be deployed to the same technology infrastructure as any other existing applications. As explained in our earlier report on Enterprise Service Bus7, we believe it is also important to think about the technology layer itself as a set of Infrastructure Services, as illustrated in Figure 7. Moving forward, as the platforms and middleware themselves become more service-based this is not just a logical concept but a run-time implementation too. Figure 7 – Enterprise Service Bus 5.10 ZACHMAN-STYLE FRAMEWORK FOR SOA Table 1 shows a Zachman-style Framework for SOA. In this we have focused on the primary extensions to enterprise architecture that will be necessary or useful when delivering an SOA. The What column is separated into Service and Data. The key delta is the focus on identifying Services at each layer, whilst the emphasis in data is now on the documents, messages and their schema rather than entities and tables. The How column is divided into Process, Components and Policies. The process column looks at Service from a process perspective; for example how a business process transforms a set of input to output services (a Service Transformation Model). The Component Architecture identifies the key business and software components, and maps the Services they provide and consume. Finally we believe it is important to separate the policies that govern process execution and the use of Services so that organizations are encouraged to manage these externally to any application. As mentioned earlier Scope is based on a domain perspective as shown in Figures 4 and 5. 20
  21. 21. What How Where Who When Why Service Data Process Components Policies Network Participants Events Motivation Scope Set of Services List of things List of List of things of List of policies List of locations List of participants List of events List of Goals and (contextual) of interest to the of interest to processes interest to the that govern the within the within the domain significant to the Objectives for the domain the domain performed in the domain domain domain domain domain domain Business Business Service Service Business Service Policy Service Service Ownership Information Business Plan (conceptual) Service Information Dependency Component Model Context Model Currency SOA Roadmap Architecture Model. Model. Model Model. Semantic Service Business rules Model Transformation and alerts Model Examples Business Documents Business Business Business Location. Partners. Business events. Service and of key Products, Messages Process Component Governance. Business Customers. Business Calendar Component Based elements Business Ontology Workflow Regulatory. Intermediary. Internal Business Business. Services. Contracts Business Organizational Transaction Business Agility. Service=service Directory Units. Business offered by the Government and virtualization business. regulatory bodies Application Logical Service Schema. Composite Service Business Service Federated Identity Information SOA Roadmap (logical) Architecture. Meta model Application Component Service Bus. deployment Model. Currency Model. System Architecture. Architecture. Service Policy model. Rules and alerts Dynamics Model Model. Service Information Model Examples Business Message Application Service Business Endpoints. Providers Service Requests System Agility. of key Service. Schema Orchestration. Automation Unit. Service Bus. Message. Consumers Service and elements Utility Service. Service Process Security. Service Endpoints Component Reuse Software Behavior Automation Unit QoS/SLA. Intermediary. and Replacement. Service. Usage Service Service and Service=service Contracts. Directory. software offered by a Compliance Message Provisioning Service services behavior. automation unit specification. Queuing topology Technology Service profiles. Data Process Component Versioning. Mapping to Service Security Service distribution integration Deployment Certification Technology Model (physical) application architecture. Architecture. Architecture architecture. and Datacenter diagrams. Examples Run-Time Message. Orchestration Executable Compliance Endpoints. Server Service Requests Deployment Agility. of key Service. Database Engine. service connection. Clients Resource elements Service=API or ESB Middleware implementation Router/Broker Virtualization 21
  22. 22. Agent - e.g. Business Directory and Provisioning Web Services activity Transport monitors. Deployment Enterprise environment Service Bus. Infrastructure Service Bus Detailed WSDL contracts Schema BPEL WS-Policy UDDI Directory Authentication Representa UDDI tModel WS-SLA WS- Services. tions Addressing SAML WS-Security (e.g. Example WS Protocols) Table 1 - Reference Views using Zachman Framework Concepts In Table 1 we have also populated each cell in the matrix with a few examples of the key elements you might expect to find in an SOA which is also illustrated for the Application/Logical layer in Figure 8 which shows how we might also build relationships between elements in the Service, Component, and Technology Architectures. 22
  23. 23. Figure 8 – Key Elements in the Logical Architecture 5.11 CONCLUSIONS Existing architecture frameworks will need to evolve rapidly to support service oriented concepts and views. While the service concept has been used loosely in many technology architectures such as CORBA, DCE etc for some years, the approach to date has been technology driven. The primary change that frameworks have to make is to bring the service construct into all three layers, conceptual, logical and physical in a coordinated manner. 1. The SOA Reference Model, John Cheesman and Georgios Ntinolazos 2. Understanding SOA 23
  24. 24. 3. Service Oriented Architecture – The Federation 4. Zachman Institute for Framework Advancement (ZIFA) 5. Open Group Architecture Framework – TOGAF 8: Enterprise Edition 6. CBDI Roadmap Maturity Model 7. CBDI Report: Time to Board the Enterprise Service Bus. 24

×