Web service architecture
In a Web service architecture, a service description covers all the necessary details to grant the service interaction, including messages’ format, transport protocols, and physical location. This interface hides service implementation details, allowing the same service can be used independently of the underlying hardware or language, thus making Web services-based applications component-oriented, making those components available for reuse. The Web services architecture is shown in Fig. 1.4.
The three entities of Web services architecture are as follows-
(i) Service Provider-
This is the service’s owner from the business perspective. From the architectural approach, this is the platform that is accessed in the service request. It is also the entity that creates the Web service, being responsible to make its description in some standard format and publish its details in a central registry.
(ii) Service Requestor-
It is an application that invokes or initializes some interaction with the service. It could be a web browser or even a non-user interface program such as another Web service. By using the service description it is possible to discover and invoke Web services.
(iii) Services Registry-
It is the place where service providers publish their service descriptions. Service requestors search the registries, fetching binding and description information both during the development time (static bindings) or run time (dynamic bindings).
There is the service description whose contents describe interface and implementation details, including data structures, operations, and network binding information. Also, it contains data to simplify the service requestor’s searching process. The service is the software deployed through the network by the service provider.
Some are common operations used in Web services architecture are –
(i) Bind-
When a service must be accessed, this operation invokes and initializes interaction within its caller in runtime, using binding information provided by the service description to both locate and contact it.
(ii) Publish-
Service must be published in a service registry to be accessed. The service provider thus contacts the service registry to publish the service.
(iii) Discover-
A service requestor finds a description of the service or queries a service registry for the required service type. A service requestor can find a service interface description in both run time and development time. Then, the necessary information regarding bindings and locales to invoke a service is found and contacted.
Define conceptual layers in Web services.
Web services conceptual layers are shown in Fig. 1.5.
(i) Service Publishing and Discovery –
These two layers use the universal description discovery and integration (UDDI) standard to discover and publish information regarding Web services.
(ii) Service Description –
The description of the service is done using the Web services description language (WSDL), which defines the interface and interaction mechanisms of the service, further describing additional information such as context, quality of service, and service-to-service relationship.
(iii) XML-based Message –
This layer uses the SOAP protocol as the message exchange technology standard, which stands for the exchange of information in a distributed, decentralized environment.
(iv) Network Tier –
It is the base layer that represents protocols such as HTTP, FTP, SMTP, POP, etc. This tier is used accordingly to the needs of the applications – security, availability, performance, and reliability.
