1. Service Proforma Middleware Workshop

2. Notes Please complete as much of this proforma as possible – it will help make the workshop more informative & productive for us all. If you will be talking about more than one service feel free to add an overall architecture diagram showing the relationship between services. Also, please provide a motivation slide for developing/using the service set.

3. Service: ICENI End to end Grid middleware. Providing Launching, Scheduling, Reservation and inter-application communication. –URL: www.lesc.doc.ic.ac.uk/iceni –Licence: ICENI, based on Sun open source licence –Support: Web site / mailing list SOA Model:Jini

4. Service: Scheduling Takes workflow (Execution Plan) and Job descriptions (JDML) and determines the best place to deploy on the grid.

5. Service Operations: Scheduling operation name: launchJob –Description: Takes a workflow, determines where to run each component within it and deploys over the Grid. –IN: XML document, either Execution Plan (workflow) or JDML (single job) –OUT: Concrete Execution Plan (XML) detailing where the component (job) has been launched to.

6. Service Operations: Scheduling operation name: generateQuote –Description: Takes a workflow, determines where to run each component within it and inform requester of this decision. –IN: XML document, either Execution Plan (workflow) or JDML (single job) –OUT: Concrete Execution Plan (XML) detailing where the component (job) would be launched to.

7. Service: Performance Provides performance information. Collects performance information. Processes performance information.

8. Service Operations: Performance operation name: register –Description: Register an application for monitoring while it runs. –IN: String name for the job. –OUT: String, unique id for the performance monitoring

9. Service Operations: Performance operation name: addEP –Description: Takes a workflow for an application and records it for use later on (processing). –IN: XML: Concrete Execution Plan (workflow), unique id provided by register –OUT: null

10. Service Operations: Performance operation name: getActivityTime –Description: Request information from the Performance repository about how long an activity is expected to take. –IN: Component description, Resource description and activity name. (string) –Optional IN: Share count, Problem specific characteristics (name value pairs) –OUT: Either a single time value or a set of timings if optional values not used.

11. Service Operations: Performance operation name: getProblemCharacteristics –Description: Find out what problem space characteristics (and types) can be used for a given case. –IN: Component description (string) –OUT: Set of name type pairings.

12. Service Operations: Performance operation name: Performance Events –Description: Events generated by applications listened to by the Performance Service. –Data Structure: Unique id for the performance monitoring of the application, Component, Time, Resource, type of event (start, port or internal)

13. Service: Launching Provides an abstract interface for launching jobs onto resources.

14. Service Operations: Launching operation name: launchJob –Description: Takes a job description JDML and launches it on a resource controlled by this service. –IN: XML document JDML –OUT: XML document describing if job launched successfully.

15. Service Operations: Launching operation name: getResources –Description: Returns a set of resource id’s that this service can deploy onto. –IN: User Credentials (optional). –OUT: Set of resource id’s. If a user certificate was provided then only resources the user can use are returned.

16. Service Operations: Launching operation name: getResourceDescription –Description: Returns a full description of the resource. –IN: The id of the resource, User Credentials (optional) –OUT: XML document describing the Resource. Empty if user not allowed to access or resource doesn’t exist.

17. Service Operations: Launching operation name: getResourceAttribute –Description: Request a single attribute about a resource. –IN: Resource id, attribute name and User Credentials (optional). –OUT: String (may be XML doc) for the named attribute. Empty if resource/attribute is not found or user doesn’t have access.

18. Service Operations: Launching operation name: getLocations –Description: Returns a human readable list of the names of the resources. –IN: User Credentials (optional). –OUT: List of names. If user credentials used only those the user can access are returned.

19. Service: Launching with Reservation Provides access to reservation services of resources exposed through a launcher.

20. Service Operations: Launching with Reservation operation name: createReservation –Description: Create a reservation with a resource. –IN: Agreement document (XML) –OUT: The modified Agreement document and a reservation id.

21. Service Operations: Launching with Reservation operation name: renegotiateAgreement –Description: Attempt to modify an agreement. –IN: Agreement document (XML). –OUT: Agreement document (XML) either conforming change or offering an alternative.

22. Service Operations: Launching with Reservation operation name: cancelReservation –Description: Cancel a previously made agreement. –IN: The reservation id. –OUT: XML indicating success or failure.

23. Service Operations: Launching with Reservation operation name: createHold –Description: Create a time limited reservation that will expire if not confirmed in time. –IN: Agreement document (XML) –OUT: Modified Agreement document and a Hold identity

24. Service Operations: Launching with Reservations operation name: confirmHold –Description: Convert a hold into a permanent reservation. –IN: The hold id. –OUT: XML conformation of success/failure.

25. Service Operations: Launching with Reservations operation name: cancelHold –Description: Cancel a hold. –IN: The hold id. –OUT: XML conformation of success/failure.

26. Service Operations: Reservations operation name: makeReservation –Description: Takes a concrete workflow (Execution Plan) and attempts to reserve all the required resources. –IN: XML document Execution Plan (workflow). –OUT: Execution Plan (XML) detailing the reservations made.

27. Service Operations: Reservations operation name: cancelReservation –Description: Takes a resource id and reservation id and cancels it. These can be found in XML document returned from makeReservation. –IN: resource id, reservation id. –OUT: XML conformation of success/failure

28. Service: Reservation Engine Allows abstract access to the low level DRM specific reservation functionality.

29. Service Operations: Reservation Engine operation name: makeReservation –Description: Takes XML reservation request (user credentials, interval) and attempts to reserve. –IN: XML document – Reservation Request. –OUT: Modified Reservation Request, either confirming details or offering an alternative.

30. Service Operations: Reservation Engine operation name: cancelReservation –Description: Takes a reservation id and attempts to cancel it. –IN: Reservation id. –OUT: XML conformation of success/failure.

31. Service Operations: Reservation Engine operation name: makeHold –Description: Make a time limited reservation. –IN: XML reservation request (user credentials, interval). –OUT: Modified Reservation Request, either confirming details or offering an alternative.

32. Service Operations: Reservation Engine operation name: cancelHold –Description: Cancel a hold. –IN: Hold id. –OUT: XML conformation of success/failure.

33. Service Operations: Reservation Engine operation name: confirmHold –Description: Convert a hold into a normal reservation. –IN: Hold id. –OUT: XML conformation of success/failure.

34. What do you use to build your service? (i.e. How ‘standard’ is your service?) NB:A low score means less risk & more mainstream Widely Implemented Standard Specification (1pt) – Implemented draft specification (2pt) – Implemented draft specification (3pt) –<Specification in standards body but alternatives exist. Industry is divided. One/few implementations exist. (e.g., Transactions, coordination, notification, etc.). Implemented proposal (4pt) –An implementation of an idea, a proposal but not submitted to standards body yet (e.g., WS-Addressing, WS-Trust, etc.) Non-implemented proposal (5pt) – Concept (6pt) – TOTAL: JINI, 1pt, Concept 6pt = 7pt.

35. Service Dependencies What else does your service depend on (i.e. external dependencies)? –Logging : Java Logging What does your implementation depend on? –Languages : Java –JINI based.

36. AAA & Security What authentication mechanism do you use? –X509 certificates based. What authorisation mechanism do you use? –From JINI infrastructure. What accounting mechanism do you use? –None at present. Does service interaction need to be encrypted? If these are not used now, will they be in the future?

37. Exploiting the Service Architecture What features from your ‘plumbing’ do you use in your service? –Event notification –Meta-data –Registry discovery/advertisement

38. Service Activity Multiple interaction or single user? –Multiple interaction Throughput (1/per day or 100/per second?) –~ 10/per min. Typical data volume moved in Typical data volume moved out –Depends on job.

39. Service Failure Required Reliability –Failure semantics? Positive ack Required Persistence –No current persistence. Required Availability –One of many.

40. Required Service Management Remote access to: –Performance –Progress (limited at present).