XML Based Interoperability-Components

advertisement

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

 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

4/13/2020 a run-time environment

2

MITRE

Initiatives That Are

Addressing The Needs

 A number of initiatives are underway, which address aspects of the problem from a business perspective

– OBI TM (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 Webbased business services

4/13/2020 3

MITRE

A Technology Perspective

Of The Initiatives

 ebXML builds on work done by RosettaNet and OBI TM

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

4/13/2020 4

MITRE

An Architectural Perspective

 The initiatives add additional level of abstraction to the ISO/OSI Reference Model

Application Layer

Action Layer

Transaction Layer

Process Layer

Service Layer

Message Layer

Transfer Layer

Security Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

4/13/2020 5

MITRE

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

4/13/2020 6

MITRE

ebXML Functional Service View

TPP:

Trading Partner Profile

TPA:

Trading Partner Agreement

Business Process and Information Models

UML to XML Conversion ebXML metamodel XML content

Registration

Retrieval of profiles

& new or updated ebXML Models

Registration

TPP

Internal Business

App

Build

TPP Derives

Registry

Registry Service

Interface

Implementers

Trading Partner

Agreement

Business Service

Interface

Payload

Registration

Registration

Build

TPP

Retrieval of profiles

& new or updated ebXML Models

Shrink-wrapped

App

Business Service

Interface

TPA

Governs

4/13/2020 7

MITRE

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 (OBI TM , Rosettanet, ebXML, BizTalk)

– Security protocols (S2ML)

– Message vocabularies

Use of an Executable Trading Partner Agreement demonstrated in the IBM Coyote Project in 1998

4/13/2020 8

MITRE

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

4/13/2020 9

MITRE

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’

4/13/2020 10

MITRE

Download