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.

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

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

Service Operations

• N/A

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: 4.5pts (an implementation of a non-publicised concept)

Service Dependencies

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

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.

Exploiting the Service Architecture

• What features from your ‘plumbing’ do you use in your service?

– None

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

Service Failure

• Required Reliability– Failure semantics

• Can accommodate various semantics.

• Required Persistence– N/A

• Required Availability– N/A

Required Service Management

• N/A