Services and Service Computing

1. The Concepts Of Services And Service Computing

As a general term, service is broadly considered as an application of specialized knowledge, skill, and experience, performed for co-creation of respective values of both consumer and provider (Qiu, 2007). In economics, service is considered as an intangible equivalent of economic goods or intangible commodities. In the computing world, a computer software support service is the computing or computational execution of a software unit that encapsulates certain business rules and logic for meeting a defined business operational need. It depends on the levels of granularity applied in a given application; this unit might be simply a software object or sophisticatedly a complex and intelligent business process module (Figure 1).

Figure 1.

Support services offered at different levels

Frequently, a computer software support service is called a computing service, IT support, IT service, or simply service. In enterprise integration, a service is essentially defined as a specific integration need. Technically, it provides a designated data or function sharing across distributed applications in support of automated business operations. At a given time, when an application provides a service, the application is called a server, and an application that needs such a service is called a client. The client makes an invocation to consume the service. An application might play a different role at a different time, depending on whether the application is providing or consuming the service.

For example, in the example of adding a new student in Lion College’s Roster System, a service that allows other applications to add a new student’s information in the Course System is considered as a designated integration need. This remote service is provided by the Course System. Whenever a new student is added in the Roster System, this service will be then invoked remotely by the Roster System, which makes sure that the same student’s information is successfully inserted into the Course System.

As discussed in earlier chapters, the successful execution of a remote invocation between disparate and heterogeneous applications requires not only a solid and sound design but also a well-executed implementation. In particular, integration practitioners should be aware that:

• •

  Regardless of the granularity level at which an interaction occurs, the interface concept, design, enterprise integration architecture, and supporting technology should always be the first taken into consideration as soon as an integration project is launched.

• •

  CORBA or the like middleware can be used as an integration platform when appropriate. The middleware-based approach in general is better than a RPC-type integration approach. An organization frequently ends up with a variety of computer applications after years’ investments on information technology. Thus open standards that are usually applied in the middleware make enterprise integration not only more effective and efficient but also more applicable and realistic than proprietary integration methods in the long run.

• •

  Asynchronous communications typically enhance enterprise integration as they promote and support loosely coupled interactions among the distributed applications, which substantially improve enterprise integrated systems’ availability, scalability, and performance.

• •

  Indeed, asynchronous messaging is considered superior to synchronous messaging in many aspects in implementing enterprise integration. Integration practitioners should be aware that certain circumstances may prove that synchronous communications would make more sense than asynchronous communications in enabling interactions between applications. For example, there are always voluminous data transmissions needed between distributed applications, or an immediate response to a validation request is a must for a client application before it can proceed.