The concept of roost SOA, like today's "cloud computing, Big Data," is being fired, and many companies are responding and claiming to embrace and implement SOA. In fact, there are two extremes in the industry: one is that because the descriptions of the various articles and books about SOA are often too abstract, together with the calls of major vendors, SOA tends to be "tall", which discourages many enterprises and architects. The second is on the contrary, some people think that SOA is nothing more than "new bottle of old wine."
Personally, SOA is really too complex on the macro level, because it involves more than just technology and the architecture itself. From a technical point of view, it is not difficult to land.
The SOA full name is "Service Oriented Architecture", which provides an architectural style and philosophy, not a technology or product. It's not that the project uses WebService, WCF, Hessian, RMI or something like SOA.
In layman's terms, SOA advocates encapsulating the business functions of different applications as "services" and hosting them, often exposing them in the form of interfaces and contracts and providing access to external applications (by exchanging messages) to achieve reusable purposes for different systems.
Popular webservice can be seen as a technical way to implement an SOA infrastructure. Of course, practicing SOA not only needs to solve the problem of service invocation, but also includes service orchestration, service governance, service routing, service monitoring and so on. In large-scale distributed systems, SOA is widely practiced, but in different scenarios, the design approach varies greatly.
SOA is a component model that can connect different services through well-defined interfaces and contracts. Services are the cornerstone of SOA, and it is important to understand the concepts of services and the common features of services before starting service design and SOA practices.
What is a service
The concept of service is very broad, on the macro level, the understanding of the service is "to do things for others, to meet the needs of others, and usually do not provide labor in physical form ...". In an SOA system, a service refers to the functional unit of an application, which typically embodies the business function. A service is an abstraction that hides the implementation details inside the service to the service consumer. Depending on the basic principles of service design, a service may have the following characteristics:
L Autonomous (rationale) Nature
Services should be deployed and run independently, with clear boundaries, minimizing external references and dependencies.
L Coarse grain size
Service invocation requires overhead, which is a cost to a loosely coupled distributed system. As a result, you should try to transfer all the required data through a service call, instead of invoking the service and assembling the data multiple times.
L Visibility
Services are provided externally and must be searchable and discoverable in a public place, with the necessary description of the service.
L No Status
Services should not rely on the context, sessions, etc. of other services to minimize the resource consumption associated with unnecessary state management processes. However, for business process services, state data is unavoidable.
L Power-Equal sex
When a consumer invokes a service, the service invocation may have a "success, failure, timeout" of three states, and when the service does not have a final response to complete, the consumer can try to invoke the service repeatedly, which still does not affect the final result.
L reusability
Services should be reusable, the same functionality should be able to invoke the same service, which is the principle of software design.
L can be combined
Services can be considered as a step, and services can also invoke other services. This allows for a flexible combination.
The "coarse-grained, stateless, idempotent" nature of the service has been a controversial topic, a matter of opinion. It is important to note that these features are not essential to the service and should be tailored to the needs in practice.
An analysis of SOA