Principles of service-oriented architecture (SOA)

Architecture
Distributed computing regards software resources distributed on the network as a variety of services. Service-oriented architecture is a good solution. But this architecture is not a new idea; CORBA and DCOM are similar, but these past service-oriented architectures are plagued by some challenges: first, they are tightly coupled, which means that both ends of a distributed compute connection must follow the same API constraints. For example, if the code for a COM object changes, the code that accesses the object must also make the appropriate changes. Secondly, these service-oriented architectures are subject to vendor constraints. Microsoft control DCOM Needless to say, CORBA is just a camouflage of standardization efforts, in fact, to implement a CORBA architecture, often in a manufacturer of the implementation of the specification work.

WEB Services is an effort to improve the drawbacks of DCOM and CORBA. The fact that today's service-oriented architecture for applying Web services differs from the past is that they are standards-based and loosely coupled. Widely accepted standards, such as XML and SOAP, provide interactivity between different vendor solutions. Loose coupling separates the participants in the distribution calculation, and the changes on either side of the interaction do not affect the other. The combination of the two means that companies can implement certain Web services without having any knowledge of the clients that use those Web services. We call this standards-based, loosely coupled, service-oriented architecture simply SOA.

The power and flexibility of SOA will bring great benefits to the enterprise. If an organization abstracts its IT architecture and expresses its functionality in a coarse-grained form of service, each service clearly represents its business value, and the customers of those services (either within the company or perhaps a business partner of the company) can get these services without having to take into account the specific technology behind their backend implementations. Further, if customers can discover and bind available services, the IT systems behind those services can provide greater flexibility. However, it is a daunting task to have a new way of implementing the architecture in order to be strong and flexible. Enterprise architects must become "service-oriented architects", not only to understand SOA, but also to understand SOA practices. The distinction between architectural practices and the resulting architectural results is subtle and critical. This article discusses the practice of SOA, which is what architecture-oriented architects must do to build SOA.

Principles of SOA

To satisfy this business agility, the practice of SOA must follow the following principles:

* Business-driven services, service-driven technology

Essentially, at an abstract level, services are in the midst of business and technology. Service-oriented architects must understand the dynamic relationship between business requirements and the services that can be provided, and on the other hand, understand the relationship between services and the underlying technologies that provide those services.

* Business Agility is the basic business requirements

SOA considers the next level of abstraction: the ability to provide responsive change requirements is a new "meta requirement" rather than a fixed set of requirements for some business. The entire architecture from the hardware system must meet the needs of business agility, because any bottlenecks in the SOA can affect the flexibility of the entire IT environment.

* A successful SOA is always changing

The scenario of SOA work is more like a living organism than "building a house", as the tradition says. The only constant change in the IT environment is that the work of service-oriented architects will never end. For designers accustomed to building a house, turning to a living organism requires a new way of thinking. The basics of SOA are some of the same architectural guidelines, as the following article says.

SOA Fundamentals

There are two more and more common development directions in the IT industry, one is architectural, the other is methodological, and service-oriented architects can reap the benefits. The first is MDA (model-driven architecture), proposed by the OMG model of CORBA. MDA believes that architects first have a formalized UML (also proposed by the OMG) for the created system. MDA first gives a platform-independent model to represent the functional requirements of the system and use cases, according to the platform built by the system, the architect can get the platform-dependent model from the platform-independent model, which is sufficiently detailed, so that it can be used to generate the required code directly.

The core of MDA is that the system is fully described in the design phase, so that when the system is created there is almost no possibility of error interpretation, and the model can generate code directly. But MDA has some limitations: first, MDA assumes that the business requirements are fully described before the model is created, and this is almost impossible in the current typical dynamic business environment. Second, MDA does not have a feedback mechanism. If developers have a need to change the model, there is no way to provide them.

Another foundation of SOA is the agile approach (AM), where the most well-known approach is extreme programming (XP). Am, like XP, provides the process of creating a software system in an environment where the requirements are unknown or changeable. XP requires a user representative on the development team, who helps write tests to guide the developer's day-to-day work. All members of the development team are involved in the design and are designed to be as small as possible and not formalized. AM's goal is to simply create what the user wants, rather than work on some formal models. The core idea of AM is its agility-handling the agility of requirements changes. The main weakness of AM is its size limitations, for example, XP works well for a small team and midsize projects, but when the project is scaled up, it is difficult for project members to grasp all aspects of the project without a coherent and clear plan.

On the face of it, MDA and am seem to be relatively-mda assumed that the requirements are fixed, whereas am is the opposite. The center of the MDA is the formalized model, and am precisely avoids them. However, we decided to take the risk of extracting some elements from these different methods and putting them into a consistent architectural practice.

There are three levels of abstraction in SOA, followed by the first rule of SOA: business-driven services, service-driven technologies. AM connects the business model directly to the practice and manifests itself in the platform-dependent model. MDA does not separate the business model from the platform-independent model, but rather the platform-independent model as the starting point. SOA must connect these models, or abstract hierarchies, to get a single architectural approach. We will implement this connection from the architecture implementation approach of the five views.

A five-view implementation approach to SOA


Enterprise Architects find their careers highly competitive and proud, because they have to consider IT systems in many ways. Kruchten (the RUP development Lead) extracts these aspects and, when applied to SOA, we call the five-view implementation method (Five-view approach).

The four boxes represent different methods of examining a schema, representing different stakeholders (stakeholder) respectively. The younger brother 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. Is the system Deployer view of the schema; The implementation view describes the organization of the Software code, the view from the developer's perspective, and the business analyst works with the process view, which describes the run-time 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 and connect services to underlying technologies in the use cases in the Use-case view.

To show how the object-oriented architecture works above these views, let's place them in the context of the SOA metamodel. Two areas of SOA overlap: the business domain represented by the business model and service model, and the technical areas represented by the service model and platform-dependent models (two domain Shared service models). Business users handle coarse-grained business services through logical views and process views, and arrange them in the process, as needed, according to changing business requirements. On the other hand, the work of technical experts is to create and maintain the abstraction layer between service and stratigraphic technology. The intermediate model of these services, which serves as an axis, is the center of the business.

The SOA meta model inherits the platform-independent model and platform-dependent model from MDA, but adds the two parts of AM and user interaction and agile feedback, which are represented by the bidirectional arrows between ellipses. Similarly, the meta model solves the scalability problem of AM by introducing the middle-tier abstraction provided by the central service model. In this way, any changes in the requirements in the service model will be reflected in the user's daily business processes. Similarly, because the underlying technology is model-driven, technologists can quickly and efficiently respond to these changing needs.

The difference between SOA practices and the traditional way of addressing enterprise architecture in the past is its support for agility. As mentioned earlier, the third principle of SOA is that it is always changing. This constant changing environment is the cornerstone of SOA practice. As shown in the picture, the stakeholder (stakeholders): This term is also used in RUP to represent the various roles involved in software development, such as users, designers, developers, and testers. Affects the overall architecture changes on a required basis. The boundaries between the design phase and the run phase become blurred as the technical experts respond to changing business needs in daily day-to-day work, and it is difficult to separate these two phases clearly.

The rest of the part

We have provided a high-level framework for service-oriented architectures where the MDA and am elements help the user of the tool to create and maintain SOA. However, there is a lack of content in SOA-that is what software developers and professional service organizations need to provide. Ideally, developers must provide service-oriented business processes, workflows, and service coordination tools and services, and modeling tools that adequately reflect business services in an agile, platform-independent fashion are also necessary; technologists must be equipped to generate code from the model automatically, And the tools to update the model as the code changes, finally, developers must provide software that supports SOA, helping service-oriented architects create an abstraction level between service and underlying technology in a trustworthy and scalable way. Fortunately, this product is coming on the market.

In addition, the most important thing is the top-down approach to SOA implementation throughout this article. Most of today's thinking about Web Services is bottom-up: "This is how you create Web services, and now we're going to use them for integration," and this approach to Web services technology is a great first step because it can dramatically reduce the cost of integration, This is what the tech executives are most willing to see now. But as the economy develops further and it gets out of the doldrums, companies seek it to help improve the core value of the organization's strategic significance. With a service-oriented architecture, it can provide a framework for the enterprise to achieve business agility.