There are a number of commercial registry/repository products but all of them are quite pricey. Also, smaller organizations or organizations just starting with SOA may not need the full power of a commercial registry/repository product; most of it functionality will remain unutilized. On the other hand, existing registries do not do a particularly good job of managing dependencies between services as well as between service consumers and service providers. Dependency management must be a key consideration in SOA since, unlike in the case of monolithic applications, an SOA consists of a large number of “moving parts”, that is, services. In a well developed SOA most services depend on other services and these services in turn may rely on some other services. Being able to manage and analyze services dependencies is required in order to be able to implement robust and maintainable SOA.

Open source Maven project has become something close to a de-facto standard in the area of dependency management for building Java-based projects and components. Also, Maven dependency mechanism can be used with any Ant build by utilizing Maven Ant dependency tasks (i.e., there is no need to migrate existing Ant build processes to Maven). Maven also has a pretty sophisticated repository support allowing implementing custom central repositories as well as local repository snapshots. Projects like artifactory further enhance Maven repository and add nice UI.

So why not use a Maven repository for storing Web services artifacts, such as WSDL, schemas and policy files? Each service or a group of related services from the same service provider can have its own POM. Using Maven (i.e., by executing “deploy” goal) service providers can publish WSDL and other artifacts (but, obviously, no binaries) along with their POMs in a Maven repository. Service consumers could then download these artifacts based on the dependencies defined in their POMs. If the version stays the same, service consumers don’t need to do anything. In case of a change, service consumers may need to make changes to their client’s implementation, including re-generating client’s classes (this is, of course, a manual process that requires some analysis of the changes). In other words, the process is very similar to how we deal with changes in APIs in third-party libraries.

The entire process can be supported by out-of –the-box Maven build process. The only required change is a custom artifact handler to support new “service” extension and packaging type.

An existing change management process can be adapted for Web services so that service consumers are notified about new versions and their backward compatibility. Again, there is nothing new here; most organizations already have a change management process in place to handle changes in shared libraries.

Using Maven for managing Web services releases and dependencies has multiple benefits:

• Ability to use full range of Maven dependency management capabilities including version range dependency, snapshot and central repositories and so on.
• Ability to use Maven dependency reports for dependency analysis.
• Web services dependency management is consistent with the dependency management process used for other artifacts, such as jars, wars and so on. Commercial repository products often provide a proprietary mechanism that can only be used for Web services - related artifacts.
• Tight integration with any Maven or Ant-based build process, no need for using UDDI or proprietary APIs for publishing services.
• Service consumers that do not use Ant or Maven could still participate in the process by downloading Web services artifacts manually using UI provided by Artifactory or a similar product (although using automated approach should be the preferred option).

Of course, the Maven-based approach does not do anything for managing and enforcing (including run-time enforcement) of Web services policies which is something that commercial registry/repository products can do quite well. So organizations need to evaluate the need for a commercial registry/repository based on types and complexity of the policies they would like to enforce. In many if not most cases the policies are quite straightforward in which case Maven-based solution becomes a viable option. ]]> http://myarch.com/using-maven-repository-as-web-services-registry/feed 6