Service Oriented Architecture
Currently, Web services represent the most widely used technology to expose the business logic implemented by enterprise applications on the web (internet and intranet). Through the adoption of web services it’s possible to encapsulate the application-logic, exposing it as a set of reusable services, promoting the interaction and the integration of the different applications (business to business integration) and minimizing the inefficiencies introduced by human actions.
This new distributed collaborative structure brings a set of advantages:
- Software as a service: Unlike traditional software, a Web service can be delivered and used as a cross-platform communication channel. Web services allow encapsulation: the application components can be isolated so that only the layer that represents the actual service is exposed outside. This has two key advantages: independence from the implementation and security of the internal system.
- Interoperability: The business logic encapsulated inside a Web service is fully decentralized and accessible through the internet from any platform, device or programming language.
- Standards: The concepts behind Web services are governed by specific standards that are universally recognized and approved by the largest and most important companies in the world of Information Technology.
- Ease of development: Developing a set of Web services around a layer of existing software is a simple task that should not require changes to the original application code. Thanks to a huge number of tools, the incremental development of a Web service-based application has become simple and natural, even in the open-source world.
The strength of Web service technology is the standardization and communication that takes place through the exchange of information in a textual format. On the one hand this limits the performance for the processing overhead of the message semantics, but allows different software platforms to talk each other.
In recent years, Web services have became part of the larger picture that is Service Oriented Architecture (SOA). It defines a new logical model for software development, providing not only an architecture of services seen from a technological perspective, but also policies, best practices, and frameworks by which we ensure the right services are provided and consumed.
It’s important to remark that the SOA approach is not only related to the Web service technology, but has a much wider scope and its principles can be applied to all kinds of software development. Basically, we have progressed over time from software modules or libraries, to objects, to components, and now to services. In the context of software services, the Web services technology provides us with certain architectural characteristics and benefits such as platform independence, loose coupling, self description, and discovery. They can enable a formal separation between the provider and the consumer because of the formality of the interface. But services, whether implemented through Web services or not, can be designed in different ways: they can be published as a general purpose API, which, for example, simply provides Create, Read, Update, and Delete (CRUD) access to a database. The drawback to this approach is that it requires users to understand the underlying data model and to follow the business rules to ensure the integrity and the coherence of the data. This is an example of services without SOA.
In fact, one of the main rules of the SOA paradigm is to assemble and reuse existing services providing added-value services exposed with coarse-grained interfaces that meet business-process requirements. It means that in a SOA architecture, services exposed outside should not be low-level and fine-grained like the CRUD-style API mentioned in the above example. Instead they should implement complex process-oriented business-logic, providing an abstraction layer to the underlying implementation.
The following picture illustrates how the level of granularity depends on the purpose of the software entity. The level of granularity for services tends to be coarser than the level of granularity for objects or components.
One of the primary benefits of the SOA approach is the ability to compose applications, processes, or more complex services from other less complex services. This activity, called “service composition”, allows developers to compose applications and processes using services from heterogeneous environments without regard to the differences and details of those environments.
The picture above shows the nine layers that are involved in a typical SOA architecture:
- The Data and Applications Layer: composed of the existing software systems and databases
- Enterprise Components Layer: the set of software components like EJBs, APIs, etc. that interacts with the data layer
- Services Layer: contains the software components which implement more coarse-grained business operations, invoking the fine-grained “data-centric” services exposed by the component layer
- Business Process and Orchestration Layer: represents the aggregation of services into a sequenced process to satisfy the needs of a business requirement
- Presentation Layer: the layer where enterprise services are exposed to end users through UI elements that can be reused across multiple applications
- Integration Layer: provides the ability to mediate, aggregate, split, transform, route and transport service requests reliably from the service requester to the service provider
- Quality of Service (QoS)- Security, Reliability, and Scalability Layer: provides the architecture with the capabilities required to meet non-functional requirements
- Governance Layer: covers all aspects of the service life-cycle management
Adding a Web service communication channel between two systems in software architecture can lead to the creation of many individual point-to-point connections which are difficult to maintain. In a future article we’ll see how an important piece of a SOA-based technology infrastructure, the Enterprise Service Bus, can help organizations to implement a service oriented architecture, avoiding the above mentioned problems related to the point-to-point interactions, and providing a framework that ensures a robust communication mechanism, intelligent routing, and sophisticated translation and transformation of services.
Author: Luciano Blasetti
