1. The SMS project WP 4.2: Service Repository & Runtime Environment ICCS

2. Page 2 Service Repository Implementation (1) : Tools Alternative tools studied: –Subversion (SVN) –Native XML databases: eXist (java) Apache Xindice (java) Berkeley XML database - embedded (c++) Sedna (c++) Chosen: eXist –Ongoing work and open source –Supports various query languages Best for SMS: XQuery (“SQL” of native XML databases) –Provides a variety of communication protocols (SOAP, XML-RPC, etc.) –Supports concurrent access We need developers to be able to access the repository at the same time –Is also used for the service registry

3. Page 3 Service Repository Implementation (2) (eXist) Files are added as collections –Collections are comprised of a number of XML and non-XML files –References to file system or URIs can also be used for non-XML descriptors (e.g. jars) Uses: –Browsing of service assets –Browsing of assets and artifacts for advanced developers –Upload of assets and artifacts for advanced developers

4. Page 4 Service Repository Implementation (3) : SMS asset description Files stored for each service: 1. -manifest.rmd: service metadata 2..lightdl 3. -model.xml (maybe add OCL expressions) 4. -nf.xml: non-functional properties description 5. -README.txt 6. -wizard.xml: additional mappings needed for the wizard 7..jar: service code and libraries –Changes: Wizard instructions

5. Page 5 Service Repository Implementation (4) Status of work –Choose Repository technology – done –Upload sample components and descriptions – done –Testing (using XQuery) – done –Implement interfaces to the repository – ongoing –Rendering on wizard – ongoing Relations with work of: –RAL on service description and user profile changes –VTT on repository interfaces

6. Page 6 Runtime Environment (1) Runtime environment –Responsible for managing lifecycle of SMS components (both core and end- user) –Needs to provide a sandbox around the end-user component –Keep in mind that each component is a SMILE process

7. Page 7 Runtime Environment (2) Low-level components –One instance –Yellow Pages Component services –Registered to Yellow pages –One instance per configuration End – user services –One instance per configuration –User discovers them through the Registry –Yellow pages for other components Service deployment –Rules for order of component deployment – derive from service description –Code –Configuration –Wiring of distinct components

8. Page 8 Future Actions for WP4.2 Development of: –additional components and services –Additional services for the repository –End-user service discovery implementation Second Deliverable preparation (D4.2.2) –“Prototype Service provider components” –Due: 01/08 Addition to rendering features (for the Service Authoring Wizard) in the service description Reference implementation of RE as a standalone application