News

CentraSite: Registry/Repository and Free Community Edition

Posted by Stefan Tilkov on Jun 12, 2007 03:38 PM

Community: SOA
Topics: Governance
Tags: Registry

Software AG and Fujitsu have released version 3.1 of CentraSite, their jointly developed SOA solution for SOA governance. According to information provided by Software AG, notable new features include out-of-the-box support for the third-party tools offered by members of the CentraSite Community, support for federation across multiple registry/repository instances, a pluggable architecture, and fully customizable life cycle support. Software AG also announced its sponsoring of the InfoQ SOA and SOA Governance communities; the CentraSite community portal is also hosted by InfoQ.

InfoQ had a chance to talk to Gerd Schneider, Software AG's Senior Director SOA Marketing, about the role of a registry/repository in SOA deployment, the CentraSite product and the JAXR and UDDI standards.

InfoQ: Many people view a registry/repository solution as something that should be added very late in a SOA deployment – i.e. as something that's more of an add-on than a necessity. Would you agree?

Gerd: No, quite the contrary – the success of any SOA initiative begins with an effective SOA governance strategy. Governance can be accomplished with something as simple as post-it notes put on a wall or a spreadsheet on a network share or via a SOA registry repository. CentraSite, our SOA Governance platform is based on a registry repository – and more. When you govern your SOA, you care about responsibilities regarding creation, deployment and change of services, processes, policies and so on. With CentraSite, architects store any type of SOA artifact, add metadata to describe it and provide a variety of lifecycle features including version control, change management, impact analysis and more. SOA Governance based on a powerful registry repository infrastructure is, in our view – the key to SOA success.

What, if anything sets CentraSite apart from other solutions?

There are a few things that set CentraSite apart – the first is our commitment to open standards. CentraSite works with all Crossvision products out of the box, as well as with other products that support Web services standards – for example those from the CentraSite community such as Amberpoint and ILOG. The second is because of the extensibility of CentraSite, we can store any type of SOA artifact – not just services. Take for example a sequence from an ESB – we will store all of the individual services that are being orchestrated – as well as any of the style sheets that we’re using for transformation, as well as the sequence itself – each are stored as separate artifacts. Additionally all of the relationships between those artifacts are automatically created and managed. These relationships lay the foundation for effective impact analysis, so we can see where a service is being used – before making any changes.

Why would someone care about extensibility?

Many reasons ... one of the biggest is the ability to store and govern any type of SOA artifact. Let’s say a customer has a special format for describing business rules which are associated to processes. Once defined the next time this artifact is checked into CentraSite it will be treated the right way. Another example: we have a customer who is using CentraSite not only to store all of the legacy modernization artifacts generated by our ApplinX and EntireX tool, but they have also extended CentraSite to store additional information including the systems that are running the application, PDF’s of policy and design documents and even information about how those services relate to JCL and cron jobs. This offers unique value to the organization by providing a unified view on a highly distributed SOA system. A last point I want to mention is the extensibility and pluggable User-Interface Architecture of CentraSite. This allows us to integrate any additional functionality customers require, one example being wiki to collaborate on processes.

CentraSite is built on top of JAXR, which doesn't seem to have much traction in the market. What's the reasoning behind that decision?

I do not share this view If you look at the market leading products from Software AG, IBM, HP and also most of the open source tools I can not see a single one that does not support the JAXR standard.
The reason for us to build our product on top of this standard is that we gain by this the meta-data flexibility that we need to support the use cases that our customers want to implement with CentraSite. In most cases CentraSite is not used as a Service registry only but as a meta-data management and monitoring platform for various customer-specific assets. This can be only achieved if you build your meta-data models on top of a flexible and customizable standard like JAXR. Furthermore our JAXR implementation does in a sense unify UDDI and EbXML interfaces since it is located on top of those.

What about support for UDDI? Why do you consider UDDI support to be relevant?

UDDI is a very important standard when it comes to managing services and without UDDI support any SOA Governance platform would be not complete. We fully support both versions, UDDI version 2 and 3. This also provides us the ability to interoperate in a standard way with a wider range of other SOA registry providers and SOA related development and management tools.

What are the community edition's restrictions?

The community edition is designed for organizations to start their SOA Governance strategy. Beside the ability for anyone to download it we include it with all our Crossvision products. The enterprise edition adds additional enterprise-strength features such as high-availability or federation with other meta-data stores. It also adds the capability to customize Lifecycle Management processes and create own business reports and metrics.

The CentraSite community edition is available for free download at the CentraSite community site.