1. Composite Applications: Value Proposition and Architecture Jean-Jacques Dubray, Ph.D. Attachmate jdubray@gmail.com May 2005 There is a newer (flash) presentation available herehere

2. Attachmate Copyright 20052 Copyright Notice According to US and Worldwide Copyright laws, it is forbidden to use all or part of this presentation without a written consent of Attachmate In particular, you are not allowed –To remove attachmate logos or the authors name –Change the title of the presentation –Publish part or all of the presentation under your name or the name of another organization

3. Attachmate Copyright 20053 Outline Evolution of the Software Industry Composite Application Model Service Orientation and Composite Applications Resources in Composite Applications Conclusion

4. Evolution of the Software Industry Problems and opportunities

5. Attachmate Copyright 20055 The software industry has failed to create normalized information systems ERP 1 CRM SCM PLM Portal PRM HCM … … Order Customer Product BOM Invoice Employee Source: David McComb et al, www.SemanticArts.com

6. Attachmate Copyright 20056 Current Application Models (all based on MVC) Couple UI, Processes and Data CICI CICI CICI CICI Broker

7. Attachmate Copyright 20057 I argue here that the notion of system of record must become irrelevant UI, Processes and Data span beyond the boundary of any single system All systems in operation today require to be connected to many other systems to perform their tasks Any new development must face an increasingly complex integration project –And/Or, users must start using more than one application to perform any given activity

8. Attachmate Copyright 20058 So how do we normalize IT? The Common Database Integration –EAI –EII –ETL Standardize on a single vendor business suite Portals The problem has not gotten simpler –Mergers/Acquisitions/Outsourcing –Rogue developments –Customer facing Web apps (scalability)

9. Attachmate Copyright 20059 The denormalization has forced organization to cross the point of negative ROI Number of Systems 10100 1000 Cost Value 1 1

10. Attachmate Copyright 200510 We must seek all opportunities bring projects back in the positive ROI area Number of Systems 10100 1000 Cost Value 1 1

11. Attachmate Copyright 200511 Moving back to a lower number of systems of records is not really an option Number of Systems 10100 1000 Cost Value 1 1

12. Attachmate Copyright 200512 The software industry attempting to improve software construction along multiple dimensions Software Constructio n Distributed Computing CORBA, J2EE DCE WS, ebXML Application Model Mainframe Client/Server Web Apps SAP, Oracle… SalesForce.com Solutions Computing Model Structured Programming Object Orientation Middleware MQ EAI, B2B BPM RUP XP MDD Service Orientation Methodologies Portals

13. Attachmate Copyright 200513 groupware EII BPMBPM However, it has often resulted in a lack of long range coherence in IT with punctual or no ROI improvement EAI Browser Portal B2Bi ETL BAMBAM WS Rich Client MOM Application Server

14. Attachmate Copyright 200514 Yet, architecturally, the end point of this evolution is relatively well understood Federated and Collaborative point of usage –Identity and activities Clients May work in disconnected mode No technical or physical boundaries –Process and Data federation Easy to deploy and evolve –Without breaking existing systems and activities As little Integration as possible –Data federation –« right-time » integration Able to deal with unreliable environments Scalability and availability of web applications

15. Attachmate Copyright 200515 So… No single information system can live in isolation from other information sources –Business activities and business processes span an increasingly larger number of systems of record IT can no longer afford to build assets that cannot be reused in future contexts New assets must be built in a way that enable them to be composed in future solutions –Current application models and middleware are not capable of composition A new application model must support UI, Process and Data federation

16. Composite Application Model Federating UI, Processes and Data

17. Attachmate Copyright 200517 Lets look at the Requisition-to-Invoice Process RFQ Order Management Procurement ERP RFQSuppliers QuotesOrders SuppliersBilling Orders Invoices Order Invoice

18. Attachmate Copyright 200518 How can we reuse these two systems to create new solutions or create new activities ? SI client SI Service Interface Activity Coordinator Service Resource

19. Attachmate Copyright 200519 The coordinator has two roles: a) normalize the business logic of business objects SCM PLMPortalPRM HCM … ERP CRM Order Customer Order Service Customer Service

20. Attachmate Copyright 200520 This normalization can be achieved with orchestration programming languages such as BPEL, BPEL-J Purchase Request Cancel Order Order Material Receipt Invoice receive invoke send Create PO receive invoke send Cancel Create PO CRM Create PO ERP Order Service

21. Attachmate Copyright 200521 b) Manage the Business Process level which can be achieved via choreography languages (WS-CDL, ebBP) and technologies (WS-CAF) RFQ Service Order Service Invoice Service Purchasing Request Invoice Order Buyer Cancel Invoice Material Receipt Supplier Order Service

22. Attachmate Copyright 200522 Orchestration and Choreography are two forms of Coordination which are complementary Not everything needs to be nor can be orchestrated –B2B for sure –Even internally, orchestrating everything is creating a maximum coupling at the business level –Orchestration is best used for creating normalized business services There are two forms of coordinators –Orchestration Engine (WS-BPEL) –Choreography agents (WS-CDL, WS-CAF) Choreography participants can often self-coordinate

23. Attachmate Copyright 200523 User Activities fit right in a service oriented composite application model RFQ Service Order Service Invoice Service RFQ Cancel Request Invoice Material Receipt Create RFQ Approve Order Query Orders, Invoices,… RFQOrder « Activities » « Services »

24. Attachmate Copyright 200524 MVC will progressively be replaced by the Service-Activity-Coordinator-Resource pattern Activity Coordinator Service Ressource SACRe Pattern

25. Attachmate Copyright 200525 Service Interface Composite Application Architecture Business Activity Business Service Business Process Initiates Participates in Invokes

26. Attachmate Copyright 200526 Software vendors are creating the technological foundation enabling this composite application model A new universal and ubiquitous distributed computing model –Web Services –Based on open standards –Would have far less value if this did not exists New programming languages (not application programming languages) –Where the message becomes a first class citizen along with code and data, based on a new formalism: Pi-Calculus –WS-BPEL, BPEL-J ou C (Microsoft) The formalism of the application model can go far beyond « principles » of Architecture and Design

27. Attachmate Copyright 200527 Shift To A Service-Oriented Architecture and Composite Applications Function oriented Build to last Prolonged development cycles FromTo Coordination oriented Build to change Incrementally built and deployed Application silos Tightly coupled Object oriented Known implementation Enterprise solutions Loosely coupled Message oriented Abstraction Source: Microsoft (Modified)

28. Service Orientation and Composite Applications

29. Attachmate Copyright 200529 Composite applications may rely on dozens systems geographically distributed There are five major concepts that represent the foundation of Service Orientation –Peer-to-peer message based interactions –Service Interfaces vs Object Interfaces –Policies and agreements (P&A) –Discovery –Composition –Coordination These concepts are critical to build successful composition applications

30. Attachmate Copyright 200530 Peer-to-peer interactions Synchronous Request / Response are not adapted for long-running interactions which may occur at the service coordination level When you have dozens of systems interacting with each other, who is controlling who?

31. Attachmate Copyright 200531 Service Interfaces Non proprietary –All service providers offer somewhat the same interface Highly Polymorphic –Intent is enough when invoking a service Implementation can be changed in ways that do not break service consumer operations –Real world services interact with thousands of consumers –Service providers cannot afford to break the context of their consumers

32. Attachmate Copyright 200532 Policies, Agreements This topic is about governance and is critical to the success of composite applications –One needs to find the appropriate services as efficiently as possible With possibly several hundreds services being consumed by a Composite Application it is essential to have a policy driven assembly mechanism –This is equivalent to type checking in compiled languages –Agreements are not yet very common in SOA, but they are a natural extensions to policies and represent the runt-time contract between the service producer and Comp. Applications

33. Attachmate Copyright 200533 Discovery is a feature that is fairly unique to SOA Services are autonomous entities often designed and managed outside the realm of their consumers Registries of Service Definitions facilitate the selection of a service during the design of a Composite Application Discovery mechanisms may also be invoked at run- time for dynamic or fail safe behaviors –However not all services can be replaced

34. Attachmate Copyright 200534 The fundamental goal of service orientation is to create assets that are composable Structured programming and Object Orientation offer code level composition mechanism –Enabling code reuse but not asset reuse External interfaces of IT assets were often an after thought built in a proprietary way (semantically and technically) limiting any potential reuse of this asset in contexts that where not necessarily known when it was designed and implemented

35. Attachmate Copyright 200535 Composition and Service Orientation Resource representation composition –Resources are represented in XML –XML documents are composable Service Composition Language –BPEL enables us to create services from other services –Supports two types of compositions operation composition interface composition Ultimately, Service Orientation will only succeed if it enables data, process and UI federation via composition

36. Attachmate Copyright 200536 Coordination Coordination technologies support the Business Process layer of Composite Applications The coordination infrastructure –Ensures state alignment between all participants in a Composite Application –Generates exception when the coordination does not proceeds as planned

37. Resources in Composite Applications

38. Attachmate Copyright 200538 at the heart of [SOA] is a very complex problem: with distributed applications comes the need for distributed data sharing Identification and equivalence authentication Authorization and privacy mediation synchronization Source: The Dataweb: An Introduction to XDI, Drummond Reed et al.

39. Attachmate Copyright 200539 Information Entities (Resources) in SOA Several dimensions appear when managing an Information Aggregate in a SOA Information Entity IdentityContentStateLocation(s) Replication Privacy Specific to SOA and Composite Apps

40. Attachmate Copyright 200540 Key problems to solve Isolation –We cannot be guaranteed that the information we have is the information held by the system of record Containment –We cannot be guaranteed that a service consumer is going to apply the same privacy rules to the information provided to it

41. Conclusion The Future Belongs to Whom Can Master Connectivity

42. Attachmate Copyright 200542 Service Orientation is a New Computing Paradigm from which Composite Applications can be built Not as a new name for –API –Component A genuine set of concepts with which we can construct new kinds of software –This is as significant if not more than Object Orientation In particular SO forces us to think about enabling the same piece of code to be leveraged –by large numbers of consumers –in unforeseen context

43. Attachmate Copyright 200543 Composite Application are the latest iteration on Service Oriented Architecture Composite Applications add value to a SOA –SOA is not just a better integration strategy Composite Applications enable an Enterprise Architecture strategy –Application model shielded from technologies –Explicit Business process and information view Capable of returning IT projects to positive ROI –Built new solutions on existing assets –Application model built for evolution and no integration –Increased in productivity because of federated UI

44. Attachmate Copyright 200544 Where do we start? Well that remains the big question –Build on the SOA momentum Vendors have started to market the concept –SAP (xApps) –Oracle (BPEL Engine) –BEA (Liquid Data) –Microsoft (CCF) –This is good news ! Tons of technology components to build your own The problem is critical mass, the more you have in a Composite Model, the easier it is to add