Presentation on theme: "Service Proforma Middleware Workshop. Notes Please complete as much of this proforma as possible – it will help make the workshop more informative & productive."— Presentation 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: –URL –License –Support?
Service Operations –Description: –IN: –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) – Implemented draft specification (2pt) – Implemented draft specification (3pt) –
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