1 / 18

CDDLM on HP SmartFrog

CDDLM on HP SmartFrog. Middleware Workshop. Service: CDDLM. Distributed Deployment Framework HPL implementation of GGF CDDLM WG http://smartfrog.org/ (and SourceForge CVS) License: LGPL Support: email + bug tracking proposed component model will use relevant parts of WS-RF.

terena
Download Presentation

CDDLM on HP SmartFrog

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CDDLM on HP SmartFrog Middleware Workshop

  2. Service: CDDLM • Distributed Deployment Framework HPL implementation of GGF CDDLM WG • http://smartfrog.org/ (and SourceForge CVS) • License: LGPL • Support: email + bug tracking • proposed component model will use relevant parts of WS-RF

  3. 6. Deployment Request 9. Rtrn Status 2. Resource Request 5. Allocated Resource 7. Transfer files and Initiate Local Program 8. Return machine job ID 3. Resource Brokering 4. Allocated Resource (Static Resource Allocation/Pre-Allocated Resource) 1.Job Submission Job Management CDDLM I/F Resource Allocation (Candidate Set Gen.) CDDLM Wrapper (Container) Local Resource Management Resources

  4. Service Operations for GGF12 • deploy • undeploy • getServerInfo • getApplicationStatus +direct communications to/between deployment components

  5. <deploy> • The JSDL descriptor of this job • A deployment descriptor in a supported language (with language identification information) • 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

  6. <undeploy> 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

  7. <getServerInfo> Query server info (version , uptime) • IN: void • OUT: <serverInfo> xsd:any (TBD)

  8. <getApplicationStatus> IN: void OUT: <applicationStatus> xsd:any (TBD) Liveness test with health info or fault returned

  9. services we expect from others • file upload/staging • something to store the persistent job info & redeploy if needed • resource allocation/scheduling • usable front end

  10. Notifications • long term: WS-N • short term: well known SOAP message/SOAPAction; caller submits URL

  11. Front end implementation

  12. back end implementationwork in progress, hence the risk

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

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

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

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

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

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

More Related