Cross-Enterprise Service Bus (XSB) Proposal

1. Proposed Profile: Cross-Enterprise Service Bus (XSB)

• Proposal Editor: Don Jorgenson
• Profile Editor: Don Jorgenson, ...
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: ITI

Summary

The proposed Cross-Enterprise Service Bus (XSB) profile is intended to address the need for a message-based infrastructure or framework, compatible with Web Services, that is constrained to meet the security, privacy and interoperability requirements of healthcare documents/messages in transit.

HL7 WS*, WS-Security, WS-Addressing and related WS-* specifications, when appropriately constrained and applied, can meet the confidentiality and integrity requirements for IHE transactions. SOAP message headers can transport user identity, user role, user credentials and other relevent information that will facilitate both audit and access control decisions.

The proposed XSB addresses several outstanding issues identified in ATNA, XUA and Appendix V.

The XSB could provide the constrained, real world technical specification anticipated by certain HL7-SOA Privacy, Access and Security Services (PASS) functional models.

An XSB is not an Enterprise Service Bus nor is it an SOA implementation.

2. The Problem

For the message-oriented Web Services environment, there is a need to profile security and privacy functionality similar to that provided by ATNA for connection-oriented, point-to-point environments.

The WS-I Basic Security Profile 1.0 provides this guidance: “Partners in a message exchange must agree which elements must be signed and/or encrypted and which elements may be signed and/or encrypted and which security tokens must be present and may be present.”

From the IHE supplement Web Services for IHE Transactions (ITI-V) : “IHE does not specify whether the Sender and Receiver should implement the HL7 WS Security Profile. The decision to implement the HL7 WS Security Profile is left to implementers. Each IHE transaction specifies its ATNA requirements for security and authentication. Currently this is the method to meet security requirements identified by IHE. With the publication of WS-Security 1.1 and when the WS-I Basic Security Profile 1.1 is released, it is expected that ATNA (or a different profile) may incorporate additional options for Web Services, and the HL7 WS Security Profile will be incorporated in this appendix.”

3. Key Use Case

Web Services for IHE Transactions (ITI-V) provides “the guidelines for specifying the use of SOAP-based Web Services as the messaging infrastructure and transport mechanism for IHE transactions.”

XSB would specify a consistent set of security and privacy capabilities, compatible with Web Services, that supports use cases across a number of IHE profiles.

4. Standards & Systems

There are Web Service stacks available for all major platforms. In addition to basic SOAP processors, they often include implementations of key WS-* processors such as WS-Addressing, WS-Security, WS-Trust and WS-ReliableMessaging.

Companies with commercial offerings include:

• IBM
• BEA
• Oracle
• Microsoft

Organizations with open source offerings include:

• Apache
• Eclipse
• Sun

XSB uses, extends or constrains:

• ATNA
• XUA
• Web Services for IHE (ITI-V)
• SAML
• HL7-SOA PASS
• WS-Addressing
• WS-Security
• WS-Trust
• WS-Federation

XSB supports or enables:

• XCA
• XDS.b
• XACML-based Policy Engines

5. Technical Approach

Existing actors

• X-Service User
• X-Service Provider
• Secure Node
• Time Client

New actors

• Service Consumer Access Node
• Service Provider Access Node

Existing transactions

• ITI-20: Record Audit Event
• ITI-1: Maintain Time
• ITI-19: Node Authentication

New transactions (standards used)

• ITI-xx: Deliver Transaction Message

Impact on existing integration profiles

It may be necessary to update several profiles, including ATNA, XUA and ITI-V.

The proposed XSB could be considered a message-based extension or supplement to the connection-based ATNA profile. It also provides additional context for XUA and addresses the security issues anticipated by Appendix V.

6. Support & Resources

Eclipse OHF

8. Open Issues

It will be necessary to determine the best way to capture the XSB specifications and constraints—whether through a new profile/supplement or updates to an existing profile, supplement or appendix.

The term “service bus” is widely used but not consistently defined. The Technical Committee should consider whether the proposed XSB should be renamed.

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA