I am working on the development of a descriptive framework that is usable for all services, including electronic and business services. Electronic services can be described (however imperfectly) using the Web Services Description Language (WSDL). while not perfect, WSDL does have the advantage of being widely adopted for SOAP-based web services. When carefully assembled, web services can be chained together into an executable workflow to perform some useful task.
There no analogous way to assemble a workflow from business services. While a business process can be described using BPMN, there is no way to automatically screen business service providers to determine whether they are suitable for performing a particular task within a given workflow. What is lacking is a WSDL for business services.
We need a machine-processable description of the services offered by a business. This description should include the tasks performed by the service (i.g., its effects), the inputs required to engage the service, the outputs that will be produced by the service, and any preconditions that must be satisfied before engaging the service. To the maximum extent practical, this description should be compatible with existing WSDLs — there is no logical reason electronic services cannot be combined with other services to form a complete workflow, so the descriptions of both services types should be compatible.
I’ve spent some time lately working on just such a service description, and over the weekend I turned my notes into a detailed class model that I exported into an XML schema. Next i need to do a detailed comparison with the WSDL schema to ensure I have accounted for all elements of the WSDL. After making any necessary refinements I will try some practical applications to see how it handles.
As best I can determine, nothing of this type has been developed to date. I had planned to call it a “Business Service Definition Language,” but I discovered that name was already taken by several researchers from the University of Wollongong who have published an interesting paper on the subject. Luckily for me, their research is in a different direction from mine even though they arrived at the same terminology. Universal Service Description Language is already taken. I considered General or Generic Service Description Language, but those seem too… generic.
So for now, it’s back to thinking of an appropriate name for my creation.