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.
• 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.
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
Service: Scheduling
• Takes workflow (Execution Plan) and Job
descriptions (JDML) and determines the
best place to deploy on the grid.
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.
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.
Service: Performance
• Provides performance information.
• Collects performance information.
• Processes performance information.
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
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
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.
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.
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)
Service: Launching
• Provides an abstract interface for launching
jobs onto resources.
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.
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.
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.
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.
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.
Service: Launching with Reservation
• Provides access to reservation services of
resources exposed through a launcher.
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.
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.
Service Operations: Launching with
Reservation
• operation name: cancelReservation
– Description: Cancel a previously made
agreement.
– IN: The reservation id.
– OUT: XML indicating success or failure.
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
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.
Service Operations: Launching with
Reservations
• operation name: cancelHold
– Description: Cancel a hold.
– IN: The hold id.
– OUT: XML conformation of success/failure.
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.
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
Service: Reservation Engine
• Allows abstract access to the low level
DRM specific reservation functionality.
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.
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.
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.
Service Operations: Reservation
Engine
• operation name: cancelHold
– Description: Cancel a hold.
– IN: Hold id.
– OUT: XML conformation of success/failure.
Service Operations: Reservation
Engine
• operation name: confirmHold
– Description: Convert a hold into a normal
reservation.
– IN: Hold id.
– OUT: XML conformation of success/failure.
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.
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.
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?
Exploiting the Service Architecture
• What features from your ‘plumbing’ do you
use in your service?
– Event notification
– Meta-data
– Registry discovery/advertisement
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.
Service Failure
• Required Reliability
– Failure semantics?
• Positive ack
• Required Persistence
– No current persistence.
• Required Availability
– One of many.
Required Service Management
• Remote access to:
– Performance
– Progress (limited at present).