HL7 Service Oriented ArchitectureSpecial Interest Group (SOA SIG)

SERVICE ORIENTED ARCHITECTURE AND HL7 V3

Architecture Approach

SCRATCHPAD

Version No. 0.1

Date: 4/10/2023

I

Document Version History

Version Number Version Date Revised By Description

0.1 Alan Honey (Kaiser Permanente)

First draft

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

Table of Contents

1 INTRODUCTION.................................................................................................................................... 4

1.1 PURPOSE OF DOCUMENT................................................................................................................... 41.2 OVERALL GOALS............................................................................................................................... 4

2 PROBLEM STATEMENT.................................................................................................................... 5

2.1 INTRODUCTION................................................................................................................................. 52.2 PROBLEM STATEMENT...................................................................................................................... 5

2.2.1 Discussion................................................................................................................................... 5

3 PROPOSED SOLUTION....................................................................................................................... 6

3.1 INTRODUCTION................................................................................................................................. 63.2 SOLUTION GOALS............................................................................................................................. 63.3 SOLUTION SCOPE.............................................................................................................................. 63.4 SOLUTION PRINCIPLES...................................................................................................................... 7

4 SOLUTION DETAILS........................................................................................................................... 8

4.1 SCOPE OF STANDARDS...................................................................................................................... 84.2 METHODOLOGY FOR DEFINING SERVICES...................................................................................94.3 SOA FRAMEWORK.......................................................................................................................... 10

4.3.1 SOA Principles.......................................................................................................................... 104.4 MAPPING WS-* TO V3................................................................................................................... 10

5 APPENDIX A – EXAMPLE ENTERPRISE FRAMEWORK FOR SOA..........................................13

5.1 INTRODUCTION............................................................................................................................... 135.2 THE SOA REFERENCE MODEL........................................................................................................135.3 CONCEPTS - DEFINITIONS AND ONTOLOGY......................................................................................145.4 CONCEPTS – META DATA................................................................................................................ 155.5 CONCEPTS - SERVICE DOMAINS.......................................................................................................165.6 REFERENCE MODEL VIEWS............................................................................................................. 175.7 BUSINESS ARCHITECTURE............................................................................................................... 195.8 APPLICATION ARCHITECTURE..........................................................................................................195.9 TECHNOLOGY................................................................................................................................. 205.10 ZACHMAN-STYLE FRAMEWORK FOR SOA........................................................................................205.11 Conclusions................................................................................................................................... 23

III

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

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 ?

5

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?

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)

7

Outline methodology for creating service implementations, including approaches to conformance and profiling

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)

8

9

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

10

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

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.

11

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.

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

12

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.

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 Wrapper Item

SOA Comments

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 Code

Not needed May be an issue in messaging paradigm. This is a function of

13

Transmission Wrapper Item

SOA Comments

the environment, not service call level

Accept Ack Code

Inherent in operation or controlled by process choreography

This is rarely (ever?) an instance level selection, i.e. should be at contract level

Message Class - Optional Items:

Transmission Wrapper Item

SOA Comments

Security Text WS-Security and associated specifications

This is unspecified in current HL7 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 Number

Need to clarify usage and intent

Attachment Text

SOAP Attachment

14

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.

15

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.

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.

16

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.

17

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.

18

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.

19

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

20

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.

21

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.

22

  What How Where Who When Why  Service Data Process Components Policies Network Participants Events MotivationScope(contextual)

Set of Services of interest to the domain

List of things of interest to the domain

List of processes performed in the domain

List of things of interest to the domain

List of policies that govern the domain

List of locations within the domain

List of participants within the domain

List of events significant to the domain

List of Goals and Objectives for the domain

Business(conceptual)

Business Service Architecture

Service Information Model.Semantic Model

Service Dependency Model.Service Transformation Model

Business Component Model

Service Policy Model

Service Context Model

Service Ownership Information CurrencyModel.Business rules and alerts

Business PlanSOA Roadmap

Examples of key elements

Business Products,Business Services.Service=service offered by the business.

DocumentsMessagesOntology

Business ProcessWorkflow

Business Component

Business Governance.Regulatory. Contracts

Location.Business Intermediary.Business Directory

Partners.Customers.Internal Organizational Units.Government and regulatory bodies

Business events.Business CalendarBusiness Transaction

Service and Component Based Business.Business Agility.Business virtualization

Application(logical)

Logical Service Architecture.System Dynamics ModelService Information Model

Schema.Meta model

Composite Application Architecture.

Service Component Architecture.

Business Service Bus.Service Policy Model.

Service deployment model.

Federated Identity Model.

Information Currency Model. Rules and alerts

SOA Roadmap

Examples of key elements

Business Service.Utility Service.Software Service.Service=service offered by a Service automation unit

MessageSchema

ApplicationOrchestration.Service Behavior

Service Automation Unit.Process Automation Unit

Business Service Bus.Security.QoS/SLA.Usage Contracts.Compliance services specification.

Endpoints.Message.Service Intermediary.Service Directory.Message behavior.Queuing topology

ProvidersConsumersEndpoints

Service Requests System Agility.Service and Component Reuse and Replacement.Service and software Provisioning

Technology

(physical)

Service profiles.Service application architecture.

Data distribution

Process integration architecture.

Component Deployment Architecture.

Versioning. Certification

Mapping to Technology Architecture and Datacenter diagrams.

Service Security Model

   

23

Examples of key elements

Run-Time Service.Service=API or Agent - e.g. Web Services

Message.Database

Orchestration Engine.ESB Middleware

Executable Compliance service implementationBusiness activity monitors.Enterprise Service Bus.Infrastructure Service Bus

Endpoints.connection.Router/Broker DirectoryTransportDeployment environment

ServerClients

Service Requests Deployment Agility.Resource Virtualization and Provisioning

Detailed Representations

(e.g. Example WS Protocols)

WSDL contractsUDDI tModel

Schema BPEL   WS-PolicyWS-SLA

UDDI DirectoryWS-Addressing

Authentication Services.SAMLWS-Security

   

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.

24

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

25

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.

26