Architecture designer and SOA (Part 2)

This article will continue the first part and introduce the impact of SOA on enterprise-level architecture design, and how to ensure that the system architecture can meet different service level requirements in the system when building an enterprise system based on SOA.

1. The impact of SOA on enterprise-level architecture design

1.1 characteristics and application scope of SOA

SOA is neither a language nor a specific technology. It is a new software system architecture model. The main application of SOA is to solve the problem of business integration between different commercial applications in the Internet environment. Different from the Intranet environment, the Internet environment has the following features:

(A) A large number of heterogeneous systems coexist. Different computer hardware works in different ways, operating systems and programming languages;

(B) massive and frequent data transmission speeds are still relatively slow and unstable;

(C) the version of the service cannot be upgraded, or even the machines on the Internet cannot directly or indirectly use a service.

The SOA architecture has some typical features, including loose coupling, location transparency, and Protocol independence. Loose coupling requires that different services in the SOA architecture maintain a loose coupling relationship, that is, a relatively independent and independent relationship; location transparency requires that all services in the SOA system be location-transparent for their callers. That is to say, each service caller only needs to know which service they are calling, however, you do not need to know where the physical location of the called service is. Protocol independence requires that each service can be called through different protocols. Through the features of these SOA architectures, we can see that, in the SOA gully, when a doctor is in charge of the governance of di shaochen, he is a zombie, and the mushroom in the tomb is twisted and twisted? To build a system architecture with SOA, we can ensure the loose coupling and flexibility of the entire system at the underlying architecture level, laying the foundation for the expansion of enterprise business logic in the future.

1.2 layered model of SOA Architecture

Next, we will briefly introduce the layered model in the SOA system, as shown in Layered Model 2 of the entire SOA architecture.

Different functional modules in the SOA system can be divided into seven layers: the first layer is the existing program resources of the system, such as ERP or CRM systems. Layer 3 is the component layer. In this layer, we use different components to encapsulate the functions of the underlying system. Layer 2 is the most important service layer in the SOA system. In this layer, we need to use underlying functional components to build services with different functions that we need. In general, services in SOA can be mapped to any functional module in a specific system, but they can be roughly divided into the following three types in terms of functionality: (1) Business Service) or a business process ). This type of service is a service that an enterprise can expose to external users or partners. For example, submit a loan application, user credit check, and loan credit query. (2) commercial function services, which perform specific commercial operations and are also called by upper-level commercial services, however, in most cases, such services are not exposed to external users for direct calls, such as searching user account information and storing user information. (3) Technical Function Service (Technical Function Service), which mainly implements some underlying technical functions, such as Log Service and Security Service. The 4th layer above the service layer is the Business Process Layer. In this layer, we use encapsulated services to build business processes in the business system. On the business process layer, the presentation layer is the 5th layer. We use the presentation layer to provide user interface services. This layer can be built using a portal-based system. The above five layers all need an integrated environment to support their operation. The Enterprise Service Bus (ESB) in layer 6th provides this function. Layer 3 provides some auxiliary functions for the entire SOA system, such as service quality management and security management.

2. Non-functional service-level requirements in the SOA Architecture

In addition to the business needs of the system, the architecture designer must ensure that the constructed system architecture can meet the non-functional service-level requirements and QoS requirements of the system) requirements. In the initial and refined phases of the project, architects should, together with all systems involved (stakeholders), define relevant measurement standards for each service-level requirement. The constructed system architecture must meet the following service standards: performance, scalability, reliability, availability, scalability, maintainability, manageability, and security. Architects need to balance all these service-level requirements during the design of the architecture. For example, if the most important service-level requirement is system performance, the architecture designer may have to sacrifice the maintainability and scalability of the system to a certain extent to ensure that the system performance requirements are met. With the development of the Internet, the new system has become increasingly important for service level requirements. Now, Internet-based enterprise system users are not limited to their employees, external customers of the Enterprise will also become the main users of the enterprise system.

One of the responsibilities of an architecture designer is to consider how to improve the efficiency of system designers and system developers. In the process of building the entire enterprise system architecture, we need to pay full attention to various service level requirements, so as to avoid major problems during system development and operation. Service-level requirements in an enterprise-level system are often very complicated. SOA architects need to separate and abstract different service-level requirements in a system based on their rich professional experience and solid theoretical knowledge, figure 3 shows the analysis process.

Figure 3

After analysis by the SOA architecture designer and abstract service level requirements, there are mainly the following types:

Performance means that the services provided by the system must meet certain performance measurement standards. These standards may include the system response time and the ability to process transaction volumes;

Scalability refers to the ability to ensure the required service quality when the system load increases, without the need to change the overall system architecture;

Reliability refers to the ability to ensure the integrity and consistency of each application and all related transactions;

Availability means that a system should ensure that a service or resource is always accessible;

Scalability refers to the ability to add new functions or modify existing functions for the system without affecting existing system functions;

Maintainability refers to the ability to correct existing functional problems or defects without affecting other parts of the system and maintain the entire system;

Manageability refers to the ability to manage systems to ensure system scalability, reliability, availability, performance and security;

Security refers to the ability to ensure that system security is not compromised.

1) Performance

We can usually measure the overall system performance based on the system response time accessed by each user. In addition, we can also measure the system performance by the transaction volume that the system can process (per second. For architects, no matter which method is used to measure the system performance to build the system architecture, these performance considerations should be transparent to system design developers, that is to say, the overall architecture performance of the system should be the work of the Architecture designer, rather than the concern of system design developers. In the traditional distributed computing model based on EJB or XML-RPC, their service provision is carried out through function call, the completion of a function usually requires many remote function calls from the client and the server. In an Intranet environment, the impact of these calls on the system's response speed and stability is negligible, however, if we use a lot of web services to provide services in the SOA-based architecture, we need to consider the impact of performance, especially in the Internet environment, these are often a key factor that determines whether the entire system can work normally. Therefore, in an SOA-based system, it is recommended to adopt a low-frequency access mode with large data volumes, that is, one-time information exchange with large data volumes. This can improve the overall performance of the system to a certain extent.

2) scalability

Scalability means that when the system load increases, it can still ensure the required service quality without changing the overall system architecture. When the load of an SOA-based system increases, if the response time of the system is still acceptable, we can think that the system is upgradeable. To understand the scalability, we must first understand the system capacity or system affordability, that is, while ensuring the normal operation quality of a system, the maximum number of processes that can be processed or the maximum number of users that can be supported. If the system is no longer able to respond within the acceptable time range, the system has reached its maximum update status. To upgrade the system that has reached the maximum load capacity, you must add new hardware. The newly added hardware can be added vertically or horizontally. Vertical upgrades include adding a processor, memory, or hard disk to the current machine. Horizontal upgrades include adding new machines in the environment to increase the overall processing capability of the system. The architecture designed by a system architecture designer must be able to handle vertical or horizontal upgrades to the hardware. The SOA-based system architecture can ensure the overall system's scalability. This is mainly because the functional modules in the system have been abstracted into different services, all hardware and underlying platform information is shielded under the service. Therefore, horizontal or vertical upgrades to existing systems do not affect the overall architecture of the system.

3) Reliability

Reliability is the ability to ensure the integrity and consistency of each application and all related transactions. When the system load increases, your system must be able to continuously process access requests and ensure that the system can process processes correctly as before the load increases. Reliability may limit the scalability of the system to a certain extent. If the reliability of the system cannot be maintained when the system load increases, the system is not upgradeable. Therefore, a truly scalable system must be reliable. When building a system architecture based on SOA, reliability must also be considered. To ensure certain system reliability in a SOA-based system, we must first ensure the reliability of different services distributed in the system. The reliability of different services can be guaranteed by the deployed application server or web server. Only by ensuring the high reliability of services in each SOA system can we ensure the overall reliability of the system.

4) Availability

Availability means that a system should ensure that a service or resource is always accessible. Reliability can increase the overall availability of the system, but sometimes it does not necessarily affect the system availability even if the system component fails. By setting redundant components and error recovery mechanisms in the environment, although the error of a single component may have a negative impact on the reliability of the system, due to the existence of system redundancy, make the entire system service still available. When building a system architecture based on SOA, the availability requirements of key services need to be considered more, which can be supported by two levels of technical implementation, the first is to use the specific internal implementation of different services to implement internal framework fault tolerance or redundancy mechanisms to support service availability; the second is to support the overall high availability of the system through dynamic search and matching methods such as UDDI. When building an enterprise system architecture, SOA architects should consider these two aspects comprehensively to ensure high availability of key businesses in the constructed SOA system architecture.

5) scalability

Scalability refers to the ability to add new functions or modify existing functions to the system without affecting existing system functions. When the system is configured, it is difficult for you to measure its scalability. Until the first time you have to expand the existing functions of the system, you can truly measure and detect the scalability of the entire system. When building a system architecture, any architect should consider the following elements to ensure the scalability of the Architecture Design: low coupling, interface (interfaces) and encapsulation. When an architecture designer builds an enterprise system architecture based on SOA, these scalability elements have been implicitly addressed. This is because different services in the SOA architecture maintain a dependency-free low coupling relationship. The service itself is defined through a unified interface (may be WSDL) language to describe specific service content, and well encapsulate the specific implementation of the underlying layer. Here we can also see the benefits of SOA-based architecture of enterprise systems.

6) maintainability

Maintainability refers to the ability to modify problems or defects in existing system functions without affecting other parts of the system. The scalability of the same system is the same. When the system is deployed, it is difficult to determine whether a system has good maintainability. When creating and designing a system architecture, you must consider the following factors to improve system maintainability: low coupling, modularity, and system documentation. In the scalability of enterprise systems, we have mentioned that the SOA architecture can bring low coupling and good controllability to the sub-functional modules exposed in the system, that is, services. In addition to the documentation of the underlying subsystem, SOA-based systems also reference services provided by third parties outside the system. Therefore, if human resources permit, A full-time document administrator should be added to collect, classify, and organize documents related to all external services involved in the entire enterprise system, these documents may involve APIs of third-party services (such as WSDL), service quality and level, and specific performance test results. Based on these documents, it can provide a good reference and support for SOA architects to build an Enterprise SOA architecture.

7) manageability

Manageability refers to the ability to manage the system to ensure the scalability, reliability, availability, performance and security of the entire system. A manageability system should be able to monitor the quality of service (QoS). By changing the system configuration, the service quality can be dynamically improved without changing the overall system architecture. A good system architecture must be able to monitor the operation of the entire system and have the function of Dynamic System Configuration Management. During System Architecture Modeling of complex systems, SOA architects should consider building the overall system architecture on an existing mature underlying system framework. There are many underlying system frameworks that can be selected by SOA architects. You can use MQ, messageborker, WebSphere Application Server, and other products to build an enterprise service bus) to support the enterprise's SOA system architecture, you can also use a newer sibus embedded in WebSphere Application Server 6 to build an enterprise's ESB to support the SOA system architecture. The underlying framework to be selected to implement the SOA system architecture depends on the characteristics of each system. However, these underlying frameworks have provided high system manageability. Therefore, analyzing and selecting different products or underlying frameworks to implement enterprise system architecture is also one of the main responsibilities of architecture designers. The Chinese SOA Design Center has published a series of articles on how to use existing underlying architectures to build SOA systems. You can see them in the SOA column on developerworks.

8) Security

Security refers to the ability to ensure that system security is not compromised. Currently, security is the most difficult control point for system quality. This is because security not only requires the confidentiality and integrity of the system, but also prevents denial-of-service attacks that affect availability. This requires that when building an architecture, SOA architects should divide the overall system architecture into sub-functional modules as much as possible, when exposing some sub-functional modules to services visible to external users, we need to build their own security zones around each sub-module, which makes it easier to ensure the security of the overall system architecture. If a sub-module is under security attack, it can also ensure the security of other modules. If some services in the Enterprise SOA architecture are implemented by web services, you must also consider efficiency when considering the security of these services, because WS-Security brings a certain degree of execution efficiency loss to the web service.

3. Conclusion

This series introduces the knowledge of architecture designers and SOA architectures, this article analyzes what the SOA architect should pay special attention to when designing the SOA system architecture. At last, it briefly introduces how to ensure the ability of the built system architecture to build an enterprise system based on the SOA architecture. meets different service level requirements in the system. From the perspective of architecture designers, SOA is a new design model and methodology. Therefore, SOA covers a lot of content and involves the overall architecture design, implementation, maintenance, and other aspects of the system. The content of this article only involves a part of the content about the architecture, hoping to help the majority of SOA system developers.