Architecture Architects and SOA

http://www.ibm.com/developerworks/cn/webservices/ws-arcsoa1/

SOA (service-oriented Architecture), a service-oriented architecture, is the most common word in a variety of technical journals in the last year or two. There are now many architects and design developers who simply equate SOA and Web services technology with the belief that SOA is an implementation of Web service. Essentially, SOA embodies a new system architecture, and the advent of SOA will have a huge impact on the entire enterprise-level software architecture design. Two parts of this series will be based on the author's own understanding of what the SOA architecture is, how SOA will have a positive impact on enterprise system architecture design, what is the role of SOA architects, and what special attention should be paid to SOA architects when designing SOA system architectures.

1 reviews:

Wang Qiang (wangq@cn.ibm.com), Senior software engineer, IBM China Software Development Laboratory

November 24, 2005 content

Develop and deploy your next application on the IBM Bluemix cloud platform.

Start your trial 1. What is a schema. What is SOA-based architecture. 1. 1 What is a schema

From the architect's point of view, architecture is a set of guidelines for building systems. With this set of guidelines, we can divide a complex system into a set of simpler subsystems that should be kept separate from each other and consistent with the entire system. And each subsystem can continue to be subdivided to form a complex enterprise-level architecture.

When an architect is building an enterprise-level software system, in addition to considering the architecture of the system and the functional behavior it should have, it is also concerned with the availability of the entire architecture, performance issues, fault tolerance, reusability, security, scalability, manageability, reliability, and other related aspects. Sometimes a good architect even needs to consider whether the architecture of the system is aesthetically demanding. From this we can see that we measure a good architecture design can not only from the functional point of view, but also to consider a lot of other factors, the lack of any one aspect of the possibility of the construction of the whole system can be buried hidden trouble. 1. 2 What is SOA-based architecture

SOA is itself a system architecture for enterprise-class services, and in short, SOA is a new architecture for system development, in a system based on SOA architecture, The functionality of a specific application is built up by a combination of loosely coupled components (that is, service) that have a unified interface definition. Therefore, SOA-based architectures must also be built from the specific needs of the enterprise. However, the difference between SOA and other enterprise architectures lies in the business agility offered by SOA. Business agility is the ability of an enterprise to respond quickly and effectively to business changes and leverage business changes to gain a competitive advantage. For an enterprise architect, creating a flexible business architecture means creating an IT architecture that meets the business needs that are currently unknown.

Using an SOA-based approach to building a system, as shown in Figure 1, all the program functions in an SOA-based system are encapsulated in a number of functional modules, and we use these already packaged functional modules to assemble and build 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 provides a guiding model for the Organization and implementation of business processes in an enterprise, and also provides guidance for the development of specific underlying service.

Back to top 2. SOA Architect's role 2. 1 What SOA architects should have.

When it comes to the role of SOA architects, we first need to understand the capabilities architects should have. Generally speaking, a good architect should not only be a mature, practical and fast learner, but also have good management skills and communication skills. Only with the necessary competencies can architects make difficult decisions at critical moments, and that is the responsibility that an architect should take. From a role perspective, SOA Architects will not only be responsible for the design of end-to-end service requesters and providers, but will also be responsible for investigating and describing non-functional service requests in the system.

For any experienced architecture designer, Whether he is using a traditional architecture design approach (based on the Java EE architecture or the. NET architecture) or using an SOA-based architecture design approach to build an enterprise-class system architecture, knowledge of the relevant business domain is essential for architects, who can often accumulate through actual work experience and receive relevant Training to gain knowledge in these areas of business. In addition to having knowledge of the relevant business areas, a qualified architect must have a broader technical background, which may include knowledge of hardware, software, communications, security, and more. But this does not mean that to be an architect you have to familiarize yourself with the details of each particular technology, and architects must have at least a holistic understanding of each technology, the characteristics and advantages and disadvantages of each technology, Only in this way can architects choose the right technology to design the overall architecture of the enterprise in a specific application scenario. 2. 2 What is the role of SOA architects?

What is the specific role of an enterprise-class SOA architect? What is the difference between a SOA architect and a design and a developer? It is believed that these are the most confusing problems that can be caused to everyone. As a practical example, when building a system based on an SOA architecture, for a specific service, the system designer should focus primarily on what services the service can offer to external users. This means that the system Designer is concerned with the functionality provided by the service. For SOA architects, they may be more concerned about what happens when 1000 users call the service at the same time. This means that architectural designers should focus on some business requirements and service level (Service-level) requirements. The roles of all architects include the need to minimize possible technical risks at the outset of building a system. Technical risk generally refers to all unknown, unproven or untested risks. These risks are often related to service level (Service-level) requirements, and occasionally to the specific business needs of the enterprise. Regardless of the type of risk, it is easier to explore these risks in the early stages of designing the overall system architecture, and if you wait until the architecture is implemented, it is likely to cause a large number of developers to wait until these risks are properly addressed. If further refinement, we can see that the main tasks of the SOA architect include the construction of the whole system solution outline, the requirement analysis, the overall decision on the architecture, the related component modeling, the related operation modeling, the logical and physical layout design of the system components.

As an SOA architect, it is important to be able to lead the entire development team in order to ensure that the design and development staff develop the entire system in accordance with the built-in system architecture, which is 10 points. This requires an architect not only to have good technical insight, but also to have a certain degree of project management and project implementation capabilities. In the system development process, the architect must have the good communication and the expression ability, this manifests in the Architecture designer constructs the system model to have the very good readability and the understanding. If the system model constructed by the architect is not very clear, it may affect the design and developer's understanding of the entire system architecture. In order to avoid this, it is important for the development team, which is regularly hosted by the architect, to discuss it internally.

Back to top 3. Issues to be aware of when building an SOA architecture 3. 1 integration requirements in legacy system architectures

When architects build an enterprise-level system architecture based on SOA, care must be taken to carefully analyze and collate the integration requirements in the original system architecture. As we all know, service-oriented architecture is the focus of current and future application system development, service-oriented architecture is essentially a special-nature architecture, built and interconnected by components with interoperability and location transparency. SOA-Based enterprise system architectures are often developed on the basis of investment in existing system architectures, and we do not need to completely re-develop all subsystems; SOA can take advantage of resources already available in the current system (developers, software languages, hardware platforms, databases and applications) to re-use existing systems and resources in the system. SOA is an adaptable and flexible architecture type, and a system architecture based on SOA can shorten time to market in the development and maintenance of the system, thus reducing the cost and risk of enterprise system development. Therefore, when an SOA architect encounters a very complex enterprise system, the first thing to consider is how to reuse an existing investment rather than replacing a legacy system, because the cost of an overall system replacement is very high if a limited budget is taken into account.

When an SOA architect analyzes the integration requirements in an existing system, it should not be limited to the integration of existing applications built on the component, and the real integration is much broader. When analyzing and evaluating the integration requirements of an existing system architecture, we must consider some of the more specific types of integration, including the requirements for application integration, the need for end-user interface integration, the need for process integration, and the need for integrated System information. When an SOA architect analyzes and evaluates all possible integration requirements in an existing system, we can see that virtually all integration approaches have a degree of representation in any kind of enterprise. These integration approaches may be simplified or not explicitly defined for different enterprise types. As a result, SOA architects must fully consider all possible integration requirements when embarking on the design of a new architecture framework. For example, there may be very few data source types in some types of enterprise system environments, so the need for message integration in a system can be simple, but in some specific systems, such as EDI (Electronic Data Interchange Electronic Exchange) systems in shipping systems, There will be a lot of demand for electronic data interchange processing, so there will be many different types of data sources, in which case the whole system for the integration of message data requirements will be more complex. Therefore, if the SOA architect wants to build a system architecture that will continue to succeed as the enterprise grows and changes, the integration functionality in the entire system architecture should be provided by the service rather than by a particular application. 3. 2 service granularity control and non-state service design

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

Control of service granularity

The control of service granularity in SOA system is a very important design task. Typically, a coarse-grained interface is recommended for services that expose the entire system, whereas a relatively fine-grained service interface is typically used internally within an enterprise system architecture. Technically, a coarse-grained service interface might be a complete execution of a particular service, while a fine-grained service interface might be a concrete internal operation to implement this coarse-grained service interface. For example, for an online store based on the SOA architecture, coarse-grained services may be exposed to the use of external users for the submission of purchase forms, and the system's internal fine-grained service may be the implementation of this submission purchase form service of a series of internal services, such as the creation of purchase records, set up customer address , update the database and a series of operations. While fine-grained interfaces provide more granular and more flexibility for service requesters, it also means introducing more difficult-to-control interaction pattern variability, meaning that the service's interaction patterns may vary with different service requesters. If we expose these easily changing service interfaces to external users of the system, it can make it difficult for external service requesters to support the fine-grained service interfaces exposed by changing service providers. The coarse-grained service interface ensures that service requesters will use the services exposed in the system in a consistent manner. While service-oriented architectures (SOA) do not enforce the need to use coarse-grained service interfaces, they are recommended as externally integrated interfaces. Typically, architects can use BPEL to create coarse-grained service interfaces for business processes that consist of fine-grained operations.

Design of Stateless service

The specific services in the SOA system architecture should be separate, self-contained requests that do not require the state of the previous request when implementing these services, that is, the service should not depend on the context and state of other services, that is, the service in the SOA architecture should be a stateless service. When a service needs to be relied upon, it is best to define it as a specific business process (BPEL). On the implementation mechanism of the service, we can implement coarse-grained services by using EJB components. We usually use stateless session beans to implement specific services, if based on Web service technology, we can expose the stateless session bean to a Web service that external users can call, that is, the traditional session The facade model translates to the EJB Web service endpoint, so that we can provide coarse-grained services to Web service customers.

If we were to build Web services in a Java EE environment (based on WebSphere), Web service customers could access the Java EE application in two ways. Customers can access Web services created with the Jax-RPC API (implemented using Servlets), and Web service clients can access stateless session beans through the EJB's service endpoint interface, but Web service clients cannot access other types of enterprise beans, such as stateful s ession beans, Entity beans, and message-driven beans. The latter option (exposing stateless EJB components as WEB services) has many advantages, and based on existing EJB components, we can take advantage of the current business logic and processes. In many enterprises, existing business logic may already be written using EJB components, and exposing it through WEB services may be the best choice to achieve access to these services from outside. An EJB endpoint is a good choice because it makes the business logic and endpoints on the same layer. In addition, the EJB container automatically provides support for concurrency, and the EJB service endpoint implemented as a stateless session bean does not have to worry about multithreaded access, because the EJB container must serialize requests for any particular instance of the stateless session bean. Because the EJB container provides support for security and transaction, the bean developer can have no need to write security code and transaction code. Performance issues have always been a problem for WEB services, as almost all EJB containers provide support for stateless session bean clusters, as well as support for stateless sessions bean pooling and resource management, so when the load increases, you can add machines to the cluster, the WEB Service requests can be directed to these different servers, while the stateless session Bean pool improves resource utilization and memory management, enabling WEB services to effectively respond to multiple customer requests. As a result, we can see that by modeling the WEB service as an EJB endpoint, the service is more scalable and the overall system reliability is enhanced.

Back to top 4. Concluding remarks

This article provides a brief introduction to architecture architects and the SOA architecture, and analyzes what SOA architects should pay particular attention to when designing SOA system architectures.

The second part of this article will show you how to ensure that the architecture of the system is built to meet the different service-level requirements in the system when building an enterprise system based on SOA architecture. From an architect's perspective, SOA is a new design pattern, methodology. Therefore, SOA itself covers a lot of content, but also touches on the overall system architecture design, implementation, maintenance and other aspects. This article is only related to the architectural aspects of the content, I hope that the vast number of SOA system development designers can play a role in helping. References patterns:service-oriented Architecture and Web Services Red Book, sg24-6303-00,2004 April, author Mark Endrei, etc. DeveloperWorks's SOA and Web services zone has a number of feature articles and introductory, intermediate, and advanced tutorials on developing WEB services applications. For more information about on-demand business, see Developer Resources for a on demand the World Web Site Web Service project role describes the different job roles involved in Web services development projects, including their goals, tasks to And how they collaborate with each other. Service-oriented analysis and design principles This paper studies the appropriate principles in Ooad, EA and BPM. An analysis of the Enterprise Service Bus solution, part 1th introduces the basics of service-oriented architecture (service-oriented Architecture,soa) and Enterprise Service Bus (BUS,ESB), the technical evolution of the ESB , and the relationship between the ESB and the SOA.