1. XML Based Interoperability Components
Dr Tom Buckman
MITRE Corporation
8 December, 2000
Authors
Dr Tom Buckman
Ms Liz Zeisler

2. Characterizing The Needs
An Illustration: ‘Dynamic’ Interoperability circa 1998
The Balkans, programmers, laptops, backpacks
Timeframe for completion: Any time in the next 72hrs!
The basic interoperability requirement
Be prepared to interoperate with? …. we are not sure who, we can only guess when and we don’t know where
The capability required
Flexible means to compose networks of applications
Needs are similar to the current challenges faced by eBusiness communities
Distributed-applications, viewed as business/mission components that can be combined and composed in a run-time environment
11/7/2018

3. Initiatives That Are Addressing The Needs
A number of initiatives are underway, which address aspects of the problem from a business perspective
OBITM (Open Buying on the Internet) - aimed at catalog services and ordering processes
RosettaNet - networked software application components aimed at IT supply chain processes
ebXML (electronic business XML) - sponsored by OASIS & UN/CEFACT aimed at providing EDI type services to the masses
UDDI (Universal Description, Discovery, and Integration) - aimed at implementing a naming, directory service and a method for invoking Web-based business services
11/7/2018

4. A Technology Perspective Of The Initiatives
ebXML builds on work done by RosettaNet and OBITM
XML is the key enabling technology for these initiatives as well as for UDDI
ebXML provides a framework
For creating interoperable business components
For constructing a run-time infrastructure for networking business components
Why all the fuss?
Business Components can be configured and networked at Run-Time!
Current use of components (EJB, ActiveX) focuses on component configuration during implementation
Business level Components provide A Fertile Ground for
Policy Enabled Applications
11/7/2018

5. An Architectural Perspective
The initiatives add additional level of abstraction to the ISO/OSI Reference Model
Action Layer
Application Layer
Transaction Layer
Process Layer
Application
Service Layer
Message Layer
Transfer Layer
Presentation Layer
Session Layer
Security Layer
Transport Layer
Transport
Network Layer
RosettaNet Layers
Data Link Layer
Physical Layer
11/7/2018
OSI Layers

6. A New Approach To Enterprise Application Integration (EAI)
Components of the ebXML solution
Business Processes
Core Business Components
Registry & Repository (R&R)
Transport Routing and Packaging (TR&P)
R&R and TR&P provide much of the functionality found in a Message Broker based approach to EAI
Repository services, Rules processing
Intelligent routing, Flow control
APIs, adapters
Directory services
Policy and security considered in R&R and TR&P
11/7/2018

7. ebXML Functional Service View
Business Process and Information Models
UML to XML Conversion
ebXML metamodel XML content
TPP:
Trading Partner Profile
TPA:
Trading Partner Agreement
Registration
Registration
Registry
Retrieval of profiles
& new or updated
ebXML Models
Registry Service
Interface
Retrieval of profiles
& new or updated
ebXML Models
Registration
Registration
TPP
TPP
Build
Build
Internal Business
App
Implementers
Shrink-wrapped
App
TPP Derives
Trading Partner
Agreement
Business Service
Interface
Business Service
Interface
Payload
TPA
Governs
11/7/2018

8. A Closer Look At Policy Considerations
IBM has recently turned over its work on Trading Partner Agreement Markup Language (TpaML) to the ebXML initiative
TpaML is an XML based specification that specifies a metadata for trade relationships. Examples of metadata
Business contact
Transport facilities
Message formats (OBITM, Rosettanet, ebXML, BizTalk)
Security protocols (S2ML)
Message vocabularies
Use of an Executable Trading Partner Agreement demonstrated in the IBM Coyote Project in 1998
11/7/2018

9. Building Blocks For Policy Driven Dynamic Interoperability
UML models allow precise specification of object behavior, collaboration, workflows, etc.
Can be documented using XML (example: XMI)
Description independent of any system or technology
Could be used to model Trading Partner Agreements
Precise enough to support automatic code generation
Enables use of simpler, more flexible component interfaces
XML standards and agreements key to providing an environment where business components can be combined and composed at run-time
XML allows key data, data structure and meaning to be provided at run-time independent of systems and technology used
11/7/2018

10. Challenges
Development of core components and business process descriptions for specific domains
Areas least developed with ebXML specification
Requires collaboration of domain experts and system analysts and engineers
Efforts are underway in commercial domains and the Department of Defense
Common, extensible, policy language
Automated generation and execution of policy based Trading Partner Agreements
Technical aspects of interoperability are being overcome
Policy issues are becoming more complex and dynamic, fast becoming the interoperability ‘bottleneck’
11/7/2018