1 / 40

Service Proforma

Service Proforma. Middleware Workshop. Notes. Please complete as much of this proforma as possible – it will help make the workshop more informative & productive for us all.

stesha
Download Presentation

Service Proforma

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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) • <Demonstrable Multiple Implementations, e.g. SOAP, WSDL> • Implemented draft specification (2pt) • <Specification in standards body and supported by most/many companies. One/few implementations exist (e.g., WS-Security, BPEL)> • 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) • <An idea that exits as a white paper, but no code and no specification details> • Concept (6pt) • <An idea that exists only as power point slides!!> • 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).

More Related