Service-Oriented Architectures (SOA)
Traditionally, the interaction and design of applications has been oriented based on the use and direct access of users through the presentation and user interface (UI) layers. To provide new functionality, the functional processing layer may need to add other business components and modules, as well as a data layer appropriate to the needs. These types of applications generally solve problems at the local departmental level. However, organizations have multiple departments and they all have relationships and dependencies, working together to meet the common purposes, services and objectives of the organization. Thus, these types of operations are likely to involve multiple applications.
As automation processes and integration needs increase, applications require access to functionality provided by other applications. This is very common in management systems, as for example a Customer Relationship Management (CRM) system, developed by the organization, is queried by the order processing system under the command "get invoice for the first order from customer X". If the application is well designed, there will be a coarse-grained function that provides this functionality. In this way, the application and its services will be ready to be accessed by other applications that require it, being covered under the concept of Enterprise Integration. This conception of services, their composition and use is the core of the Service-Oriented Architecture (SOA) concept.
These two figures show the main differences between the traditional architectural model and the new designs based on service-oriented architectures. Traditionally, there was a coupling between layers, which were not well differentiated and came to combine aspects of presentation and user interfaces with the business logic itself. On the other hand, emerging SOA architectures have as a fundamental principle the possibility of being accessed both by end users and by external applications and services. To this end, they require a higher degree of decoupling between layers, in addition to providing coarse-grained functions that can be easily described and used, often composed and operated by means of design patterns and Façade components. In Service Oriented Architectures, separation between layers is inevitable, so that flexibility and composition of services is easy to realize, characterizing it as a first-order entity.
SOAs are Enterprise Architectures where applications are designed and exposed to provide independent coarse-grained services. These services are accessed by business processes, other services and integration applications. For this reason, SOA is both a design concept, providing applications and systems with well-defined accessible interfaces that compose business processes, as well as an architecture, as it provides simple mechanisms to use those interfaces for effective and flexible business integrations.
SOA architectures enable systems to talk to each other in a simple way through common and standard mechanisms, such as XML/JSON over HTTP or JSONB protocols with WebSockets, to ensure loosely coupled services. These architectures facilitate the creation of stable and scalable enterprise infrastructures with a high degree of quality of service.
This design paradigm involves both the definition of UI schemas and their flows, and the specification of business services (not associated with user interfaces) by the application architects. The functional requirements of the application to be accessed from other applications are provided by accessible service methods, although this is not a trivial task and there may be several orchestration paths. Multi-tier distributed architectures and good design practices for building Java Enterprise Edition (J2EE, JAVA EE) applications with Enterprise Java Beans (EJB) already differentiate the UI and presentation from the business processing layers, establishing well-defined interfaces. However, these are SOA requirements, in addition to the need to establish coarse-grained functions that allow access by any consumer (end users, applications, integrations, third-party services, etc). These business functions expose ways for each service to be accessed by a specific method.
Access between applications is not trivial when you have multiple independent solutions and applications that need to be accessed to perform business functions, such as enterprise resource planning systems (SAP), ERPs, corporate management tools or J2EE applications for warehouse management systems (WMS). Integration needs have always existed, even using Enterprise Application Integration (EAI) platforms, through their adapter-based access model. However, in these cases there is no explicitly exposed and invoked functionality, hindering their accessibility and visibility as services.
The central design principle with SOA is, as its name suggests, Service Orientation, so that applications have to be designed from the beginning based on these, through well-defined interfaces and coarse-grained functions to operate with the exposed functionalities. Here the presentation and business layers are also well separated, but it is important to facilitate mechanisms and clearly establish the entry points to use the Façades of the business processes. However, identifying these mechanisms in the intermediate layers (Mid-Tier) is a somewhat more complex task, so a set of application attributes must be established:
- The application has a well-defined and separate functionality layer (generalized decoupling between tiers).
- The functional layer has clearly defined entry points, generally enabled by façade design patterns and specialized components as input to the service system.
- Entry points are coarse-grained functions, each of which performs business functionality that can complete itself. They are generally atomic and independent behaviors, with no upstream or downstream work from other units (e.g. a single call that requests pickup in 24h and shipment in 48h to the logistics company, manages inventory, updates all order and product statuses, as well as notifies the personalized warning message to each of the parties involved).
This architectural model and design principle is strongly linked to how corporations work, adapting to their organizational, administrative and operational functioning. Each department knows and is usually responsible for its business processes, is strongly linked to the characteristics of its operational environment and the problems it deals with, as well as being subject to an IT budget allocated by department. Thus, it can be concluded that today's IT solutions solve problems and offer localized solutions to specific problems and businesses, either intra- (applications, services and departments) or inter-corporate (applications within a corporate group or between third parties). Regardless of their location, they will all be sufficiently independent in their functions and business processes, giving rise to the concept of IT islands of applications and services.
Once the consolidation and integration is done, all the problems between applications, corporations or departments are solved, converging in localized ICT solutions (IT islands), each of which solves a business function appropriately. These principles facilitate the maintainability, flexibility and evolution of the organization's applications, improving present and future integration efforts.
This article has introduced the Service-Oriented style of ICT architecture, as opposed to the "traditional" style of application composition and integration solutions. In SOA, services are a first order entity, a fundamental part of the design principle, where each service is a well-defined unit of functionality that can be accessed remotely and acted upon independently, generally representing a business process or activity that has a specific business outcome.
This concept from the field of Software Engineering and specifically Software Architecture and Software Design is sufficiently abstract to allow a greater degree of flexibility, broadening the applicability with the objective of considering the entire enterprise organization and its business processes. Thus, it is not restricted to a specific technology, product or manufacturer. In case it is of interest, since it is a sufficiently complex principle and it is necessary to understand its design concepts, principles and patterns, Group4Layers has been developing and teaching specific courses on B2B integration and SOA architectures for ICT entities, including real examples of construction, composition and integration evolution.