Service-oriented architecture expansion of the foreground of Web services, Part 1
Characteristics of the service-oriented architecture
Level: primary
April 2004
The current Web service is often simple, usually similar to the client-server model. However, the platform neutral exchange is supported, which makes a series of different client implementations to interact with new code or legacy code as a server function. Many articles describe techniques that make such applications directly realize. Take a look at how we can use their bigger pictures. The author solves the problem of how to transfer the business model of any complexity representing the realistic model from a simple model.
In 221 BC, Qin Shihuang will unify several countries that have warned as a new country, and we are now called China. As a possible reason for China as a country is that Qin Chao introduces standards, standard consolidation culture, promoting trade: standard spacing makes carriages to effectively exercise in any road, common written language makes everyone You can exchange information (even if they are not the same language), and rugged work (such as China's Great Wall) makes people defend against foreign enemies. You can say that he has 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 marked by the introduction of SOAP 1.1, 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 regards service-Oriented Architecture, SOA, is deemed to have the key to 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 loosely coupled service requester 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 situation is true, 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 operation used in the following partial interaction: the message of the service call operation constructs the details of this message about where the information of the message for constructing the processing of this message is not included in any of the service implementation. technical details. 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" provider is asked to remember the account 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" service granular operation The particle size is an important design point. For external consumption, it is recommended to use a coarse particle size interface, while fine-grained interfaces may 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, setshippingaddress, 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. Conclusion The focus of this article is that the benefits of increasing the complexity of the distributed application while expanding the value of the service-oriented architecture (SOA). It also defines the nature of the service and analyzes their characteristics, as well as some best practices. The next article will discuss the concept of SOA architecture according to the following list:
Service call and discovery Description Agent model internal integrated service external reference
If you are interested in some aspects of service-oriented architecture, you can access the IBM's service-oriented architecture web site. Please refer to the "Tao of E-Business Services", which is still an excellent information on Web services and service-oriented architectural (SOA) concepts (developerWorks, October 2000). Migrate to a service-oriented architecture, Part 1 migrates to a service-oriented architecture, Part 2 You can purchase a wide range of technical topics on the developer bookstore.
About author
Mark Colan is the main e-commerce technology advocate of IBM Corporation. He gives technical, tone and customer display on Web services and XML technology and strategies. He spoke in 2000 and 2001 XML meetings and Java One '98 and '99. Mark currently displayed PDF can be downloaded from http://ibm.com/developerWorks/speaker/colan. Before joining IBM, Mark was working in Lotus Development Corporation for 12 years and helped to develop some commercial products. Mark has more than 20 years of design and experience of commercial software products and technology, which is well connected to component software strategies, operating systems and software tools. He as Chief Architects of Infobus Technology (Java Standard Extension). You can contact Mark via mcolan@us.ibm.com.
