Service-oriented architecture

from Wikipedia, the free encyclopedia

Service-oriented architecture ( SOA , English service-oriented architecture ), and service-oriented architecture is an architectural pattern of information technology in the field of distributed systems to service structuring of IT systems and use. The focus on business processes , the abstraction levels of which are the basis for specific service implementations, plays a special role : "Grant a loan", for example, is at a high level; in a banking company, this is a business process with several people and information technology systems involved ("Open the business relationship ”,“ opening one or more accounts ”,“ credit agreement ... ”and so on), while“ add the customer to the customer directory ”is a service at a lower level. By assembling ( orchestrating ) services of lower abstraction levels, services of higher abstraction levels can be created quite flexibly and with the greatest possible reusability .

General

In simplified terms, SOA can be viewed as a method or paradigm to encapsulate the existing IT components such as databases , servers and websites in services and then coordinate them (“orchestration”) so that their services are combined into higher services and available to other organizational departments or customers Can be made available. The decisive factor is not technical individual tasks such as database queries, calculations and data processing, but the consolidation of these IT services for “higher purposes” - such as executing an order or checking the profitability of a department, etc. - offered by an organizational department. SOA is a structure that enables enterprise application integration by hiding the complexity of the individual applications behind the standardized interfaces.

The goals here are the long-term lowering of costs in software development and greater flexibility in business processes by reusing existing services. The costs of programming the nth application implemented with SOA should be eliminated, since all the necessary services are already available and these only have to be orchestrated. This leaves only the costs for business analysis and software configuration.

SOA requires a very strong integration of the individual IT components so that their orchestration can be cost-effective. SOA therefore already plays a role in the selection of IT components.

One technical form of implementing SOA is to offer these services on the Internet or in the cloud. The communication between such offered services can take place via SOAP , REST , XML-RPC or similar protocols. The user of these services only knows that the service is offered, what inputs it requires and what type of result is. Details about how the results are determined do not need to be known.

A directory service such as UDDI can find out which services can be used and how they are controlled .

definition

Structure and elements of SOA

The term "service-oriented architecture" was first used in 1996 by the market research company Gartner . Gartner is therefore considered to be the inventor of the term SOA. There is no generally accepted definition of SOA. Nevertheless, the definition of the OASIS from 2006 is often quoted:

"A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains"

"SOA is a paradigm for structuring and using distributed functionality for which different owners are responsible."

Services are central to all definitions. The ideal properties of services in an SOA are listed below. In practice, not all of these requirements are fully met.

  • A service is an IT representation of technical functionality.
  • A service is self-contained (self-sufficient) and can be used independently.
  • A service is available in a network.
  • A service has a well-defined published interface (contract). To use it, it is sufficient to know the interface. However, knowledge of the details of the implementation is not required.
  • A service is platform independent , i. H. Providers and users of a service can be implemented in different programming languages on different platforms .
  • A service is registered in a directory.
  • A service is dynamically bound ; H. when building an application that uses a service, the service need not be present. It is only localized and integrated during execution.
  • A service should be coarse-grained in order to reduce the dependency between distributed systems.

Finally, it should be noted that “the SOA” does not exist; Rather, SOA is just a point of view that can be interpreted in different ways.

Demarcation

  • SOA is not web services - SOA describes an architecture paradigm detached from concrete implementation methods and techniques.
  • SOA is not new - a service-oriented architecture could be implemented years before the term was introduced using the methods and procedures available at the time and was used with CORBA in 1991 .
  • SOA is not a solution for business problems - as an architectural paradigm, SOA does not give any recommendations for dealing with business problems. See also the section Criticism .
  • SOA is individual - there is no such thing as a “standard SOA”. A company always has to tailor an SOA to its own needs.

example

A customer's order from a mail order company serves as an example of a business process . There are the following process steps for this:

Acquisition - availability check - credit check - order - picking - shipping - invoicing - receipt of payment

There is a service for every step in the business process. The implementation - programming language, system requirements, etc. - can be different. The services can also be implemented on different systems, even in different companies. The solvency of the customer could be determined by a financial service provider, or the various logistics services are provided by a logistics service provider. Key information such as customer number or article number is made available to the services by the infrastructure as far as it is needed.

The sequence does not have to be as sequential as shown. On the contrary, most business process steps can fail. A lack of inventory, a lack of creditworthiness and a lack of incoming payments lead to ramifications that require different procedures. The simultaneous processing of several business process steps - for example dispatch and invoicing - is possible.

However, it is important that the credit check, for example, is always the same, even if it is used by a wide variety of processes or even companies. In this way, important goals of SOA, such as easier maintenance, better consistency and more uniformity, are achieved: Once a service has been implemented, it can be retained in the long term, it does not have to be touched again and again when business processes change, which saves effort and prevents errors become.

If the company decides to outsource the credit check, the infrastructure only has to call up this service from another provider. Otherwise nothing will change.

Implementation of an SOA

The following paragraph needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

An implementation of an SOA is essentially based on decisions about the communication and integration between service providers (including service providers ) and service users (including service users , service consumers ) as well as the mapping of business processes.

Any network protocols can be used for communication between service users and service providers , since these only serve as a transport vehicle for the actual message from the application. Protocols such as IIOP , DCOM , DCE or SNA , CORBA , SAP RFC (Remote Function Call) and also the web transfer protocol HTTP , which despite some disadvantages in the area of ​​security and reliability, gained particular popularity due to the Internet, are widespread . Even if web service is not a standardized term, it is commonly used to describe the transmission of messages between applications using the HTTP transport protocol. As an alternative to HTTP, the asynchronous protocols SMTP and FTP are occasionally used.

Since HTTP is a transport protocol for ensuring the complete and error-free transmission of any messages, it says nothing about the structure and content of the transmitted message. The actual message is therefore packaged again in a web service protocol. REST , JSON or JMS- based transmission or SOAP- based messages are conceivable , which are described via the WSDL and both are formulated via XML . AMQP is an alternative to this because, as a binary open format for Message Oriented Middleware (MOM), it does not exchange data via HTTP , but directly via TCP .

The integration of individual services can be implemented in an SOA via point-to-point connections . With point-to-point connections, a connection between the employer and the user is individually designed, developed and administered. With a large number of communication paths, however, it is always advisable to send the messages via an intermediate intermediary, a middleware or also called a message broker . This middleware takes on recurring tasks such as the conversion of protocols, filters and redirecting (routing) messages and guarantees their secure delivery and event processing. If this middleware can be expanded as required and is set up independently of the protocol, it is called an Enterprise Service Bus (ESB). With a few exceptions, message-oriented middleware reduces the overall complexity of a computer landscape even with very few computers communicating with one another.

The mapping of business processes can be specially developed or use a standard such as BPEL . Processes described in BPEL can be executed directly on suitable platforms. The BPEL is therefore suitable for the technical implementation of business processes or for the definition of the orchestration of services. In 2007, many SOA implementations mapped the business processes using specially developed applications. In the long term, it is expected that BPEL will prevail for mapping business processes.

When implementing the SOA paradigm, it is usually broken at a certain point; the individual services of the SOA are then addressed by pure clients such as web browsers, which are no longer part of the SOA.

The activities, decisions, roles and responsibilities for regulating and controlling a service-oriented architecture are known as SOA governance . The rules of an SOA are developed and monitored within SOA governance.

Modeling an SOA

There are various ways of describing SOA with a modeling language. From the OMG there is the open source specification SoaML , with which SOA services can be represented by means of an extended UML profile using your own stereotypes .

Technical implementation at runtime

The interaction between service provider and service user runs according to the paradigm of (publish or register), find, bind, execute , in German: (publish or register), find, bind, execute.

Publish or register
The service provider publishes or registers its service in a directory.
Find
The software component that wants to use a service searches for it in a directory. If a suitable service is found, you can move on to the next step.
Bind
The using component receives a reference (address) from the directory under which it can access the service. The function call is linked to this address .
Execute
The service is called. Input parameters are transmitted to the service and output parameters are returned in response to the call.

environment

The term service-oriented architecture can be classified in the following context:

Risks of SOA implementation

Due to the extent to which existing organizational structures and business processes are influenced, the introduction of a service-oriented architecture depends largely on the support and cooperation of the workforce and, above all, the management. Due to its greater complexity compared to monolithic program structures, the development of an SOA requires a higher initial effort and only makes use of the savings when basic services already exist and can be used in a company's broader application areas. The introduction for a single project in the hope of improving it is usually doomed to failure due to the higher complexity and also pointless as long as the requirements of other potential areas of application are not clarified. In addition, the design, implementation and maintenance of an SOA require a high level of method support.

Therefore, the possibility of reusing or sharing services or service modules by other processes, departments, etc. could not be realized to the extent hoped for; even Gartner Research - the authors of the concept - estimates their probability to be only 20 percent. In addition, the goal of reusability conflicts with that of flexibility. As a result, many SOA projects have failed. While, according to AMR Research, US $ 22 billion was spent on SOA projects in 2007, and US $ 6 billion according to IDC , the hype (and thus the volume of newly published literature on SOA) has decreased significantly since the 2008 financial crisis. According to expert assessments, however, other service-oriented architecture approaches such as software as a service (SaaS) and cloud computing will remain relevant .

criticism

  • SOA is currently subject to the misuse of the term by marketing departments who promise their customers the solution to all previous problems by introducing SOA. As described under delimitation, however, SOA is neither a solution for technical problems in companies, nor is there a standardized SOA that could be sold to a company as such. If there are technical problems, the introduction of SOA will most likely fail for the reasons mentioned.
  • Due to the work that has to be put into the decoupling of services, SOA generates more effort than previous monolithic program structures.
  • SOA creates much more complex processes in the code, which makes writing log files ("logging") and troubleshooting ("debugging") much more difficult. Tests are also inevitably more complex.
  • SOA requires considerable know-how for the developers involved. This means that developers are not that easy to replace, and companies are becoming increasingly dependent on individual developers.
  • SOA is mostly implemented with services that communicate with each other in some form via XML , which is due to the high level of standardization and the platform independence of this markup language. However, since XML for analysis and use in the program sequence with the current state of the art requires significantly more computing time and a higher volume of data to transmit than a conventional function call, additional effort ("overhead") occurs here, which causes corresponding costs.

See also

literature

  • Stephan Aier, Marten Schönherr (ed.): Enterprise Application Integration. Service orientation and sustainable architectures. (= Enterprise Architecture. Volume 2). 2nd Edition. Gito, Berlin 2006, ISBN 3-936771-74-X .
  • Norbert Bieberstein, Robert G. Laird, Keith Jones, Tilak Mitra: Executing SOA - a practical guide for the service-oriented architect Pearson, Upper Saddle River 2008, ISBN 978-0-13-235374-8 .
  • Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah: Service-Oriented Architecture Compass. Business Value, Planning and Enterprise Roadmap. Pearson, Upper Saddle River 2006, ISBN 0-13-187002-5 .
  • Daniel Liebhart: SOA goes real. Hanser Verlag, 2007, ISBN 978-3-446-41088-6 .
  • Knut Hildebrand: IT integration & migration . Dpunkt Verlag, Heidelberg 2007, ISBN 978-3-89864-455-6 .
  • Kai J. Oey, Holger Wagner, Simon Rehbach, Andrea Bachmann: More than old wine in new bottles. An introductory presentation of the concept of service-oriented architectures. In: Stephan Aier, Marten Schönherr (ed.): Enterprise architectures and system integration. (= Enterprise Architecture. Volume 3). 2nd Edition. Gito, Berlin 2006, ISBN 3-936771-75-8 , pp. 197ff.
  • Martin van den Berg, Norbert Bieberstein, Erik van Ommeren: SOA for Profit, A Manager's Guide to Success with Service Oriented Architecture. 2007, ISBN 978-90-75414-14-1 .
  • Thomas Erl: Service-Oriented Architecture. Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River 2004, ISBN 0-13-185858-0 .
  • Ingo Melzer among others: Service-oriented architectures with web services. 3. Edition. Spektrum Verlag, 2008, ISBN 978-3-8274-1993-4 .
  • OSGi Service Platform, Release 3. IOS Press, 2003, ISBN 1-58603-311-5 . (English)
  • David A. Chappell: Enterprise Service Bus. Theory in Practice. O'Reilly Media 2004; English, ISBN 978-0-596-00675-4 .
  • Frank Leymann , Dimka Karastoyanova et al. (Eds.): Service Oriented Architecture - Overview of Technologies and Standards . Focus issue of the magazine it - Information Technology . Vol. 50 (2008) issue 2.
  • Jörn-Axel Meyer, Alexander Tirpitz: Service-oriented architectures in medium-sized businesses - between what is technically feasible and what is commercially sensible. Josef Eul Verlag, Lohmar 2009, ISBN 978-3-89936-765-2 .
  • Hans-Peter Fröschle, Stefan Reinheimer: Service-Oriented Architectures. (= Practice of business informatics. HMD 253). dpunkt verlag, 2007, ISBN 978-3-89864-434-1 .
  • Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA - Service-Oriented Architecture Best Practices. Prentice Hall PRT, 2007, ISBN 978-0-13-146575-6 .
  • Dieter Masak: SOA ?, service orientation in business and software. Springer Verlag, 2007, ISBN 978-3-540-71871-0 .
  • Louise E. Moser, PM Melliar-Smith: Service-Oriented Architecture and Web Services. In: Wiley Encyclopedia of Computer Science and Engineering. 2009, ISBN 978-0-471-38393-2 . doi: 10.1002 / 9780470050118.ecse510
  • Johannes Maximilian Ahrens: Design and improvement of services with special attention to cloud computing and service-oriented architectures. Dissertation . St. Gallen 2016. (with 64 pages of bibliography)

Main sources

Web links

Individual evidence

  1. ↑ Research Note SPA-401-068, April 12, 1996, "'Service Oriented' Architectures, Part 1" and SSA Research Note SPA-401-069, April 12, 1996, "'Service Oriented' Architectures, Part 2"
  2. ↑ Reference Architecture Foundation for Service Oriented Architecture Version 1.0, December 04, 2012 online
  3. ↑ Reference Model for Service Oriented Architecture 1.0, Committee Specification 1, August 2, 2006 oasis-open.org
  4. ↑ a b Bianco Phil, Kotermanski Rick, Merson Paulo: Evaluating a Service-Oriented Architecture. Software Engineering Institute at Carnegie Mellon University , September 2007 http://www.sei.cmu.edu/publications/documents/07.reports/07tr015.html
  5. ↑ SOA in Practice, Nicolai Josuttis, 2008
  6. ↑ Haibin Zhu: Challenges to Reusable Services , scc, 2005, IEEE International Conference on Services Computing (SCC'05) Vol-2, 2005, pp. 243-244.
  7. ↑ See critically in 2006: David Chappell: SOA and the Reality of Reuse. August 2006. Online: davidchappell.com , accessed May 16, 2015.
  8. ↑ Wolfgang Herrmann: The recession broke SOA's neck. In: Computerwoche. October 16, 2008. online: computerwoche.de .