Service Orientation

Home -> Basic Concepts #Orientação a Serviços According to the w3c definition, a service is :"A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent". Three terms should be highlighted: fuctionality, provider and requester... So, in a first attempt to simplify this definition, I could say that a service represents a functionality offered by an entity (provider) on behalf of another (a requester). As presented in [Cervantes and Hall - "Technical Concepts of Service Orientation"], this functionality " is contractually defined in a service description, which contains some combination of syntactic, semantic, and behavioral information". This description should also express non-functional aspects that act as "...constraints over the functionality of the service [Non-functional requirements for information system design]".

In service-orientated computing (SOC) paradigm, services are considered reusable elements that can be connected to assemble applications or higher level services. The central idea is to promote the development of low-coupled solutions based on the dynamic discovery and binding of services, which results from the utilization of an architectural pattern reffered to as Service Oriented Architecture. This pattern is centered around of three elements (Figure 1): service provider, service requester (consumer), and service registry. The service provider is responsible for supplying a service implementation and for publishing a corresponding description in a service registry. The service consumer discovers alternative services based on a service description, select one of them, and bind to it in order to be able to make a request. Finally, the registry acts as an intermediator storing service descriptions and references, and offering a discovery API to their potential consumers. In this scenario, we say that SOA favors loose coupling once that the only information that is shared between consumers and providers is that contained in the service description.

Service-Oriented Architecture

Figure 1 - Service-oriented Architecture

In the service-oriented arena, various solutions(platforms) are available, each one based on a different set of technologies (languages, protocols, standards, etc). While defining/selecting a platform, it is very important to consider how service descriptions and compostions are specified.

• Service Description: ideally, a service description could include, besides the syntatical description of the service interface, some information concerning its non-functional aspects (quality of service attributes). It is also possible to include some semantical data and the specification of the service behaviour.

• Service Compostion: basically, a service compostion establishes not only a set of service elements, but also the control and data flows that define the interactions with these elements. These flows can be specified using standard programming languages (such as C++ or Java), workflows languages (such as BPEL), or visual languages(JOpera). Despite of the specification language, service compositions should be "abstract" at design-time. It means that its service references should be defined in terms of service description elements, enabling the dynamic (runtime) discovery and binding of the actual services. Besides enabling dynamic adaptation, this approach prevents the requester from the necessity of knowing, a priori, the service locations.