Infrastructure for building service-oriented prototypes ...

© 2008 DFKI GmbH SE P. 1

Infrastructure for building service-oriented prototypes ...


Outline

Why Servicia was built

Introducing Servicia

Example Service

Integration activities– History of Servicia– Lessons learned

Conclusion

Next Steps


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?


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


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


A Servicia Service

Interface

Implementation

Remote proxy (handwritten or generated automatically)


Service Descriptor

– Informal description

– Service Parameters

– Dependencies

– APIs


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

…


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


Services Spread Over Multiple VMs

Instances run on different ports

Location-transparent use of services using XML-RPC


Launching a Runtime Instance


Example Service

http://servicia.opendfki.de/wiki/ExampleService

Repository:https://servicia.opendfki.de/repos/trunk/Software/ExampleService


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


Current Service Landscape

Context Elicitation

User Observation

MyDesk

KaulkoluWiki

TaskPad

iDocument

Semantic Search

Catwiesel

DynaQ (backend, experimental)


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


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


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


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


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


Next Steps

Better usability

Maven2-like jar management– Jar-hell is still present yet

JINI/RIO support for distributed parts of Servicia?


Resources

Opendfki:http://servicia.opendfki.de

SVN-Repositoryhttps://servicia.opendfki.de/repos

Infrastructure for building service-oriented prototypes ...

Documents

Transcript of Infrastructure for building service-oriented prototypes ...