Download Service Proforma Middleware Workshop

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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