SOA Repository Best Practice

SOA Repository Best Practice
By: John Moe, Head of Business Integration, TORI Global
Tuesday, December 8, 2009

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.

Read On....