Download Service Proforma Middleware Workshop

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
Service Proforma
Middleware Workshop
• 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
• <availability of code/implementation>
– 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>
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)
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
Event notification
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