Architecture Web Service: Battle Web Service
content:
Case requirements Description Application System Architecture Catalog ServiceOrder ServiceFeedback Service Interaction, what is interaction? Why choose a web-based solution? What is the need to open? Reference author
related information:
WEB-based applications, solutions and development platform What is web service? Why is a web service? Dynamic e-commerce model
Chainivel@uddi-china.org, Chief System Architect, August 14, 2001 (this article was originally published by IBM DeveloperWorks China website, its URL is http://www.ibm.com/developerworks/cn/)
This article is the fourth article of architecture web services, but also discusses the business needs, technical definitions, and technical specifications and existing existing web services practices, this article is discussed. Chapter. A case in which actual practical and can extend the computer product trading market is given, and the data to be exchanged by the loose system is divided by a brief system analysis, the module division, and is based on the definition. The data structure of the API of the web service laid the basis of system and analysis.
In the previous article series, I have already introduced a comprehensive introduction to the business needs of Web services, Web services technology implementation, and the current application of Web services, and development tools, and in the next article, I will combine one instance. Describe how to truly plan, design, and create a specific application of a web service. The resources cited herein mainly include two categories, one is the technical resource website of web services, including the technical information of a large number of web services, and the other is the "Stack" technical specification of the web service, they are a whole technical system. Including UDDI, SOAP, WSDL, XML, etc. The links of these resources are given in this article, and interested readers can find the desired content through these resource links. Case requirements Description Here we assume that the application background is a computer product sales market, the role and its corresponding behavior described below:
Computer product trading market, the market is a marketing platform between contact computer product manufacturers / retailers and consumers. The responsibilities and features include: collecting and publishing a catalog from each computer product producer / retailer; accepting consumers' purchase requests and delivering to the manufacturer / retailer system to complete the purchase transaction; collect consumption feedback from consumers To give the guidance recommendation for the purchase of goods and transfer to the manufacturer / retailer. Manufacturer / retailer, this is a business that directly sells computer products, he can publish a catalog through its own web, and can also transfer the directory to the computer product trading market. He is able to accept orders (from your own web site or from computer product trading market) and transfer to internal management systems, as for capital flow and logistics are completed by offline systems. Consumers, computer products buyers (possibly personal, may also be a business), he can access the computer product catalog and can purchase online ordering services. Through the analysis of the above roles and its behavior, we believe that there should be such a summary level in the final implementation system:
Product catalog, the product catalog is generated by the manufacturer / retailer, and the computer product trading market is summarized and used by consumers. Orders, orders are generated by consumers, transferred by the computer product trading market, and acceptable by the manufacturer / retailer. Feedback from the consumer, the computer product trading market is summarized, and consumers and producers / retailers are used. Users, users are divided into two categories, and one is consumer users, one is the manufacturer / retailer user, which is used to handle two types of transactions. The system architecture is comprehensively analyzed in the system, we can divide the entire system as follows: Figure 1. System division summary may find that Marketplace System and Retailer System do not have something difference? It is true, we are When designing, you should not forget the concept of "reuse". The more components are reused. The less the development is, the lower the price of maintenance, the better the scalability, of course, the reusability cannot lead to the alienation of function, this It is also what we need to pay attention to. Below I spend a little one slightly analyzes the three main services in the frame: Catalog Service, Order Service, and Feedback Service. Catalog Service For this service, the Catalog Service in Retailer System should be a subset of the MarketPlace System function. In Retailer System, Catalog Service should have the following features: Category management, including adding category, deleting a category, modifying a Category et al; product (Product), including adding a product, delete a product, modify a product, Move a product (moving from a category to another Category), etc .; Data backup, backup / recovery of all product data in the entire directory. In MarketPlace System, you need to add a function: the data exchange and data backup module should provide operations for the relevant data of the specified data owner, such as exporting all products of IBM under a category, etc.. ORDER Service For this service, ORDER Service in the Retailer System and Marketplace Systems can be said that there is no substantially different differences. They will have the following functions:
Accepting the order between the order to other services to receive orders, only the order of the order, only the order from the ORDER Service accepted by the Retailer System comes from the user interface, and needs to be transmitted to the Order Service in MarketPlace System. Order service accepted by Marketplace System comes from the ORDER Service in Retailer System, and you need to send an order to your own internal enterprise. Feedback Service For FEEDBACK Service, the status in both systems is similar to the Catalog Service.
Feedback management, including adding a feedback information, deleting a feedback information, modifying a feedback information, etc. Evaluation of a product, etc.); data exchange, including imported exports associated with a single category or feedback information associated with a single product, and all feedback related to a single user (Retailer user, data owner) Import export, etc .; Feedback can be seen as a comment article associated with each node of the entire product directory tree. Not only publishes consumers not only in the Marketplace system, but also saves the relevant Retailer systems and available for Retailer. What is interaction and interaction? We will summarize the above features, remove the internal implementation, and we can find the logical view of the data that needs to be transmitted on the Internet: Figure 1. Data entity relationship diagram where the yellow three entities are completely It is seen as a tree-shaped information directory, which has three levels of nodes: category, product and feedback, Category's sub-nodes can be category, product and feedback, and the child's child node can only be Feedback, the whole directory tree The root node is category. For each product, there is a data owner, which should be a Retailer account in Marketplace. Another type of entity is an order. For a order, it will contain multiple Product's order record, and the order object: a Retailer. Interactive data between the system is the first level of interaction: data exchange, however, for web services, light light has data exchange, and the higher level: support for service integration should be provided. Therefore, the interactive content is not light including data interacting with each other, and should include operations for data (such as data requests, data adding, data update, etc.). These often correspond to one processing module with the server. Whether it is the operation of the data, or the data itself, in order to interact between the system and the system, in particular the heterogeneous platform, we need to put all the operations (service calls) and the data (parameters and returns of service calls) Value) Specification description, forming a standard document to be published for all systems that need to participate in interoperability. Why choose a web-based solution? I have already prelimated a preliminary discussion in front of why e-commerce needs Web services. E-commerce needs to get rid of the implementation mode of the independent solution, and requires the process of discarding complex system connections. An effective e-commerce application is definitely not based on programmers and those complex code. For e-commerce, the traditional development model dominated by the programmer should be replaced by the user-led development model. The lengthy serial development cycle should be replaced by instant, fast application assembly. At the same time, such an application should have highly customizable. If you explore its business nature, this is from time-tested business technology concept: "Instant Manufacturing" and "Scale" and other concepts, what we need to do is to extend traditional business concepts to e-commerce. By using a web service, companies can use their own e-commerce components by abstraction and mixing. When the core competitiveness of a company is assembled, then these core competitiveness can be easily shared between different enterprises, while architecture across the enterprise e-commerce application, forming a business web.
In our computer product sales network applications, we can foresee the systems used by different vendors very likely to be a variety of WINDOWS / IIS-based web applications, with Java Platform's web applications, and Windows Platform desktop applications, may also be based on UNIX ERP applications, compatible with many types of applications, and it is difficult to meet all the needs in general integration technology. Even if you are satisfied, when there is any new Retailer who wants to join this system, the integration costs of each other cannot be predicted. By publishing pre-defined scalable service access specifications, these Retailer systems that need to be integrated into the system can be entered in a convenient standard. Can you say that the Retailer system is not usually developed? Yes, part, and may even be a large part of the Retailer system may use the platform with the MarketPlace system, and it is only a few of the service module. However, we are at the era of open internet in the Internet. For Marketplace, the more retailer's entry represents more business opportunities, and MarketPlace operators will try their best to recruit, integrated more Retailer systems. Then, each of which has a heterogeneous Retailer system is developed to develop project development with its single-point integration, it is better to develop a specification, so that these newly added Retailer can autonomously join the system in accordance with these specifications. MarketPlace also has the ability of Haina Baichuan, while do not use index to invest in the development cost. At the same time, if the specification becomes a public acceptance, other standard MARKETPLACEs can also appear, and the Retailer system that follows this specification can be widely accessed to all compatible MarketPlace with very low cost. Go, get more sales opportunities and channels. Even according to specifications, the Retailer system can also achieve low cost peer interconnection. It can be said that the integration of Web-based service integration based on the specification is true to integrate the Internet age of Internet era in the Internet. What is needed? We have already disclosed that we need to disclose the calling specification, then the call specification should define it. If you follow me in this column about UDDI's article, I have studied the UDDI specification, then basics It can be understood that For Web services (UDDI Registry is a standard web service), the specification definition can be divided into two parts: Programmer's API: This is a similar API definition, but the carried media is SOAP MESSAGE, that is, Programmer's API is a set of SOAP APIs. Different APIs are used to complete different service calls, which need to define different SOAP API behavior and implementation of the modes of calling / response; Data Structure: This is defined in SOAP The parameter / data and response data transmitted in the message, this part is a recorded message format supplemented by each API while providing the final API process. In the following article, I will tell this Demo Case in this article, step in step by step to define the Programmer's API and Data Structure. Reference
Web Service Technology / Commentary
UDDI-CHINA.ORG, with UDDI-based Web service technology website. WebServices.org, comprehensive technology website for Web services. IBM DeveloperWorks / Web Service Zone, IBM Web Services Technology Resource Center MSDN Online Web Services Developer Resources, Microsoft Web Services Developer Resources Website ITPAPERS / Web Service, ITPAPERS Web Services Comments Ability to resolve B2B e-commerce application interaction and integration Interop Stack Series Technical Standard Specification UDDI Executes White Paper, UDDI-CHINA.ORG, UDDI.ORG UDDI Technology White Paper, UDDI-CHINA.ORG, UDDI.ORG UDDI Programmer API Specification, UDDI-CHINA.ORG, UDDI.ORG UDDI Data Structure reference, UDDI-China.org, UDDI.org Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000 SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 OCT 2000 Architecture Web Services Series
Architecture Web Service (1): Why is a web service architecture Web Service (2): What is web service architecture Web Service (3): Web service-based applications, solutions and development platform architecture Web Service (5): interactive interface, Web service definition core architecture Web Service (6): Description and registration, release web service author profile Chai Xi Road: Shanghai Dealeasy Chief System Architect, XML Technical Consultant. UDDI-CHINA.ORG Blue Flame Studio Member. UDDI Advisor Group member, WSUI Working Group member. In 2000, he won a master's degree in computer science at Fudan University. He has worked at the International Computer Science Conference (ICSC), the Asia Pacific XML Technology Seminar (XML Asia / Pacific'99), China XML Technology Seminar (Beijing), Computer Science Journal and so on International, domestic important conferences and journals published multiple articles. Specialized in technological research based on XML-based system integration and data exchange, while the database, object-oriented technology, and CSCW is good at.
