Service oriented computing

1. Service oriented computing Gergely Sipos, Péter Kacsuk www.lpds.sztaki.hu

2. Progress in Grid Systems Supercomputing (PVM/MPI) Network Computing (sockets) Clusters Cluster computing Web Computing (scripts) OO Computing (CORBA) Client/server High-throughput computing High-performance computing Object Web Condor Globus Web Services OGSA Semantic Grid Grid Systems

3. Define a service-oriented architecture … the key to effective virtualization … to address vital “Grid” requirements on-demand, system management, collaborative computing … building on Web services standards extending those standards where needed Context:Open Grid Services Architecture

4. Standardization Open Grid Services Architecture(www.ggf.org/ogsa-wg) Domain-Specific Services Program Execution Data Services Core Services Open Grid Services Infrastructure Web Services Messaging, Security, Etc.

5. Two basic components: OGSA (Open Grid System Architecture) OGSI (Open Grid Services Infrastructure) An extension of the WS technology Focuses on dynamic service behaviour: service factories lifetime management notification framework Prepare WSes for Grid environments www.ggf.org Grid Service technology

6. Roots of OGSA/OGSI Globus Web Services OGSA

7. The Globus toolkit: GRAM GridFTP MDS-2 GSI Web services: SOAP (Simple Object Access Protocol) WSDL (Web Services Description Language) Roots of OGSA/OGSI

8. The Globus model Resource description GIIS (MDS-2) Publish MDS-2 API (configuration description) Resource Resource requestor provider GRAM API Your program moves to resource(s) Security is a serious problem!

9. (SOAP) The Web services model Predefined programs (services) wait for your invocation Much more secure than the Globus concept

10. Moving from Globus to OGSA Globus toolkit OGSA mechanism GRAM GridFTP MDS-2 GRAM GridFTP MDS-2 HTTP FTP LDAP Grid Services Abstraction TLS/GSI SOAP+TLS/GSI Other transports IP IP

11. Objectives: to integrate services across distributed heterogeneous dynamic “virtual organizations”(VO) Solution scheme: defines standard mechanisms for creating, naming, and discovering transient Grid service instances provides location transparency and multiple protocol bindings for service instances Supports integration with underlying native platform facilities Basic features of OGSA

12. Web services define a technique For describing software components to be accessed Methods for accessing these components Discovery methods that enable the identification of relevant service providers Web services standards are being defined within the W3C (World Wide Web Consortium) and other standard bodies and form the basis for major new industry initiatives such as Microsoft .Net IBM Dynamic e-Business Sun One Web services

13. SOAP provides a means of messaging between a service provider and a service requester. SOAP is a simple enveloping mechanism for XML payloads that defines an RPC convention. SOAP is independent of the underlying transport protocol SOAP payloads can be carried on HTTP, FTP, Java Messaging Service (JMS) and the like. Simple Object Access Protocol (Service-Oriented Access Protocol) Service requester Service provider SOAP: XML over HTTP

14. Simple Object Access Protocol Service requestor Service provider SOAP: XML over HTTP SOAP messages are XML documents, usually sent over HTTP A simple XML document: <invoice id = ‘12345’> <item> ball <\item> <amount> 400 <\amount> <\invoice>

15. Standards and Protocols - SOAP (Simple Object Access Protocol) • Protocol for messaging and RPC-style communication between applications and services • XML-based • Uses common Internet transport protocols (HTTP, SMTP, FTP, MQ, etc.) • SOAP elements: • http://www.w3.org/TR/SOAP/

16. SOAP container Service provider Soap container XML over HTTP Native call Service • The easiest way to publish a sw component as a web service is to use a Soap container which • Accepts incoming requests • Dispatches them to published components • Translates them to the component’s native language interface • Soap containers are available for Java, C++, Perl, etc.

17. Standards and Protocols - SOAP • XML messaging using SOAP:

18. Role of WSDL Client Server WSDL 1. Fetch WSDL 2. Invoke service using SOAP Service A client needs WSDL before invoking service • SOAP clients read a WSDL file to get • the address • and message information of a web service. SOAP containers automatically generate WSDL, so developers don’t have to write WSDL manually. • Once the WSDL file is read, the client can start sending SOAP messages to the web service.

19. Standards and Protocols - WSDL • Used by the service provider to describe a service • XML-based • Describes • what a web service can do • where it resides • how to invoke it • Components: • Messages (corresponds to messages between the client and service) • PortType (corresponds to operations) • Binding (corresponds to a portType implemented by a specific protocol as SOAP or CORBA) • Service (collection of ports) • http://www.w3.org/TR/wsdl/

20. Standards and Protocols - UDDI (Universal Description, Discovery and Integration Service) • A standard that allows information about businesses and services to be electronically published and queried • a “meta service” for locating web services by enabling robust queries against rich metadata • to find a WS of a particular provider • to find providers that offer a required WS • Under development! UDDI is evolving fairly rapidly. • http://www.uddi.org/

21. service data of the requested WS URI service data elements URI HTTP get WSDL doc. XML file SOAP/HTTP message Usage of a Web Service Globally unique ID of the WS. Belongs to it „forever”. UDDI registry Client stub WS provider Enough information to use the WS. May change during WS lifetime.

22. OGSA (Grid) services are described as WSDLinterfaces: which defines the method names, parameters, and their types for Grid service access A new tag gsdl has been added to WSDL for Grid service description The UDDI registry and WSIL document are used to locate Grid services. The transport protocol SOAP is used to access Grid services. OGSA and Web Services Technology

23. The Grid serviceis a special Web service that provides a set of well-defined interfaces (Open Grid Service Interface) that follow specific conventions (for naming and upgrading) The interfaces of Grid services are for: Discovery and service characterization (a variety of information about the Grid service instance) Lifetime managementof transient service instances SoftStateDestruction (set and get termination time for Grid service instance) ExplicitDestruction (terminate Grid service instance) Registry (conduct soft-state registration of Grid service handles) Factory (gatekeeper) (create new Grid service instance) Handle mapping (return Grid service reference) Notification (subscribe to notifications of service-related events) Manageability (support remote management of Grid service instances) Components of a Grid Service

24. Grid-service MUST implement a serviceType that aggregates: • the Grid ServiceportType • zero or more other OGSI defined portTypes • discovery • dynamic service creation • notification • manageability • one or more portTypes that define domain specific behavior

25. PortType definitions: GridService: every GS must implement Factory: GS factories must implement HandleMap: to find a new GSR (Grid Service Reference) if the old expires Service lifetime management Notification framework OGSA/OGSI adds to WS technology

26. The standard interface of a Grid service includes multiple bindings and implementations such as Java C# Such Grid services can be deployed on different hosting environments(even different operating systems). OGSA also provides a Grid security mechanism to ensure that all the communications between services are secure. The basic idea of OGSA: Grid structure + Web services + Toolkit Implementation of OGSA

27. OGSA enables application programs and application users to create transient services to discover and evaluate the properties of available Grid services The OGSA Factory Registry Grid Service and HandleMap interfaces cover the aspects of the creation of transient Grid service instances the service discovery characterization in a virtual organization Semantics of a Grid service interface

28. OGSA defines the semantics of a Grid service instance including service instance creation Naming lifetime management communication protocols. The creation of a new Grid service instance => creation of a new process in the hosting environment Multiple Grid service instances may correspond to the same Grid service interface Semantics of a Grid service interface

29. service data of the requested GS service data elements GSH GSH request XML file SOAP/HTTP message Usage of a Grid Service UDDI registry Practically a URI Customise the GS instance Client GS Factory

30. Factory PortType Creation of new Grid-service instances Operation: • Factory :: CreateService • creates a new Grid service instance • returns a GSH (Grid Service Handle) and a GSR (Grid Service Reference) for the instance • supports soft state lifetime management • CurrentTerminationTime • MaximumExtension • implementation is not specified in OGSA

31. service data of the requested GS service data elements GSH GSH request GSR GSH XML file GS instance SOAP/HTTP message Usage of a Grid Service UDDI registry Client stub GS Factory Practically a WSDL doc.

32. GSH and GSR GSH: Grid Service Handle • globally, uniquely and for all time identifies a Grid-service instance (URI) • not enough information to invoke the service GSR: Grid Service Reference • protocol and instance specific information • network address • supported protocol bindings • can change – expiration time • in case of a SOAP binding  WSDL GSH to GSR mapping is required

33. HandleResolver PortType Takes a GSH and returns a valid GSR Steps: • identifying home HandleResolver – included in GSH • contacting the HandleResolver to obtain the GSR • relationship between Factory and HandleResolver Operation: • HandleResolver :: FindByHandle • GSH  GSR

34. Goal of the HandleMap GSs HandleMap GS Client GSH GSR GS instance stub

35. GSR GSR Goal of the HandleMap GSs Must contain information about the “home HandleMap” HandleMap GS New functionalities added Client GSH GSR GS instance GS instance stub stub Valid no more

36. request GSH GSR initial lifetime GS instance „Keepalive” request GS lifetime management GS Factory Client stub To avoid „soft” service termination

37. Termination request Every GS is able to provide lifetime functionality GS lifetime management GS Factory request GSH Client GSR initial lifetime stub GS instance Methods for lifetime management are part of the GridService portType!

38. Notification Delivering messages from Notification Source to Notification Sink NotificationSource PortType: • allows clients to subscribe to notification messages • operation: NotificationSource :: Subscribe NotificationSink PortType:: • defines a single operation for delivering a notification message • operation:NotificationSink :: DeliverNotification NotificationSubscription PortType: • a subscription causes the creation of a Subscription instance • used by clients to manage the lifetime of the subscription

39. Notification subscription Event message XML file SOAP/HTTP message Notification framework Client GS instance stub stub Must implement the NotificationSink portType Must implement the NotificationSource portType

40. GS implementation details: Language How to generate SOAP messages What protocol to use for the stub-GS communication OGSA does not define

41. The environment initially comprises four simple hosting environments: One that runs the user application One that encapsulates computing and storage resources Two that encapsulate database services R R Database service Database service ftp ftp ftp Storage Storage Application example: data mining R Storage reservation factory Mining service factory R User appl. Storage

42. The user application invokes “create Grid service” request on the two factories in the second hosting environment: Requesting the creation of a “data mining service” And an allocation of temporary storage Each request involves mutual authentication of the user and the relevant factory followed by authorization. The new data mining service instance is also provided with delegated proxy credentials that allow it to perform further remote operations on behalf of the user. Application example: data mining

43. Create mining service Create storage reservation Storage reservation Mining service R R Database service Database service ftp ftp ftp Storage Storage Application example: data mining R Storage reservation factory Mining service factory R User appl. Storage

44. The data mining service uses its proxy credentials to start requesting data from the two database services, placing information in local storage Uses notification mechanisms to provide the user application with periodic updates on its status. The user application Generates periodic “keepalive” requests to the Grid services R R Keepalive Database service Database service ftp ftp ftp Query Status update notification Storage Storage Application example: data mining R Storage reservation factory Mining service factory R User appl. Storage reservation Mining service Storage

45. The user application fails: The data mining computation continues but there is no more “keepalive” requests. R R Database service Database service ftp ftp ftp Query Status update notification Storage Storage Application example: data mining R Storage reservation factory Mining service factory R User appl. Storage reservation Mining service Storage

46. As a result the two Grid services time out and terminate, freeing the storage and computing resources R R Database service Database service ftp ftp ftp Storage Storage Application example: data mining R Storage reservation factory Mining service factory R User appl. Storage