1. Service Proforma Middleware Workshop

2. 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.

3. Endpoint Services A means of increasing service dependability by using well-known dependability patterns. Implementation: –http://sourceforge.net/projects/digs –BSD License –No Guaranteed Support SOA Model:WS, OGSA

4. Motivation Our aim is to provide a (relatively) transparent means of increasing service dependability. –By dependability we currently refer mainly to availability and reliability. We do this by providing a simple means of deploying dependable “compositions” based upon common dependability patterns (redundancy, recovery-blocks, etc.)

5. Service Operations N/A

6. 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) – Implemented draft specification (2pt) – 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) – Concept (6pt) – TOTAL: 4.5pts (an implementation of a non-publicised concept)

7. Service Dependencies Languages: The implementation consists of a Java API and compositions are accessed as Java servlets.

8. AAA & Security What authentication mechanism do you use? –None. What authorisation mechanism do you use? –None. What accounting mechanism do you use? –None. Does service interaction need to be encrypted? –No. If these are not used now, will they be in the future? –Potentially.

9. Exploiting the Service Architecture What features from your ‘plumbing’ do you use in your service? –None

10. Service Activity Multiple interaction or single user? –N/A Throughput (1/per day or 100/per second?) –N/A Typical data volume moved in –N/A Typical data volume moved out –N/A

11. Service Failure Required Reliability –Failure semantics Can accommodate various semantics. Required Persistence –N/A Required Availability –N/A

12. Required Service Management N/A