英文原文

Service-Oriented Architecture and Legacy Systems

Enterprise systems are quickly evolving from monolithic silos to distributed applications with service-oriented exible usage schemes. To keep up, IT organizations must adapt their legacy systems to meet changing business challenges almost in real time, with no second chances. Service-oriented architectures (SOAs) have evolved to exibly operate and federate business processes and underlying systems. Authors Nicolas Serrano, Josune Hernantes, and Gorka Gallardo provide an overview of current SOA technologies and how to evolve in legacy environments. I look forward to hearing from both readers and prospective column authors about this column and the technologies you want to know more about. — Christof Ebert

Todayrsquo;s business must be able to flexibly and quickly adapt to market needs, but even minor changes to processes can involve rework in multiple IT systems that were originally designed as application silos. To stay competitive, maintenance efforts must be reduced, yet IT systems must continue to evolve. Service-oriented architecture (SOA) enables the transition from a silo-based system to a service-oriented one. It facilitates loose coupling, abstraction of underlying logic, fl exibility, reusability, and discoverability. The SOA Manifesto outlines additional guiding principles.

SOA Primer SOArsquo;s novelty is in how it designs infrastructure architecture based on services instead of focusing on entire applications. Services are small, discrete units of software that provide a specific functionality and can be reused in multiple applications. SOA applies a loose-coupling design principle, which means that each service is an isolated entity with limited dependencies on other shared resources such as databases, legacy applications, or APIs. It helps provide an abstraction layer between producers and consumers, which promotes fl exibility in changing service implementations without impacting consumers. SOA offers several benefi ts to busi- nesses, but it isnrsquo;t the best architectural choice for all cases. On the plus side, it:

provides a natural way to modularize complex systems by integrating services from different vendors independent of platform and technology;

promotes loose coupling, helping the interface with legacy systems;

increases efficiency by allowing applications to be reused, thus reducing cost and development time;

improves flexibility and scalability because multiple services can be easily developed from the integration of existing applications;

allows a reduction of costs associated with maintenance;

enables standards-based interoperability between systems;

provides location independence to access data via any channel such as smartphones, tablets, or laptops; and

allows an incremental approach to be taken, which helps meet customer demands faster by adding new services in response to specific business needs. However, on the minus side, it

is difficult to implement asynchronous communication between applications;

is challenging to implement real-time responses or high data transfers because XML brings robustness, not speed (although there are other alternatives such as JSON);

has numerous security vulnerabilities due to process-sharing applications and systems; and

involves complex transaction management in interactions between logically separate systems.

Moving to SOA isnrsquo;t easy, and enterprises wishing to do so must be aware of the difficulties and inherent issues. Needless to say, every IT organization will experience multiple tradeoffs with SOA implementations; your mileage may vary. For effi ciency and fl exibility we recommend an incremental transition to SOA in legacy environments.

Web Services

Web services are, for most organizations, the simplest approach for implementing a loosely coupled architecture. This interoperability is gained through a set of XML-based open standards such as WSDL, SOAP, and UDDI to provide a common approach for defi ning, publishing, and using Web services .

Web services evolved from Web applications. In fact, theyrsquo;re a simplification of Web applications: in- stead of serving the user interface along with the data, they only serve the data; the client application is in charge of presenting the information. Consequently, Web services are the most common way to implement a SOA—indeed, many systems use Web services without defining them as a SOA.

The main advantage of SOA (and therefore of Web services) is that the same service can be consumed by different clients. The data that was originally designed for a Web application to consume can be used, without any modifi cation, by any other type of client. Examples include desktop applications that get data from a server without providing explicit SQL queries of the database or external systems such as a vending or public client information point that gets its data from a SOA service.

A legacy system can be wrapped as a SOA service and respond directly to the HTTP protocol or work behind a proxy that translates the request to the legacy systemrsquo;s language. Ultimately, the message in HTTP is plaintext, which any system or programming language can produce.

Technologies

SOA is a good option for building more fl exible applications, but choosing the right technology to achieve it will depend on your needs and environment. Letrsquo;s review the most relevant technology considerations for organizations wishing to adopt SOA in their own business processes.

SOAP vs. REST

When designing a Web service, we need to define the set of rules wersquo;re going to use to exchange information. The main tools for doing this today are SOAP and REST. SOAP is the older protocol; it was developed as an Internet-capable alternative to established technologies such as CORBA. SOAP can use various transports (HTTP, SMTP, and so on)

剩余内容已隐藏，支付完成后下载完整资料

英语译文共 5 页，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[238000]，资料为PDF文档或Word文档，PDF文档可免费转换为Word