1. Transition and Evolution Moving to Grid Services

2. GT3 is *not* Grid Services l There is nothing special about GT3 l GT2 was GT1.1.3 with feature enhancements to the existing components and a lot of new functionality (GridFTP and RC) l GT3 is all of GT2.4 with feature enhancements to the existing components and a lot of new functionality (OGSI compliant components)

3. Terminiology l Everyone (including us) has a bad habit of saying GT3 to mean Grid Services. l To be clear we should refer to OGSI or non-OGSI compliant services. l One confusing point: u For the first time, there are two ways to do some things in the toolkit. u I.e., non-OGSI job submission.vs. OGSI compliant job submission

4. Transition l We use the Linux versioning convention u Even number releases, I.e. 3.0, are stable releases (bug fixes only) u Odd number releases, I.e., 3.1 are experimental (feature additions, possible interface changes) l Our support policy has not changed since GT 2.0. u We support the current and one previous stable release

5. The Question l How long will we support GT2.x? u That is the wrong question l We invested substantial work in packaging so that we could upgrade components separately. l We can also End-Of-Life (EOL) them independently as well. l This is what we will do

6. The Right Question… And the Answer l When will we EOL specific Components l Depends on the component, but what we do know is this: u All components will be present in 3.2 u The earliest we could EOL something is 3.4 (though we have no plans for this yet) u Therefore, support for all existing components AT LEAST until the release of 3.6, probably longer u This means late 2004, probably well into 2005

7. Evolution l How a specific project makes this transition is a huge question depending on a lot of details. l Largely depends on how much you have already invested in Grid development l Obviously, EDG has a significant investment, which makes it harder l However, there are some techniques that should help.

8. OGSI and non-OGSI in Toolkit l For now, the entire non-OGSI suite is present. l You can install non-OGSI just like you do today and run production, while working on transition issues. l We have provided transition clients where we think it is needed or feasible l Let us know if you think there is something missing.

9. Where do you put the OGSI Interface? l Build an OGSI service to interface to non-OGSI services u RFT to GridFTP l Maintain your client interface and re-implement to send SOAP messages u globus-job-run u globus-url-copy? l What if I want to use both OGSI and non-OGSI services? u Must use discovery of some kind to choose appropriate client interface

10. GT3 Key Points And a glimpse of things to come

11. Web Services l At the heart of Web services is: u WSDL: Language for defining abstract service interfaces u SOAP (and friends): Binding from WSDL to bytes on the wire l Web services appears to offer a fighting chance at ubiquity (unlike CORBA) l But Web services does not go far enough to serve a common base for the Grid…

12. Transient Service Instances l “Web services” address discovery & invocation of persistent services u Interface to persistent state of entire enterprise l In Grids, must also support transient service instances, created/destroyed dynamically u Interfaces to the states of distributed activities u E.g. workflow, video conf., dist. data analysis, subscription l Significant implications for how services are managed, named, discovered, and used u In fact, much of Grid is concerned with the management of service instances

13. The Specification Defines how Entities can Create, Discover and Interact with a Grid Service Service data element Service data element Service data element Service Implementation GridService (required) … other interfaces … (optional) Optional: - Service creation - Notification - Registration - Service Groups + application- specific interfaces Required: - Introspection (service data) - Explicit destruction - Soft-state lifetime GT3 Core: OGSI Specification Includes 0 or more Grid Service Handles (GSHs) Includes 0 or more Grid Service References (GSRs) Service locator

14. RFT in Action Registry * The scenarios in this presentation are offered as examples and are not prescriptive 1. A Grid Service Container is started up; It contains an RFT Factory service; The RFT Factory service registers itself RFT Factory Grid Service Container

15. Client RFT in Action Registry * The scenarios in this presentation are offered as examples and are not prescriptive 2. From a known registry, the client discovers a factory by querying the Service data of the registry RFT Factory Grid Service Container

16. Client RFT in Action 3. The client calls the createService operation on the factory and passes in a TransferRequest RFT Factory Grid Service Container * The scenarios in this presentation are offered as examples and are not prescriptive

17. Client RFT in Action RFT Factory Grid Service Container RFT Service Instance - Start the Instance - Deserialize XML to Java - Write Request via JDBC - Persist Service State 4. The instance is started, and the factory returns a locater * The scenarios in this presentation are offered as examples and are not prescriptive

18. Client RFT in Action RFT Factory Grid Service Container RFT Service Instance - Start the Instance - Deserialize XML to Java - Write Request via JDBC - Persist Service State 5. Client calls Start(), subscribes to notificaitons, etc. * The scenarios in this presentation are offered as examples and are not prescriptive

19. RFT in Action l Service is OGSI compliant l Uses existing GridFTP (non-OGSI) protocols and tools to execute 3 rd Party Transfer for the user l Provides extensive state transition notification GridFTP Server RFT Service Instance * The scenarios in this presentation are offered as examples and are not prescriptive

20. Notification Sink A Notification Scenario 1. NotificationSink calls the subscribe operation on NotificationSource

21. Notification Sink A Notification Scenario 1. NotificationSink calls the subscribe operation on NotificationSource Notification Subscription 2.Notification Source creates a subscription service

22. Notification Sink A Notification Scenario 1. NotificationSink calls the subscribe operation on NotificationSource Notification Subscription 2.Notification Source creates a subscription service 3. Notification Source returns a locator to the subscription service

23. Notification Sink A Notification Scenario 1. NotificationSink calls the subscribe operation on NotificationSource Notification Subscription 2.Notification Source creates a subscription service 3. Notification Source returns a locator to the subscription service 4.b The NotificationSink and Subscription service interact to perform lifetime management 4.a deliverNotification stream continues for the lifetime of NotificationSubscription

24. Notification Sink A Notification Scenario 1. NotificationSink calls the subscribe operation on NotificationSource Notification Subscription 2.Notification Source creates a subscription service 3. Notification Source returns a locator to the subscription service 4.b The NotificationSink and Subscription service interact to perform lifetime management 4.a deliverNotification stream continues for the lifetime of NotificationSubscription The sole mandated cardinality: 1 to 1 subscribe

25. Data Service Overview Resource manager: implements the data virtualization & manages access to data sources GridServiceDataDescriptionDataAccessDataFactoryDataManagement GSH Underlying data sources Data service implementation …… Perhaps other interfaces Data service interfaces Grid service handle

26. Multiple Virtualizations Example Frame File system Collection of files Relational database Collection of files Data sources File system MovieFrameDatabase DB view Filter Derived quantities Data virtualizations

27. (OGSI-) WS-Agreement l Recall key criteria of a Grid: u Coordinates resources that are not subject to centralized control … u using standard, open, general-purpose protocols and interfaces … u to deliver non-trivial qualities of service. l Implies need to express and negotiate agreements that govern the delivery of services to clients u Agreement = what will be done, QoS, billing, compliance monitoring l All interesting Web/Grid services interactions will be governed by agreements!

28. WS-Agreement Contents l Standard agreement language u A composition of a set of terms that govern a service’s behavior with respect to clients u Agreement language uses WS-Policy (currently) u Standard attributes for terms that express current state of negotiation u Other groups define specific terms l Standard agreement negotiation protocol u Establish, monitor, re-negotiate agreement u Expressed using OGSI GWSDL interfaces u Each agreement represented by a service

29. Agreement Overview Agreement Initiator Agreement Provider Data Service Consumer Data Service Provider AgreementProvider (extends OGSI factory) Agreement I/F (extends GridService I/F) DataFactory (extends AgreementProvider) Agreement DataAccess (extends Agreement I/F) [1] [4] [2] [3] Steps (Operations): [1] Create Agreement [2] Create Data Service [3] Access Data Service [4] Monitor Agreement Policy