A Web services registry is arguably one of the most important components of SOA. The registry provides a single source of information about all services in an enterprise.

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.

6 thoughts on “Using Maven Repository as Web Services Registry

  1. I like that idea.
    I’m currently trying to figure out the best architecture for such an approach.
    I don’t want to keep the wsdl within the service implementation project, because I see it as a contract the developer has to fulfill.
    Also it should be versioned independently from the service implementation versioning.

    I would then like to have the wsdl file included as a dependency, so the generated wsdl during jboss deployment can be validated against the “contract”.
    However I have no idea yet on how to fetch the wsdl from the repository during the build process.

    Did you already manage to work this out?

  2. Andi,
    No, I haven’t implemented it yet but I’m planning to work on it in the near future. I’m not sure about your point about service contract versioning. While the contract won’t change as often as the implementation would, in general it still follows the lifecycle of the implementation, i.e., implementation always changes when the contract changes.

    The contract would still be independent from the implementation from the repository standpoint since there is no need to put implementation into the repository; “deploying” in Maven should only upload WSDL to the repository and not the code.

  3. You’re right. The implementation will in most cases not be published.
    My point is separation of concerns, though. Having the wsdl at hand is tempting. I’d rather have the ones who change the implementation (as you said this will happen more often than a wsdl change) depend on a frozen state of it for validation.

    My quick-and-dirty-approach:
    The wsdl dependency is deployed with type wsdl.
    In the dependency of the service implementation you must use pom for a type.
    And then the maven-dependency-plugin copies the artifact. Luckily, you can use type wsdl again here.
    No other work necessary.

  4. Andi, Alexander,

    I like the idea as well : have you gotten a chance to try this out, or have you found a better approach ?

    Thanks in advance.

  5. Patrice,
    No, I have not – the problem I’ve run into is that Maven is just not very widely used in corporate environments, I’m guessing, because it’s not very easy to customize.

Comments are closed.