Abstract WSDL contains only messages and operations.

Abstract WSDL is used by web Server

where as 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 WSDL(definitions )
Messages, portTypes, and operations
Concrete WSDL(implementation)
SOAP clients must retrieve the concrete WSDL file before sending a SOAP request to
the service

Abstract WSDL consists of the structure of the message that is like what operation, what is
the input and what is the ouput . Whereas in concrete WSDL has all the things that the
abstract wsdl has in addition it has transport(http,jms) details.

Abstract wsdl:- Used on server side,contains request,response and type of operation

performed.

concrete wsdl:- Used on client side,contains abstract wsdl and transport used.

An abstract WSDL document 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.

● A concrete WSDL document 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.

When we import WSDL we can see 5 tabs 1. Operation 2, Binder 3. Handler 4. WSDL 5.
policies:

Handlers: Can be used to perform various types of processing, including processing

SOAP headers, adding SOAP headers, removing SOAP headers, passing data from

the header to the endpoint service or vice versa. Provider and consumer web service

descriptors can use handlers.

In Integration Server, a handler is a set of up to three handler services. The handler can

contain one of each of the following handler services:

PUBLIC
 Request handler service

Response handler service

Fault handler service

Binder: is a webMethods term for a collection of related definitions and specifications

for a particular port. The binder is a container for the endpoint address, WSDL binding

element, transport protocol, and communication protocol information. Designer createscat

least one binder when it generates the web service descriptor based on the data in

the WSDL or IS service. The Binders tab displays the binders defined for a web service

descriptor.

You can add new binder definitions to a service first provider web service descriptor.

Binders cannot be added to a WSDL first provider web service descriptor or a consumer

web service descriptor.

You can define a separate binder for each combination of endpoint address and protocol

information that you want the service first provider web service descriptor to support.

PUBLIC
 WSDL consists Parameters types, return types, throwing exceptions, web service method
names and URL.

WSDL (Web Services Description Language: WSDL document is just a simple XML document.

It contains set of definitions to describe a web service.

WSDL is an XML grammar for describing web services. The specification itself is divided into
six major elements:

definitions
The definitions element must be the root element of all WSDL documents. It defines
the name of the web service, declares multiple namespaces used throughout the
remainder of the document, and contains all the service elements described here.
Definition − It is the root element of all WSDL documents. Contains the elements that
describe a Web service.
types
The types element describes all the data types used between the client and server.
WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML
Schema specification as its default choice. If the service uses only XML Schema built-
in simple types, such as strings and integers, the types element is not required. A full
discussion of the types element and XML Schema is deferred to the end of the
chapter.
Contains the type definitions that describe the data that is received and sent by the Web
service.
message
The message element describes a one-way message, whether it is a single message
request or a single message response. It defines the name of the message and
contains zero or more message part elements, which can refer to message
parameters or message return values.
Message − It is an abstract definition of the data, in the form of a message which
can be either as a document or as arguments.
portType

PUBLIC
 The portType element combines multiple message elements to form a complete
one-way or round-trip operation. For example, a portType can combine one request
and one response message into a single request/response operation, most
commonly used in SOAP services. Note that a portType can (and frequently does)
define multiple operations.

Port − It is a combination of a binding and a network address.

binding
The binding element describes the concrete specifics of how the service will be
implemented on the wire. WSDL includes built-in extensions for defining SOAP
services, and SOAP-specific information therefore goes here.
Binding − It is the protocol and data formats for the operations that are defined for a
particular port type.
service
The service element defines the address for invoking the specified service. Most
commonly, this includes a URL for invoking the SOAP service.
Groups ports that can be used to call Web services. A <service> element can contain many
ports.
SOAP & REST

SOAP means SOAP is a protocol, which was designed before REST and came into the picture.
The main idea behind designing SOAP was to ensure that programs built on different
platforms and programming languages could exchange data in an easy manner. SOAP stands
for Simple Object Access Protocol.

XML data format is using only SOAP webservices/Big webservices to exchange or transfer
the data from consumer application to producer application and producer application to
consumer application.

 SOAP can only work with XML format. As seen from SOAP messages, all data passed
is in XML format.

UDDI Universal description discovery and integration.it’s XML based registry. The service
providers are publishing the WSDL document in to a registry that is nothing but UDDI.

REST
REST API is an application programming interface architecture style that
conforms to specific architectural constraints, like stateless communication
and cacheable data. It is not a protocol or standard

Using Designer you can create a REST API descriptor using resource first or Swagger first
approach

Swagger firstrefers to REST API descriptors created by importing a Swagger document.

During this process, Integration Server creates services, doctypes, and REST V2 resources
based on the contents of the Swagger document.

Rest resource – select the resource type – and select the check box for
generate JSON API URL templates and click Finish
REST consists of swagger, URL, Rest resources, Rest definations.

PUBLIC
 When we execute service we need URL, Method type, Content Type -
JSON or XML, and request
Any web service that is defined on the principles of REST can be called a RestFul web service.
A Restful service would use the normal HTTP verbs of GET (To read), POST( To create),
PUT(To update) and DELETE (To delete) for working with the required components.
REST stands for Representational State Transfer.

 REST permits different data format such as Plain text, HTML, XML, JSON, etc. But the
most preferred format for transferring data is JSON.Swagger is an Interface
Description Language for describing RESTful APIs
 Swagger is a specification and complete framework implementation for describing,
producing, consuming, and visualizing RESTful web services. Swagger is language
agnostic. Swagger-enabled API, allows you to get interactive documentation, client
SDK generation and discoverability.

 The Swagger specification allows you define a set of files to describe an API. Using
these files, the Swagger-UI project could display the API and Swagger-Codegen
could generate clients in various languages.
 Swagger UI is a dependency-free collection of HTML, Javascript, and CSS assets that
dynamically generate beautiful documentation from a Swagger-compliant API.
 Swagger CodeGen is a template-driven engine to generate client code in different
languages using your Swagger documentation.
The Swagger Ecosystem provides support for various tooling built both by external parties
and the developers of the Swagger specification.

Sample WSDL File

The following figure shows a sample WSDL document.

PUBLIC
PUBLIC
 Difference between soap and REST

 SOAP stands for Simple Object Access Protocol whereas REST

stands for Representational State Transfer.
 SOAP is a protocol whereas REST is an architectural pattern.
 SOAP uses service interfaces to expose its functionality to client
applications while REST uses Uniform Service locators to access to
the components on the hardware device.
 SOAP needs more bandwidth for its usage whereas REST doesn’t
need much bandwidth.
 Comparing SOAP vs REST API, SOAP only works with XML formats
whereas REST work with plain text, XML, HTML and JSON.

PUBLIC
  SOAP cannot make use of REST whereas REST can make use of
SOAP.

 SOAP requires more bandwidth for its

usage. Since SOAP Messages contain a lot
of information inside of it, the amount of
data transfer using SOAP is generally a
lot.  REST does not need much bandwid
sent to the server. REST messages m
<?xml version="1.0"?>
<SOAP-ENV:Envelope JSON messages. Below is an examp
xmlns:SOAP-ENV passed to a web server. You can see
="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle message is comparatively smaller t
=" http://www.w3.org/2001/12/soap-encoding">
<soap:Body> {"city":"Mumbai","state":"Maharastra"}
<Demo.guru99WebService
xmlns="http://tempuri.org/">
<EmployeeID>int</EmployeeID>
</Demo.guru99WebService>
</soap:Body>
</SOAP-ENV:Envelope>
 SOAP can only work with XML format. As  REST permits different data format
seen from SOAP messages, all data HTML, XML, JSON, etc. But the mos
passed is in XML format. transferring data is JSON.

SOAP is a standard communication protocol system that uses XML

technologies to define an extensive messaging framework that allows
structured information to be exchanged in a decentralized, distributed
environment
REST, on the other hand, is an architectural style, not a protocol. As
stated above, it stands for Representational State Transfer. That
means, when a client requests a resource using a REST API, the
server transfers back the current state of the resource in a
standardized representation.
Since SOAP is a messaging protocol, securing SOAP APIs is
primarily focused on preventing unauthorized access to the
messages (and users’ information contained within those messages)
received by and sent from SOAP APIs

PUBLIC
 REST APIs only support traditional web security mechanisms, such
as HTTPS. That means when an application sends and retrieves a
message from a REST API using HTTPS, the message is secured
only for the HTTPS connection

PUBLIC