1 / 43

MDA for Web Services

MDA for Web Services. EDOC-ECA. Applying Model Driven Architecture to Web Services Document webserv/2002-04-05. Problem Space. Integration Nightmare Infrastructure, Version & Vendor lock-in Complex, divergent and manual development and deployment processes. Goals.

zahi
Download Presentation

MDA for Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MDA for Web Services EDOC-ECA Applying Model Driven Architecture to Web Services Document webserv/2002-04-05

  2. Problem Space • Integration Nightmare • Infrastructure, Version & Vendor lock-in • Complex, divergent and manual development and deployment processes

  3. Goals • A scalable and robust enterprise architecture • Loosely coupled enterprise components • Enable rapid provisioning of business solutions • Simple, reproducible processes supporting reuse • Technology & vendor independence • Enable the integration and collaboration of multiple; • Business units (internal and external) • Customers • Suppliers • Systems • Technologies

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

  5. The new center • The strategic core of you systems must be the business itself • 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 • Enabler: Model Driven Architecture (MDA) with EDOC-ECA Extreme Modeling

  6. Collaboration and Web Services Collaboration is the center of applying web services to core enterprise problems.

  7. EDOC – Enterprise Collaboration Architecture EDOC Provides the standard UML “PIM” profile suitable for enterprise application of web services

  8. What is 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. • 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.

  9. Using MDA for WSDL Business Focused ECA Model “PIM” Mapping WSDL & Soap “PSM”

  10. Collaboration is Key • 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

  11. AutomatedModel Driven Architecture Profile (E.G. EDOC) Business Focused Model (UML) Manual Coding Enterprise Components Infrastructure Mapping (E.G. Web Services) Tools Produce & Integrate Minimize and structure manual implementation Framework & Infrastructure (E.G. Web Services) Mapping is tuned to the infrastructure

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

  13. Enterprise Components • Enterprise Components must be independent • While being able to interoperate with each other • Making the information system a lattice of cooperating components Open Standards Open Standards Open Standards

  14. Making a monolithic web application doesn’t help! Web Browser HTTP Poor Monolithic Architecture Traditional data sources SQL DBMS & Client/Server Monolithic Applications Monolithic Applications Bad Thing All business rules, data rules, application logic, technology and user interface code are contained here The data goes here

  15. Enterprise Architecture Supply Chain Enterprise Components EAI Applications & B2B E-Commerce SQL DBMS, Client/Server & Legacy Applications XML Corba EJB DCOM MQ Web Browser Client Applications HTTP Web Server Applications Standard Middleware connects applications to components & components to components The data goes here User interface and application logic go here Business and data rules go here

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

  17. Web Service B2B Buyer Seller Typical Requirement HTML Buyer Web Page Seller Redundant Work!

  18. HTML Buyer Web Page Buyer Proxy Multi-tier implementation Web Service B2B Buyer Seller Could have multiple implementations using different technologies Could have multiple implementations using different technologies

  19. HTML Buyer Web Page Buyer Proxy Multi-tier implementation Web Service B2B Buyer Seller Event Cloud Event Event Legacy Seller Applications Implementing seller using events

  20. Understanding Collaborations

  21. Digital Map Census Data Police Records House Drawings Aerial Photos The Connected EnterpriseContent and Communication PoliceDispatcher Role

  22. Multiple roles in a collaboration

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

  24. The Internet Computing Model The technology model behind WSDL and ebXML and others

  25. The Internet Computing Model • Collaboration of independent entities • Document exchange over internet technologies • Large grain interactions • No shared infrastructure required * • Long lived business processes • Business transactions Portals Business Party Business Party

  26. Requirements for the “ICM” • Contract of Collaboration • Shared business semantics • Meta-Model (EDOC-ECA) and representation (I.E. XMI, ebXML-BPSS) • Shared Repository for Contracts (MOF, UDDI, ebXML) • Connectivity (middleware) which meets requirements of the contract • Implementation of each contract role providing connectivity (application server) Business Partner Business Partner Instance Data Repository Contracts (Metadata) Contract of collaboration can be mapped to the format of various technologies. (ebXML, Soap, .NET)

  27. Two levels of interoperability Instance data and interoperability Business Partner Business Partner Biztalk ebXML Bridge Over Soap Over Soap Metadata (contract) interoperability .NET ebXML BPSS Purchasing Model Normal Form Each can be transformed

  28. 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 Inner Role Legacy Inner Role Domain Inner Role Cust

  29. Collaborative Business Semantics • Defined: The processes, information and contracts of interaction between collaborators within a community • Collaborative business semantics are a valuable long-term asset • Captures information and process • Requires ownership and support • Do not put this valuable asset in a (transient - one size fits all) technology specific form • Use technology independent models (MDA) • Map to the technology of the day (E.G. DTD)

  30. Generic web services • Generic web services is any set of technologies that can implement the internet computing model. • WSDL, ebXML, .NET…

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

  32. XML Standards • XML Schema & DTD • Description and packaging of data • WSDL • Specification a services, operations and flows available via that service • Soap • Basic messaging and packaging • Extensions for Soap-RPC with WSDL • May be extended to support collaborative messaging

  33. ECA as the normal form Web Services (WSDL) MDA Mappings ebXML (BPSS) EDOC-ECA J2EE (Java RMI) .NET The standard way to model and tool for multiple technologies MOM (MQ-Series) English

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

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

  36. Order Processing Shipping Receivables Event The Seller’s Detail Order Conformation Shipped Ship Req Shipped Delivered

  37. The Community Process • Identify a “community process”, the roles and interactions in a collaboration Protocol

  38. Protocols

  39. Composition

  40. ECA/WSDL mapping • ECA works well as a modeling framework for WSDL • How major concepts could map • WSDL Port <-> ECA Port • WSDL Operation <-> ECA Flow port (one way) or Operation (Two way) • WSDL Service <-> ECA Component • WSDL Port type <-> ECA Protocol • WSDL Message <-> ECA Document type

  41. WSDL/ECA Differences • WSDL Adds • Technology binding and endpoints • ECA adds • Choreography, nested conversations, two-way protocols, nested components.

  42. Next steps • RFP Draft – “Web services for enterprise collaboration” • Two way mapping between EDOC-ECA and WSDL/Soap • Draft available – discussion in “MARS” • Roadmap items to make web services more viable as enterprise infrastructure • Security and reliability

  43. Business Case • · High level support for understanding and documenting collaborative business processes. • · Loose coupling between independent parties in a collaboration • · Tighter coupling in the software development life-cycle between design and implementation processes and artifacts. • · Consistency in the way WSDL is used to implement collaboration. • · A standard way to use UML for web services. • · Enhanced support for asynchronous interactions. • · Automation of the development process from design to implementation. • · A faster, more deterministic development processes. • · Ability to adapt to changing business requirements. • · Ability to adapt to multiple and changing infrastructure technologies. • · Full life-cycle tool support

More Related