The term SOA is surrounded by hyperbole and generalizations. We need a definition that we can work with.
You need to define the SOA with some precision before proceeding to respond correctly to the expectations. A large amount of exaggerations has surrounded SOA in recent years, somewhat complicating the issue. But it can be done. Many definitions There is SOA. Here is the desired definition as follows:

"SOA is an architecture that uses serviceable components to simplify integration activities again It is used in the form of a building block in the form of a loose connection."

In the following, we will expand the discussion:
SOA is a type of architecture.
While this may be overstating the obvious, there is a small lesson in it. Create a collection Services do not automatically provide a simple architecture. Architecture, while a guide to service creation, It is a separate issue from the implementation of the service itself.
In SOA terms, it uses service orientation as an attribute of the architecture. That is, SOA is an architectural process, which can be implemented describes to be. This is not a development mode. An EJB cannot simply be interpreted to represent a The service is online and now we have an online service. There must be a proper beginning for SOA. If carefully to If we look at the goal, it is possible to have a very laborious and expensive start.
Building SOA requires considerable analysis and integration and cannot be achieved by simply buying a product.
SOA is built with services.
This service is part of Service Oriented Architecture and we proceed with emphasis on the said definition. If there is no architecture Or if the service is not the main part of the architecture, SOA is meaningless. (Like an object-oriented system in which the object is the main part.)
Without services there is nothing to build, nothing to monitor and nothing to run. On the other hand, someone who takes a lot of trouble Can produce a set of architectural diagrams that relate to the real world. If you carefully work on the set Focus on the implementation of services and forget the architecture, not only do you not have SOA, you have something worse. and time And it will charge you a significant amount to solve an unrelated problem. This wrong process is not following the pattern (anti-pattern). It is said to cause a set of Aimless web services be. Also the programmers caused without architectural guidance They work inadvertently distracting the business from following the pattern, which is the result of a set of Services without Sovereignty who are not able to build SOA.

SOA makes integration easy.
SOA is a way of thinking about integrated systems States. SOA offers new or expanded business or opportunities with It offers the connection of multiple systems together. In its simplest form, this means that you can do B2B work Do it faster.
CORBA, connectivity architecture, EDI, point-to-point EAI have tried for decades to all demonstrate the ability to integrate They have different systems. But such efforts can be costly and fragile. They can be programmers and distract IT departments from solving real business problems. In general, SOA uses XML as the standard form for The message brings us closer to the goal of integration.
SOA facilitates reuse by implementing loose coupling.
The idea that SOA reuse with deployment Loose connection It makes it easy to make a key point in the discussion Support efforts Integration is. SOA proposes two distinct ideas: First Reuse makes it easy, and this work It does this by creating loosely coupled components.
At the beginning of the integration process or the previous efforts to provide the service, the focus is entirely on the idea of reuse did not have. But now it is possible, new standards and the use of a public format such as XML for message exchange, for Implement important services in a generic and complete way so that the services can be reused.
Can be reused in form one Interactivity be shown in general. If two software components can interact with each other This does not mean a loose connection. But loosely coupled components can eventually interact with each other. Reusability is achievable alongside loosely coupling services, but it is not a requirement for each service's purposes. Reuse in every service is not very necessary.
"SOA with non-reusable components is not an SOA."