What is SOA (Service Oriented Architecture)?

Question

If you want, call me a troll, but I’m serious: how exactly is the new SOA trend different from the client services architecture that I built 15 years ago? I keep hearing SOA, but I don’t understand, I don’t see how it differs from what we always did.

10 years ago in my company there were several clients (in several languages) who used the same service. It was not XML (it was a binary protocol called Microsoft DCOM), and there was no automatic detection through WSDL, but this is normal, as reading documents was just as easy. Our system was even “open” in the sense that we have documented it enough to allow third-party organizations to communicate with our services. We were not pioneers - any other company that I knew 10 years ago did the same.

The only difference that I see between then and now is that now one service is available on the Internet, whereas 10 years ago each client posted its own copy of the service. But this is not a problem of architecture - where the service physically lives, it is transparent to everyone who uses the service.

So what is the difference between SOA and what we have been doing for years? Is SOA just a marketing term representing best practice that has actually become common a long time ago? Or am I missing some of them in SOA that are different from what we have been doing all this time?

Answer 1

Forget XML. Forget about WSDL. SOA is not a technology that you can buy, although it is often sold that way.

The real point of SOA is all about the IT organization. The essence of SOA is to avoid having a huge collection of “applications” that have isolated data pools and do not talk to each other at all (and therefore often duplicate data), or only in an inefficient, erroneous way through adapter layers or EAI.

For large companies, this is a serious problem - they have literally hundreds of separate applications that are not sufficiently integrated. There, incompatible data is repeated everywhere, and the result is that the customers are angry and the real money is lost, because the billing department continues to send invoices for the canceled order, and the customer service representative cannot even find the order because it is canceled in tracking system orders, but not a billing system.

SOA must solve this problem by designing each application from scratch to publish its services in a standardized way of cross-transfer, so that other applications can access data and not duplicate it.

From a business perspective, this is highly desirable. Deceiving the hype and the bags of acronyms are simply IT companies trying to cash in on this desirability. Unfortunately, this has led many people, including executives, to believe that SOA is a product that you can buy, and it will magically make your IT more effective without realizing that it will happen only if you also reorganize all your IT, possibly your business units) to be compatible with SOA.

Answer 2

Let me use the famous Integration Hell: Telco scourge boy.

Back in the 90s, cell phone companies were abundant in my area, almost as numerous as long-distance resellers made possible by the deregulation of communications from the mid-90s. Well, time goes on and Bell Atlantic becomes Verizon's powerhouse and takes over the company after the company (and at least one Baby Bell). Each of these companies has technologies on towers, in switching equipment, in billing systems, which are completely incompatible with each other.

So, the company leaves and says, well, we have these models for how we do business, let's have a friendly, consistent face on ALL of our technologies in the form of WSDL / SOAP / XSD - in every language and system we can be paired today with this! Slowly but surely, the company creates all systems that can report opportunities, be polled for downloading and billing, and expose future widgets to use in ways that have not yet been accounted for.

Anyone can create an SOA client. Anyone who has wget and a text editor. And everyone can analyze the results (XML).

This is fundamentally different from past client-server architectures. The other day, I just talked with someone about how Cobol and Smalltalk systems interact with SOA architecture. This is an easy problem to solve. Say you can say the same for your DCOM systems.

Answer 3

SOA is nothing but a design method in which modules interact with each other through "services." It's simple, and now the next question is: what is a “service” and what is its difference from the usual “method”?

A service is an operation that performs a single, atomic business operation. This atomicity makes it highly reusable from many modules. Then a complex business operation is simply an indication of calling many of these services in a specific order.

SOA has nothing to do with a particular technology; it is just a special design method.

Answer 4

Professor Frank Leimann of the University of Stuttgart accepts SOA as a key concept of his Service Oriented Research (SOC) when he talks about SOA. He is apparently asked about the definition of SOA, and the subsequent conversation can be well read.

Please note that our roadmap is dedicated to “service-oriented computing (SoC),” that is, the computational paradigm behind service-oriented computing. Service Oriented Architecture (SOA) is the architectural implementation of this computing paradigm. You can compare this with “client-server computing” as a paradigm and “browser / web server” or “DB-client / stored procedure” as two (from other other) architectural implementations of this paradigm.

...

SOA is not brand new. Some specific aspects of SOA have been used in practice for a long time. For example, take a look at “free communication”: enterprises have been using reliable messaging technology since decades to integrate applications, i.e. Free to bind them. Don't get me wrong, there are new concepts in SOA, for example. concepts arising from a combination of concepts embedded in SOA, i.e. they arise because of the appearance.

Web service specifications enable advanced technology. That is, the corresponding specifications do not invent fundamentally new concepts, but determine how these concepts and corresponding implementations work in heterogeneous environments. As a result, interoperability is groundbreaking, making SOA real.

So SOA is a mixture of mature things and new emerging things.

There is also a link to April 2006 SoC paper .

---

A Google search identifies Prof. Frank Leymann and his works .

Answer 5

Neal Ford has many strong opinions regarding SOA. You may find his point of interest interesting.

Tactics versus Strategy (SOA and Tarpit of Irrelevancy)

Standard standards and standardized (SOA and Tarpit of Irrelevancy)

Tools and Anti-Behavior (SOA and Targeting Failure)

Rubick Cubicle (SOA and Tarpit of Irrelevancy)

The Triumph of Hope over Mind (SOA and Tarpit of Irrelevancy)

Guerrilla SOA (SOA and The Tarpit of Irrelevancy)

Answer 6

I think that SOA is a marketing term, and the integration of existing solutions with the idea, and not the sale of all software or a machine, we sell services.

Answer 7

For me, a service-oriented architecture arises when Enterprise wants to integrate the selection of disparate applications that belong to a common domain into a set of compatible services that work against a single data source.

In the case of a new startup company with an idea for a software element / software suite, I don’t see how a company can start with a service-oriented architecture from off. First, each solution (which can develop well into a service so that it can interact) should strive for an isolated solution to the problem space.

Perhaps it is in the “roadmap” for corporate capabilities or recruiting for each solution that it will become a compatible service as solutions are completed and services are introduced. To do this, perhaps the development team will take a modular / component approach to building soluton (a possible service) in order to simplify the inclusion of the solution as a service in a service-oriented architecture.

In the case where existing software islands become interoperable services in a service-oriented architecture, the approach allows software elements that can be distributed and written in different languages ​​to communicate through an open API and / or a common protocol (for example, the taste of the web services) and a common data format (e.g. XML).

SOA is an approach or an idea. This is not a wireframe or tool. When WDSL and EJB get a fall-name, it is often forgotten ... just like the idea of ​​SOA is not new at all.

Answer 8

Most of the answers here seem to indicate that SOA (Service Oriented architecture) refers to creating an application in a standardized way so that other applications can interact with it regardless of platform.

I'm not sure if the value has changed since then, but I had the opportunity to work with a company offering an SOA package and following my thoughts.

Of course, when developing an application, you cannot guarantee that it will be cross-platform compatible. Take stock Trading systems , for example. They use the Fix protocol to send messages. Do you now expect to return the data in XML format so that it can be called SOA-compliant? Absolutely not! SOA is an architectural approach that can help you decouple your application/services and allow them to interact with each other. An SOA backbone is an ESB (Enterprise Service Bus) that is used to transfer data from one service to another. An SOA architecture must take care of format conversions. For example -

 FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2) 

These conversion modules are commonly called adapters and are usually part of the SOA package. For more information, refer to another answer -

The difference between SOA and ESB

Of course, SOA is a hyped word for marketing purpose. Technically, it is as simple as de-serializing and serializing data so that services can be decoupled and platform independent, but the idea behind it is concrete.

Also link to the Wiki page for this.

Answer 9

Service Oriented Architecture (SOA) is an architectural template in which software is designed as a building block. that is, a modular design that provides flexibility in assembly in whatever way we want. If you want to start a new project, rather than starting from scratch, we can reuse services, and if you want a new service, we can easily integrate with an existing service to create a new project. Thus, we can save a lot of time and money. The basic principles of a service-oriented architecture are independent of suppliers, products, and technologies.

Analogy: Toys are built using Lego building blocks.

Answer 10

In fact, an SOA is a set of well-defined services. Basically, an SOA uses a loosely coupled service to easily get results. Information about the implementation of the service is hidden from the client / consumer, so any change in the implementation does not affect the service until the contract between them changes. Service providers are components that execute some business logic based on predefined inputs and outputs and expose this functionality through the implementation of SOA. This allows SOA-based systems to respond more quickly and cost-effectively to the business. The main difference between a component and SOA is that SOA provides an open standards message that is not specific to any programming language or platform. As a result, you can achieve a high degree of isolation and interaction between platforms and technologies. In the traditional world, the client-server provider will be the server, and the consumer will be the client. Here you can learn more about SOA: Service Oriented Architecture (SOA)

Answer 11

In fact, SOA also uses a client-server architecture. In addition, SOA is a way to develop your software. Suppose your application can break down into simple and independent tasks, such as finding a book, adding a new book, recommending a book according to your preferences, and so on. If you are considering a service (API) for each task, you are actually using SOA. The advantage of this architecture is not that you create a web application or a mobile application, you only need the above-mentioned services (APIs).