Download Service Proforma Middleware Workshop

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: <name>
• <short description as to what the service
does>
• <availability of code/implementation>
– URL
– License
– Support?
• <SOA Model:WS/WS-GAF/WS-RF/Jini>
Service Operations
• <operation name>
– Description:
– IN: <arguments/data types in>
– OUT: <arguments/data types out>
• <REPEAT TO DESCRIBE SERVICE>
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)?
–
–
–
–
RDBMs (e.g. service persistence)
Notification (e.g. callbacks to client)
Logging
Other services (name them)
• What does your implementation depend on?
– Languages (e.g. PERL, Java, .NET/C#)
– Container type
AAA & Security
• What authentication mechanism do you use?
– Bespoke? From the infrastructure?
• What authorisation mechanism do you use?
– Gridmap file, CAS, From service or infrastructure?
• What accounting mechanism do you use?
– Is interaction audited? Is usage run against quotas?
• 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?
–
–
–
–
–
–
–
Factory port
Factory pattern
Logging
Event notification
Meta-data
Registry discovery/advertisement
Other OGSI/WSRF/WS/WS-GAF characteristics?
Service Activity
•
•
•
•
Multiple interaction or single user?
Throughput (1/per day or 100/per second?)
Typical data volume moved in
Typical data volume moved out
Service Failure
• Required Reliability
– Failure semantics?
• Positive ack
• Submit & forget
• Required Persistence
– Work never lost?
• Required Availability
– One of many or unique requirement
Required Service Management
• Remote access to:
– Performance
– Progress
– Diagnostic and repair interfaces