Part 1 of this series describes the knowledge of architect designers and SOA architectures, and analyzes where SOA architects should pay special attention to design SOA system architecture. This article will continue the content of the first part, introduce you to the impact of SOA as an enterprise architecture design, and
How to ensure the constructed system architecture can meet the different service level requirements in the system when building an SOA architecture-based enterprise system.
1. The effect of SOA is the impact of enterprise architecture design
1.1 SOA characteristics and range
SOA is neither a language, nor a specific technology, which is a new software system architecture model. The main application of SOA is to solve business integration issues between different commercial applications in the Internet environment. The Internet environment distinguishes between several features of the intranet environment is:
(a) a large number of heterogeneous systems coexist, different computer hardware works, different operating systems, programming languages are different;
(b) a large number of frequent speeds of data transmission is still relatively slow and unstable;
(c) Unable to complete the version of the service (Service) upgrade, even simply unable to know which machines on the Internet use a service directly or indirectly.
The SOA architecture has some typical features, mainly including loose coupling, position transparency, and protocol independence. Loose coupling requires a loosely coupled relationship between different services in the SOA architecture, which should maintain a relatively independent relationship; location transparency requires all services in the SOA system to come to their callers Say it is a transparent location, that is, the caller of each service only needs to know which service they call it, but do not need to know where the physical location of the calling service is not required; and the agreement is independent of each service. You can call through different protocols. Through these SOA architectures, we can see that the emergence of the SOA architecture provides a more flexible building method for enterprise system architecture. If the enterprise architect designer builds a system architecture based on SOA, you can guarantee from the primary architecture level. The loose coupling and flexibility of the entire system, which has made the foundation for the expansion of future business business logic.
1.2 sliding model for SOA architecture
Next, the layered model in the SOA system is briefly introduced, and the hierarchical model of the entire SOA architecture is shown in Figure 2.
Different functional modules in the SOA system can be divided into 7 layers: The first layer is the program resources already existing, such as an ERP or CRM system. Layer 2 is the component layer, in which we use different components to encapsulate the function of the underlying system. Layer 3 is the most important service layer in the SOA system. In this layer we need to build the different features we need with the underlying functional components. In general, services in SOA can be mapped into any functional module in a specific system, but from functional aspects, it can be generally divided into the following three types: (1) Business service or business process (Business Process). This kind of service is a service that companies can expose to external users or partners. For example, submit loan applications, user credit checks, loan credit queries. (2) Business Function Service, such services will complete some specific business operations, will be called more upal commercial services, but in most cases this kind of service will not expose to external users directly, For example, retrieve user account information, store user information, etc. (3) Technical Function Service, such services mainly complete some of the underlying technical functions, such as log services and security services. The 4th floor above the service layer is the business process layer, which we use various services that have been packaged to build business processes in the commercial system. On the commercial process layer is the 5th layer representation, we use the representation to provide user interface services to users, this layer can be built in portal-based systems. These 5 layers need to have an integrated environment to support their operations, and the Enterprise Service Bus (ESB) in Layer 6 provides this feature. The 7th floor mainly provides some auxiliary functions for the entire SOA system, such as service quality management, security management, and auxiliary feature. 2. Non-function-level demand in the SOA architecture
In addition to the business needs of the system, architectural designers must also ensure that the built-in system architecture can meet the non-function-level demand in the system and the quality of service (QoS). In the initial and refinement of the project, architect designers should be together with all the Stakeholders to define their related metrics for each service level. The build-up system architecture must meet the following aspects of service level requirements: performance, upgradeability, reliability, availability, scalability, maintainability, easy management, and security. Architecture designers need to balance all of these service level requirements during the design architecture. For example, if the service level needs are system performance, architect designers may have to sacrifice the maintenanceability and scalability of the system to ensure system performance requirements. With the development of the Internet, the newly constructed system has become increasingly important for service level, and now users of Internet-based enterprise systems are not limited to the employees of the company. The external customers of the enterprise will become the main user of the enterprise system. .
One of the responsibilities of architect designers is to consider the efficiency of improving system designers and system developers as much as possible. In the process of building a whole enterprise system architecture, you need to pay full attention to various service level needs, thereby avoiding major problems when system development and operation. The service level demand in an enterprise system is often very intricus. SOA architect needs to separate and abstract service-level needs in the abstract system with rich professional experience and solid theoretical knowledge. Figure 3 shows this analysis. process.
image 3
The SOA architect analysis and abstract service level requirements are mainly divided into the following categories:
Performance refers to the service provided by the system to meet certain performance measurements, which may include system response times and the ability to handle transaction.
The upgradeability is that when the system load is increased, it is possible to ensure the quality of the service required, without changing the architecture of the entire system;
Reliability refers to ensuring the integrity and consistency of all applications and related transactions;
Availability means that a system should ensure that a service or resource can always be accessed; scalability means that the ability to fill a new function or modify the existing functionality without affecting the existing system function;
Maintainability refers to the ability to fix problems or defects in existing functions without affecting the other parts of the system, and maintaining the entire system;
Manageable management means that the management system ensures the ability of the system's upgradeability, reliability, availability, performance, and security;
Security refers to ensuring that system security is not endanger.
1) Performance
We can usually measure the overall performance of the system according to the system response time accessed by each user; in addition, we can also measure the performance of the system through the system capable of processing the transaction (per second). For architect designers, no matter which measure system performance is taken to build system architectures, these considers of performance should be transparent to system design developers, that is, for system overall architecture performance should be considered It is the work of architect designers, rather than what system design developers should pay attention. In a more conventional EJB or XML-RPC-based distributed computing model, their service provides through function calls, and the completion of a function is often necessary to call back to the remote function call back to the server. carry out. In an intranet environment, these invoifications can be ignored to the system's response speed and stability, but if we use a lot of web services to provide a point in the SOA-based architecture, we need to consider The impact of performance, especially in the Internet environment, is often a key determinant that determines whether the entire system can work properly. Therefore, in SOA-based systems, it is recommended to use large amounts of low frequency access mode, which is to exchange information at once in a large amount of data. This can improve the overall performance of the system to a certain extent.
2) Upgradeability
Upgradeability means that when the system load is increased, it is still possible to ensure the quality of service required without changing the architecture of the entire system. When the load based on the SOA-based system increases, if the response time of the system can still be within acceptable limits, then we can think that this system is reality. To understand the upgradeability, we must first understand the system capacity or system's ability to afford the capacity, that is, a system that guarantees the maximum number of processes that can be processed or the maximum number of users supported. If the system is running, it is no longer able to react within the acceptable time range, then this system has reached its maximum upgraded state. To upgrade the system that has reached the maximum load capacity, you must add new hardware. The newly added hardware can be added in a vertical or horizontal manner. Vertical upgrades include adding processors, memory, or hard disks for the current machine. Horizontal upgrade includes adding new machines to an environment to increase the overall processing power of the system. The architecture that is designed as a system architecture designer must be able to handle vertical or horizontal upgrades for hardware. SOA-based system architecture can guarantee the upgradeability of the overall system, mainly because the function modules in the system have been abstracted into different services, all hardware and underlying platforms are shielded under service, Therefore, whether it is a horizontal upgrade of an existing system or a vertical rope, it will not affect the overall architecture of the system.
3) Reliability
Reliability refers to ensuring the integrity and consistency of all applications and all relevant transactions. When the system load increases, your system must be able to process demand access and ensure that the system can properly handle each process as before the load is not increased. Reliability may limit the upgradeability of the system to a certain extent. If the system load is increased, it cannot maintain its reliability, then this system does not have upgradeability. Therefore, a truly upgraded system must be a reliable system. When building a system architecture based on SOA, reliability must also focus on problems. To ensure a certain system reliability in a SOA architecture, you must first guarantee the reliability of different services distributed in the system. The reliability of different services can generally be guaranteed by their deployed application servers or web servers. Only by ensuring that services in each SOA system have high reliability, we can guarantee the overall reliability of the system to be guaranteed. 4) Availability
Availability means that a system should ensure that a service or resource should always be accessed. Reliability can increase the overall availability of the system, but even if the system components are wrong, sometimes it does not necessarily affect the availability of the system. By setting redundant components and error recovery mechanisms in the environment, although a separate component error affects the reliability of the system, the entire system service is still available due to the presence of system redundancy. When building a system architecture based on SOA, for critical services require more consideration of its availability requirements, this can be supported by two levels of technical implementation, the first one is to implement the internal system based on the specific internal interior of different services. The fault or redundant mechanism of the frame is supported to support the availability of the service; the second is to support the overall availability of the system through dynamic lookup matching methods such as UDDI. When the SOA architect builds a corporate system architecture, you should consider the contents of these two aspects, try to ensure that key services in the SOA system architecture constructed can have high availability.
5) Scalability
Scalability refers to the ability to add new features or modify existing features without affecting existing system functions. When the system is just configured, you will be difficult to measure its scalability until the first time you have to expand the system already function, you can really measure and detect the scalability of the entire system. Any architect designer is building a system architecture, in order to ensure the scalability of architecture design, the following elements should be considered: low coupling, interfaces, and packaging. When the architecture designer builds the Enterprise System architecture based on SOA, the extensibility elements have been implicitly solved. This is because the different services in the SOA architecture have maintained a dependence of low coupling relationships; the service itself describes the specific service content by unified interface definition (can be WSDL) language, and is well packaged The specific implementation of the underlying layer. Here we can also see the benefits of the SOA architecture enterprise system from one aspect.
6) Maintainability
Maintainability refers to modifying the ability of issues or defects in existing system functions without affecting the other parts of the system. The same scalability is the same, when the system is just deployed, it is difficult to judge whether a system has a good maintenanceability. When creating and designing a system architecture, you must improve your system's maintenanceability, you must consider the following elements: low coupling, modular, and system documentation. In Enterprise System Scalability We have mentioned that the SOA architecture can expose each sub-function module that is exposed in the system is to bring low coupling and good modularity. With regard to the system document record, in addition to the relevant documentation of the underlying subsystem, SOA-based systems will also reference the services provided by third parties outside the system, so if the human resources are allowed, the full-time document administrator should be responsible. Collection, classifying, and finishing all external services related documents involved in the entire enterprise system, these related documents may involve the interface of third-party services (can be WSDL), the quality and level of the service, the specific performance test results, etc. Related documents. Based on these documents, you can provide good documentation and support for the SOA architect building enterprise SOA architecture.
7) Manageability
Manageability is the ability to manage the management system to ensure the ability to upgradeability, reliability, availability, performance, and security. A manageable system should have system monitoring capabilities for service quality requirements (QoS), and dynamically improve service quality by changing the configuration of the system, 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. When system architecture is modeled in complex systems, SOA architects should try to consider the use of system overall architecture on an existing mature underlayer framework (Framework). For SOA architect designers, there are many underlying system frameworks, which can be used to build Enterprise Services Bus (Enterprise Service Bus) to support enterprise SOA system architecture based on MQ, MessageBorker, WebSphere Application Server. New SIBUS Based on WebSphere Application Server 6 is built to build an ESB of the company to support the SOA system architecture. Specifically, which bottom framework is to implement the SOA system architecture to be determined according to each of the systems, but these underlying frames have provided higher system manageability. Therefore, analyzing and selecting different products or underlying frames to achieve corporate system architecture is also one of the main responsibilities of architect designers. About how to use the underlying architecture to build a SOA system, China SOA Design Center has published a series of related articles, you can see them in the SOA column in developerWorks. 8) Safety
Security refers to ensuring that system security is not endanger. At present, security should be said to be the most difficult system quality control point. This is because security not only requires the system's confidentiality and integrity, but also prevents the Denial-of-Service attack affecting the availability. This requires that when the SOA architect designer builds an architecture, the overall system architecture should be divided into individual sub-function modules as much as possible. When some sub-function modules are exposed to the service visible outside, we must surround each sub-module. Build their own security zones, which makes it easier to ensure the safety of the overall system architecture. If a submoduption is securely attacked, you can also ensure that other modules are relatively safe. If some of the services in the Enterprise SOA architecture is implemented by Web Service, it is necessary to consider efficiency when considering these service security, as WS-Security will bring a certain efficiency loss for Web Service.
3. Conclusion
This series describes the knowledge of architect designers and SOA architectures. It analyzes what SOA architects should pay special attention when designing the SOA system architecture and, in the end, it should be introduced to build SOA architectural enterprise systems. How to ensure that the system architecture constructed can meet different service level requirements in the system. From the perspective of architect designers, SOA is a new design pattern, methodology. Therefore, SOA itself covers a lot of content, also touches all aspects of system overall architecture design, implementation, and maintenance. The content of this article is only involved in the content of the architecture, hoping to play a certain help of the majority of SOA system development and designers.
