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

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

3. 3 Context: Open Grid Services Architecture 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

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

5. 5 Grid Service technology 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

6. 6 Roots of OGSA/OGSI Globus OGSA Web Services

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

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

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

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

11. 11 Basic features of OGSA 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

12. 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. 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 requesterService provider SOAP: XML over HTTP

14. 14 SOAP messages are XML documents, usually sent over HTTP Simple Object Access Protocol A simple XML document: ball 400 SOAP: XML over HTTP Service requestorService provider

15. 15 Standards and Protocols - SOAP  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/ (Simple Object Access Protocol)

16. 16 XML over HTTP Soap container Service Native call SOAP container 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. Service provider

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

18. 18 1. Fetch WSDL A client needs WSDL before invoking service WSDL Service 2. Invoke service using SOAP ClientServer Role of WSDL 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. 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. 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  to find a WS of a particular provider  to find providers that offer a required WS  a “meta service” for locating web services by enabling robust queries against rich metadata  http://www.uddi.org/  Under development! UDDI is evolving fairly rapidly.

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

22. 22 OGSA and Web Services Technology OGSA (Grid) services are described as WSDL interfaces: –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.

23. 23 Components of a Grid Service The Grid service is 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 management of 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)

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

25. 25 OGSA/OGSI adds to WS technology 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

26. 26 Implementation of OGSA 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

27. 27 Semantics of a Grid service interface 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

28. 28 Semantics of a Grid service interface 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

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

30. 30 Factory PortType Creation of new Grid-service instances Operation:  Factory :: CreateService  c reates 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. 31 Usage of a Grid Service Client UDDI registry GS Factory service data of the requested GS service data elements GSH request stub XML file SOAP/HTTP message GSR GSH GS instance Practically a WSDL doc.

32. 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. 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. 34 Goal of the HandleMap GSs Client GSR GS instance GSH stub HandleMap GS

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

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

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

38. 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. 39 Notification framework ClientGS instance stub Notification subscription Event message XML file SOAP/HTTP message Must implement the NotificationSink portType Must implement the NotificationSource portType

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

41. 41 Application example: data mining 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 User appl. R Storage reservation factory Mining service factory Storage R Database service R Storage Database service R

42. 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. 43 User appl. R Storage reservation factory Mining service factory Storage R Database service R Storage Database service R Create mining service Mining service Create storage reservation Storage reservation Application example: data mining

44. 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 User appl. R Storage reservation factory Mining service factory Storage R Database service R Storage Database service R Mining service Storage reservation Keepalive Query Status update notification Application example: data mining

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

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