XML Based Interoperability Components Dr Tom Buckman MITRE
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 MITRE
Characterizing The Needs l An Illustration: ‘Dynamic’ Interoperability circa 1998 – The Balkans, programmers, laptops, backpacks – Timeframe for completion: Any time in the next 72 hrs! l 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 l The capability required – Flexible means to compose networks of applications l Needs are similar to the current challenges faced by e. Business communities – Distributed-applications, viewed as business/mission components that can be combined and composed in a run-time environment 9/17/2021 2 MITRE
Initiatives That Are Addressing The Needs l 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 – Rosetta. Net - networked software application components aimed at IT supply chain processes – eb. XML (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 Webbased business services 9/17/2021 3 MITRE
A Technology Perspective Of The Initiatives l eb. XML builds on work done by Rosetta. Net and OBITM l XML is the key enabling technology for these initiatives as well as for UDDI l eb. XML provides a framework – For creating interoperable business components – For constructing a run-time infrastructure for networking business components l Why all the fuss? – Business Components can be configured and networked at Run-Time! – Current use of components (EJB, Active. X) focuses on component configuration during implementation Business level Components provide A Fertile Ground for Policy Enabled Applications 9/17/2021 4 MITRE
An Architectural Perspective l The initiatives additional level of abstraction to the ISO/OSI Reference Model Application Action Layer Transaction Layer Application Layer Process Layer Service Layer Message Layer Transfer Layer Transport Presentation Layer Session Layer Security Layer Transport Layer Network Layer Rosetta. Net Layers Data Link Layer Physical Layer 9/17/2021 OSI Layers 5 MITRE
A New Approach To Enterprise Application Integration (EAI) l Components of the eb. XML solution – Business Processes – Core Business Components – Registry & Repository (R&R) – Transport Routing and Packaging (TR&P) l 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 l Policy and security considered in R&R and TR&P 9/17/2021 6 MITRE
eb. XML Functional Service View Business Process and Information Models TPP: Trading Partner Profile TPA: Trading Partner Agreement UML to XML Conversion eb. XML metamodel XML content Registration Registry Retrieval of profiles & new or updated eb. XML Models Registration TPP Internal Business App Build TPP Derives Business Service Interface Registry Service Interface Registration TPP Implementers Build Retrieval of profiles & new or updated eb. XML Models Shrink-wrapped App Trading Partner Agreement Payload Business Service Interface TPA Governs 9/17/2021 7 MITRE
A Closer Look At Policy Considerations l IBM has recently turned over its work on Trading Partner Agreement Markup Language (Tpa. ML) to the eb. XML initiative l Tpa. ML is an XML based specification that specifies a metadata for trade relationships. Examples of metadata – Business contact – Transport facilities – Message formats (OBITM, Rosettanet, eb. XML, Biz. Talk) – Security protocols (S 2 ML) – Message vocabularies l Use of an Executable Trading Partner Agreement demonstrated in the IBM Coyote Project in 1998 9/17/2021 8 MITRE
Building Blocks For Policy Driven Dynamic Interoperability l 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 l 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 9/17/2021 9 MITRE
Challenges l Development of core components and business process descriptions for specific domains – Areas least developed with eb. XML specification – Requires collaboration of domain experts and system analysts and engineers – Efforts are underway in commercial domains and the Department of Defense l Common, extensible, policy language l 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’ 9/17/2021 10 MITRE
- Slides: 10