Servicia: A Robust Infrastructure for Service-Oriented Architecture Prototypes

1. Infrastructure for building service-oriented prototypes ...

2. Outline • Why Servicia was built • Introducing Servicia • Example Service • Integration activities • History of Servicia • Lessons learned • Conclusion • Next Steps

3. What is Servicia? • Infrastructure for a service oriented architecture • Load services at runtime • Plug-in-like behavior • Services can be re-arranged without changing code • Services are accessible via XML-RPC • Allows communication with external non-java components (javascript, …) • Services can be controlled in some way while they are running • For example via JMX … • Platform for integrating KM components • Help to build research prototypes • But, why another SOA platform?

4. Desired Features of the Platform • Services comprise an application • Easy to install • No installation of third party software (e.g., web container) • Services may use the file system to persist data • Configuration and service data can be persisted with subversion • checkout and run, e.g. for demo setups • Integrate web-applications into service landscape • Classes of all services available in servlets • Multiple instances may run in parallel • Additional communication patterns offered • Event-like or bus-like communication, e.g., for observation data, … • Application may be split over more than one VM • Offer location-transparent access to services with minimum (zero) programming overhead • Service calls with maximum performance when running in a single VM

5. The Answer: Servicia • Assumptions • Services share the same file space • Even when running in different VMs services are somewhat “near” • Running in a productive environment is secondary • Services offer an arbitrary number of APIs • Backbone provides access to service APIs • Services declare dependencies to other services • Services may run on different VMs

6. A Servicia Service • Interface • Implementation • Remote proxy (handwritten or generated automatically)

7. Service Descriptor • Informal description • Service Parameters • Dependencies • APIs

8. Servicia Runtime Instances Runtime File Space Config S S … • Runtime instance identified by an ID • Backbone hosts services • Services are accessible via XML-RPC • Services can be managed through JMX • Each service has it’s own file space to operate on

9. Runtime Configuration Dialog • Configuration is stored in the runtime file space • Only relative directory references are stored • Re-locatable configs • Startup sequence derived from service dependencies

10. Services Spread Over Multiple VMs • Instances run on different ports • Location-transparent use of services using XML-RPC

11. Launching a Runtime Instance

12. Example Service • http://servicia.opendfki.de/wiki/ExampleService • Repository:https://servicia.opendfki.de/repos/trunk/Software/ExampleService

13. History of Servicia • First introduced in EPOS • Gnowsis-beta built on top of it • Single application, composed out of services • Services tightly coupled • Enhanced in Mymory • Multiple instances at the same time possible • Better dependency management • JMX support • Spread throughout KM department • User Observation, Context Elicitation, Kaukoluwiki, TaskPad, iDocument, Catwiesel, Semantic Search • Detached from Mymory • Available at opendfki: Servicia

14. Current Service Landscape • Context Elicitation • User Observation • MyDesk • KaulkoluWiki • TaskPad • iDocument • Semantic Search • Catwiesel • DynaQ (backend, experimental)

15. Lessons Learned: Application Drives Integration • Integration is • done on-demand • need-driven • Always two participants: a donator and an “integrator” • Support for the integration processes is vital • Answering questions • Fast bug fixes • Non-technical issues also very important • e.g., Shared understanding of models

16. Lessons learned: Don’t Code For a Particular Environment Resource Resolution Dependency Resolution JMX Logging Parameter Transfer • Components “live” in an environment provided by a runtime framework (Tomcat, OSGi, pure JVM, ...) • logging, file environment, management, dependency resolution, setup • Don’t develop components for a particular runtime environment • Split into core functionality and glue code to adjust to a runtime environment Component Glue Code Runtime Environment

17. How to Build a Good Component for Servicia? • Don’t use Servicia code in your component!!! • Separate component and environment strictly • Different source folder! • Use an initializer class to setup your component and to keep Servicia references from the component • Environment comprises (amongst others) • Configuration/Setup • Logging • Relative filename resolution • References to other services • MBeans • ...

18. More Lessons Learned • References to other components/services should be injected • Assembly code within components tends to hinder flexibility (sequence of initialization) • Inversion of control • Be aware of difference between remote and local invocations • Borderline can be blurred to some extend • Using fine-grained interfaces remotely cripples performance • Minimize dependencies to other services • Difficult but vital

19. Conclusion • Easily connect to components already available as Servicia services • Jar-hell reduced • Get XML-RPC and JMX support for free • Publish web front-ends with the power of the services • Add your component to the „tool box“ • Nevertheless, other runtime environments may be more appropriate in some situation (Web Application, OSGi, ...) • KM group must not rely on a single environment

20. Next Steps • Better usability • Maven2-like jar management • Jar-hell is still present yet • JINI/RIO support for distributed parts of Servicia?

21. Resources • Opendfki:http://servicia.opendfki.de • SVN-Repositoryhttps://servicia.opendfki.de/repos