Service-Oriented Architecture and Legacy Systems
Enterprise systems are rapidly evolving from monolithic repositories to distributed applications based on services with flexible usage patterns. To keep up with the times, IT organizations must adapt their old applications to changing business requirements almost in real time, and in fact without a second chance. Service Oriented Architecture (SOA) has evolved to support the flexibility of operations and the federation of business processes and subsystems. The authors of the article Nicolas Serrano, Josune Hernantes and Gorka Gallardo give an overview of the current state of SOA technology and how to evolve in the existing environment.
Preface by Christof Ebert
Modern business must be able to flexibly and quickly adapt to the requirements of the market, but even minor changes in the processes may entail the processing of a variety of information systems that were originally designed as monolithic repositories. To remain competitive, support costs must be constantly reduced, and systems constantly evolve. SOA makes it possible to move from monolithic to service-oriented systems. This contributes to flexibility, weak connectivity, the separation of abstractions from real infrastructure. Service discovery and reuse capabilities are much higher with SOA. Additional features and principles can be found in the SOA Manifesto . [1] [2]
The novelty of SOA is how the infrastructure of an architectural solution based on services is modeled instead of focusing on the entire application. Services are small, separate software elements that solve one problem and can be reused in many applications. SOA is based on the principle of weak connectivity, which means that each service is an isolated entity with limited dependencies on other shared resources, such as databases, application legacy or different APIs. This architectural solution allows you to create a level of abstraction between consumers and creators. This entails freedom in the implementation and updates without prejudice to consumers of the service. Yes, SOA has a lot of benefits for business, but it is not the best solution for all cases. Among the advantages of the approach are the following points:
Of the minuses can be called:
The transition to a service-oriented architecture is not a simple process. Enterprises wishing to switch to SOA should be aware of the difficulties and associated problems. It is quite obvious that the transition will be fraught with many compromises, and each will have their own. For a more efficient and painless transition, we recommend a gradual (incremental) transition from old monolithic systems to SOA.
')
Writing web services for many organizations is the easiest way to build a loosely coupled interaction model. It is achieved through a set of open standards based on XML, for example: WSDL, SOAP, UDDI - they all provide the same approach for defining, publishing, and using web services.
Web services have evolved from web applications, but in reality, they are a simplification of web applications: instead of providing a user interface and data processing, they only work with data. Responsibility for displaying data passes to the client application. However, it is worth noting that many systems use web services, but do not call themselves SOA systems.
The inherited system can be wrapped in an SOA service and respond via the HTTP protocol or work for a proxy ( which is rather a gateway ), which translates requests into a language that it understands. After all, a message in HTTP is plain text that can be processed by any system and in any programming language.
An SOA-based solution makes it possible to build more flexible applications, but the choice of a specific implementation technology depends on the needs and capabilities of your organization. Let's look at the most likely technological considerations for an organization that wants to transfer its business processes to SOA.
When designing a web service, we need to define a set of rules for the exchange of information. The main tools for this are SOAP and REST [3] .
SOAP is an older protocol. It was developed as an internet compatible alternative for such well-established technologies as CORBA. The SOAP protocol can use different transport (HTTP, SMTP, and so on), which gives additional flexibility. Data is exchanged in XML format, so some performance problems may arise if the amount of data transferred is high. SOAP can be used with Web Services Security, a standard for encrypting and signing messages that provides a more secure exchange of data. [four]
REST is a newer protocol that uses HTTP as a transport, but it supports several data formats (XML, JSON, and so on). Unlike SOAP, it relies on specific URLs instead of parsing XML. Since it does not imply rigid implementation, it is flexible in implementation, is more lightweight and less dependent on documentation. REST can also use GET methods when SOAP is implemented on POST.
Naturally, the choice between REST and SOAP depends on the constraints and needs of the organization. The SOAP protocol supports security and error handling at a deeper level, which is why many large online stores prefer it. Simplicity, performance and freedom in implementation make REST the preferred protocol for those who work on the interaction of Internet services at the API level.
Although the SOA approach may be the best alternative for seamless integration of enterprise systems and a headache solution with protocols [5] and platforms, most people have to work with existing infrastructure. There is no perfect solution in the matter of upgrading old systems to SOA, because it's all about the nuances. You need to take into account the existing technological stack in the company to develop an optimal solution for the transition, taking into account risks and costs.
A plan for a gradual transition, taking into account the evolution (and not revolution) of enterprise systems, should be developed taking into account the use of hybrid systems on the way to pure SOA, since key business processes are tied to legacy systems. And there are several strategies for converting them to SOA.
The planned transition of systems to an SOA implementation can be facilitated with the help of third-party products. But, as always happens, all offers differ in support and complexity, so the right choice is vital. You can break all solutions into three groups depending on the complexity of the integration.
Obviously, the best choice always depends on the specific needs and complexities of the process, and it is better to solve such a problem by the method of elimination, starting with simple options. First you have to decide whether the integration framework may be enough. For example, if you have only two applications need to communicate, or you can work with only one protocol (REST), then you can use the simplest solution in the form of an integration framework, despite the lack of tools and support. Otherwise, an ESB might be a better option. If it is not enough, then it is worth plunging into the study of more complex integration packages.
The next step may be in the direction of easier integration of your SOA solution with cloud services. Clouds provide the ability to obtain resources on demand, and also contain a rich toolkit for storing data, creating services and processing data.
In general, the main challenge for business today is integration with cloud services. In this context, iPaaS (integration platform as a service) is gaining popularity as a suitable solution for a wide range of integration tasks. iPaaS is a set of cloud services that allow users to create, manage and organize integration flows for many applications or data without installing specialized equipment or libraries.
Looking at the future, researchers at Garther predict that in 2016 at least 35 percent of all large and medium-sized companies will use at least one iPaaS solution in one form or another. However, experts do not say that iPaaS will replace SOA. Traditional solutions with SOA will be in demand for scenarios where the speed of processing messages is important and there is an intensive exchange of data between databases and businesses in a corporation.
Source: http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems
If you are close to the subject of the article or want to learn more about how to properly design, maintain and work with the API , come to our conference API & Backend ! If you have a story to tell, we are waiting for your stories !
Preface by Christof Ebert
Modern business must be able to flexibly and quickly adapt to the requirements of the market, but even minor changes in the processes may entail the processing of a variety of information systems that were originally designed as monolithic repositories. To remain competitive, support costs must be constantly reduced, and systems constantly evolve. SOA makes it possible to move from monolithic to service-oriented systems. This contributes to flexibility, weak connectivity, the separation of abstractions from real infrastructure. Service discovery and reuse capabilities are much higher with SOA. Additional features and principles can be found in the SOA Manifesto . [1] [2]
The novelty of SOA is how the infrastructure of an architectural solution based on services is modeled instead of focusing on the entire application. Services are small, separate software elements that solve one problem and can be reused in many applications. SOA is based on the principle of weak connectivity, which means that each service is an isolated entity with limited dependencies on other shared resources, such as databases, application legacy or different APIs. This architectural solution allows you to create a level of abstraction between consumers and creators. This entails freedom in the implementation and updates without prejudice to consumers of the service. Yes, SOA has a lot of benefits for business, but it is not the best solution for all cases. Among the advantages of the approach are the following points:
- The natural way to create a complex modular system through the integration of services from different vendors, regardless of platform and technology.
- It pushes for loosely coupled systems, helps to work with old systems.
- Increases efficiency by reusing services, which reduces development costs and time.
- Improves flexibility and scalability because many services can be developed using different layouts of existing applications.
- Makes it possible to reduce the costs associated with supporting the solution.
- You can develop a standard communication protocol between systems.
- Access to data does not depend on the geography of the user, you can use mobile communications.
- The possibility of gradual commissioning of parts of the system, which allows you to respond faster to business needs.
Of the minuses can be called:
- Difficult to implement asynchronous communication between services.
- It is difficult and time consuming to implement responses in “real time” because XML gives reliability, not speed. Of course there is an alternative in the form of JSON
- Various security vulnerabilities associated with data exchange between many applications and systems.
- A complex transaction management process associated with the interaction of logically different systems.
The transition to a service-oriented architecture is not a simple process. Enterprises wishing to switch to SOA should be aware of the difficulties and associated problems. It is quite obvious that the transition will be fraught with many compromises, and each will have their own. For a more efficient and painless transition, we recommend a gradual (incremental) transition from old monolithic systems to SOA.
')
Web services
Writing web services for many organizations is the easiest way to build a loosely coupled interaction model. It is achieved through a set of open standards based on XML, for example: WSDL, SOAP, UDDI - they all provide the same approach for defining, publishing, and using web services.
Web services have evolved from web applications, but in reality, they are a simplification of web applications: instead of providing a user interface and data processing, they only work with data. Responsibility for displaying data passes to the client application. However, it is worth noting that many systems use web services, but do not call themselves SOA systems.
The inherited system can be wrapped in an SOA service and respond via the HTTP protocol or work for a proxy ( which is rather a gateway ), which translates requests into a language that it understands. After all, a message in HTTP is plain text that can be processed by any system and in any programming language.
Technology
An SOA-based solution makes it possible to build more flexible applications, but the choice of a specific implementation technology depends on the needs and capabilities of your organization. Let's look at the most likely technological considerations for an organization that wants to transfer its business processes to SOA.
SOAP vs. REST
When designing a web service, we need to define a set of rules for the exchange of information. The main tools for this are SOAP and REST [3] .
SOAP is an older protocol. It was developed as an internet compatible alternative for such well-established technologies as CORBA. The SOAP protocol can use different transport (HTTP, SMTP, and so on), which gives additional flexibility. Data is exchanged in XML format, so some performance problems may arise if the amount of data transferred is high. SOAP can be used with Web Services Security, a standard for encrypting and signing messages that provides a more secure exchange of data. [four]
REST is a newer protocol that uses HTTP as a transport, but it supports several data formats (XML, JSON, and so on). Unlike SOAP, it relies on specific URLs instead of parsing XML. Since it does not imply rigid implementation, it is flexible in implementation, is more lightweight and less dependent on documentation. REST can also use GET methods when SOAP is implemented on POST.
Naturally, the choice between REST and SOAP depends on the constraints and needs of the organization. The SOAP protocol supports security and error handling at a deeper level, which is why many large online stores prefer it. Simplicity, performance and freedom in implementation make REST the preferred protocol for those who work on the interaction of Internet services at the API level.
Retrofit old solutions
Although the SOA approach may be the best alternative for seamless integration of enterprise systems and a headache solution with protocols [5] and platforms, most people have to work with existing infrastructure. There is no perfect solution in the matter of upgrading old systems to SOA, because it's all about the nuances. You need to take into account the existing technological stack in the company to develop an optimal solution for the transition, taking into account risks and costs.
A plan for a gradual transition, taking into account the evolution (and not revolution) of enterprise systems, should be developed taking into account the use of hybrid systems on the way to pure SOA, since key business processes are tied to legacy systems. And there are several strategies for converting them to SOA.
- The first approach is to simply replace the current system with a new or set of systems. In general, this is a normal approach if the market offers a finished product that fully meets your requirements. This solution reduces support costs, but significantly increases the cost of future modifications. ( We all know that only changes are constant in this world - lane comment )
- An alternative approach would be to create a wrapper for the old system, which can provide access to existing interfaces via web services. In this case, the old functionality "wrapped" the service layer and "included" in the SOA environment. This will not solve all your problems, for example, it will be difficult to achieve the desired degree of independence of the services, because the old application may closely link some possible services. In financial terms, such a move can work when rewriting the entire system is very expensive, but parts of the solution can be reused and budgets are limited.
- The final option is to rewrite the legacy system. If you can influence the architecture of the application and know in general how to achieve the required level of independence between services, this will be a good choice. However, legacy systems are usually critical for business, and the difficulty with expensiveness of replacing them lies in the use of old technologies and the lack of documentation, which leads to some problems of reverse engineering with increasing risks for project implementation. In this embodiment, the main difficulty lies in understanding all the risks.
Enterprise integration
The planned transition of systems to an SOA implementation can be facilitated with the help of third-party products. But, as always happens, all offers differ in support and complexity, so the right choice is vital. You can break all solutions into three groups depending on the complexity of the integration.
- Integration frameworks are the easiest way to build libraries with a specific API for different development environments. Examples of such frameworks include Apache Camel and Spring Integration for Java and NServiceBus for .NET.
- The Enterprise Service Bus (ESB) offers integration framework capabilities, as well as tools for its deployment, administration, and monitoring in a “combat” mode. The ESB supports connections between data providers and consumers, additionally offering improved tools that significantly reduce the cost and complexity of solving integration problems at a higher level of abstraction. Examples of ESBs include: Oracle Service Bus and Mule ESB.
- Integration packages offer a complete toolkit that contains not only ESB capabilities, but also business-oriented tools, such as BPM (business process management), business process monitoring, critical data management, repository. All these features allow you to respond to changes more quickly. It is very difficult to compare such packages with each other.
Making a choice
Obviously, the best choice always depends on the specific needs and complexities of the process, and it is better to solve such a problem by the method of elimination, starting with simple options. First you have to decide whether the integration framework may be enough. For example, if you have only two applications need to communicate, or you can work with only one protocol (REST), then you can use the simplest solution in the form of an integration framework, despite the lack of tools and support. Otherwise, an ESB might be a better option. If it is not enough, then it is worth plunging into the study of more complex integration packages.
The next step may be in the direction of easier integration of your SOA solution with cloud services. Clouds provide the ability to obtain resources on demand, and also contain a rich toolkit for storing data, creating services and processing data.
In general, the main challenge for business today is integration with cloud services. In this context, iPaaS (integration platform as a service) is gaining popularity as a suitable solution for a wide range of integration tasks. iPaaS is a set of cloud services that allow users to create, manage and organize integration flows for many applications or data without installing specialized equipment or libraries.
Looking at the future, researchers at Garther predict that in 2016 at least 35 percent of all large and medium-sized companies will use at least one iPaaS solution in one form or another. However, experts do not say that iPaaS will replace SOA. Traditional solutions with SOA will be in demand for scenarios where the speed of processing messages is important and there is an intensive exchange of data between databases and businesses in a corporation.
Links
- Gold et al., “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
- Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
- Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,” Int'l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
- Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62–67.
- Vinoski, “REST Eye for SOA Guy,” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.
Source: http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems
If you are close to the subject of the article or want to learn more about how to properly design, maintain and work with the API , come to our conference API & Backend ! If you have a story to tell, we are waiting for your stories !
Source: https://habr.com/ru/post/257713/
All Articles