A similar concept is that of a service. A service is also a unit of reuse corresponding to a piece of functionality, described in a standard language, with published interfaces through which the service execution can be requested. A service, however, is technology-neutral in the sense that it can be invoked using standard communication protocols, while a component is usually technology-dependent as a client needs to use the same technology as the component.
A service is also discoverable, meaning that it can be used by clients independently of where it is located – service repositories can be accessed to locate services according to their definitions. A service-oriented architecture (SOA) structures software as a set of services.
The notion of services being accessed remotely through a web browser – software as a service (SaaS) – is popular now with systems such as those provided by Google (for example, Gmail and Google Docs).
Services may not be owned by the organisation developing the software systems that use them. They come with a service description and reside in a provider server. Programmers (consumers) who use them in their systems do not have access to the code that implements them – they need to find them in a registry of service descriptions and once found they can invoke them (see Figure 4).
Components tend to relate to entities, while services relate to processes. Components are assembled together through connectors (usually called glue) that are static structures, while services are bound at run-time in a dynamic way when they are discovered (Mašek et al, 2009).
Layers, components and services are different ways of structuring an architecture. They can also be used in conjunction with each other.
Activity 7 Reuse
- a.What are the characteristics of a component?
- b.How does the concept of an architecture contribute to component reuse?
- c.Which form of decomposition might be used in a software architecture?
- d.What are the similarities and differences between components and services?
- a.A component is a module that is considered to be a sufficiently good abstraction for the problem in hand. A component should be capable of being reused in future projects having the same software architecture, or being easily replaced at a later date within the existing software system. As with all modules, a good component has a well-defined interface and is an encapsulated abstraction of a well-understood concept, with strong cohesion and low coupling.
- b.The architecture of a software system embodies high-level decisions about the overall structure of the system, and this architecture may apply to more than one system.
- c.The basic form of decomposition used in a software architecture is partitioning to meet a number of separate concerns, each concern being addressed by a subsystem. For example, you might want to separate the user interface layer from the core business services layer, or you may decide to build or reuse components and/or services for some of the partitions.
d.There are similarities between a service and a component. They both promote reuse and flexibility. They both use public interfaces to allow requesters to make use of their functionality without relying on their implementation.
There are differences too. A component is usually implemented in a specific object-oriented technology, therefore only clients compliant with that technology can easily communicate and integrate with it. In contrast, a service uses communication standards that allow the interoperation of diverse technologies.
Finally, components tend to be associated with business entities, while services tend to be associated to business processes – they may realise part or the whole of the functions within such a process and may involve several business entities. Be aware that although this is a widely accepted classification, not everyone follows it, and you may see components called services and vice versa.