Reference: Sommerville, Software Engineering, 10 ed., Chapter 18

 

A web service is an instance of a more general notion of a service: "an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production."
The essence of a service, therefore, is that the provision of the service is independent of the application using the service. Service providers can develop specialized services and offer these to a range of service users from different organizations.

Services are reusable components that are independent (no requires interface) and are loosely coupled. A web service is:
A loosely coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols.
Services are platform and implementation-language independent.

Benefits of a service-oriented approach:

• Services can be offered by any service provider inside or outside of an organization so organizations can create applications by integrating services from a range of providers.
• The service provider makes information about the service public so that any authorized user can use the service.
• Applications can delay the binding of services until they are deployed or until execution. This means that applications can be reactive and adapt their operation to cope with changes to their execution environment.
• Opportunistic construction of new services is possible. A service provider may recognize new services that can be created by linking existing services in innovative ways.
• Service users can pay for services according to their use rather than their provision. Instead of buying a rarely-used component, the application developers can use an external service that will be paid for only when required.
• Applications can be made smaller, which is particularly important for mobile devices with limited processing and memory capabilities. Computationally-intensive processing can be offloaded to external services.

Service-oriented software engineering is as significant as object-oriented software engineering. Building applications based on services allows companies and other organizations to cooperate and make use of each other's business functions. Service-based applications may be constructed by linking services from various providers using either a standard programming language or a specialized workflow language.

Service-oriented architecture (SOA) is a means of developing distributed systems where the components are stand-alone services. Services may execute on different computers from different service providers. Standard protocols have been developed to support service communication and information exchange.

 

Benefits of SOA:

• Services can be provided locally or outsourced to external providers
• Services are language-independent
• Investment in legacy systems can be preserved
• Inter-organizational computing is facilitated through simplified information exchange

Key standards:

• SOAP (Simple Object Access Protocol): a message exchange standard that supports service communication
• WSDL (Web Service Definition Language): allows a service interface and its bindings to be defined
• WS-BPEL (Web Services Business Process Execution Language): a standard for workflow languages used to define service composition

Existing approaches to software engineering have to evolve to reflect the service-oriented approach to software development:

• Service engineering (software development for reuse): the development of dependable, reusable services.
• Software development with services (software development with reuse): the development of dependable software where services are the fundamental components.

A service can be defined as:
A loosely-coupled, reusable software component that encapsulates discrete functionality which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols
A critical distinction between a service and a component as defined in CBSE is that services are independent. Services do not have a 'requires' interface. Services rely on message-based communication with messages expressed in XML.

The service interface is defined in a service description expressed in WSDL (Web Service Description Language). The WSDL specification defines:

• What operations the service supports and the format of the messages that are sent and received by the service. The 'what' part of a WSDL document, called an interface, specifies what operations the service supports, and defines the format of the messages that are sent and received by the service.
• How the service is accessed - that is, the binding maps the abstract interface onto a concrete set of protocols. The 'how' part of a WSDL document, called a binding, maps the abstract interface to a concrete set of protocols. The binding specifies the technical details of how to communicate with a Web service.
• Where the service is located. This is usually expressed as a URI (Universal Resource Identifier). The 'where' part of a WSDL document describes the location of a specific Web service implementation (its endpoint).

Current web services standards have been criticized as 'heavyweight' standards that are over-general and inefficient. REST (REpresentational State Transfer) is an architectural style based on transferring representations of resources from a server to a client. This style underlies the web as a whole and is simpler than SOAP/WSDL for implementing web services. RESTful services involve a lower overhead than so-called 'big web services' and are used by many organizations implementing service-based systems.

The fundamental element in a RESTful architecture is a resource. Essentially, a resource is simply a data element such as a catalog, a medical record, or a document. In general, resources may have multiple representations i.e. they can exist in different formats.

Resource operations:

• Create - bring the resource into existence.
• Read - return a representation of the resource.
• Update - change the value of the resource.
• Delete - make the resource inaccessible.

The Web is an example of a system that has a RESTful architecture. Web pages are resources, and the unique identifier of a web page is its URL.

• POST is used to create a resource. It has associated data that defines the resource.
• GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser.
• PUT is used to update the value of a resource.
• DELETE is used to delete the resource.

Disadvantages of RESTful approach:

• When a service has a complex interface and is not a simple resource, it can be difficult to design a set of RESTful services to represent this.
• There are no standards for RESTful interface description so service users must rely on informal documentation to understand the interface.
• When you use RESTful services, you have to implement your own infrastructure for monitoring and managing the quality of service and the service reliability.

Service engineering is the process of developing services for reuse in service-oriented applications. The service has to be designed as a reusable abstraction that can be used in different systems. Generally useful functionality associated with that abstraction must be designed and the service must be robust and reliable. The service must be documented so that it can be discovered and understood by potential users.

Stages of service engineering include:

• Service candidate identification, where you identify possible services that might be implemented and define the service requirements.It involves understanding an organization's business processes to decide which reusable services could support these processes. Three fundamental types of service:
  • Utility services that implement general functionality used by different business processes.
  • Business services that are associated with a specific business function e.g., in a university, student registration.
  • Coordination services that support composite processes such as ordering.
• Service design, where you design the logical service interface and its implementation interfaces (SOAP and/or RESTful). Involves thinking about the operations associated with the service and the messages exchanged. The number of messages exchanged to complete a service request should normally be minimized. Service state information may have to be included in messages. Interface design stages:
  • Logical interface design. Starts with the service requirements and defines the operation names and parameters associated with the service. Exceptions should also be defined.
  • Message design (SOAP). For SOAP-based services, design the structure and organization of the input and output messages. Notations such as the UML are a more abstract representation than XML. The logical specification is converted to a WSDL description.
  • Interface design (REST). Design how the required operations map onto REST operations and what resources are required.
• Service implementation and deployment, where you implement and test the service and make it available for use. Programming services using a standard programming language or a workflow language. Services then have to be tested by creating input messages and checking that the output messages produced are as expected. Deployment involves publicizing the service and installing it on a web server. Current servers provide support for service installation.

Existing services are composed and configured to create new composite services and applications. The basis for service composition is often a workflow. Workflows are logical sequences of activities that, together, model a coherent business process. For example, provide a travel reservation services which allows flights, car hire and hotel bookings to be coordinated.

Service construction by composition:

Formulate outline workflow

In this initial stage of service design, you use the requirements for the composite service as a basis for creating an 'ideal' service design.

Discover services

During this stage of the process, you search service registries or catalogs to discover what services exist, who provides these services and the details of the service provision.

Select possible services

Your selection criteria will obviously include the functionality of the services offered. They may also include the cost of the services and the quality of service (responsiveness, availability, etc.) offered.

Refine workflow

This involves adding detail to the abstract description and perhaps adding or removing workflow activities.

Create workflow program

During this stage, the abstract workflow design is transformed to an executable program and the service interface is defined. You can use a conventional programming language, such as Java or a workflow language, such as WS-BPEL.

Test completed service or application

The process of testing the completed, composite service is more complex than component testing in situations where external services are used.