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

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

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

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

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

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

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

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

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

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