1. 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

2. Primary author of “Component Collaboration Architecture” in EDOC
Introductions
Cory Casanave
Primary author of “Component Collaboration Architecture” in EDOC

3. 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

4. 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

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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

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

13. 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

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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

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

22. 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

23. 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

24. “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

25. 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

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

27. Collaborations and Roles
Conceptual Foundation
Portions copied with permission of Trygve Reenskaug - Taskon
OORAM (

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

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

30. Multiple roles in a collaboration

31. 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.

32. 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

33. Collaboration Diagram

34. 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

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

36. 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

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

38. 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

39. EDOC Component Collaboration Architecture
The model of collaborative work
CCA

40. 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

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

42. 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

43. Identifying roles and collaborations

44. Identify Documents

45. Distinguish protocols and events

46. Create Business Transactions

47. Organize into protocols

48. Add ports to complete community process

49. Drill-down

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

51. Add technology specifics for deployment

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

53. 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

54. 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

55. Engine exposing a DC

56. Defining an external component resource

57. Using a proxy
Endpoint

58. Aspects

59. Mapping of a WSDL Engine
- <definitions xmlns=" xmlns:soap=" xmlns:mime=" xmlns:http=" xmlns:SOAP-ENC=" xmlns:xs2000=" xmlns:xs2001=" 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

60. 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=" />
  </port>
  </service>
Aspects
WSDL
WSDL-SOAP

61. Mapping of a protocol binding
- <binding name="BuySellProtocol" type="tns:BuySellProtocol">
  <soap:binding transport=" 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=" />
Aspects
WSDL
WSDL-SOAP

62. 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

63. 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

64. 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>
                                 

65. 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

66. 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

67. 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 per PIM Classifier
0-20% manual override

68. 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

69. 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

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

71. [4] GSA PIM

72. [4] GSA PIM

73. [4] FEA Inheritance

74. [4] FEA baseRole

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

76. 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

77. Model-driven UI for submitting a UBL Order

78. trace population

79. The UBL OrderResponse

80. GSABuySell component context

81. AcquisitionManagement component context – a view of ‘recursive decomposition’

82. in-context UBL Order data

83. Purchasing component context

84. in-context UBL OrderResponse data

85. FOP generated performance_trace.pdf

86. B-P-A-A as ABM input

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

88. 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