Ontology-based Web Services
By toddfast on Mar 03, 2005
This demonstration facilitates enhanced discovery, composition, and transformation of business processes through semantic enablement and intelligent agents. The technology used in this demonstration can aid in the discovery of services, invoke an ABLE rules-based system, infer the processes needed, and compose the appropriate BPEL-based business processes.This goes well beyond Web service orchestration using, say, BPEL. A process expressed in BPEL is still just a developer-defined program, albeit geared toward Web service interactions. However, the process could technically be expressed in various other programming languages like Java (though arguably not as easily). By contrast, using ontology-based services and basing service behavior on updatable rules instead of a rigid, pre-conceived scenario allows for construction of much more flexible, robust, and loosely-coupled services. Imagine: rather than rebuild and redeploy a service implementation to take into account new behavior, a developer could instead add a new rule annotated with behavior and pre- and post-conditions to an already-deployed service in order to change the way it functions. This is a much more lightweight approach, and allows for complex superposition of capabilities based on rule matching.
For example, let's say you need to update your service to take advantage of a new version of a message format used between certain partners. Using today's technologies, you would have to create a new version of the service and deploy it. Depending on your environment, you may need to deploy this in parallel to the existing version and notify your partners of the new service interface and endpoint. In the worst case, you would have to update the service and lose compatibility with partners that aren't yet using the new message format.
With a rule-based Web service, however, you could just deploy new rules that would match the appropriate facts (e.g. the message format or partner) and apply behavior based on conclusions from these rules. The same service could then concurrently handle both the older and the new message formats because it would dynamically match the appropriate behavior with the incoming message.
Ultimately, these ideas speak to the inevitability of going beyond imperitive specification of behavior to functional specification of behavior. I think it will be a long, long time before we see such approaches go mainstream, but even small steps in this direction can blend with existing development techniques and provide palpable benefits in the near term--especially with tools that lower the barrier of entry and give the typical, non-Ph.D.-holding developer the capability to understand and use these technologies with a minimum of overhead.