enry Ford’s development of assembly lines was of major significance to the manufacturing process. Ford brought all of the raw materials and skilled workers into a single facility and focused on the efficiency of building the entire product.

The assembly line model was in place for many years before a more global model predicated on a cheap, efficient transportation infrastructure supplanted it. In modern manufacturing, companies turn conventional wisdom on its head by decomposing the production process into optimized manufacturing with mind-boggling workflows. Sub-assemblies are produced by specialist facilities in parts of the world where it can be done cheaply and efficiently. These partial results are then sent elsewhere for further development and integration. It has reached the point that, for example in the world of dolls, there is a specific company that produces just eyes and noses!

It seems inconceivable that this new form of manufacturing would work as well as it does because of the complexities involved. Henry Ford’s model seems like it would be the right way to do it, but this new supply chain approach recognizes some fundamental principles that change the game. It realizes that there are efficiencies to specialization not exploited in the assembly line model. Not every step takes the same amount of time. Not every skill can be utilized maximally by waiting for the preceding steps to occur. By allowing each sub step to occur in one location at maximum efficiency, the overall process can be made dramatically more efficient. A finished product becomes an orchestrated workflow of materials flowing through a combination of optimized sub-steps. Not only does this have an effect on the overall cost and efficiency of the process, it also engenders an agility to respond to new demands quickly. Resilience is gained by having a distributed process that’s not as subject to the sensitivities of local politics, weather, or unexpected disasters. Retooling and rerouting to accommodate new requirements requires only localized effects. Not every facility along the chain needs to be affected and new steps can be woven in quickly without upstream dependencies.

Supply Chain Service Oriented Architecture
The supply chain vision applies to the world of service oriented architectures (SOA) and Enterprise development. Historically, this software development approach yielded vertical silos where everything was done in one place or application. Database layers feed raw content to various processing steps, which display the end results through a client-facing technology. This approach has dominated the industry’s thinking for quite some time, but this is starting to change. The single-application strategy has the same costly duplication and inefficiencies as Henry Ford’s assembly-line approach. You cannot reuse functionality locked behind the application boundary. Not every step takes the same amount of time. Costly contention for resources (e.g., database connections, processing threads, synchronized access to shared state, etc.) can affect the computational and economic costs of the entire effort. Scaling horizontally by adding more processing nodes helps, but that is too expensive and ultimately not the best strategy.

Supply chain SOA suggests a model in which you can tie together individual data sources and services on demand to produce a desired result. New requirements put minimal burden on reorchestrating a different configuration with new processes. Each piece of raw material (i.e., data) can be identified at its source and referenced as needed. It is not necessary to pass actual data everywhere, which results in costly duplication and unmanageable regulatory access control compliance. These ideas have always formed the basis behind the SOA space, but it has not been accomplished fully or cheaply using the WS-* stack.

You can implement this vision today by applying the concepts of the web in the Enterprise, combining URL-addressable RESTful web services and data sources into sophisticated, efficient processes. It is not necessary to pull all the pieces into a heavy deployment structure like conventional J2EE and .NET applications. New functionality becomes a recombination of existing information and functionality. Each step can be separately credentialed and tied into arbitrary single sign-on or other authentication and authorization systems. While many organizations commit to an Enterprise Service Bus (ESB) to coordinate all of this, the web demonstrates that this is not required. It is easy to imagine building on top of the following ideas with an ESB or without one.

What is necessary is a cheap, efficient infrastructure to identify data sources and services to allow these potentially complex orchestrations to combine with low inertia. It is necessary to find, select, and bind to these subcomponents. Users and developers cannot be expected to remember URLs, particularly as they are likely to change. Instead, a classification scheme is needed to describe all of this content and functionality via metadata. Nearly all service-oriented environments have attempted this with arguably tragic and unsuccessful results. The JINI community attempted to define a taxonomy of services for devices and software but the approach taken was not flexible enough to satisfy everyone. UDDI attempted to provide a hierarchical metadata infrastructure but ultimately failed to deliver sufficient value for the cost of implementation.

The issue with the existing approaches is that they require too much human agreement and are not universally applicable across services and data. The social costs of these efforts always far outweigh the technical costs. It is necessary to support different classification schemes because it is simply not possible to achieve consensus among all stakeholders. Additionally, it is necessary to have a consistent metadata strategy for not just the services, but the data, concepts, policies, documents, and everything else that might participate in these orchestrated spaces. This is where the Resource Description Framework (RDF) in general and the Simple Knowledge Organization System (SKOS) language come in.

By binding sub assemblies to logical URLs, it is possible to address and describe the content and services through the same technologies. SKOS builds on RDF allowing both the notion of categorization as well as the ability to mix in arbitrary metadata and perhaps competing classification schemes. When grounded in a software infrastructure that allows the registration and discovery of this metadata, all of the pieces are finally in place to achieve this supply chain vision for SOA.

Describing Services with SKOS

Figure 1. Printing ServicesHierarchy: A sample service taxonomy for printing services.

The goal of using these technologies is to describe and categorize services as quickly and easily as possible. Languages such as the Web Ontology Language (OWL) provide the ability to model domains quite accurately, but the skills and effort to do so remain outside the reach of most Enterprise developers for the near future. As discussed in the article, “Applying SKOS Concept Schemes”, SKOS is an attempt to allow simpler concept schemas (e.g., taxonomies, controlled vocabularies, etc.) to be used in place of heavier weight ontologies. Modeling taxonomies is within the skill set of modern information architects, software developers, and service-oriented architects. Figure 1 shows the represented hierarchy.

A PrintingService is a root service of a particular type that deals with services for printing documents. Below that are the concepts of LaserPrintingService and PlotterPrintingService; one for conventional documents, another for large CAD/CAM, and perhaps architectural diagrams. There are two types of LaserPrintingService concepts: ColorLaserPrintingService and BWLaserPrintingService. This does not represent a likely decomposition of services in an organization, but is merely meant to be demonstrative of the kinds of taxonomic relationships between associated services.

Listing 1 shows a sample encoding of this hierarchy in SKOS.

There is a hierarchical relationship between these concepts. You can imagine wanting to query for all PrintingServices or all LaserPrintingServices. This requires a selection of a concept and a traversal down the concept schema. Alternatively, you can imagine starting at a terminal node and wanting to find the path to the root service concept to find similar types of services. In the on-demand SOA orchestration world, you respond to what is available by presenting options to users. RDF alone is insufficient for walking these SKOS relationships. It allows straight graph pattern-matching queries; a different set of technologies is required to “figure things out” about the concepts in a taxonomy in SKOS.

OWL and RDFS Reasoners can perform inference and type entailment over knowledge bases expressed using constructs from those languages. By adopting a richer language than just RDF, it is possible to encode more information in fewer statements. Most RDF stores and platforms require some special handling to deal with SKOS data; but all the different languages that are based on RDF should be interoperable. This allows various categorization schemes and arbitrary metadata to describe the services in a SOA. You can query more realistic systems like this for all services of a certain type, or a certain version published in the last six months. You can also query the metadata for service definitions, input/output schema, etc. All of this infrastructure enables a rich, flexible supply chain SOA capable of growing more quickly than you would expect.

SOA Description and SKOS Entailment with Mulgara
The Mulgara Semantic Store is used for the rest of this article although you could substitute other systems without a lot of effort, as long as they support SKOS entailment. The fundamental choices are to commit to URLs, RDF, and SKOS. You can download Mulgara from the project site. After you have the distribution, simply run:

java -jar dist/mulgara-2.0.5.jar (or whatever the Jar file currently is called when you try)

Mulgara does not support SKOS out of the box, but Paul Gearon—one of the project’s main other-worldly forces—has created a rule-based entailment system called Krule that makes it easy to add. He has contributed the rule base used for these examples and will eventually fold them into the Mulgara system. You are free to investigate this rule base but it has already been processed for these examples. There are certainly holes in the SKOS support, but it is surprisingly simple to achieve the functionality used here, and it will be expanded over time. This rlog file is converted to an RDF description of the entailment rules by issuing this command (although you need not do this to run the examples):

java -jar dist/rlog.jar skos.rlog > skos-rules.rdf

After Mulgara is running, point your browser at the web interface:

http://localhost:8080/webui

From the web ui screen, enter the following commands. First, create four named graphs:

create ;create ;create ;create ;

Click the Submit Query button. You should see evidence of success. Next, load the SKOS taxonomy into a graph to capture the service definitions. You can add new concepts to the taxonomy later if you like, but for now, just use the PrintingServices example by issuing this command via the Mulgara web interface:

load  into ;

This encodes the taxonomy as described above. Only the statements explicitly in the SKOS file above appears in this model. For example, there is no direct RDF connection between a PrintingServices and a ColorLaserPrintingService. Simple graph match queries do not yield the desired results.

After you deployed some real services you need to describe them. In this case, categorize three (fake) services by inserting RDF triples into a service instance data graph:

insert    
into ;insert    
into ;insert    
 into ;

Here you have described three separate services as being a ColorLaserPrintingService, a BWLaserPrintingService, and a PlotterPrintingService. At this point, you could do straight pattern matches for each of the concrete service instances, but you could not search the service instance model for all PrintingServices. In order to do that, you need to load up the SKOS entailment rules into a graph:

load   into  ;

and apply it to the SKOS taxonomy expressed in the graph:

apply   to    ;

At this point, the graph should have many more triples in it than the graph. This is because the Krule engine has entailed relationships suggested by, but not expressed, in the hierarchy encoding. Now there is an explicit, bi-directional connection between the different concepts in the taxonomy. Something that is related by the predicate is now also related by the predicate in the opposite direction. Somewhat unintuitively, and are not automatically transitive. The SKOS entailment rules indicate if there is instance data that suggests:

A   B   C, then A   C.

This allows the following query to finally solve the desired problem. Given the graph, what deployed services are PrintingServices? Again, these relationships were never explicitly expressed; the Krule engine entailed them. So, the query below asks for all service instances from the instance graph where the named service category is either a PrintingService explicitly or connected to the PrintingService concept through one or more relationships:

select $instance from   where $instance   $service and 
 (   $service in 
 or $service  );

The results are all three service instances from above:

http://server1/printhttp://server2/printhttp://server3/print

Here’s the code to select just the LaserPrintingServices:

select $instance from  where $instance  $service and (  $service in  or $service  );

Running the preceding code yields two services:

http://server1/printhttp://server2/print

Conclusion
The successful adoption of a service oriented architecture requires the right balance of deployment infrastructure, metadata description, and query capability. By applying web architectures in the Enterprise you can achieve a flexible, scalable addressing scheme that hides specific backend implementation details behind logical names. After you commit to this kind of information-driven architecture, you need to describe and categorize the kinds of data and services available in this environment. RDF and SKOS provide tremendous capabilities while striking a nice balance of simplicity, expressiveness, and flexibility. If you have more sophisticated modeling needs and ontology engineers at your disposal, throwing OWL into the mix can greatly enrich your descriptive and inferencing capabilities even more.

These technologies enable the kind of lightweight, flexible, scalable, on-demand orchestrations as envisioned by the supply chain SOA metaphor in ways that lower costs and are more efficient than conventional technologies.