Service-oriented architectures (SOA) have brought significant gains for process automation. According to the official definition of OASIS [1], it is a paradigm for organizing and utilizing distributed resources that may be under the control of different domains of ownership.
Although the official definition may be ambiguous, it is possible to define SOA as a paradigm for designing software systems from reusable components designated by services [3], [2], with service being a set of code blocks that perform distinct functions [4], [5], [6]. The goal of SOA-based development is to enable organizations to build business systems from simple modules to obtain flexibility, agility, and productivity improvements in their business development [3], capable of relating business processes to technical processes [7] and mapping workflow relationships between them [4]
SOA is usually based on the principle of providing reusable business services that can be assembled from software sub-components in such a way that the provider (who makes the service available) [3] and the customer (who uses it) are considered loosely coupled [4] (definition of the neutral interface that is not strongly tied to a particular implementation) [6]. They do not need to have an in-depth knowledge of each other, from the technologies, platforms [8], location, or environments around them, and the code can be reused thanks to their neutral interface features, making it easy for developers who need only discovering the interfaces of already developed applications, rather than building new systems from scratch whenever new business rules are changed or added [9].
SOA services have components that relate through well-defined interfaces and contracts. The interface is defined neutrally and independently of the hardware, operating system, and programming language [7] in which it is implemented, allowing these services to interact with one another uniformly and universally.
The architecture’s ability to have loosely coupled services allows service providers with these characteristics to benefit from their agility and ability to survive the constant changes in the structure and internal implementation that make up the application [4]. In addition to having services such as a key component of architecture, SOA is also comprised of service interfaces that enable vendor-customer interaction.
SOA – Guiding principles for achieving SOA
Although there is no official standard for SOA composition, the community agrees with four fundamental principles as guiding principles for achieving SOA [10], where they are, service boundaries must be explicit [11]; services must be autonomous [7]; customers and services should share contracts and not code; and finally the possibility of policy-based compatibilities. Policy-based compatibility understands that two orthogonal requirements must be supported when interacting with a service. Vendor functionality, syntax, and semantics must meet consumer requirements; and the skills and technical needs must match. However, functional aspects are described in the service interface, but capabilities, orthogonal and nonfunctional needs are specified using policies [12].
SOA architecture is also known as an evolution of client/server architecture, where business logic is broken down to lower levels of granularity, based on the ideas and technologies implemented in XML and WS [4]. WS is known as a software system designed to support interoperable machine-to-machine interactions with key elements [3], [6]:
- Web Services Definition Language (WSDL), the standard for representing pieces of software;
- Simple Object Access Protocol (SOAP), a protocol for information exchange in a decentralized and distributed environment;
- Universal Description, Discovery, and Integration (UDDI), XML-based service registration engine. Allows services to be discovered on the web and make interoperable. It is compared to the yellow pages of a phone book, where companies can list themselves by name, product, location, or the services they offer.
Gains in the organization and software development when using SOA
Thus, communication with WS is done from the network using technologies such as XML (data fundamentals and protocol related), WSDL (service description related), SOAP, and UDDI (Figure 1), these are capable of providing a common approach to defining, publishing, and using WS accessible through a standard protocol, specifically SOAP [5]. A WS usually allows the discovery of the service, the customer requests the provider, the provider processes the request, and sends the response to the customer [3],[6].
Parallel to the use of SOAP, WS also allows the use of Representational State Transfer (REST). REST is an architectural style that typically uses HTTP / HTTPS, while SOAP is network layer independent and can use a variety of network protocols.
WS can be said to provide the base technology for implementing the SOA architecture, but it is not the only one. Common Object Request Broker Architecture (CORBA) vendor-independent architecture and infrastructure that enables systems to communicate over a network [13] and Message-Oriented Middleware (MOM) systems that support general-purpose messaging in environments distributed systems [14]) can also be used. SOA is not language-specific and services can be implemented in any programming language that allows generating and interacting with WSDL [4]. In this way, the use of SOA allows for obtaining circumstantial gains in the organization and the software development (Table 1):
| Benefits | Description |
| Business-centric | Business-centric software development. |
| Regardless of location, the service consumer can search for and discover it | The lower incremental cost for development |
| Reduced Skills | Lower requirement for training and technical knowledge |
| Low costs | Lower costs in software development. |
| Speed | The faster software development cycle |
| Platform independent | The lower long-term cost |
| Focused developer roles | Developers can focus completely on implementing and maintaining their services without having to worry about the services of others as long as the default contract is respected. |
| Regardless of location | Regardless of location, it is possible for the service consumer to search for and discover it |
| Code Reuse | Dividing applications into small separated parts helps to reuse in various other systems, thereby reducing the cost of development |
| Greater testability | Small, standalone services are easier to test and debug than monolithic applications, allowing you to have more reliable software |
| Parallel development | Independence between services with pre-defined contracts helps parallel development by greatly reducing the software development lifecycle. |
| Better scalability | Possibility to have multiple instances of the service running on different servers, allowing you to move the service transparently to more resourceful servers |
| Greater availability | The ability to have multiple instances of a service and not care about its location ensures high availability. |
References
[1] C. M. Mackenzie, K. Laskey, F. Mccabe, R. Metz, and A. Hamilton, “Reference Model for Service Oriented Architecture 1.0 Committee Specification 1, 2 August 2006,” no. August, pp. 1–31, 2006.
[2] P. Desfray and G. Raymon, Modeling Enterprise Architecture with TOGAF: A Practical Guide Using UML and BPMN. 2014.
[3] M. Liu, WCF 4.5 Multi-Layer Services Development with Entity Framework Third Edition. 2012.
[4] D. Minoli, Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. 2008.
[5] M. Gousset, B. Keller, A. Krishnamoorthy, and M. Woodward, “Professional WCF 4 Windows Communication Foundation with NET 4,” 2010.
[6] M. Liu, WCF 4.0 Multi-tier Services Development with LINQ to Entities, no. 4. 2010.
[7] N. Pathak, “Pro WCF 4,” pp. 3–24, 2011.
[8] J. Lowy, Programming WCF Services. 2010.
[9] Microsoft IC, “Introducing Windows Communication Foundation in .NET Framework 4.” [Online]. Available: https://msdn.microsoft.com/en-us/library/ee958158.aspx
[10] M. L. Bustamante, Learning WCF, Master Windows Communication Foundation, and SOA Fundamentals. 2007.
[11] Scott Klein, Professional WCF Programming. 2007.
[12] “10 Principles of SOA,” 2007. [Online]. Available: https://www.infoq.com/articles/tilkov-10-soa-principles/.
[13] C. Interfaces, “Common Object Request Broker Architecture (CORBA) Specification, Version 3.3,” no. November 2012.
[14] B. S. of I. University of California, “Distributed Computing Applications and Infrastructure.” [Online]. Available: http://courses.ischool.berkeley.edu/i206/f97/GroupB/mom/what_is_mom.html