Service-oriented architecture to extend the prospect of Web service
Writing / Mark COLAN
In 221 BC, Qin Shihuang will unify a new country in several countries in the year, and we are now calling China. China as a country has a possible reason is that the Qin Chao introduced the standard, standard consolidating the culture, promoting trade: The standard spacing makes the carriage can effectively exercise in any road, common written language makes everyone can Exchange information (even if they are not the same language), and rugged work (such as China's Great Wall) makes people defense against foreign enemies. You can even say that they have developed some models for standardized transmission, message exchange and firewall. Similarly, modern business integration also benefit from standard, which enables heterogeneous computer systems to effectively interoperate. These technologies are called web services together. The appearance of the web service is the introduction of SOAP 1.1 as a logo, and SOAP 1.1 defines the details of the XML content for distributed systems while hiding the details of the implementation. Today, four years later, many companies are using web services, and they can have no doubt that the industry is at the beginning of the mainstream era of Web service. IBM will deepen service-Oriented Architecture, SOA as the key to the interoperability and flexibility of on Demand business prospects. Service-oriented architecture (SOA) supports end-to-end integration between enterprises and business partners. This provides a flexible business process model that allows customers to quickly respond to new customer needs, new business opportunities, and threats of competition.
What is a service-oriented architecture (SOA)? Service-oriented Architecture (SOA) means how you can use a large picture of Web services. The Web service specification defines the details required to implement services and their interaction with them. However, the service-oriented architecture (SOA) is a method for constructing a distributed system, and a distributed application constructed using SOA method can deliver functions as a service to end users, or other services can be constructed. Service-oriented architecture (SOA) can be based on web services, but it may be replaced with other technologies. When using a service-oriented architecture (SOA) design Distributed application, you can extend web services from simple client-server models into any complex system. Thus, a single software asset becomes a basic component for developing other applications. You can reduce the complexity of the system with new code and legacy code (CBDi's Lawrence Wilkes joking, the service-oriented architecture (SOA) can represent "save our assets (Save Our assets) "). There is a standard method to indicate these software assets and interact with them; the focus of people's concern has been transferred to application assembly based on these components. Although discussed here is a service-oriented architecture (SOA) for business applications, the service-oriented architecture (SOA) can also be used in other distributed systems, such as grid computing and advanced web service specifications. (For example, web service distributed management (WS-DistributedManagement), Web Service Trust (WS-Trust), and UDDI).
What is a service? In a service-oriented architecture (SOA), the service is an application function that encapsulates the reusable components used for business processes. It provides information or simplifies business data from a valid, consistent state to another state. The process used to implement a specific service is not important, as long as it responds to your command and provides high quality service for your request. The service can be called to emphasize interoperability and location transparency by defining a communication protocol. A service is a software component because it looks like a self-contained function from the perspective of the service requestor. However, in fact, the implementation of the service may include many of the steps performed on a computer that is within a computer or a computer owned by many business partners. For packaging software, the service may be a component or may not be a component. As with type objects, the requester application can see the service as a whole. The Web service is based on the call to use the SOAP message (it is described) using a WSDL like HTTP. Best practices using Web services are communicating with external business partners. The bulk coupling service requestor to the service provider's binding and service should be loosely coupled. This means that service requesters do not know the technical details of the provider, such as programming language, deployment platform, and so on. Service requesters tend to operate through the message call - request message and response - instead of using the API and file format. This loose coupling makes the software at one end of the session can change without affecting the other end, provided that the message mode remains unchanged. In an extreme case, the service provider can replace the implementation of the previous legacy code (e.g., COBOL), in the Java language-based new code, while do not have any impact on the service requester. This is achievable, as long as the new code supports the same message mode.
A clearly defined interface service interaction must be clearly defined. Web Services Description Language (WSDL) is a widely supported approach to describe the details of the bind to the service provider required by the service requestor. The focus of service description is that the operations used in the following partial interaction: l Service L Call operation Message L Constructs Detail of this message L Q about where to send the information of the information for constructing this message, does not include Any technical details for service implementation. Service requesters don't know if they are not concerned by Java code, C #, COBOL, or by some other programming language. It can describe SOAP calls using HTTP. Due to its extended mechanism, it can also define other types of interactions, such as XML content submitted by JMS, direct way to call, calls (CICS), and so on. WSDL's General Definition allows the development tool to create a variety of types of interactions through interfaces, while hiding it is the details of how it is called by the application code. For example, if the service is disclosed in a variety of interactions, the Web Services Invocation Framework (WSIF) uses this capability by allowing runtime to determine the optimal approach to calling high quality services.
The stateless service design service should be independent, self-contained, and it does not require information or status from one request to another when implementation. The service should not depend on the context and status of other services. When you need to rely, they are best defined into a generic business process, function, and data model rather than implementing components (such as session keys). Of course, the requester application requires a persistent state between service calls, but this should not be separated from the service provider. Here is an example of an error method that defines a session:
Requester: "What is Bruce's Checking Account Balance ?? provider:" $ x? Requester: "And what is his credit limit ?? provider:" $ y? The provider is asked to remember the account between the request between the request, this is Complexity is introduced in service implementation. The stateless service design will redefine the session as follows: Requester: "What is Bruce's Checking Account Balance ?? provider:" $ x? Requester: "What is Bruce's Credit Limit?" Provider: "$ y?
The particle size of the service granular operation is an important design point. For external consumption, the coarse particle size interface is recommended, while fine-grained interfaces can be used interior. The coarse granular interface may be a complete handling of a particular service, such as SubmitPurchaseOrder, where the message includes all business information required to define the ordering order. The fine-grained interface may have different operations for the following methods: CreateNewPurchaseOrder, setshipping-address, additem, and more. Although fine-grained interface provides more flexibility for the requester app, it also means that the interaction mode may vary with different service requestors. This may make it more difficult to support the service provider. The coarse granular interface ensures that the service requester will use the service in a consistent manner. Service-oriented architecture (SOA) does not require a coarse particle size interface, but it is recommended to use the best practices for external integration. Service Orchestration can be used to create a coarse granular interface that runs a business process consisting of fine-grained operations.
Questions Need to consider the service-oriented architecture (SOA) design will span the computer system and may also cross the corporate boundary. You have to consider the security features and needs when using Internet and how to link partners. The Internet protocol is not designed for reliability (with guaranteed submission and submission order), but you have to make sure the message is submitted and processed once. When this is impossible, the requester must know that the request is not processed. For example, you may need to consider metrics, reliability, and response times you deploy to ensure they within the promise. When you design a system from other business partners, you have to consider service-oriented management to manage partners in collaboration.
Service work roles are the same as web services, there are two key roles in object-oriented architectural (SOA): service requester and service provider. One or more provider applications provide services by sending request messages and process response messages, requiring these services. Some service providers are also a service requester: they gather the functions of other service providers to construct a higher level of services. This combination is accomplished by using a special proof language such as Java, C # or as a business process executing language (BPEL). Some SOA technology like UDDI and WS-TRUST propose a third role called Service Broker. Service agent is an intermediary-service localization between service providers and service requestors, agency hosting scheme, and so on. Entities modeling using these three roles use service calls (Service Invocation, such as SOAP messages).
Service call W3C SOAP 1.2 Specification defines messages using XML format between service requestors and service providers to communicate. Put the application request (package in XML) into the SOAP envelope (also XML), and send an application request from the requester to the provider, and the response sent back by the provider also uses the same form. Most of the products on the market support early SOAP1.1 norms, but will support SOAP 1.2 in future product releases. Since there are already many content about SOAP, please refer to the relevant publication. Soap is the best way to support service calls in the loose interoperability between partners with a separate IT infrastructure, so SOAP is the best way to support service calls. However, SOA does not need to use SOAP. For example, before SOAP, some companies use IBM WebSphere MQ to send an XML document to other computers, and other computers perform application operations based on these documents. The Ebey XML using the HTTPS interface is transmitted to the item entry for auction in a similar manner. Although web services cannot be called because there is no SOAP, the service can still be called in SOA. Of course, WebSphere MQ currently provides direct support for SOAP messages. As long as all entities are written in Java language, you can create SOA only using available features in J2EE. However, this method does not provide a satisfactory solution for non-Java applications. Where the IT system control code is required inside the company, you can consider the service calling method other than SOAP, which may not be built and parse XML content. This will have better performance and avoid writing SOAP package code around existing features. For the simplicity of the simplicity, a single call API style that can be used to call the service using other protocols is a good practice. Multi-Agreement Services call JAX-RPC specification (also called JSR-101) Defining a Java API, making it easy to call Web services from the Java program. The JAX-RPC implementation must at least support SOAP 1.1 for HTTP. However, in order to call it, it may also support other protocols. Multiple protocol service calls can specify different protocols using the same API, such as changing the URL. The JAX-RPC implementation in the current version of WebSphere Application Server is JSR-101-Compliant, but allows simple to use the SOAP calls on the JMS by modifying the URL to the JMS server (such as WebSphere MQ) addressing. In the near future, this multi-protocol style will allow service calls on the IIOP to enable EJB services to implement valid interoperability. The key to simplicity is to use the same API without consideration of the agreement. Let this make it possible to describe the capacity of the protocol in WSDL, which is different from SOAP on HTTP.
The Service Description Web Service Description Language (WSDL) specification defines an XML vocabulary that defines a contract between service requestors and service providers in accordance with request and response messages. You can define the web service as software, which provides reusable application functions by describing the WSDL document of the SOAP message interface, and communicating using standard transport protocols. The WSDL describes the necessary details so that the service requestor can use a specific service: l Request message format L Response message format L Directive to send message WSDL based on XML, so the WSDL document is a computer readable (Machine-Readable). This development environment uses WSDL to automatically process the integrated service process to the requester application. For example, WebSphere Studio generates a Java agent object, which can be implemented like a local object, but actually proxy objects only process the request to create and respond to resolution. Regardless of whether the service is implemented with Java, C # or other language, the generated Java proxy object can call any web services from the WSDL description. In fact, WSDL cannot describe the implementation details like programming languages. WSDL uses its extension and supports service definitions by different protocols on HTTP. Based on SOA, you can refer to any application feature that can be described by WSDL to describe the interface. When SOA does not require WSDL - you can use other service description languages - most manufacturers and products are supported by WSDL.
Information exchange mode In the popular request-response (Request-response) exchange mode, the service requestor sends a request message to the service provider (or endpoint). After processing the request, the provider sends the response message to the requester. Service interoperability can be a session, consisting of several requests-responses. However, in order to achieve the simplicity of performance, the design is benefited from the loose coupling, the design of the coarse particle size interface is a good way, which can minimize the number of exchanges required for transactions. In addition to requesting-response mode, WSDL also defines the following: l Send a single-Way message to endpoint -, for example, requests that do not need to be responsive: L from the one-way message sent from the endpoint, called notification: L Requirements - Solicit-Response model, endpoints send messages and receive responses by it: Current SOA implementations typically use HTTP, resulting in synchronous communication - the requester is waiting for a response before processing. Synchronous exchange for services for the expected completion time relatively short (several seconds or minutes). It is also possible to have asynchronous service interoperability, and the service requestor does not wait for a response during asynchronous service interoperability, but expects to deliver a response. This is suitable for long-running transactions. For example, call a business process to request a specified passenger aircraft quote, the process includes many partners or people's interoperability, which takes a few days or for a few weeks. Use asynchronous exchanges to avoid losing connections (because server maintenance, etc.) and therefore lose response. The WS-Addressing specification will use the reply-to address as an extension of the SOAP envelope header element. Services requesters will request the queue to put into the port specified in the WSDL document, but do not wait. Instead, it does other work before the response arrives. When the service provider is ready to send a response, use the reply-to address in SOAP: the header of the request message. When using messages such as WebSphere MQ, you can use JMS to implement synchronization messages. The requester can choose to queue the completion of the queuing but not waiting for processing. When performing other operations, check the response queue in the response queue. You can use the method of synchronization messages to create additional swap modes, such as receiving multiple notification requests (such as notifications in stock quotation.). Service discovery although service calls and service descriptions are often considered to be SOA requirements, service discovery is also its optional feature. UDDI (General Description, Discovery and Integrated Protocol) defines a standard interface (based on SOAP message) for the availability and discovery of the publishing service. The UDDI implementation interprets the SOAP request of the publishing and discovery service as a data management function call for basic data storage. To publish and discover other web services, UDDI implements service registration by defining standard SOAP messages. Registration is a service agent, which is an intermediary that requires the requester and the provider of the service on UDDI. Once the requester decides to use a specific service, developers typically use the development tools (such as IBM WebSphere Studio or Microsoft Visual Studio .NET) and to access the service by creating the request to send a request and process the response. Discover services for building SOA applications, and the result is like electronic yellow pages. You can use tools (such as UDDI Browser in WebSphere) to find appropriate services during application design. SOA does not need to use UDDI, but because UDDI is built on SOA to complete its own work, UDDI is a good solution for service discovery.
As mentioned in Steve Graham's article "SIX Species of UDDI", you can use UDDI in a variety of different ways. This paper specifically pointed out the use of UDDI within IT organizations, mainly for managing internal services to increase reusability and further facilitating endpoint independence. For example, the location of the required service may be cached in the application. If the service is redeployed into a different server, the service requestor can discover the new location with UDDI and cache it to be used in future. When the UDDI is deployed within, using the UDDI service requestor application will automatically adapted to the change of the service deployment (for example, a change to maintain load balancing). With the development of UDDI, it will extensive services to discover publicly available (publicly-a protocol VAILABLE) services provided by other organizations in the market model. As we will be discussed in the article on the service-oriented article, UDDI is useful in running the UDDI dynamic selection of services at runtime. Conclusion The focus of this paper is that the benefits of increasing the complexity of the distributed application while expanding software asset value in the service-oriented architecture (SOA). It also defines the nature of the service and analyzes their characteristics, as well as some best practices. The basic elements of SOA and their mutual discovery and interoperability are discussed herein. You create an SOA-based IT architecture by developing a service directory (internal or partner) and writes code to develop new applications. Since the service provider can complete your own work by requesting other services, the layered structure of the service can be used on the design. Although a simple request - the response message model is most popular, you can use other messaging models flexible design systems. WSDL document tells you how to integrate services, UDDI helps you find the service you need.
