Before we talk about service-oriented architecture, let's look at what services are. Talk about business components, business methods or operations are all services? The real service must meet two conditions, a service itself is the ability to supply, must have external needs; one is that the service itself is reusable or reusable. In general, a service should be a reusable task, which can be a combination of business operations or a technical capability.
Service-oriented focus is all service-centric, from service identification, service analysis, service design, service development and service on-line use everything is service-centric. However, it is important to note that service orientation is not a new approach to structure-oriented or object-oriented, but an elevation to object-oriented and component-based thinking.
Service-oriented architecture is easily understood as a technical architecture, and SOA itself is more of an architectural style, this architectural style and traditional software development is the most different from the idea of business and process-driven it, embodies the IT system components and service-building ideas, reflecting the service itself can be reused, The implementation of the business can be met through a combination of services and orchestration. SOA as an architectural style, so that the demand side and the supply side have a common language and value Agreement; SOA as an architectural style, so that services are not purely a technical capability, but more a business capability and it intellectual assets.
Look at the full definition of SOA on Wikipedia:
A service-oriented Architecture (SOA) isAn architectural patterninchComputer Software DesigninchWhich application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation is independent of any vendor, product or technology. [1]a Service isA self-contained unit of functionality, such asRetrieving an online bank statement. [2] By that definition, a service isA discretely invokable operation. However,inchThe Web Services Definition Language (WSDL), a service isAnInterfaceDefinition that the May list several discrete services/operations. And elsewhere, the term service isUsed forA component that isEncapsulated behind anInterface. This widespread ambiguity isReflectedinchWhat follows. Services can be combined to provide the functionality of a large software application. [3] SOA makes it easier forSoftware computers connected over a network to cooperate. Every computer can run any number of services, and each service isBuiltinchA-the-ensures that the service can exchange information with any other serviceinchThe network without human interaction and without the need to make changes to the underlying program itself.
SOA is generally said to be an architectural approach that breaks down monolithic applications into discrete, autonomous business services that leverage standards to enhance their interoperability so that they can be better shared, reused, and assembled to quickly build composite applications to meet changes in business needs. There are two key points, one is to find reusable services, and these services meet the basic conditions of discrete, autonomous and stateless, and secondly, the service itself can be combined and orchestrated to meet the needs of process integration.
The first step in the process of finding a service is System analysis and modeling from the top down process, to fully embody the implementation of process-driven it, through process decomposition, business modeling and data modeling, identify business components and business capabilities, through the process of cross-system or component interaction to identify reusable services. Finally, a reusable service Intelligence Asset Library is formed. The second step of the assembly and orchestration of the service is more from the bottom-down process, for the atomic services we can be combined into a combination of services, for business services we can combine and orchestrate the formation of process sub-service and process services, and ultimately enable reusable services to meet the needs of process interaction.
In the process of cross-system process integration and SOA application integration, high-end modeling focuses on the EA Enterprise Architecture or the TOGAF methodology, starting with the business architecture, data architecture and application architecture, and decomposing and unfolding the analysis to derive the overall cross-business system process interaction and integration architecture. For SOA applications within the system, the focus remains on the identification of business components, service components and service identification through interactions between components, and the extraction of reusable service component units.
So how does the application system itself be understood based on the SOA architecture? If an application is based on an SOA architecture, at least we need to see that the application has a clear definition of business components and service components, and that the components meet the requirements of high cohesion and coupling, and secondly for the interaction between components through the service, or at least the service interface reserved Secondly, the internal services can be flexibly reused or combined. As to whether there is an internal ESB bus is not the focus, but we see as. NET development internal IOC mechanism is also based on the internal soft bus idea, to achieve good interoperability and location transparency.
Another core of SOA is to achieve two levels of decoupling, one is the decoupling of business and technology, business implementation no longer depends on a particular technology or language, as long as the business standards can be implemented to implement SOA and services, it is because of business and technology loosely coupled, technology changes to business impact less. Another aspect is the decoupling of the operation method and the business data entity, and for the operation method we can follow the WSDL file definition, and the transferred data entity can be defined by the XSD, which is similar to the separation of the control class and the entity class in the Rup development method.
SOA has some basic features, and here's a simple explanation:
- Coarse granularity: Simply exposing what needs to be exposed, methods and transports are simple, but the internal process of implementing the method is complex, and the business rules or logic are all hidden within the business components and do not need to be exposed.
- Stateless: Every time the service call completes, it does not store any global state information, which is also a feature of WebService.
- Interoperability: Including location transparency, through ESB and UDDI, only care about the service catalog, not the source system that specifically provides the service.
- Standardization: There is a precise service contract and service interface, which is also an important output during the service Identification and service analysis phase in the SOA methodology.
If you want to cite a simple example to illustrate SOA, you can use movable printing to illustrate that: the 3000-4000 words used in print is the most basic atomic services, with these atomic services we easily through these characters to typesetting the entire article. The content of the article has been adjusted we just need to adjust the order of these atomic services. But if all is a single Chinese character typesetting work is still very large, so upward will appear phrases or commonly used phrases, these are the combination of services, so the typesetting speed can be increased, but you can see the phrase or phrase can be reused compared to the reduction of individual characters. Therefore, the more complex the service or process services, the more difficult the reuse, but if it can be reused can greatly improve efficiency.
Some thoughts on service-oriented architecture