XML Based Interoperability Components

1
XML Based Interoperability Components

• Dr Tom Buckman
• MITRE Corporation
• 8 December, 2000

Authors Dr Tom Buckman buckmant_at_mitre.org Ms Liz
Zeisler ezeisler_at_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 dont
  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 (RR)
• Transport Routing and Packaging (TRP)
• RR and TRP 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 RR and TRP

7
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