Principles of Service-Oriented Architecture (SOA)

Web service is no longer a newly married girl. Many enterprises have already created various experimental web services projects. It turns out that this emerging distributed computing technology can indeed reduce the cost of integration and development. In addition, some key web services standards have been developed, and strong security (robust security) and management products have also been released. For ambitious enterprises, they are already considering the next step. For most companies, the next step is not to consider point-to-point applications, but the broader application of Web services between enterprises and business partners. This technological change requires a more loosely coupled, standard-based service-oriented architecture. Such an architecture requires a new perspective and understanding of the IT role in the Organization, not just an implementation method. Through agile response to the business, enterprises can get real returns. To achieve this, the role of service-oriented architecture designers is critical. In addition, the potential returns are beyond the limit-distributed computing technology can ensure a flexible response to business needs, and this business agility is what companies dream of and is still out of reach. Distributed Computing regards distributed software resources on the network as various services. Service-Oriented Architecture is a good solution. However, this architecture is not a new idea. The architecture is similar to that of DCOM. However, these past service-oriented architectures have been plagued by some difficulties: first, they are tightly coupled, this means that both ends of the distributed computing connection must follow the same API constraints. For example, if a COM Object'sCodeWith changes, the code for accessing this object must also be changed accordingly. Second, these service-oriented architectures are constrained by vendors. Microsoft controls DCOM. It is not necessary to say that CORBA is just a disguised standardization effort. In fact, to implement a CORBA architecture, it is often done by a vendor to implement the specifications. Web services is an effort to improve the disadvantages of DCOM and CORBA. The difference between the service-oriented architecture of web services today and the past is that they are standards-based and loosely coupled. Widely accepted standards (such as XML and SOAP) provide interoperability between solutions of different vendors. Loose coupling isolates participants in distributed computing, and changes made by one party on both sides of the interaction will not affect the other. The combination of the two means that the company can implement some web services without having to have any knowledge of the clients using these Web Services. We refer to this standard, loosely coupled service-oriented architecture as SOA. The strength and flexibility of SOA will bring great benefits to enterprises. If an organization abstracts its IT architecture and expresses its functions in the form of coarse-grained services, each of which clearly represents its business value, customers of these services (either inside the company or a business partner of the company) can obtain these services without considering the specific technologies implemented in the background. Furthermore, if customers can discover and BIND available services, the IT systems behind these services can provide greater flexibility. However, to achieve a strong and flexible architecture, a new method is required, which is a daunting task. Enterprise Architecture designers must be "Service-Oriented Architecture designers", not only understanding SOA, but also understanding SOA practices. The differences between architecture practices and the final architectural results are extremely subtle and critical. This article will discuss the practice of SOA, that is, what architecture-oriented designers must do when building SOA. Principles of SOA SOA is an enterprise architecture, so it starts from the needs of the enterprise. However, the difference between SOA and other enterprise architecture methods lies in the business agility provided by SOA. Business agility refers to the ability of enterprises to quickly and effectively respond to changes and use changes to gain a competitive advantage. For architects, creating an agile Business Architecture means creating an IT architecture that can meet unknown business needs. To meet this business agility, SOA practices must follow the following principles: * Service-driven services and service-driven technologies In essence, services are in the middle of Business and Technology at the abstract level. Service-Oriented Architecture designers must understand the dynamic relationship between business needs and services that can be provided, and understand the relationship between services and underlying technologies that provide these services. * Business agility is a basic business requirement. SOA considers the next abstraction layer: the ability to respond to changing needs is a new "meta requirement", rather than a fixed business requirement. From the hardware system, the entire architecture must meet the agile business needs, because any bottleneck in SOA will affect the flexibility of the entire IT environment. * A successful SOA is always changing. The scenario in which SOA works is more like a living organism, rather than "Building a house ". The only thing that remains unchanged in the IT environment is changes. Therefore, the work for service architecture designers will never end. For a designer who is used to building a house, it is necessary to turn to a new way of thinking to design a living organism. As written in the following article, the basis of SOA is similar architecture principles. SOA Basics There are two more and more common development directions in the IT industry. One is architecture and the other is methodology. Service-Oriented Architecture designers can gain some benefits from this. The first is the MDA (model-driven architecture), which is proposed by the OMG model of the proposed CORBA. MDA believes that the architect should first treat the created system with a formal UML (also proposed by OMG) model. MDA first provides a platform-independent model to indicate the functional requirements of the system and use cases. Based on the platform set up by the system, the architecture designer can obtain the platform-related model from the platform-independent model, these platform-related models are detailed enough to generate the required Code directly. The core of MDA is that the system has been fully described in the design phase. In this way, when creating a system, there is almost no possibility of incorrect interpretation, and the model can generate code directly. However, MDA has some limitations: First, it assumes that the business requirements have been fully described before the model is created, which is almost impossible in the current typical dynamic business environment. Second, there is no feedback mechanism for MDA. If developers need to modify the model, they are not provided with such a way. Another foundation of SOA is agile method (AM). The most famous method is eXtreme Programming (XP ). An am like XP provides the process of creating a software system in an environment with unknown or variable requirements. XP requires a user representative in the development team who helps write tests to guide developers in their daily work. All members of the development team participate in the design, and the design should be as small as possible and non-formal. The goal of AM is to only create what users want, rather than consuming some formal models. The core idea of AM is its agility-the agility to handle demand changes. The main weakness of AM is its scale limitation. For example, XP works well in a small team and medium-sized project, but when the project scale increases, without a clear and consistent plan, it is difficult for project members to grasp all aspects of the project. On the surface, MDA and am seem to be opposite-MDA assumes that the demand is fixed, while am is the opposite. The center of MDA is a formal model, and am needs to avoid them. However, we decided to take the risk of extracting some elements from these different methods into a consistent architecture practice. There are three abstract layers in SOA, according to the first SOA principle: business-driven services and service-driven technologies. Am connects the business model directly with the practice, as shown in the platform-related model. Instead of separating the business model from the platform-independent model, MDA uses the platform-independent model as the starting point. SOA must connect these models or abstract layers to obtain a single architecture method. We will implement this connection from the architecture implementation methods of the five views. Five-view Implementation Method of SOA Enterprise architects find their careers highly competitive and proud because they have to consider it systems in many ways. Kruchten (the development leader of RUP) extracts these aspects. when applied to SOA, we call it the five-view implementation method (five-view approach ). The four boxes indicate different ways of looking at an architecture, representing different stakeholders ). Five Views. The use-case view covers other views and plays a special role in the architecture. The deployment view maps the software to the underlying platform and related hardware, which is the view of the architecture by the system deployment personnel. The implementation view describes the software code organization and is a view from the developer's perspective; business analysts use the process view to describe the runtime characteristics of the software system. Finally, the logical view represents the user's functional requirements. In SOA, a service-oriented architecture must be able to connect users to services using use cases in the use-case view and connect services to underlying technologies. To demonstrate how the object-oriented Architecture Works on these views, let us place them in the context of the SOA meta-model. There are two overlapping fields in SOA: business fields represented by business models and service models, and technical fields represented by service models and platform-related models (shared service models for two fields ). Business users process coarse-grained business services through the logical view and process view. They are arranged in the process as needed according to the changed business needs. On the other hand, technical experts work to create and maintain the abstraction layer between services and formation technologies. Indicates the intermediate model of these services, which plays the role of the axis, and the business is centered on it. The SOA meta-model inherits the platform-independent model and platform-related model from the MDA, but the AM and user interaction and agile feedback are added, the latter is represented by a bidirectional Arrow between the ovans. Similarly, the meta-model solves the scalability problem of AM by introducing the intermediate layer abstraction provided by the central service model. In this way, any demand changes in the service model will be reflected in the daily business processing of users. Likewise, because underlying technologies are model-driven, technical experts can quickly and effectively respond to these changes. The difference between SOA practices and traditional solutions for enterprise architecture lies in its support for agility. As mentioned above, the third principle of SOA is that it is always changing. This constant changing environment is the cornerstone of SOA practices ., Stakeholders: the word "Stakeholders" is also used in RUP to indicate various roles involved in software development, such as users, designers, developers, and even testers .) The change of the entire architecture is affected on an essential basis. When technical experts constantly respond to changing business needs in daily work, the boundaries between the design and operation phases become blurred, it is difficult to clearly separate these two stages. Remaining parts We have provided a high-level framework for the service-oriented architecture, in which the users of the MDA and am element help tools create and maintain SOA. However, there is still something missing in SOA-software developers and professional service organizations must provide. Ideally, developers must provide service-oriented business processes, workflows, and service coordination tools and services. In addition, modeling tools that fully reflect business services in an agile and platform-independent manner are also required. Technical Experts must be equipped with tools that can automatically generate code from models, and update the model tool when the code changes. Finally, the developer must provide software that supports SOA, it helps service-oriented architects create abstraction layers between services and underlying technologies in a trusted and scalable manner. Fortunately, this product will be available soon. In addition, the most important thing is the top-down SOA Implementation Method in this article. Most of today's Thoughts on Web services are based on their own: "This is how to create Web Services. Now, let's use them for integration ", this approach to Web Services technology is a great first step, because it can surprisingly reduce the cost of integration, which is now the most desirable for technical managers. However, when the economy develops further and it goes out of the troughs, enterprises will seek it help to increase the core value in the strategic sense of the Organization. With a service-oriented architecture, it can provide enterprises with such a framework for business agility.