SOA Repository Best Practice

For those of us who have been developing applications for many years (think COBOL & Assembler from the 70s and 80s), the idea of having a code library (programs and routines) is nothing new. However for the Web Services generation, this concept has taken a while to re-emerge, but has now been packaged in the form of a services registry and/or repository.

Although it can be a single utility, the terms ‘Registry’ and ‘Repository’ accurately describe the functions of this new library. The Registry acts as a pointer to the correct version or instance of a service to be invoked at run-time (another gotcha of the SOA revolution is the difficulty in managing complex environments, where the same service is used by multiple processes, making maintenance and patching of these services a logistical nightmare). The Service Repository provides the more traditional library function, and provides a rich set of tags and identifiers to track what services are available, what function they provide, and where they are currently being used.

Many early adopters of SOA developed their own repositories, varying in complexity from a spreadsheet (still the most popular form) to a real time Oracle database containing all the services, attributes and relationships. Commercial SOA repositories appeared almost ten years ago and were aimed at either lifecycle management support or service governance and have been fairly slow to gain critical mass as most SOA adopters had not figured out what they would need.

It is now clear that for best practice in SOA you need support for not only lifecycle management and service governance, but also:

• Security - Ability to define roles and respective access control policies to carry out necessary task



• Version Management - Ability to assign version to a capability in design-time environment.



• Audit - Ability to monitor the changes made in the registry



• Interoperability – Given the wide range of commercial and bespoke SOA repositories in existence, the ability to share service metadata using UDDI, ebXML, JAXR and other emerging standards



• Service Catalogue – CMDB integration is now becoming essential as companies look to implement ITIL & SOA



• Taxonomy – It still amazes me how often naming standards are not addressed before development begins. Make sure you agree naming structures and conventions for ALL services.

So how do you ensure that your SOA repository is fit for purpose? The first thing to bear in mind is that is no single solution for all situations. Your environment, SOA maturity, toolsets used and development methodology will all have a bearing on the relative priorities you should give to the features mentioned above.

For your first SOA pilot, a simple spreadsheet may suffice. However, make sure you have agreed naming conventions and the list of metadata attributes you are going to need as your development grows. This will typically just provide a repository function with little need for a runtime registry for your first few deployments.

Once you start finding new web service or SOA projects springing up across your organisation, you will need to start imposing some governance, starting with an SOA Steering Committee who can agree divisional, corporate or enterprise-wide standards, as well as guidance on technologies and lifecycle management. A purpose built repository will now be needed, either off the shelf (preferably), or bespoke (if sufficient justification can be given).

As you get close to putting some of these services live, particularly on customer- or partner-facing applications, you will need to invest in a service registry to provide more security and auditing to ensure both regulatory compliance and risk management are covered.

By this time you may well have ended up in any of the following:

1. Islands of service. Your projects and/or divisions are doing their own thing. This is potentially acceptable if there is no cross-over or overlap in the services being developed and implemented. More likely, it is a failure of governance and you will need to apply some painful retro-fitting of standards and organisation.



2. Central SOA Function. All service development is controlled and managed centrally using a single Registry/Repository with strict library functionality. You will be a minority if you have reached this state, and it will provide good governance and cost/maintenance control for your development.



3. Federated SOA Function. With a central master repository, you have satellite repositories that provide specific support for different service development teams which allows them to remain innovative and agile, but retaining central control of the standards that matter. Seen as a future state for organisations that embrace SOA as their core development approach. Tends to evolve and requires a flexible and pragmatic approach to SOA. I would expect to see more of these frameworks as the SOA adoption matures further.

So, there is an overview of the SOA Repository Best Practice starting to appear in the field (as opposed to an analyst’s presentation), and I believe that we shall see more consolidation of the relevant standards to support this, vendors permitting, of course.

John Moe, Over more than 25 years, John has managed a number of strategic transformation programmes for large companies, using ERP technologies, process improvement and change management techniques to ensure successful adoption and transition.

More recently John has consulted and mentored extensively on SOA and BPM, helping individuals, teams and organisations to understand and gain significant business benefit from these architectural approaches.

A former Gartner Consulting Director, John works closely with senior IT management to remove the perceived gap between Business and IT, using a synthesis of process, people and systems to make change stick.

Bookmark / Share This

Bookmark or share this with others.