© 2008 DFKI GmbH SE P. 1
Infrastructure for building service-oriented prototypes ...
© 2008 DFKI GmbH SE P. 2
Outline
Why Servicia was built
Introducing Servicia
Example Service
Integration activities– History of Servicia– Lessons learned
Conclusion
Next Steps
© 2008 DFKI GmbH SE P. 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?
© 2008 DFKI GmbH SE P. 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
© 2008 DFKI GmbH SE P. 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
© 2008 DFKI GmbH SE P. 6
A Servicia Service
Interface
Implementation
Remote proxy (handwritten or generated automatically)
© 2008 DFKI GmbH SE P. 7
Service Descriptor
– Informal description
– Service Parameters
– Dependencies
– APIs
© 2008 DFKI GmbH SE P. 8
Servicia Runtime Instances
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
Runtime File SpaceConfig
S
S
…
© 2008 DFKI GmbH SE P. 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
© 2008 DFKI GmbH SE P. 10
Services Spread Over Multiple VMs
Instances run on different ports
Location-transparent use of services using XML-RPC
© 2008 DFKI GmbH SE P. 11
Launching a Runtime Instance
© 2008 DFKI GmbH SE P. 12
Example Service
http://servicia.opendfki.de/wiki/ExampleService
Repository:https://servicia.opendfki.de/repos/trunk/Software/ExampleService
© 2008 DFKI GmbH SE P. 15
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
© 2008 DFKI GmbH SE P. 16
Current Service Landscape
Context Elicitation
User Observation
MyDesk
KaulkoluWiki
TaskPad
iDocument
Semantic Search
Catwiesel
DynaQ (backend, experimental)
© 2008 DFKI GmbH SE P. 17
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
© 2008 DFKI GmbH SE P. 18
Parameter TransferLogging
Dependency ResolutionResource Resolution
JMX
Lessons learned: Don’t Code For a Particular Environment
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
Runtime Environment
Glue Code
© 2008 DFKI GmbH SE P. 19
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– ...
© 2008 DFKI GmbH SE P. 20
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
© 2008 DFKI GmbH SE P. 21
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
© 2008 DFKI GmbH SE P. 22
Next Steps
Better usability
Maven2-like jar management– Jar-hell is still present yet
JINI/RIO support for distributed parts of Servicia?
© 2008 DFKI GmbH SE P. 23
Resources
Opendfki:http://servicia.opendfki.de
SVN-Repositoryhttps://servicia.opendfki.de/repos