Abstract WSDL vs Concrete WSDL
A WSDL structure:
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 the 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.
Abstract WSDL(Types, Message and PortType):
It describes what the web service does, but not how it does it or how to contact it.
An abstract WSDL document defines:
- the operations provided by the web service.
- the input, output and fault messages used by each operation to communicate with the web service, and their format.
- Used on server side.
- Abstract WSDL is reusable because there is no binding details in it whereas Concrete WSDL used for specific service for which it is defined.
Concrete WSDL(Types, Message, PortType,Bindings and Services):
It adds the information about how the web service communicates and where you can reach it.
A concrete WSDL document contains the abstract WSDL definitions, and also defines:
- the communication protocols and data encodings used by the web service.
- the port address that must be used to contact the web service.
- Used on client side
- concrete WSDL contains messages, operations and binding/transport specific information i.e. SOAP over Http/HTTPS/JMS having wsdl style i.e. RPC/DOC literal
When to use Abstract and Concrete WSDL:
A WSDL structure:
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 the 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.
Abstract WSDL(Types, Message and PortType):
It describes what the web service does, but not how it does it or how to contact it.
An abstract WSDL document defines:
- the operations provided by the web service.
- the input, output and fault messages used by each operation to communicate with the web service, and their format.
- Used on server side.
- Abstract WSDL is reusable because there is no binding details in it whereas Concrete WSDL used for specific service for which it is defined.
Concrete WSDL(Types, Message, PortType,Bindings and Services):
It adds the information about how the web service communicates and where you can reach it.
A concrete WSDL document contains the abstract WSDL definitions, and also defines:
- the communication protocols and data encodings used by the web service.
- the port address that must be used to contact the web service.
- Used on client side
- concrete WSDL contains messages, operations and binding/transport specific information i.e. SOAP over Http/HTTPS/JMS having wsdl style i.e. RPC/DOC literal
 |
| Abstract vs Concrete |
When to use Abstract and Concrete WSDL:
- Suppose we have a service which calls another service within the application and if we are using concrete wsdl then we can face the caller service loading issue or caller service is in invalid state.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. To avoid such scenario, we have to use abstract wsdl and provide the endpoint in the location reference section of the composite.xml.
- Suppose if we have a service and that need to be shared with the external client who will consume this service, in this scenario, we have to use concrete wsdl to provide the address of service/endpoint to be communicated.
- MDS is generally used for within SOA application services, so we need to import abstract wsdl in MDS and use respective services to enhance the re-usability of the services.
This is helpful as a basics revision. Thanks :)
ReplyDelete