Services Oriented Architecture is now a wide spread approach and Web services tools and implementations are becoming quite mature. It seems like nothing can stand in the way of SOA and Web services success. However, not all SOA integration projects are so simple. Not because SOA is not a very powerful and flexible architectural approach, but because some old problems are still with us and are getting worse. I refer to the problem of correctly interpreting data and data definitions used by the applications or partners with which you are trying to integrate. Data elements, like those defined by XML Schema, can be named the same but be used to hold entirely different data. Likewise, two elements intended for the same purpose, can be have quite different names. A similar statement can be made about Web services operations, for which the operation name is really not sufficient to tell use what the operation does with its input.
Many people in the Web services community are proposing to address development cost and integration errors caused by these problems by applying formal semantics. The approach is called Web services semantics or semantic Web services. I talked earlier about the fact that the W3C is in the process of creating a new working group to address Semantics in Web services by adding annotations to WSDL documents. An important input document for that working group is our WSDL-S specification.
To help developers explore this area and try to determine how semantics can aid in the creation and maintenance of SOA solutions, we have just updated our ETTK package Semantic Tools for Web Services. This new release allows you to annotate you WSDL with references to a semantic model, or ontology, support that has been greatly enhanced over the initial release. It also, supports searching for services that match a given WSDL interface. Matches can be individual services or compositions of services, represented by automatically generated BPEL documents. A match can be examined to see how the inputs and outputs of the discovered match correspond to the original interface. The tool then can generate a mediation file that contains information to help create the "glue" code that might be needed to use the matched service. Other features like ontology browsing and editing are also included.
I have talked to companies who are now documenting the semantics of their services using Word documents. This is a step in the right direction, but not something that can be used by tools to help automate the process of SOA solution creation. Using formal semantic models and WSDL annotation, we can enable tools to really help improve the development process. The Semantic Tools for Web Services is an good example.
Is it time for SOA developers to start thinking about semantics?