Saturday, October 27, 2012

Abstract WSDL vs Concrete WSDL

In recent times, the abstract WSDL terminology is used more than ever and I am seeing more & more coffee-table discussions on this topic. In this post I will make an effort to provide an illustrated explanation in regards to the differences & usage of concrete and abstract WSDL.

First up, abstract WSDL is not a new technology. A typical WSDL (Web Services Description Language) consists of the following sections; types, messages, portType, binding & service elements. A quick look at what each of these sections define will ease the task of clarification of the differences;

Types - Defines the data type definitions for messages that will be exchanged by the web service. Generally defined from a schema (XSD)

Message - Defines the set of actual messages that will be exchanged. A message can consist of one or more parts which is a logical separation which together constitutes the message.

PortType - Defines the abstract operations provided/available and abstract messages involved. Operation refers to the messages involved in the transaction.

Bindings - Defines the message format and protocol information for operations defined by the portType.

Service - Defines the endpoint where the webservice will be exposed

Based on these definitions, we can figure out that the Types, Message & PortType sections of a WSDL definition is abstract (since it has no information pertaining to the communication protocol & how or where the service is exposed) where as the Bindings & Service section is concrete.

Hence, if we have a WSDL which just has these elements (excluding the Bindings & Service sections), then the WSDL is referred to as "Abstract WSDL". This WSDL definition cannot be used to connect to the webservice due to the 'missing information' on where & how the service is exposed. But there are certain advantages with abstract wsdl which we will see in a bit.

Definition of concrete WSDL now becomes a no-brainer. If a WSDL has all the sections - including the concrete parts such as Bindings & Service then it is referred to as a concrete WSDL. This WSDL defnition can be used to connect to the actual service since it has the protocol and service endpoint information.

Now, where exactly do we use an abstract WSDL?

Coming to the world of SOA, I am taking the example of Oracle SOA composites referencing external services. Ever wondered why some SOA composites are in "Invalid State" even though all the services that it references are up & available? This is because of the usage of concrete WSDL reference where the referenced service is not available yet when the caller service composite starts up. There is no way for the server to know about the service dependencies when it starts. By leveraging the concept of the abstract WSDL, we would be able to effectively resolve dependencies both at design time as well as runtime.

More on resolving service dependency issues in SOA on my next post here


  1. good explanation

  2. clear explanation!

  3. Excellent explanation. Thank you.

  4. hi bro,

    i have small doubt if we are calling a wsdl from MDS(runtime),i.e wsdl we are calling is abstract or concrete how could we know

    1. Your composite will have 2 sections - reference & binding. Your reference will point to abstract WSDL which is what is used while loading composite references during startup. Service binding in your SOA composite will have the actual concrete WSDL.

  5. Hi Satya,

    I like your posts. I have been started reading all of your posts and they are very informative.

    My question is related to context of this post is, what is the disadvantage of having concrete WSDL in the MDS instead of abstract. so that I no need to remove the binding and service parts of the wsdl before I store them in the MDS. At design/load time, the composite only needs types, messages and port related information and is already available in the concrete wsdl stored in the MDS. What is the disadvantage of having binging and service information in the MDS wsdl?

    1. Thanks for your comments. Think of a situation where the service has been moved/upgraded - typically in such scenario the service endpoint changes but contract still remains the same. We don't want to store the concrete wsdl (with actual service endpoint) in MDS, hence we decouple the service from its contract - Abstract WSDL helps with this design. Your SOA composite will have the reference pointing to abstract WSDl and the service binding will reference the concrete WSDL.