sapienti sat: Making SOA Ready for the Enterprise

Let's try to do it right

In a previous post we tried to scope the problem of service categorization, identified the common traits of successful taxonomies and pointed out some limitations of existing approaches to service categorization. Today I wanted to leverage all this as a basis for defining the scope and requirements for an enterprise-grade Service Taxonomy Utility or STU. Let us start with some basic

Assumptions

about the perceived users of service taxonomies.

1. Each service provider wants to maximize the usage of their service. This does not have to be number of invocations and might mean number of consumers, uses or simply to prevent duplication. Service providers usually fulfill some need by publishing a service's availability. This could be a business need, such as usage charge, support for other revenue streams, or just good will towards partners. Service provider could also be motivated by non-business reasons, such as regulatory or policy compliance. In either case people would not be promoting their services if they do not want them to be found and utilized or at least considered.
2. Service consumers build applications that invoke services to satisfy specific needs. The searching that is done at design time or runtime by a service requester is not based upon casual curiosity, it is intended to find the best; service available to invoke for a particular purpose.
3. There can be no single taxonomy to classify all possible services from every point of view. Many taxonomies of services will coexist on multiple levels.
4. Services can appear in one or more categories in one or more taxonomies. Different consumers will use different taxonomies, that best match their view of the service domain and will follow different paths to get to a service.
5. Finally, only humans can determine what business need is satisfied by a particular service. Artificial intelligence techniques for the foreseeable future are no substitute for human judgment in determining, based on the description of the category, whether the services within that category match the required business need.

Based on this foundation we can define a set of

Functional Requirements

for a Service Taxonomy Utility (STU), which can be used in SOA implementations on enterprise, industry and global levels.

1. STU should support multiple hierarchical taxonomies.
2. STU should support non-hierarchical (“see also”) relationships between nodes.
3. STU should support typed relationships between nodes in taxonomies. The types should be user-definable but should be able to express generalization, aggregation, refinement, type-of and equivalence.
4. It should be possible to annotate nodes with plain text and XML descriptions.
5. STU should allow to import an external taxonomy.
6. STU should support unique identification of taxonomies, nodes and relationships.
7. STU should support federation by stubbing internal or external taxonomies to nodes in other taxonomies.
8. STU should support versioning of taxonomies, nodes and relationship types.
9. STU should support deprecation of taxonomies, nodes and relationship types. Users can browse and search in deprecated taxonomies and nodes, but service publishers should not be able to publish into them.
10. STU should support both direct (nodes-to-entities) and reverse (entities-to-nodes) referential models. This would ensure that category-based searches will be supported with booth cooperating service registries and repositories, which can express relationships to the categorizing taxonomy nodes as part of the metadata associated with services and with non-cooperative ones.
11. STU should provide security. There will be three primary types of actors using the STU: administrators who create and maintain taxonomies, publishers who register their services in the defined taxonomies, and users who browse the taxonomies to locate the services they need. Security requirements for each type of actor are outlined below.
    1. STU administrators should be able to create and modify taxonomies, and delegate administration rights to individual nodes and sub-trees.
    2. Service publishers should be able to register services to taxonomies, individual nodes and sub-trees.
    3. STU Users should be able to browse taxonomies and search within them. The read access should be granted on per-node basis. The users will not be able to go into or under the nodes to which they do not have access.
12. STU should provide GUI-based and programmatic access to all functionality.
13. STU should provide notification capability to inform interested parties when certain changes occur. Users should be able to register to receive notifications by event scope and type. The scopes include taxonomy, node, sub-tree; and the event types: service published, unpublished, object deprecation and change.

So what?

That is a perfectly valid question. I do not think that a COTS STU solution exists that meets all of this requirements and can be used out of the box, so I see two possible roads that lead to the desired end result: build and adapt. The first one is fairly obvious and in my estimate in about 6 man-months a production-ready solution can be put together by a small competent team. Investing a man-year will deliver lots of nice bells and whistles. The second option is more interesting – essentially what I have described so far is a narrow specialization of an XML repository. In particular, I have discussed these requirements with Farrukh Najmi one of the authors of ebXML Registry Repository standard and the lead of the freebXML Registry project, and he told me that 95% of the above requirements are met by the version 3 of the Registry. I have not had a chance to verify this myself, but if anyone out there wants to try it, I would be very grateful to hear about the outcome.