In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design.[1] By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.[2]
Different services can be used in conjunction as a service mesh to provide the functionality of a large software application,[5] a principle SOA shares with modular programming. Service-oriented architecture integrates distributed, separately maintained and deployed software components. It is enabled by technologies and standards that facilitate components' communication and cooperation over a network, especially over an IP network.
SOA is related to the idea of an API (application programming interface), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software. An API can be thought of as the service, and the SOA the architecture that allows the service to operate.
Overview
In SOA, services use protocols that describe how they pass and parse messages using description metadata. This metadata describes both the functional characteristics of the service and quality-of-service characteristics. Service-oriented architecture aims to allow users to combine large chunks of functionality to form applications which are built purely from existing services and combining them in an ad hoc manner. A service presents a simple interface to the requester that abstracts away the underlying complexity acting as a black box. Further users can also access these independent services without any knowledge of their internal implementation.[6]
Defining concepts
The related buzzword service-orientation promotes loose coupling between services. SOA separates functions into distinct units, or services,[7] which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.[8]
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these[11][12][13] include the following:
Services adhere to a standard communications agreement, as defined collectively by one or more service description[disambiguation needed] documents within a given set of services.
Service reference autonomy (an aspect of loose coupling)
The relationship between services is minimized to the level that they are only aware of their existence.
Service location transparency (an aspect of loose coupling)
Services can be called from anywhere within the network that it is located no matter where it is present.
Service longevity
Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
Service normalization
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done. These are the cases where performance optimization, access, and aggregation are required.[15]
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
Patterns
Each SOA building block can play any of the three roles:
Service provider
It creates a web service and provides its information to the service registry. Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance: security or easy availability, what price to offer the service for and many more. The provider also has to decide what category the service should be listed in for a given broker service[16] and what sort of trading partner agreements are required to use the service.
Service broker, service registry or service repository
Its main functionality is to make information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker. Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public. UDDI was an early, no longer actively supported attempt to provide Web services discovery.
Service requester/consumer
It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
The service consumer–provider relationship is governed by a standardized service contract,[17] which has a business part, a functional part and a technical part.
Service-oriented architecture can be implemented with web services or Microservices.[21] This is done to make the functional building-blocks accessible over standard Internet protocols that are independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.[22]
Implementers commonly build SOAs using web services standards. One example is SOAP, which has gained broad industry acceptance after the recommendation of Version 1.2 from the W3C[23] (World Wide Web Consortium) in 2003. These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, also implement SOA using any other service-based technology, such as Jini, CORBA, Internet Communications Engine, REST, or gRPC.
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:
Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data following a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. SOA enables the development of applications that are built by combining loosely coupled and interoperable services.
These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET, etc.). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as web services that facilitate reuse. Managed environments can also wrap COBOL legacy systems and present them as software services..[24]
High-level programming languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals.
Service-oriented modeling is an SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The Service-oriented modeling framework (SOMF) offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the "what to do" aspects of a service development scheme. The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.
Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk SlamaSOA meta-model, The Linthicum Group, 2007
Organizational benefits
Some enterprise architects believe that SOA can help businesses respond more quickly and more cost-effectively to changing market conditions.[26] This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to—and usage of—existing IT (legacy) assets.
With SOA, the idea is that an organization can look at a problem holistically. A business has more overall control. Theoretically there would not be a mass of developers using whatever tool sets might please them. But rather they would be coding to a standard that is set within the business. They can also develop enterprise-wide SOA that encapsulates a business-oriented infrastructure. SOA has also been illustrated as a highway system providing efficiency for car drivers. The point being that if everyone had a car, but there was no highway anywhere, things would be limited and disorganized, in any attempt to get anywhere quickly or efficiently. IBM Vice President of Web Services Michael Liebow says that SOA "builds highways".[27]
In some respects, SOA could be regarded as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development of solutions that use truly static bindings to talk to other equipment in the network has taken place. By embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces. Other predecessors of SOA include Component-based software engineering and Object-Oriented Analysis and Design (OOAD) of remote objects, for instance, in CORBA.
A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of subordinate services.
Reasons for treating the implementation of services as separate projects from larger projects include:
Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility. That is to say, it fosters business innovations and speeds up time-to-market.[28]
Separation promotes the decoupling of services from consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.
Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.
SOA promises to simplify testing indirectly. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. If an organization possesses appropriately defined test data, then a corresponding stub is built that reacts to the test data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh is test deployments of full services. As each interface is fully documented with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test cases of all services within the environment. Managing the data state of idempotent services is the only complexity.
Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 exemplifies such a file.[29]
Criticism
SOA has been conflated with Web services;[30] however, Web services are only one option to implement the patterns that comprise the SOA style. In the absence of native or binary forms of remote procedure call (RPC), applications could run more slowly and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI), Windows Communication Foundation (WCF) and data distribution service (DDS)) that do not depend on remote procedure calls or translation through XML or JSON. At the same time, emerging open-source XML parsing technologies (such as VTD-XML) and various XML-compatible binary formats promise to significantly improve SOA performance.[31][32][33]
Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider if the service-provider needs to retain the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.[34] Ultimately, some critics feel that SOA services are still too constrained by applications they represent.[35]
A primary challenge faced by service-oriented architecture is managing of metadata. Environments based on SOA include many services which communicate among each other to perform tasks. Due to the fact that the design may involve multiple services working in conjunction, an Application may generate millions of messages. Further services may belong to different organizations or even competing firms creating a huge trust issue. Thus SOA governance comes into the scheme of things.[36]
Another major problem faced by SOA is the lack of a uniform testing framework. There are no tools that provide the required features for testing these services in a service-oriented architecture. The major causes of difficulty are:[37]
Heterogeneity and complexity of solution.
Huge set of testing combinations due to integration of autonomous services.
Inclusion of services from different and competing vendors.
Platform is continuously changing due to availability of new features and services.
Application programming interfaces (APIs) are the frameworks through which developers can interact with a web application.
Web 2.0
Tim O'Reilly coined the term "Web 2.0" to describe a perceived, quickly growing set of web-based applications.[38] A topic that has experienced extensive coverage involves the relationship between Web 2.0 and service-oriented architectures.[which?]
SOA is the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus can not be regarded "parallel philosophies", whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA.[39]
The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, as of 2008[update], use-cases demonstrated the potential of combining technologies and principles of both Web 2.0 and SOA.[39]
Microservices are a modern interpretation of service-oriented architectures used to build distributed software systems. Services in a microservice architecture[40] are processes that communicate with each other over the network in order to fulfill a goal. These services use technology agnostic protocols,[41] which aid in encapsulating choice of language and frameworks, making their choice a concern internal to the service. Microservices are a new realisation and implementation approach to SOA, which have become popular since 2014 (and after the introduction of DevOps), and which also emphasize continuous deployment and other agile practices.[42]
There is no single commonly agreed definition of microservices. The following characteristics and principles can be found in the literature:
Service-oriented architectures for interactive applications
Interactive applications requiring real-time response times, for example low-latency interactive 3d applications, are using specific service oriented architectures addressing the specific needs of such kind of applications. These include for example low-latency optimized distributed computation and communication as well as resource and instance management.[43][44][45]
Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.
A web service (WS) is either:
REST is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave. The REST architectural style emphasises uniform interfaces, independent deployment of components, the scalability of interactions between them, and creating a layered architecture to promote caching to reduce user-perceived latency, enforce security, and encapsulate legacy systems.
An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.
Web Services Discovery provides access to software systems over the Internet using standard protocols. In the most basic scenario there is a Web Service Provider that publishes a service and a Web Service Consumer that uses this service. Web Service Discovery is the process of finding suitable web services for a given task.
In computing and systems design, a loosely coupled system is one
in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.
A mashup, in web development, is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface. For example, a user could combine the addresses and photographs of their library branches with a Google map to create a map mashup. The term implies easy, fast integration, frequently using open application programming interfaces and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data. The term mashup originally comes from creating something by combining elements from two or more sources.
Component-based software engineering (CBSE), also called component-based development (CBD), is a style of software engineering that aims to build software out of loosely-coupled, modular components. It emphasizes the separation of concerns among different parts of a software system.
The Open Knowledge Initiative (OKI) is an organization responsible for the specification of software interfaces comprising a Service Oriented Architecture (SOA) based on high level service definitions. The OKI specifically focuses on educational software environments.
An open service interface definition (OSID) is a programmatic interface specification describing a service. These interfaces are specified by the Open Knowledge Initiative (OKI) to implement a service-oriented architecture (SOA) to achieve interoperability among applications across a varied base of underlying and changing technologies.
An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic. They are most popularly implemented in service-oriented architectures (SOA) to control XML-based web services traffic, and increasingly in cloud-oriented computing to help enterprises integrate on premises applications with off-premises cloud-hosted applications. XML appliances are also commonly referred to as SOA appliances, SOA gateways, XML gateways, and cloud brokers. Some have also been deployed for more specific applications like Message-oriented middleware. While the originators of the product category deployed exclusively as hardware, today most XML appliances are also available as software gateways and virtual appliances for environments like VMWare.
In telecommunications, Multi-Technology Operations System Interface (MTOSI) is a standard for implementing interfaces between OSSs. Service providers (carriers) use multiple Operational Support Systems (OSS) to manage complex networks. Since the various parts of the network must interact, so must the OSSs. It is standardized by the Telemanagement ForuM . The TMF Frameworx provides a set of reference models that aid in analyzing and designing next generation BSS and OSS solutions that may utilize the MTOSI interface specifications.
Service-oriented modeling is the discipline of modeling business and software systems, for the purpose of designing and specifying service-oriented business systems within a variety of architectural styles and paradigms, such as application architecture, service-oriented architecture, microservices, and cloud computing.
Service-oriented communications (SOC) technologies are designed to be easily used in the context of service-oriented architectures. These technologies are generally software based and are built more like a business application than a traditional PBX business communications system. Service-oriented communications systems allow their services to participate in business processes. They make their services available to other business applications within and SOA and allow for reuse of the services. The goal of service-oriented communications is to enable business environments to build communications into their business processes, enabling more streamlined collaboration among people within the business. It typically assumes that certain services are provided in the context of an SOA service provider. This is often in the form of a suite of web services, but may also be attached to other means of sharing the services such as an enterprise system bus (ESB).
Service-oriented programming (SOP) is a programming paradigm that uses "services" as the unit of computer work, to design and implement integrated business applications and mission critical software programs. Services can represent steps of business processes and thus one of the main applications of this paradigm is the cost-effective delivery of standalone or composite business applications that can "integrate from the inside-out". It inherently promotes service-oriented architecture (SOA), however, it is not the same as SOA. While SOA focuses on communication between systems using "services", SOP provides a new technique to build agile application modules using in-memory services as the unit of work.
Service Component Architecture (SCA) is a software technology designed to provide a model for applications that follow service-oriented architecture principles. The technology, created by major software vendors, including IBM, Oracle Corporation and TIBCO Software, encompasses a wide range of technologies and as such is specified in independent specifications to maintain programming language and application environment neutrality. Many times it uses an enterprise service bus (ESB).
Web data services refers to service-oriented architecture (SOA) applied to data sourced from the World Wide Web and the Internet as a whole. Web data services enable maximal mashup, reuse, and sharing of structured data, semi-structured information, and unstructured information.
An application programming interface (API) is a way for two or more computer programs or components to communicate with each other. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation. Whereas a system's user interface dictates how its end-users interact with the system in question, its API dictates how to write code that takes advantage of that system's capabilities.
In software engineering, service virtualization or service virtualisation is a method to emulate the behavior of specific components in heterogeneous component-based applications such as API-driven applications, cloud-based applications and service-oriented architectures. It is used to provide software development and QA/testing teams access to dependent system components that are needed to exercise an application under test (AUT), but are unavailable or difficult-to-access for development and testing purposes. With the behavior of the dependent components "virtualized", testing and development can proceed without accessing the actual live components. Service virtualization is recognized by vendors, industry analysts, and industry publications as being different than mocking. See here for a Comparison of API simulation tools.
In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users. As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.
↑ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Exploring Cloud Service Brokering from an Interface Perspective". 2014 IEEE International Conference on Web Services. IEEE. pp.329–336. doi:10.1109/ICWS.2014.55. ISBN978-1-4799-5054-6. S2CID17957063.
↑ Duan, Yucong (2012). "A Survey on Service Contract". 2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing. IEEE. pp.805–810. doi:10.1109/SNPD.2012.22. ISBN978-1-4673-2120-4. S2CID1837914.
↑ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
