Architecture designer and SOA (Part 1)

Service-Oriented Architecture) is a service-oriented architecture. This is the most frequently used word in a variety of 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.

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. In a SOA-based system, the functions of a specific application are constructed by a combination of components (that is, services) that are loosely coupled and have a unified interface definition method. 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 that these are the systems that allow Yi yizhao to hit the NAI Shi Yu> Shi mu to always carry the mushrooms and handle the OA architecture, for a specific service, the system designer should pay attention to what kind of service the service can provide for external users. That is to say, the system designer pays attention to 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 security code and 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.