Service-oriented architecture overview
Written / ITSO, Raleigh Center
This paper briefly describes the development of the service-oriented architecture. Then, the relationship between the development of the assembly and the service-oriented architecture is explored, and how the component is explained as an infrastructure that implements the service.
The commercial driver of new methods Although IT managers have been facing cutting costs and maximizing problems that maximize the prior art, they must continue to work hard to better serve customers and respond to corporate strategies faster. Focus on winning greater competitiveness. Under all these pressures, there are two basic subjects: heterogeneous and change. Most companies have a wide range of systems, applications, and architectural architectures of different periods and technologies. Integrated products from multiple vendors across different platforms are just like a nightmare. But we can't use a manufacturer's product, because it is difficult to change the application suite and support infrastructure. In today's IT manager, the change is the second topic. Globalization and e-commerce have accelerated the pace of change. Globalization has brought fierce competition, and the product cycle is shortened. Each company wants to win the advantage of competitors. Under the promotion of competitive products and the promotion of a large number of product information available on the Internet, customers require more rapid changes. Thus, competition in improving products and services is further intensified. In order to meet the increasing new requirements of customers, the improvement in technology is constantly accelerating. Companies must quickly adapt to this change, otherwise it is difficult to survive, not to succeed in this turmoil, and IT infrastructure must support enterprises to improve their adaptability. As a result, corporate organizations are being developed to new ecosystem business examples from the 1980s or earlier in the early 1980s or earlier in the 1980s and the 1990s and the level of business processes in the 1990s. The focus is to expand the supply chain, support customers and partners to access business services. Figure 1 shows this development of the company. How do we make companies' IT environments and more quickly respond to constantly changing business needs? How to make these heterogeneous systems and applications to communicate as seamlessly as possible? How do I achieve the abyss of the corporate goal without bringing companies to bankruptcy? IT responders / supporters are in parallel with this development of enterprises, as shown in Figure 2. Now, many IT managers and professionals believe that we really found a satisfactory answer - the service-oriented architecture. In order to reduce the problems caused by isomer, interoperability, and continuous changes, such an architecture should provide a platform to construct an application service with the following characteristics: l Loosen coupling L position transparent L protocol independently based on this The system structure, service users don't even have to care about the specific services of communication, because the underlying infrastructure or service "bus" will make an appropriate selection of users. Infrastructure hides the requested technical details. In particular, technical specifications from different implementations (such as J2EE or .NET) should not affect SOA users. If there is already a service implementation, we should re-consider replacing with a "better" service implementation, and new service implementations must have better service quality.
As a solution-oriented service architecture since the "Software Crisis" promotes the creation of software engineering, the IT industry has always struggled to seek solutions to the above problems. In the past few years, the progress of some core technologies has enabled us to come today. Below, we will briefly discuss these core technologies, but our focus is still concerned about how these technologies help solve IT issues.
Object-Oriented Analysis and Design In "Applying Uml and patterns - analogsis and design", Larman describes the essence of object-oriented analysis and design as "from the perspective of objects (objects, concepts or entities). Problems and Logic Solutions. In "Object-Oriented SoftwareEngineering: a Use Case Driven Approach", Jacobson or the like is defined as "" Features "have many objects with many operations and status (memory of these operations)." In an object-oriented analysis, such objects are identified and described in the problem domain, while in the object-oriented design, they are converted to logic software objects, which will eventually be implemented with object-oriented programming languages. By object-oriented analysis and design, some aspects of the object (or object group) can be packaged to simplify the analysis of complex business scenarios. In order to reduce complexity, some features of the object can be abstract, so you can only capture important or inherent aspects. Component-based design is not a new technology. It is naturally developed in an example. In the early stage of object-oriented analysis and design, fine-grained objects are advertised as providing "reuse" mechanisms, but such objects are too low, there is no suitable standard to make reuse in practice . In application development and system integration, coarse granular components become more and more reused. These coarse particle size objects provide a well-defined function through a more fine particle size object. In this way, the packaged solution kit can also be packaged into such an "component". Once the organization implements a completely independent functional component on a higher level, it is possible to divide the company's application score into a component of a set of particle size increasingly larger. Components can be considered as a mechanism for packaging, managing, and public service. They can use a group of techniques: achieving a large-scale enterprise component of enterprise-level use cases can be achieved by updating object-oriented software development with legacy systems.
Service-oriented Design In "Component-based Development for Enterprise Systems", Allen involves the concept of service, "It is the executable code unit that describes the components into physical black box packages that provide related services. Its service can only pass Consistent published interfaces (including interaction standards) are accessed. Components must be able to connect to other components (via communication interfaces) to form a larger group. " The service is usually implemented as a proven software entity of coarse particle size, which exists as a single instance and interacts with the application and other services by loosely coupled to the application and other services. Figure 3 shows important service-oriented terms: l service: logical entity, a contract defined by one or more published interfaces. l Service Provider: Realize service specification software entities. l Serving users (or requesters): Call the software entity of the service provider. Traditionally, it is called "client". Service users can be a terminal user application or another service. l Service Locator: A special type of service provider, which uses a registry, allows the search service provider interface and service location. l Service Agent: A special type of service provider, which can transmit service requests to one or more other service providers. Interface-based design requires interface design in components and service development so that software entities can implement and disclose their definitions. Therefore, in the component and the service-oriented system, the concept of "interface" is critical to the successful design. Here are some important definitions related to the interface: l Interface: Define a set of public method signs, which is not implemented in accordance with logical grouping but does not provide implementation. Interface Definition Service The contract between the requester and the provider. Any implementation of the interface must provide all methods. l Published interface: An only identifier and accessible interface, the client can discover it through the registry. l Community interface: An accessible interface that is available for clients, but it does not release, thus requires static knowledge about the client. l Dual interface: Usually a pair development interface, so that an interface relies on another interface; for example, a client must implement an interface to call the requester, because the client interface provides some callback mechanism. Figure 4 defines the UML definition of customer relational management (CRM) service, which is represented as a UML component, specific implementation interface AccountManagement, ContactManagement, and SystemsManagement. Only two interfaces in these interfaces are published interfaces, but the latter is a common interface. It should be noted that the SystemsManagement interface and the ManagementService interface form a dual interface. CRMService can achieve many of the interfaces that enable the behavior of the interface in a variety of ways, depending on whether the client is allowed to have greater flexibility in terms of behavior implementation. It is even possible to provide different or additional services to a particular type of client. In some runtime environments, such functions are also used to support different versions of the same interface on a single component or service. The hierarchical application architecture is as mentioned earlier, object-oriented techniques and languages are excellent ways to implement components. Although component is the best way to achieve services, you must understand that a good component-based application does not necessarily constitute a well-oriented application. Once the role of the service is in the application architecture, the component developers may use existing components. The key to performing this transformation is to recognize the service-oriented method means an additional application architecture layer. Figure 5 demonstrates how to apply the technical layer to the program architecture to provide a large particle size (it is closer to the application of the application).
We have created this part of the term "Application Edge" called system, which reflects the excellent method of service is an excellent method of the external view of the public system (by internal reuse and use traditional component design) . The proximity to review the service-oriented architecture provides a way of service. In this way, the distributed system can be constructed to provide application functions as a service to end user applications or other services. Its constituent elements can be divided into functional elements and service quality elements. Figure 6 shows an architecture stack and an element that may be observed in a service-oriented architecture. Note: Service-oriented architecture stack is an easy-to-controversial issue, because supporters in all aspects have proposed several different stacks. Our stack is not proposed as a service stack. The reason why we will put it because we want to build a useful framework. The architecture stack is divided into two halves, half of the left side focuses on the functional aspect of the architecture, and half of the right side focuses on the quality of service of the architecture. These elements are described in detail below: Functional aspects include: l Transmission is a mechanism for transmitting service requests from service users to the service provider, and transmit responses from the service provider to the service user. l Service Communication Protocol is a negotiated mechanism. By this mechanism, service provider and service user can communicate with the content to be requested and the content to return. l Service Description is a negotiated mode for describing what services are, how to call services and successfully call services. l Serving Description The actual service is available. l Business Process is a collection of services that can be called in a specific order and use a set of specific rules to meet business requirements. Note that the business process itself can be regarded as a service, which produces the concept of business processes that can be composed of different granular services. l Service Registration Center is a repository for services and data descriptions, and the service provider can publish their services through the Service Registry, while the service user can discover or find available services through the service registration center. The service registration center can provide additional features to services that require centralized repository. Service quality includes: l Policy is a set of conditions and rules. Under these conditions and rules, the service provider can apply the service to the user. The strategy is both functional aspects, and there is also aspects related to service quality; therefore, we have policy functions in both functional and service quality. l Security is a rule set, which can be applied to the service user of the service user authentication, authorization, and access control. l Transmission is a property set, which can be applied to a set of services to provide consistent results. For example, if you want to use a set of services to complete a business feature, all services must be completed, or there is no completion. l Management is a property set, which can be applied to manage the services provided or used.
SOA Collaboration Figure 7 shows collaboration in the service-oriented architecture. These collaboration follows the "Find, Binding and Call" example, where the service user performs dynamic service positioning, the method is the Query Service Registry to find the service that matches its standard. If the service exists, the registration center provides the user with the endpoint address of the interface contract and service. The following figure shows an entity that collaborates to support the "Find, Binding and Call" example in the service-oriented architecture. The roles in the service-oriented architecture include: l Services: Service users are an application, a software module, or another service that requires a service. It initiates queries for services in the registration center, through the transfer binding service, and perform service functions. Service users perform services based on the interface contract. l Service Provider: Service Provider is an entity that can be addressed through a network, which accepts and executes requests from the user. It releases your service and interface contract to the service registration center so that the service user can discover and access the service. l Service Registration Center: Service Registration Center is the supporter discovered by the service. It contains a repository that can be used, and allows for interested service users to find the service provider interface. Each entity for service-oriented architecture plays a certain type of service provider, user, and registration center in these three characters (or multiple). The operation in the service-oriented architecture includes: L Publish: In order to enable service access, you need to issue a service description to enable service users to discover and call it. l Discover: Service Requesters Location Services, the method is to query service registration centers to find services that meet their standards. l Binding and calling: After searching the service description, the service user continues to call the service according to the information in the service description. The components in the service-oriented architecture include: l Services: You can use the service by the published interface and allow the service user call service. l Service Description: Service Description Specifies how to interact with the service user and service provider. It specifies the format of requests and responses from the service. Service description can specify a set of prerequisites, back conditions, and / or service quality (QoS) levels. In addition to the definition of dynamic service discovery and service interface contract, the service-oriented architecture also has the following features: l Service is self-inclusive and modular. l Service supports interoperability. l The service is loosely coupled. l Service is a transparent location. l Service is a combination module consisting of components. These features are also the main features that meet the requirements of e-commerce operational environment, as defined in "E-Business On Demand and Service-Oriented Architecture". Finally, it is necessary to explain that the service-oriented architecture is not a new concept. As shown in FIG. 8, the techniques involved in the service-oriented architecture include at least CORBA, DCOM, and J2EE. Early employees in service-oriented architectures have successfully created their own service-oriented enterprise architecture based on message delivery systems such as IBM WebSphere MQ. Recently, SOA's active stations have extended to include World Wide Web (WWW) and web services. The service in the SOA range is in the service-oriented architecture, and the service mapped to the business function is determined in the process of business process analysis. The service can be fine-grained or coarse particle size, depending on the business process. Each service has a well-defined interface, and you can discover, publish and call your service through this interface. Enterprises can choose to post out their services to business partners, or choose to publish services within the organization. The service can also be combined by other services.
The service and component service is a coarse particle size processing unit, which uses and generates an object set transmitted by a value. This is different from the objects in the programming language terminology. Instead, it may be closer to the concept of business transactions (such as CICS or IMS transactions) rather than the concept of remote CORBA objects. The service is composed of some components, and these components work together to jointly provide services requested by the service. Therefore, in contrast, the components are thinner than the particle size of the service. In addition, although the service is mapped to business functions, components are typically mapped to business entities and their business rules. As an example, let's take a look at the Purchase Order component model of WS-I Supply Chain Management. As shown in Figure 9. In a component-based design, components can be created to strictly match business entities (such as customer (Customer), purchase order, order items, and package matches the behavior expected by these entities. For example, a Purchase Order component provides a function of obtaining information about the total amount of information that has been ordered; ordered (Order Item) component provides the ability to get the number and price information about the priced product. The implementation of each component is encapsulated behind the interface. Therefore, the user of the Purchase Order component does not know the mode of the Purchase Order table, calculates the tax algorithm, as well as the buckle and / or discount in the total order. In a service-oriented design, it is not possible to design service based on business entity. Instead, each service is a complete unit that manages operations in a set of business entities. For example, a customer service will respond to a request from any other system or a service that needs to access customer information. Customer service can handle requests for updating customer information; add, update, delete portfolios; and query the customer's order history. The customer service has all the data related to the customer's customer, and can be able to provide other service queries on behalf of the caller to provide a unified customer service view. This means that the service is a manager object that creates and manages a set of components. The benefits of service-oriented architecture are as mentioned earlier, companies are handling two issues: the ability to quickly change and reduce costs. In order to maintain competitiveness, companies must quickly adapt to internal factors (such as mergers and reorganization) or external factors (such as competitiveness and customer requirements). It takes an economical and flexible IT infrastructure to support enterprises. We can realize that the use of service-oriented architecture will bring us a few benefits, which helps us succeed in this turmoil today:
With an existing asset SOA, an abstraction layer is provided. Through this abstract layer, companies can continue to use it in IT investment, and the method is to pack these existing assets into services that provide corporate functions. Organizations can continue to obtain value from existing resources without having to re-start building.
It is more likely to integrate and manage complexity in a service-oriented architecture, the integration point is specification rather than implementation. This offers transparency and reduces the impact of infrastructure and implementation of these changes to minimize. By providing service specifications for existing resources and assets based on completely different systems, integration makes it easier to manage because complexity is isolated. This will become more important when more companies provide a value chain together.
Faster response and listing speed provide a unique advantage of combining new services from existing services to organize harsh commercial requirements. By using existing components and services, it is possible to reduce the time required to complete software development lifecycle (including collection requirements, design, development, and testing). This makes it possible to quickly develop new business services and allow organizations to respond quickly and reduce the listing preparation time for changes. Reducing costs and increasing business services disclosed in a loosely coupled manner can be used to use and combine services based on business requirements. This means that the resource copy is reduced, and the increase in reuse and cost reduction.
Speaking of doing SOA, companies can prepare for future preparations for future. The SOA business process consists of a range of business services, which can be easier to create, modify, and manage it to meet different periods. SOA provides flexibility and responsiveness, which is critical to the survival and development of enterprises. But the service-oriented architecture is never a panacea, while migrating to SOA is not a thing that can be completed. Don't expect a night to migrate the entire enterprise system to the service-oriented architecture. Our recommended approach is to migrate the enterprise functionality at the time of business requirements or expose the plot.
