Using an ECM solution as a service repository
While designing EasySOA, our specific needs made us explore alternatives to the existing service repositories1. Rather than a using an existing product, we chose to build on an Enterprise Content Management platform (ECM), and here is why.
We believe that what SOA governance and registries are currently lacking is the fostering of communication between developers, architects, system admins and – why not? – business users. In other words, we want to bring people back in SOA. So, one of the core needs of our project is not only to store information regarding all the web services of a company, but also from various point of views: we need to know about their specifications, their architecture, their implementations (ex: the WSDLs for SOAP services)… Eventually, we aim at storing an exhaustive, service-oriented map of the information system, which will serve as a basis to ease the SOA evolutions.
In short, here are the main specific needs we had for our SOA model:
- To store business-oriented information, as much as technical information
- To provide simple ways to access the model remotely
- To enhance collaboration between all actors of the SOA
- To integrate easily with Open Source service platforms (FraSCAti, Talend, etc.)
What is lacking from current solutions
Service repositories are often recognized as useful tools: they enhance services reuse, ease developments of clients and make them easier to maintain ; depending on the products, they can even provide IT governance capabilities. But a lot of repositories out there are heavy, proprietary solutions, and even when Open Source2, most are technology-specific: they are made by an ESB editor, and (especially) for its ESB users.
Also, existing products usually embed both a service registry & a repository. We don’t really need certain features, like the publishing and the testing of the services, since we plan on developing our own components, with slightly different goals than traditional service registries.
Rather than using an existing solution, we then decided to build our repository on an ECM platform, namely the Open Source project Nuxeo DM.
The document-oriented model
The first consequence of using document management software is quite obvious: all information is document-oriented. Compared to usual service repositories, this turns out to work well since Nuxeo is easily extensible: with little effort, we can store SOAP services as a set of properties with an attached file, its WSDL. Since several files can be attached to the same document, we can as well add any relevant file produced at design time (specifications, etc.), whatever its format is.
Another important thing is that documents are stored, as we can expect, as a hierarchy of folders and sub-folders. It can help us classify services, for example by building a hierarchy based on services APIs and applications. However, this is both an opportunity and a drawback: should we build the folder structure according to the services architecture, or to their business domain? Or even to the machines they are stored on? How can we take in consideration the differences and the relations between things that have been specified by architects (data from design time), and things that have been found from real environments? (ex: data extracted by our discovery by monitoring tool)
Using documents is a bit complicated when it comes to create complex relations between entities. Unlike using relational databases, creating semantic links between documents is not obvious. Fortunately, Nuxeo provides various tools to overcome this issue, for instance by making relations between documents, by using tags or by building “virtual hierarchies” of documents.
Another thing about the model is that we have to make it open to other EasySOA components, or any piece of software that might want to interact with it. For this, we can take benefit from the built-in, extensible REST API provided by Nuxeo, but also from its CMIS3 implementation.
A collaborative repository
The greatest opportunity that comes with an ECM is its collaborative features. In the case of Nuxeo DM, we have found that a lot of things could be reused, to serve as tools to communicate between users, and help them work together. Here are examples of what we can do:
- Document comments can serve as a way to communicate around a single service ;
- The versioning of services can store their evolutions, and notifications allow users to be aware of such changes ;
- Document preview and annotation capabilities allow developers to view and communicate on specific parts of the WSDLs ;
- With a few business developments, Workflows, forums & wikis can also serve as useful tools to back up SOA evolutions.
The main benefit of using Nuxeo was its low cost of turning it into a basic service repository: it is modular and easily extensible/configurable with XML (being based on OSGi4 ), has an extensible REST API, and most features are customizable and programmatically available. The product also brought various opportunities from the document management domain, making ECM softwares in general actually relevant to build service repositories.
In the case of EasySOA, this repository will serve both as a collaborative core and an open SOA model, which is a solid first step before building all of the ambitious features we want (see “Why EasySOA?” for a list of planned components).
More articles on registries and repositories
- Service Registry: A Key Piece for Enhancing Reuse in SOA by Juan Pablo García-González, Verónica Gacitúa-Décar & Dr. Claus Pahl
- DIY SOA: How to build your own Simple Service Repository by Ben Wilcock
- For an introduction to service registries & repositories, see Service Registry: A Key Piece for Enhancing Reuse in SOA [↩]
- A few Open Source service registries/repositories: Muse Galaxy, WSO2 Governance Registry, Petals Master [↩]
- http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services [↩]
- http://en.wikipedia.org/wiki/OSGi [↩]