CDDLM on HP SmartFrog Middleware Workshop

Service: CDDLM Distributed Deployment Framework HPL implementation of GGF CDDLM WG – (and sourceforge CVS) –License: LGPL –Support: + bug tracking WS-RF + proposed component model

Service Operations –server info (version, uptime) –IN: void –OUT: xsd:any (TBD)

Query server info (version, uptime) –IN: void –OUT: xsd:any (TBD)

–The JSDL descriptor of this job –A language name –A deployment descriptor in that language –A list of (name,value) properties –An optional callback type and xsd:Any with callback information. –synchronous deployment :boolean –xsd:any for optional extra stuff

IN: void OUT: xsd:any (TBD) Liveness test with health info or fault returned

In: –Application: identifier –cause: String –synchronous: boolean –xsd:any minOccurs=0 : for future use Out: –boolean: Success/failure response. –xsd:any minOccurs=0 : for future use

Front end implementation SOAP1.2 doc/lit1 WS-BaseNotification3 JSDL2 SmartFrog language3 CDL Language5 WS-BaseFaults2 16

back end implementation work in progress, hence the risk WS-Resources3 WS-Resource Pattern3 CDDLM Basic Services6 CDDLM Component Model 6 WSDM3 21

Service Dependencies external dependencies? –Ultimately: GRAAP, –WS-DM implementations –Callbacks: initially, direct SOAP, eventually WS-N –Logging if extant What does your implementation depend on? –Java 1.4; Axis 1.2. SmartFrog 3.x, Jetty webserver

AAA & Security we will use the OGSA security stuff Current internal: encrypted, PKI-authenticated communications (RMI!) What authorisation mechanism do you use? –TBD What accounting mechanism do you use? –Nothing, yet Does service interaction need to be encrypted? –Potentially sensitive data (passwords &c).

Exploiting the Service Architecture What features from your ‘plumbing’ do you use in your service? –Event notification –Logging –Instrumentation for Management –Optional :Registry discovery/advertisement

Service Activity Multiple users per machine And/or one user/many machines Throughput: O(minutes)-O(days) data volume moved in (KB, + binary content) Typical data volume moved out: KB

Service Failure Required Reliability: service lifetime defines lifetimes of apps; uptime must exceed deployments. Failure semantics? –Submit & forget –App failure policy in deployment descriptor Persistence? Good Question. Fault tolerance through distribution; can implement high-availability w/ custom components

Required Service Management We are management infrastructure Uses: management interfaces of things we deploy Generates: management interfaces to the deployment graph.

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.

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: