Web Services, Business Process and Enterprise Simulation with MDA Collaboration Architecture A tutorial on applying Model Driven Architecture to web services using the OMG Enterprise Collaboration Architecture with UML

Primary author of “Component Collaboration Architecture” in EDOC Introductions Cory Casanave cory-c@enterprise-component.com www.enterprise-component.com Primary author of “Component Collaboration Architecture” in EDOC

It’s about Collaboration Collaboration is a key differentiation and key cost center (Healthcare Example) Customer Collaboration Claim processing Disputes Physician Collaboration Payer Collaboration Hospital Collaboration Broker Collaboration Government Collaboration Employee Collaboration Others... The system integrates multiple collaborations

Integrating Enterprises, People & Systems - Worldwide Business Requirements Virtual Enterprises Enterprise Integration (EAI) Supply-chain automation (B2B) Customer Integration (B2B) Web deployment (B2C) Internet Marketplace (B2C) Collaboration and Integration

Model What You Simulate & Perform Validation & Metrics Enterprise Models Process & Information Validation & Metrics Simulation Execution M&S World Management Information MDA World

Enterprise Components Enterprise Components must be independent and distributable While being able to interoperate with each other Making the information system or simulation a lattice of cooperating components Simulated or Real Same model, same architecture Standards Open Open Standards Open Standards

Web services provides open connectivity Web Services allow components to be independently implemented While interacting across well defined services Making the information system a lattice of cooperating components Simulated or Real Same model, same architecture Standards Open Other Middleware Web Services

An XML component architecture XML Components XML Component (Abstract) XML WS Port XML WS Port XML WS Port Simulation Implementation Execution Implementation Modeled Web services provide An XML component architecture Independent of protocol and platform For execution and simulation

Core Requirements Web Services Common Models Providing flexible connectivity between components implemented in a variety of technologies for both simulation and execution Web services provides for the connecting points between components Common Models Models of process, structure, roles, interactions, components and information representing the collaborative fabric of the enterprise driving both execution and simulation

The Marketplace Example Order Conformation Shipped Process Complete Mechanics Are Us Buyer Acme Industries Seller Status Ship Req Physical Delivery Shipped Delivered GetItThere Freight Shipper

Where are the services? Status Mechanics Are Us Acme Industries Buyer Order Web Service Conformation Web Service Shipped Mechanics Are Us Buyer Acme Industries Seller Web Service Status Web Service Ship Req Physical Delivery Shipped Web Service Delivered GetItThere Freight Shipper

Inside the Seller Event Order Processing Shipping Receivables Order Web Service Conformation Web Service Shipped Shipping Event Ship Req Receivables Shipped Delivered

Components collaborate in processes Identify a “community process”, the roles and interactions in a collaboration Models helps organize and define the set of services required for enterprise collaboration and simulation Protocol

Web services implement connections between components in roles Web Service Specification Service Port on the service Protocol Operation Message Schema Type

The new center The strategic core of you systems must be the enterprise its self Only technology independent business focused models will survive the transience of technology and lock-in These models can become part of your source code, driving enterprise applications and simulations Enabler: Model Driven Architecture (MDA) with EDOC-Enterprise Collaboration Architecture

Automated Model Driven Architecture Meta-Model UML Profile (E.G. ECA) Domain Model (PIM) Domain Architecture Manual Coding Enterprise Components Infrastructure Mapping (E.G. J2EE-WS) Tools Produce & Integrate C Minimize and structure manual implementation Framework & Infrastructure (E.G. -J2EE-WS) PSM Mapping is tuned to the infrastructure Technical Architecture

Automated Model Driven Architecture Meta-Model UML Profile (E.G. ECA) Domain Model (PIM) Multiple and Changing Technology Support Domain Architecture J2EE-WS Enterprise Components .NET-WS Enterprise Components C Infrastructure Mapping (E.G. J2EE-WS) Tools Produce & Integrate Infrastructure Mapping (E.G. .NET-WS) C C Framework & Infrastructure (E.G. -J2EE-WS) PSM Framework & Infrastructure (E.G. -.NET-WS) PSM Technical Architecture Mapping is tuned to the infrastructure Technical Architecture

Integration of Intellectual Capital UML Modeling Requirements Modeling Component Modeling Process Modeling Information Modeling MDA Platform Models define the system Intellectual Capital MOF J2EE Simulation .NET Integration of infrastructure

The Enterprise Collaboration Architecture ECA is a “profile of UML”, a way to use UML for a specific purpose - it is an OMG standard That purpose is modeling enterprise systems and components. You can also think of this as a “modeling framework” for enterprise computing ECA is part of the “Model Driven Architecture” (MDA) initiative of the OMG Using precise modeling techniques as part of the development lifecycle to speed development and provide technology independence ECA has been adopted by the OMG as part of the EDOC RFP. ECA defines an architecture and meta model

MDA Solution for Web Services Platform Independent Model Enterprise Collaboration Architecture Web Services For Enterprise Collaboration Standards Mapping Platform Dependent Model Web Services Stack Standards? Future Platform (J2EE, .NET…) Mapping Not standard

Tooling & Infrastructure Solution Triad Service Based Architecture Components Web Services Corba J2EE .NET Model Driven Development OMG ECA Development Process Tooling & Infrastructure Standards

Loose Coupling Loose coupling is the ability for independent parts of systems to be built and evolve independently Tightly coupled systems Prevent change (the next legacy system) Cause lock-in Become unmanageable Prevent reuse Quality architecture is essential for loose coupling

Architecture Goals Create a system from loosely coupled “enterprise components” that can evolve independently Provide well defined interfaces and interaction points between these enterprise components Make each enterprise component a reusable asset that can serve many business processes Build the information system as a community of interacting enterprise components Utilize open standards such as Web Services, EJB and Corba to integrate the enterprise components

“Wrapping” Legacy Applications and Data Enterprise Components are defined in terms of their external contract; implementation may use existing applications Can “call” existing application Can read and write legacy DBMS Can use “screen scraper” (Last resort) Legacy applications can appear as enterprise components but may not be implemented as components

Technology Independence Business Logic Component ebXml What the infrastructure vendors would have you do Business Logic Component .NET Business Logic Component RosetaNet Business Logic Component WebServ Adapters EJB Business Logic Component ebXml BizTalk Rosetanet CICS WebServ MQ Corba

Legacy “Wrapping” Wrapping allows existing programs and data to work with and work as enterprise components Adapters

Collaborations and Roles Conceptual Foundation Portions copied with permission of Trygve Reenskaug - Taskon OORAM (http://www.ifi.uio.no/~trygver)

History OORAM Enterprise UML Object Oriented Collaboration Role Analysis UML Collaborations Enterprise Collaboration Architecture Influence

The Connected Enterprise Content and Communication Digital Map Census Data Police Records House Drawings Aerial Photos Police Dispatcher Role

Multiple roles in a collaboration

Travel Expense Example Peter (Technical author) Bill (Dispatcher) Joyce (Sales clerk) Douglas (Marketing manager) Kim (Methodologist) Elsie (Programmer) Eve (Software Manager) (Bookkeeper) Joe (Paymaster) Adam (Chief Accountant) Ruth (President) John (Cashier) Ann (Customer consultant) 4: authorizedExpenseReport 1: travelPermissionRequest 2: travelPermission 3: expenseReport 5: paymentRequest We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties. In the collaboration, we study patterns of interacting objects: What are the objects, what are their responsibilities, and how do they collaborate to achieve the system functionality.

UML Collaboration Diagram Travel Expense Model Peter (Technical author) Bill (Dispatcher) Joyce (Sales clerk) Douglas (Marketing manager) Kim (Methodologist) Elsie (Programmer) Eve (Software Manager) (Bookkeeper) Joe (Paymaster) Adam (Chief Accountant) Ruth (President) John (Cashier) Ann (Customer consultant) / Authorizer / BookKeeper / Paymaster The classifierRole represents the object’s position in the structure and its responsibility for performing its part of the system function. / Traveler Objects --> ClassifierRoles

Collaboration Diagram

Synthesis – People, Organizations & Components play several roles ProjectManager ProjectParticipant ProjectParticipant ProjectManager Project responsible Dept. Manager Project manager Section manager Project participant Hat-stand modellen Hatte-holder modellen Jmf. kombinasjon av PL/prosj.medarbeider-rolle og linjeansvar. Jane 2

Roles to Systems Component in Role Role Collaboration Interaction Path (With Information) Role Collaboration Framework, Middleware & Container Implementation Net Hardware Operating System

Drilling down – inside a role The open domain should make no assumptions about the “inside” of a role. Inside one role you frequently find more collaborating “parts” of the enterprise - the same model may be used Until you get to system inside a managed domain Shared resources (DBMS) Common Management Frequently a legacy system Code Role Inner Role Inner Role Legacy DBMS

Standards for Global Internet Computing XML EDOC WSDL SOAP .NET BPML XML-Schema XLANG

Web Service Standards XML Schema & DTD WSDL Soap Description and packaging of data WSDL Specification a services, operations and flows available via a service Soap Basic messaging and packaging Extensions for Soap-RPC with WSDL

EDOC Component Collaboration Architecture The model of collaborative work CCA

Parts of a CCA Specification Structure of process components and protocols Process components, ports, protocols and documents Class Diagram or CCA Notation Composition of process components How components are used to specify components Collaboration diagram or CCA Notation Choreography Ordering of flows and protocols in and between process components Activity Diagram

A simple methodology for creating collaborative business processes ECA Methodology A simple methodology for creating collaborative business processes

Basic Steps Identify roles and organize roles into collaborations Define collaboration documents Create basic business transactions Organize into protocols and events Use protocols to define ports on roles Drill-down into role detail Implement roles Configure implementations for deployment with technology specifics Deploy

Identifying roles and collaborations

Identify Documents

Distinguish protocols and events

Create Business Transactions

Organize into protocols

Add ports to complete community process

Drill-down

Add implementation As component compositions In a programming language By using an external service Wrap legacy As a simulation

Add technology specifics for deployment

Web Services for Enterprise Collaboration In standards process WSEC Web Services for Enterprise Collaboration In standards process

Main Parts Distributed Component Profile Aspects How to define & structure distributed components Aspects How to augment a model for a technology Aspects defined for WSDL/Schema The augmentations required for Web Services Mapping Transformations between ECA and WSDL/Schema

Distributed Components Define “role” as the abstract contract Define “Engine” as exposing a set of DCs Define “Endpoint” as consuming a set of DCs Define “Proxy” as the use of an external role

Engine exposing a DC

Defining an external component resource

Using a proxy Endpoint

Aspects

Mapping of a WSDL Engine - <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xs2000="http://www.w3.org/1999/XMLSchema" xmlns:xs2001="http://www.w3.org/2001/XMLSchema" name="SellerServer" targetNamespace="urn:SellerServer" xmlns:tns="urn:SellerServer" xmlns:CoreTypes="urn:CoreTypes" xmlns:Ordering="urn:Ordering"> - <!-- definitions obtained from component /BuySell/Deployment/SellerServer Aspects WSDL WSDL-SOAP

Mapping of a DC Aspects WSDL WSDL-SOAP - <service name="MySeller"> - <!-- implemented service role /BuySell/Deployment/SellerServer/MySeller   -->   <documentation><p> </p></documentation> - <port name="BuySellProtocol" binding="tns:BuySellProtocol"> original service port was /BuySell/Deployment/SellerServer/MySeller/BuySellProtocol (extending Component </BuySell/SellerImplementation/MySeller/BuySellProtocol> )   -->   <soap:address location="http://localhost:8080/cx/app/BuySell/Deployment/SellerServer/MySeller/BuySellProtocol" />   </port>   </service> Aspects WSDL WSDL-SOAP

Mapping of a protocol binding - <binding name="BuySellProtocol" type="tns:BuySellProtocol">   <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" /> - <operation name="Order">   <soap:operation soapAction="urn:/BuySell/Community/BuySellProtocol/Order" style="rpc" /> - <input name="Order">   <soap:body use="encoded" namespace="urn:SellerServer" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> Aspects WSDL WSDL-SOAP

Mapping of a protocol Aspects WSDL WSDL-SOAP - <portType name="BuySellProtocol"> - <!-- original cx operation = /BuySell/Community/BuySellProtocol/Order   --> - <operation name="Order"> original cx flow port = /BuySell/Community/BuySellProtocol/Order/Order   -->   <input name="Order" message="tns:Order" />   <output name="OrderConfirmation" message="tns:OrderConfirmation" />   <fault name="OrderDenied" message="tns:OrderDenied" />   </operation>   </portType> Aspects WSDL WSDL-SOAP

Mapping of message types - - <message name="Order">   <part name="Order" type="Ordering:Order" /> <message name="OrderConfirmation">   <part name="OrderConfirmation" type="Ordering:OrderConfirmation" />   </message>   </message> - <message name="OrderDenied">   <part name="OrderDenied" type="Ordering:OrderDenied" />   </message> Aspects WSDL WSDL-SOAP

Mapping of data types - <xs2001:complexType name="Order"> - - <xs2001:sequence>   <xs2001:element minOccurs="1" maxOccurs="1" name="CompanyID" type="CoreTypes:CompanyID" />   <xs2001:element minOccurs="1" maxOccurs="1" name="OrderID" type="Ordering:OrderID" />   <xs2001:element minOccurs="0" maxOccurs="unbounded" name="Item" type="Ordering:Item" />   </xs2001:sequence>   </xs2001:complexType>                                  

Ways to map Generate code and other artifacts Usually required to adapt to legacy Emulates the manual process Assemble and configure existing generic and specific components Both efficient and dynamic Interpret or otherwise “animate” the high-level model High level & dynamic but may have performance issues Simulate Evaluate technical and business impact through simulation

MDA Automation Solution Automated Provisioning Test & Sim Artifacts Infrastructure Models Component Models System Engineer Domain Knowledge Automated Provisioning Documentation Artifacts Test & Sim Artifacts Components Harness Monitors Execution Artifacts Code (Java, C++…) Database Schema (SQL) Integration Artifacts Interfaces (IDL, WSDL) Configuration Metadata, Descriptors Runtime Configuration Policies, Processes Data Structures (XML,IDEF0) Message Formats IDEFx Solution

Example Generated Artifacts Implementation Artifacts (EJB Examples) Class Objects Jars,Wars,Ears Java Source Homes, SQL Stubs, Skeletons, Managers, Helpers, Holders, Primary Keys Interfaces Descriptors BeanInfo ,Editors. Documentation Serialization, . Persistence Management M0/M1 XMI/DTD Business Object Implementation Logic Artifact generation involves multiple tools EJB Container provider;Deployment tools;Packagers; java development tools(IDE);persistence provider;… Typical 10-20 per PIM Classifier 0-20% manual override

Web Services Plus/Minus Advantages High degree of buy-in and support Easy to implement in legacy as well as new systems Flexible and adaptive structure Rapidly improving performance and enterprise support Disadvantages Not the fastest thing around Security and reliability infrastructure needs work Does not carry binary data well (E.G. Images) Large system will require complex matrix of interdependent web services Still changing

MDA Mitigates Web Services problems and risk MDA components can use Web Services as one of many middleware technologies Switch to other middleware if Web Services does not prove-out for particular applications As web services changes and improves (E.G. better security) changes can easily be propagated to MDA supported components Web service specifications (WSDL) and middleware implementation can be automated MDA provides “system view” across many web services

GSA Enterprise Model Example Thanks to George Thomas Enterprise Architect General Services Administration

[4] GSA PIM

[4] GSA PIM

[4] FEA Inheritance

[4] FEA baseRole

[4] XMLDB Reusable Components – TRM Frameworks as OO Design Patterns Components for provisioning Implementation Simulation and Documentation

GSA Process Model Trace Next few slides are screen shots from Live Simulation of a notional ‘to-be’ GSA EA model in Component-X, which traces through each and every component in the business collaborations that have been modeled

Model-driven UI for submitting a UBL Order

trace population

The UBL OrderResponse

GSABuySell component context

AcquisitionManagement component context – a view of ‘recursive decomposition’

in-context UBL Order data

Purchasing component context

in-context UBL OrderResponse data

FOP generated performance_trace.pdf

B-P-A-A as ABM input

Iterative Development Business Model Design Deploy Release Build Automation Build Build Build Build Build Infrastructure Development

Net effect Using these open standards and automated techniques we can; Achieve the strategic advantage of an open and flexible enterprise Produce and/or integrate these systems FASTER and CHEAPER than could be done with legacy techniques Provide a lasting asset that will outlive the technology of the day Integration of modeling, simulation and executable systems