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: GT4 GRAM
• GRAM provides a service interface to compute
resources (clusters etc).
• Not yet available (first alpha at end of month)
– URL: www.globus.org/toolkit
– License: Globus Toolkit Public License (BSD style)
– Support: Will become fully supported with the release
of GT 4.0
• SOA Model:WS-RF
Service Operations (Factory)
• WS-ResourceProperties operations
• createManagedJob()
– Description:
– IN: Job description
– OUT: EPR for created job resource
Service Operations (Service)
• WS-ResourceProperties operations
• WS-ResourceLifetime operations
• WS-BaseNotification NotificationProducer
operations
• start()
– Description:
– IN: void
– OUT: current state of job
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: <List specs and add up!>
Service Dependencies
• What else does your service depend on (i.e.
external dependencies)?
– GT4 Core which in turn depends on a host of
third party technologies (RDBMs etc)
• What does your implementation depend on?
– Languages: Java, C, Perl
– Container type: Web container/servlet
AAA & Security
• What authentication mechanism do you use?
– Any provided by GT 4 Security (WS-Security: Username/Password,
X.509 (w & w/o proxy certs) and GSI SecureConversation
• What authorisation mechanism do you use?
– Any provided by GT 4 Security (identity, gridmap, self, CAS, callout,
custom)
• What accounting mechanism do you use?
– Deferred to scheduler implementation
• Does service interaction need to be encrypted?
– No, but it can be
• 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?
–
–
–
–
–
–
Logging
Event notification
Lifetime management
Registry discovery/advertisement
State inspection
(probably more than that)
Service Activity
• Multiple interaction or single user?
– multiple
• Throughput (1/per day or 100/per second?)
– Depends/unknown
• Typical data volume moved in
• Typical data volume moved out
Service Failure
• Required Reliability
– Failure semantics?
• Positive ack (two phase commit)
• Required Persistence
– Work never lost? - Yes
• Required Availability
– Should always be available
Required Service Management
• Remote access to:
– Progress