Architecture designer and SOA)

SOA (Service-Oriented Architecture) is a service-oriented architecture, the most widely used word in various technical journals in the past one or two years. Currently, many architecture designers and design developers simply equate SOA with Web Services, and think SOA is a kind of Implementation of Web Services. In essence, SOA represents a new system architecture. The emergence of SOA will have a huge impact on the design of the entire enterprise-level software architecture. Two parts of this series Article Based on the author's own understanding, we will help you analyze and understand what SOA architecture is, how SOA will positively affect enterprise system architecture design, and what is the role of SOA architecture designer, what Should SOA architects pay special attention to when designing the SOA system architecture.

1. What is architecture? What is an SOA-based architecture?

1.1 What is architecture

From the perspective of architects, architecture is a set of system building principles. Through this set of rules, we can divide a complex system into a set of simpler subsystems, which should be independent from each other and consistent with the entire system. In addition, each subsystem can be further subdivided to form a complex enterprise-level architecture.

When an architecture designer builds an enterprise-level software system, in addition to considering the architecture of the system and its functional behavior, he must also pay attention to the availability and performance of the entire architecture, fault Tolerance, reusability, security, scalability, manageability, maintainability, and reliability. Sometimes a good architect even needs to consider whether the system architecture meets aesthetic requirements. From this we can see that a good architecture design can not only be measured from the functional perspective, but also many other factors, the lack of any aspect may pose a hidden risk for the construction of the entire system.

1.2 What is an SOA-based architecture

SOA itself is a system architecture oriented to enterprise-level services. Simply put, SOA is a new system architecture for system development. It is applied in SOA-based systems.ProgramThe function is built by a combination of components (that is, services) that are loosely coupled and have a uniform interface definition. Therefore, the SOA-based architecture must begin with the specific needs of the enterprise. However, the difference between SOA and other enterprise architectures lies in the business flexibility provided by SOA. Business flexibility refers to the ability of an enterprise to quickly and effectively respond to business changes and use business changes to gain a competitive advantage. For enterprise-level architecture designers, creating a flexible business architecture means creating an IT architecture that can meet the current unknown business needs.

Using the SOA-based system construction method, as shown in 1, all program functions in a SOA-based system are encapsulated in some functional modules, we use these encapsulated functional modules to assemble the programs or systems we need. These functional modules are different services in the SOA architecture ).

Figure 1

Therefore, the SOA architecture essentially embodies a composite concept: it not only provides a guiding mode for the organization and implementation of business processes in an enterprise, it also provides guidance for the development of specific underlying services.

2. Roles of SOA architects

2.1 What Should SOA architects have?

When talking about the role of SOA architects, we must first understand the capabilities that architects should possess. In general, a good architect should not only be a mature, practical, and fast-learning person, but also have good management and communication skills. Only with the necessary capabilities can an architect make difficult decisions at a critical moment. This is the responsibility of an architect. From the perspective of roles, the SOA architect is not only responsible for the design of end-to-end service requestor and provider, but also for the investigation and presentation of non-functional service requests in the system.

For any experienced architecture designer, whether it is based on the traditional architecture design method (based on the J2EE architecture or. net Architecture) or the SOA-based architecture design method is used to build an enterprise-level system architecture. knowledge in the relevant business field is essential for architecture designers, architects often obtain knowledge in these business fields through practical experience accumulation and relevant special training. In addition to knowledge in the relevant business field, a qualified architecture designer must have a wide range of technical backgrounds, which may include hardware and software, communication, security, and other aspects of knowledge. However, this does not mean that to become an architecture designer, you must be familiar with the details of each specific technology. The architecture designer must at least have an overall understanding of various technologies, be familiar with the characteristics and advantages and disadvantages of each technology. Only in this way can the architecture designer correctly select various technologies in specific application scenarios to design the overall architecture of the enterprise.

2.2 What is the responsibility of SOA architects?

So what is the role of an enterprise-level SOA architect? What is the difference between SOA architects and design and development personnel? I believe these are the most confusing problems. For example, when building a system based on the SOA architecture, system designers should focus mainly on the services that the service can provide to external users. That is to say, the system designers are concerned with the functions provided by the Service. For SOA architects, they are more concerned about what will happen when one thousand users call this service at the same time? That is to say, architects should focus on business needs and service-level needs. The roles of all architects include minimizing possible technical risks from the very beginning of building a system. Technical risks generally refer to all unknown, unproven, or untested risks. These risks are usually related to service-level requirements, and occasionally related to specific business needs of the enterprise. Regardless of the type of risks, it is easier to discover these risks when designing the overall system architecture at the initial stage of the project. If these risks are discovered when the architecture is implemented, A large number of developers may wait until these risks are properly solved. For further refinement, we can see that the main tasks of the SOA architecture designer include building the outline of the entire system solution, requirement analysis, overall decision-making on the architecture, and modeling of related components, relevant operation modeling, logical and physical layout design of system components.

As an SOA architecture designer, you must be able to lead the entire development team to ensure that the design and development personnel develop the entire system according to the built system architecture. This is important at 01:10. This requires an architect not only to have good technical insight, but also to have certain project management and project implementation capabilities. In the process of system development, the architecture designer must have good communication and expression skills, which is reflected in whether the system model built by the architecture designer has good readability and comprehensibility. If the system model constructed by the architect is not clear, it may affect the design and developers' understanding of the entire system architecture. To avoid this situation, it is very important to regularly discuss the development team hosted by the architecture designer.

3. issues that should be paid attention to when building an SOA Architecture

3.1 Integration requirements in original system architecture

When architects build an enterprise-level system architecture based on SOA, they must carefully analyze and organize the integration requirements in the original system architecture. We all know that the service-oriented architecture is the focus of current and future application system development. The service-oriented architecture is essentially a special architecture, it is built and interconnected by integrating components with interoperability and location transparency. SOA-based enterprise system architecture is usually developed on the basis of existing system architecture investment, and we do not need to completely re-develop all subsystems; SOA can reuse existing systems and resources in the system by utilizing existing system resources (developers, software languages, hardware platforms, databases, and applications. SOA is an adaptive and flexible architecture. A system architecture built based on SOA can shorten product time to market during system development and maintenance, therefore, the cost and risks of enterprise system development can be reduced. Therefore, when an SOA architect encounters a very complex enterprise system, the first thing to consider is how to reuse existing investments rather than replacing legacy systems, because if a limited budget is taken into account, the cost of overall system replacement is very high.

When the SOA architect analyzes the integration requirements in the original system, it should not be limited to the integration of existing applications built based on components. The real integration is much broader than this. When analyzing and evaluating the integration requirements of an existing system architecture, we must consider more specific integration types, which mainly include the following aspects: application integration requirements, end user interface integration requirements, process integration requirements, and existing system information integration requirements. When the SOA architect analyzes and evaluates all possible integration requirements in the existing system, we can find that all integration methods are actually reflected to a certain extent in any type of enterprise. For different enterprise types, these integration methods may be simplified or not clearly defined. Therefore, SOA architects must fully consider all possible integration requirements when starting to design a new architecture framework. For example, in some enterprise system environments, there may be only a few data source types. Therefore, the requirements for message integration in the system may be very simple, but in some specific systems, for example, the Electronic Data Interchange (EDI) system in the shipping system has a large number of electronic data exchange and processing requirements, so there will be many different data source types, in this case, the entire system requires more complex integration of message data. Therefore, if the SOA architect hopes that the system architecture can be successfully maintained as the enterprise grows and changes, the integrated functions in the entire system architecture should be provided by the Service, instead of specific applications.

3.2 service Granularity Control and stateless service design

When an SOA architect builds an enterprise-level SOA system architecture, there are two important points to note about the most important elements of the system, namely the construction of services in the SOA system: the first is service granularity control, and the design of stateless services.

Service Granularity Control

Service Granularity Control in SOA systems is a very important design task. Generally, coarse-grained interfaces are recommended for services exposed outside the entire system, while relatively fine-grained service interfaces are usually used inside the enterprise system architecture. Technically, coarse-grained service interfaces may be the complete execution of a specific service, while fine-grained service interfaces may be the specific internal operations that implement this coarse-grained service interface. For example, for an online store based on the SOA architecture, coarse-grained services may be the purchase submission form that is exposed to external users, the fine-grained service in the system may be a series of internal services that submit the Purchase Form service, such as creating purchase records, setting customer addresses, updating databases, and other operations. Although fine-grained interfaces can provide more refined and flexible services for service requestors, they also mean that the introduction of difficult-to-control interaction modes is variable, that is to say, the service interaction mode may vary with different service requestor. If we expose these easy-to-change service interfaces to external users of the system, it may make it difficult for external service requestors to support fine-grained service interfaces exposed by constantly changing service providers. Coarse-grained service interfaces ensure that service requestors use the services exposed in the system in a consistent manner. Although Service-Oriented Architecture (SOA) does not require coarse-grained service interfaces, we recommend that you use them as interfaces for external integration. Generally, architects can use BPEL to create coarse-grained service interfaces for business processes composed of fine-grained operations.

Stateless service design

The specific services in the SOA system architecture should be independent and self-contained requests. when implementing these services, the status of the previous request is not required, in other words, services should not depend on the context and status of other services, that is, services in the SOA architecture should be stateless services. When a service needs to be dependent, we 'd better define it as a specific business process (BPEL ). In terms of service implementation mechanism, we can use EJB components to implement coarse-grained services. We usually use stateless Session Bean to implement specific services, we can expose stateless session beans to Web services that can be called by external users, that is, to convert the traditional Session Facade model to the Web service endpoint of EJB. In this way, we can provide coarse-grained services to Web Service customers.

If we want to build Web Services in a J2EE environment (based on WebSphere), Web Service customers can access J2EE applications in two ways. Customers can access web services created with JAX-RPC APIs (implemented using servlets); web service customers can also access stateless session beans through the service endpoint interface of EJB, however, Web Service Customers cannot access other types of enterprise beans, such as stateful session beans, entity beans, and message-driven beans. The latter option (publish stateless EJB components as Web Services) has many advantages. Based on the existing EJB components, we can use the existing business logic and processes. In many enterprises, the existing business logic may have been written using the EJB component. disclosing it through web services may be the best choice for external access to these services. The EJB endpoint is a good choice because it puts the business logic and the endpoint on the same layer. In addition, the EJB container automatically provides support for concurrency. As the EJB service endpoint implemented by the stateless Session Bean, you do not have to worry about multi-thread access, because the EJB container must serialize requests to any particular instance of the stateless Session Bean. Because the EJB container provides support for security and transaction, bean developers do not need to write SecurityCodeAnd the transaction processing code. Performance issues have always been a problem for Web Services, because almost all EJB containers provide support for stateless Session Bean clusters and for stateless Session Bean pools and resource management, therefore, when the load increases, you can add machines to the cluster, and Web Service requests can be directed to these different servers. In addition, the stateless Session Bean pool improves resource utilization and memory management, enables the Web service to effectively respond to multiple customer requests. From this we can see that by transforming the Web service model into an EJB endpoint, the service can be more scalable and the overall system reliability is enhanced.

4. Summary

This article briefly introduces the knowledge of architecture designers and SOA architectures, and analyzes the points that SOA architects should pay special attention to when designing SOA system architectures.

The next part of this article will show you how to ensure that the system architecture can meet different service level requirements in the system when building an enterprise system based on SOA. 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.

The previous sections of this series Introduce the knowledge of architecture designers and SOA architectures, and analyze the points that SOA architects should pay special attention to when designing SOA system architectures. 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, and the operating systems are different,Programming LanguageAlso different;

(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 characteristics of these SOA architectures, we can see that the emergence of SOA architecture provides a more flexible way to build the enterprise system architecture. If the enterprise architecture designer builds the system architecture based on SOA, we can ensure the loose coupling and flexibility of the entire system at the underlying architecture level, which lays a 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 entire 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;

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

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

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

Token security is 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.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx? Postid = 1432229