The principle of a service architecture (SOA) Jason Bloomberg Web Service is no longer a newly marma. Many companies have created a variety of experimental Web Services projects, which have proved that this emerging distributed computing technology can reduce the cost of integration and development. In addition, some key Web Services criteria have developed, strong security (Robust Security) and management products have also been introduced. For companies that are far from a large, they are already considering the next step. For most companies, the next step is no longer a point-to-point application, but the Web Services is a more wide application between business and business partners. This technique is changed to be loosely coupled to standard-based architectures. Such an architecture requires a new view and understanding of the role of IT in your organization, not just a method of implementation. By reacting to the business, companies can get a real return, and to achieve this, the role of the service architect designer is very critical. In addition, potential returns are ambiguous - distributed computing technology guarantees a flexible response to business needs, and the agility in this business is that the company's dreams of still unreachable. Distributed computing puts software resources distributed on the network as a variety of services. A service architecture is a nice solution. But this architecture is not new; Corba and DCOM are very similar, however, these past facilities are troublesomely plagued: First, they are closely coupled, which means that the connection between the connection is calculated. All must follow the same API constraint. If you want to say that if the code of a COM object has changed, the code to access the object must also make a corresponding changes. Two, these conservatives are constrained by the manufacturer. Microsoft Control DCOM does not have to say that CORBA is just a standardized effort of camouflage. In fact, realizing a CORBA architecture, often working on a manufacturer's implementation of the norms. Web Services is an effort to improve DCOM and CORBA shortcomings. Today's service-oriented service architecture for Web Services is characterized by them in terms of standard and loose coupling. The widely accepted standards (such as XML and SOAP) provide interactivity between different vendor solutions. Loose coupling will isolate the participants in the distribution calculation, and the changes in some part of the interaction will not affect the other. The combination of both means that the company can implement some Web Services without having to know any knowledge of clients using these Web Services. We refer to this standard, loosely coupled-oriented architecture as SOA. Soa's powerful and flexibility will bring huge benefits to companies. If a organization abstracts its IT architecture, it is expressed in the form of a coarse grain size, and each service clearly represents its business value, then the customer (may be within the company, may also be the company) A business partner can get these services without having to consider specific technologies achieved in the background. Further, if the customer can discover and bind the available services, the IT system behind these services provides greater flexibility. However, to get powerful and flexibility, there is a need for a new way to realize the architecture, which is a daunting task. Enterprise architects must become "service-oriented architect designers" not only to understand SOA, but also understand SOA practice. The difference between architecture practice and final resulting architecture is very subtle, and it is also very important. This article will discuss SOA practices, namely: the schema-oriented designer must do things when building SOA. The SOA principle SOA is a corporate architecture, so it starts from the needs of the company.
However, the difference between SOA and other enterprise architectural methods is the business agility provided by SOA. Business agility refers to the ability to respond quickly and efficiently, and utilize changes to get competitive advantage. For architect designers, creating a business agile architecture means creating such an IT architecture that meets the current unknown business needs. To meet this business agility, SOA practice must follow the following principles: * Business driver service, service driver technology is essentially in the abstract level, service is in the middle of business and technology. Service-oriented architect designers must understand the dynamic relationship between business needs and services that can be provided, and on the other hand, it is also necessary to understand the relationship between the service and the underlying technique of these services. * Business agility is the basic business needs SOA considers the next abstract level: the ability to respond to change needs is a new "meta demand", rather than dealing with fixed-constant needs on some business. The entire architecture from the hardware system must meet business agility requirements, because any bottleneck in SOA will affect the flexibility of the entire IT environment. * A successful SOA is always changing the scene of SOA work, it is more like a living organism, not like the traditional "cover a house." The only unchanged IT environment is changing, so the work for service architect designers will never end. For designers who are accustomed to covering the house, it is necessary to turn to design a living organism requires a new way of thinking. As described below, the foundation of SOA is still some similar architectural guidelines. The SOA foundation has two increasingly common development directions in the IT industry, one is architectural aspects, one is a methodological, service-oriented architect designer can gain something. The first is MDA (model drive architecture), which is proposed by the OMG model proposed by CORBA. The MDA believes that the architect is first to treat the created system with a formal UML (also proposed by OMG). The MDA first gives a platform-independent model to represent the functional requirements of the system and the USE CASES, the architect-constructed model can be related to the platform-independent model, and the related models of these platforms are sufficiently detailed. Can be used to directly generate the required code. The core of MDA is that the design phase system has been fully described so that when the system is created, there is almost no error interpretation, the model can directly generate code. However, MDA has some limitations: First, MDA assumes that business needs have been described before creating models, and this is almost impossible in current typical dynamic business environments. Second, there is no feedback mechanism for MDA. If the developer has a change in the model, there is no way to give them such a way. Another foundation of SOA is Agility Method (AM), which is very famous for extreme programming (XP). The AM like XP provides the process of creating a software system in an unknown or variable environment. XP requires that there is a user representative in the development team, helping to write tests to guide the daily work of developers. All members of the development team are involved in the design and design should be small and non-formal. AM's goal is to create only the user's desired, not on some form models. The core idea of AM is its agility - the agility of demand changes. The main weakness of AM is a limit on its scale. For example, XP is good in a small team and medium-sized projects, but when the project size increases, if there is no uniform clear plan, the project member is difficult to grasp the project. Aspect. From the surface, MDA and AM seem to be opposite-MDA assumptions are fixed, while AM is just the opposite. The center of MDA is a formal model, and AM is just avoiding them.
However, we still decide to take a risk to extract some of these elements in these different methods, and put them into a consistent architecture practice. There are three abstractions in SOA, according to SOA's first guidelines: business driver, service driver technology. AM connects the business model directly and practices to behave in the platform-related model. The MDA did not separate the business model and platform, but the platform-independent model as the starting point. SOA must connect these models, or abstract hierarchy, get a single architecture method. We will implement this connection from the architecture of five views. SOA's five-view realization method of enterprise architect finds that their careers are very competitive and worthy of pride because they have to consider IT systems from many ways. Kruchten (RUP development person) extracts these aspects, when applied to SOA, we call the five view implementation method (Five-View Approach). The four boxes indicate that different examinations of an architecture, representing a different involvement, respectively. Five views of the younger brother, the Use-Case view covers other views, playing in the architecture a special role. The deployment view maps the software to the underlying platform and related hardware. It is a view of the system deployment person to the architecture; the implementation view describes the organization of the software code, is a view from the developer's perspective; business analysts use the process view to work, It describes the runtime characteristics of the software system. Finally, the logical view represents the user's functional requirements. In SOA, the service-oriented architecture must be able to connect the user to the service in the Use case in the USE-CASE view, connect the service to the underlying technology. In order to indicate how object-oriented architecture works above these views, let us put them in the context of the SOA meta model. There are two fields in the SOA: the business model represented by the business model and the service model and the technical field represented by the service model and the platform-related model (two field sharing service models). Business users handle coarse granular business services through logical views and process views, according to changes in business needs, as needed to arrange them in processes. On the other hand, the technical expert's work is to create and maintain abstract layers between services and formation technologies. Indicates the intermediate model of these services, which acts as the axis, and the service is carried out by it. The SOA meta model is independent of the platform and platform-related models from the MDA, but adds AM and user interactions and agile feedback, the latter being manifested by the two-way arrow between the ellipse. Similarly, the metamorphosis solves the problem of AM in scalability by introducing an intermediate layer provided by the center's service model. In this way, changes in the service model are reflected in the daily business processing. Similarly, since the underlying technology is a model drive, technical experts can make strain according to the demand of these changes. SOA practices and past resolve the difference in the traditional way of enterprise architecture are their support for agility. As mentioned earlier, the third principle of SOA is that it is always changed. This constant change environment is the cornerstone of SOA practice. As shown in the figure, there is a public (Stakeholders, the translator's note: RUP also has this word, indicating various roles involved in software development, such as users, designers, developers, and even testers, etc.) in a required On the basis of changes in the entire architecture. In this case, when a technical expert is constantly responding to a change in business demand in daily business needs, the boundaries between design phases and operational phases become blurred, it is difficult to clearly separate these two phases. The remaining part We have provided a high-level framework for the service-oriented architecture, where MDA and AM's element help tools to create and maintain SOA. However, some of the SOA is still lacking - that is, software developers and professional service organizations must be provided.
