XSD Schema for defining Business Services at the Business Level, rather than the technical level WSDL.
The ESB.NET Business Service Definition Language (BSDL) is an XSD Schema for defining Business Services at a higher level than WSDL.
Why
Business Services need to be expressed in a manner that is expressly relevant to the service being described and does not include anything that will clutter the service definition.
Business Services aimed at being implemented with a Service Oriented Architecture approach work at this higher level of abstraction. Whether it’s explicit or not, the service definition is at this level.
WSDL is a programming & interoperability level language that does not meet the criteria mentioned. It is too low level and contains a plethora of information irrelevant at this level. In the same way that models can be used to generate source code, BSDL can be used to generate WSDL if required.
What
BSDL is basically an XSD schema that describes the ESB.NET message contents for a particular service. At runtime, it’s definition is expressed as an ESBEnvelope (or other valid ESB.NET Envelope) with the relevant documents and attachments included in the envelope. On the ESB.NET server, the Service Definition can be referenced to enforce any service level rules pertinent to the service.
The image below shows the XSD structure and an example ESB.NET Service Definition for a service.
Basically, it contains a set of nodes that describe the service name, version & description information.
It then specifies the request and response documents relevant to this service, and any related attachments.
Finally there’s service characteristics such as sync/async, priority, transaction, aggregation, availability, acceptable response time and so forth.
There’s also opportunity for further service elaboration, and the ability to specify any important attributes as far as the business is concerned in terms of nodes that should be populated. For example, if you’re using an industry standard XSD that contains many nodes (eg. Acord OLife) and this particular service requires only some of the nodes in that schema, you can choose to highlight any nodes that are say, optional in the Acord OLife XSD, but that you actually need for your service. As such, this service definition acts as a form of formal documentation or a place where you can reference any detailed documentation. Note that the fields such as SpecialRequirementsConstraintsAndComments can be used to reference an external document etc. as required.
The idea is that this definition is to be the primary source of information for services.
As you can see, information such as this is not at all addressed by WSDL, however, using some of the info in this XSD, namely using some of the mandatory nodes in the “Service” node.
Example
Benefits
The benefits of BSDL over straight WSDL are now immediately obvious. There are no deployment level descriptions and method level parameter clutter to confuse the issue & scare away business users.
This information is of course needed at some point, but not at this level, as some of it it changes from environment to environment (eg. Dev/staging/prod etc.). Also, with ESB.NET, there is a single WSDL that takes all these parameters as an ESBEnvelope XML node, so creating a WSDL for each service is not necessary. There’s already a generic one available, although you may wish to create a more specific one for each service if you like, and this would be a straight forward exercise as the parameters are always similar. You may have namespace issues for your proxy classes though but more on that in another article…
Being a pure message based architecture, the information in BSDL focuses on the name and business data for a particular service. All other nodes are optional (with some implied defaults – eg. Synchronous behavior is assumed if not specified).
With this setup, everything you need to describe a service is stored in one place, and if used with ESB.NET, you don’t need to look at WSDL ever again. BPM tools can also build in this abstraction so that invoking services is as simple as pointing to a BSDL and passing in the necessary data (in much the same way as is done with WSDL), except that all services are then alike and changing service invocations is a matter of data manipulation rather than mucking around with WSDL & proxies etc.