XML Based Interoperability Components

1. XML Based Interoperability Components Dr Tom Buckman MITRE Corporation 8 December, 2000 Authors Dr Tom Buckman buckmant@mitre.org Ms Liz Zeisler ezeisler@mitre.org

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

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

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

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 RosettaNet Layers Network Layer Data Link Layer Physical Layer 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

7. Business Process and Information Models UML to XML Conversion ebXML metamodel XML content ebXML Functional Service View 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

8. A Closer Look AtPolicy 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

9. Building Blocks ForPolicy 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

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’