Realisation of SOA using Web Services Advanced WS

1. Realisation of SOAusing Web ServicesAdvanced WS Adomas Svirskas Vilnius University December 2005

2. Agenda • WS-* Specifications • Advanced WS Architecture • WS Taxonomy

3. Why the WS core is not enough? • We have got SOAP, WSDL, UDDI • So we can develop, publish, discover, invoke Web Services • But... this is about application integration • While the business world needs business process integration • Thus we need composable, orchestrated, transactable, secure Web Services

4. Current State of WS [1] • The Web Services stack of standards has grown rapidly in the last three years from its original form as SOAP, WSDL and UDDI specifications • With it, the Web is moving towards being an open distributed computing platform with which we can build Service Oriented Architectures and Composite Applications

5. The Reality - WS-Nonexistent Standards [2] • The numerous WS specifications introduced by various parties over the past few years show that there's a clear desire to fill out the WS architecture stack • Unfortunately, converting those specifications into actual industry standards is elusive • WS-This and WS-That • The specifications (collectively known as WS-*) are numerous and daunting. • A coalition of developers and architects from BEA Systems, IBM, and Microsoft authored most of them, though different specifications also include contributions from several other smaller companies. • Because the same author companies didn't write all the specifications, at least two different lists exist.

6. The Reality - WS-Nonexistent Standards [2] • One can find complete lists of the WS-* specifications at: • http://msdn.microsoft.com/Webservices/understanding/specs • http://www-128.ibm.com/developerworks/webservices/standards/ • http://dev2dev.bea.com/webservices/standards.html • Natural questions: • How do these specifications fit together? • Are they all really necessary? • If they are necessary, how and when will they become actual standards?

7. WS-* • These lists from Microsoft, IBM and BEA (there are more lists) cover pretty much every topic imaginable: • WS-Addressing • WS-Attachments • WS-BusinessActivity • WS-Coordination • WS-Discovery • WS-Enumeration • WS-Eventing • WS-Federation • WS-Inspection • WS-Manageability • WS-MetadataExchange • WS-Notification • WS-PolicyFramework • WS-Provisioning • WS-ReliableMessaging • WS-Resource • WS-Security • WS-Topics • WS-Transactions • WS-Transfer • Moreover, some areas have two, three, or more specifications devoted to them • There is a need for taxonomy of WS-* specs

8. Current State of WS [1] • Within Web-based platform, software agents may • Exchange messages • Provide or consume services • Perform cooperatively units of work • Message exchanges and operation invocations may be part of a unit of work performed by software agents. • Instances of this unit of work have a precise lifecycle and often have a context. • Service compositions represent a particular type of unit of work.

9. Messages, Services, UoW [1] J-J Dubray, SAP Blog http://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2261

10. Web Services Taxonomy [1] • All standards and (the proposed specs) developed as part of the Web Services stack fall in one of these three categories • At the message exchange level, the message exchange protocol (SOAP) is layered on top of transport and syntax specifications. This protocol can be composed with other specifications for reliable and/or secure message exchanges • The WS-Addressing specification standardizes addressing mechanisms for the protocol

11. WS-* Standards Architecture [1] J-J Dubray, SAP Blog http://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2261

12. WS-* Standards Architecture (W3C) Web Services Architecture, W3C, http://www.w3.org/TR/ws-arch/#technology

13. WS-* Standards Architecture – M$ http://msdn.microsoft.com/webservices/webservices/understanding/specs/default.aspx

14. WS-* Standards Architecture - IBM http://www-128.ibm.com/developerworks/webservices/standards/

15. Web Services Taxonomy [1] • At the service level, the service definition specification (WSDL) can be composed with other specifications to add the concepts of Event and Resource • A directory (UDDI) may be used to store, search and retrieve service definitions.

16. WS Taxonomy – UoW [1] • WS- RemotePortlets specification provides a service interface to user activities. • The foundation of the unit of work level is composed of Context, Lifecycle and optionally Coordination services for a particular type of unit of work. • The most basic type is a transaction: WS-AtomicTransaction (WS-AT), WS-Business Activity (WS-BA). • WS-BPEL provides more sophisticated capabilities and can be used to specify service compositions.

17. WS Choreography • Finally, WS-CDL has the capability to describe any message exchanges performed by an arbitrary number of participants • WS-CDL is a choreography language as opposed to WS-BPEL which is an orchestration language. WS-BPEL is executable, WS-CDL is not. • In a choreography, it is the mere exchange of messages by agents which advances the state of the choreography.

18. WS Choreography • The decision process by which an agent decides to send a message is hidden from the choreography definition. • In an orchestration, an engine decides what to do next when it receives or sends a message, based on an orchestration definition. • A choreography definition may be used by each participant to configure the validation of the current message exchange instead of hard coding it.

19. WS Choreography http://www.w3.org/TR/ws-cdl-10/#Purpose-of-WS-CDL

20. WS-* Standards Architecture • The architecture is complemented by security (WS-Security, SAML ,…), management (WS-DM) and metadata (WS-Policy) specifications • Overall, these specifications have enabled the web to become a powerful distributed computing platform

21. Service Component Architecture (SCA) • A major news as of 30 November: SAP, IBM, BEA, Oracle, IONA, Sybase, Siebel an others have announced the development of a new component model specifically designed for building service oriented architectures - SCA • SCA is a new component model based on the principles of Service Oriented Architecture • middleware and programming language neutral • offers a superior application model to support "Rich Clients" and construct RIAs (Rich Internet Applications) • http://dev2dev.bea.com/pub/a/2005/11/sca.html

22. Service Component Architecture (SCA) • SCA is also an assembly mechanism, based on the injection of dependency pattern (as in Spring framework) to create Modules from Components and Systems and Subsystems from Modules. • A module is composed of service components which run in the same process. • As such, SCA provides the means to compose assets which have been implemented using a variety of technologies as services can be accessed and reused in a uniform manner • Any component developed with SCA should be able to participate in a system with any other SCA component, regardless of its implementation language

23. References • [1] Dubray, J-J, SAP Blog 2005. Taxonomy and Architecture of Web Service Standards, http://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2261 • [2] Vinoski, S. WS-Nonexistent Standards. IEEE's Internet Computing, November 2004. http://www.iona.com/hyplan/vinoski/pdfs/IEEE-WS-NonexistentStandards.pdf • [3] Ferguson, D. et al. Secure, Reliable, Transacted Web Services: Architecture and Composition, 2003. http://www-306.ibm.com/software/solutions/webservices/pdf/SecureReliableTransactedWSAction.pdf • Papazoglou, M., Dubray, J-J. A Survey of Web service technologies. 2004, http://eprints.biblio.unitn.it/archive/00000586/