Real-combat Web services

Web|web Service
Architecture Web Service: Combat Web Services




Content:

Case Requirements Description
System Architecture for Application
Catalog Service
Order Service
Feedback Service
Interacting, interacting with what?
Why choose a Web service based solution?
What is the need to be public?
Resources
Author Introduction


Related content:

Web services based applications, solutions, and development platforms
What is a Web service?
Why do I need a Web service?
Dynamic e-business Model




Chai Xiaolu (fennivel@uddi-china.org)
Chief System Architect
August 14, 2001

This article is the fourth of a series of articles on architecture Web services, followed by a discussion of the business requirements of Web services, technical definitions and technical specifications, and existing Web service practices, to start a chapter on Web services through the use of a specific case. In this paper, we give a practical and can extend the case of the computer products trading market, through the brief system analysis, the module division, to the loose system to exchange the data to carry on the boundary division, simultaneously has laid the system and the Analysis Foundation for the definition Web service API data structure.
In the previous article series, I have made a comprehensive introduction to the business requirements of Web services, the technical implementation of Web services, and the current application of Web services and development tools, and in the following articles I will combine an example to describe in detail how to really plan, Design and create a specific application for a Web service.

The resources cited in this article mainly include two categories, one is the Web Services Technical Resources Web site, contains a large number of Web services technical information, the other is the Web services "stack" series of technical specifications, they are a whole technical system, including UDDI, SOAP, WSDL, XML and so on. At the end of this article, the links to these resources are given, and interested readers can find what they need through these resource links.

Case Requirements Description

Here we assume that the application background is a computer product sales market, where the roles and their corresponding behaviors are described as follows:

Computer Products Trading market, which is a marketing platform between computer product manufacturers/retailers and consumers. Its responsibilities and functions include: collection and release of product catalogs from individual computer product manufacturers/retailers, acceptance of customer purchase requests and reliable delivery to the manufacturer/retailer system to complete the purchase transaction, collection of consumer feedback from consumers, guidance advice on the purchase of goods, and transmission to the manufacturer/retailer.
Manufacturer/retailer, which is a merchant who sells computer products directly, he is able to publish catalogues through his own web, and also to transfer directories to the computer product market. He was able to accept orders (from his own web site or from the computer product exchange market) and into an internal management system, and the flow of money and logistics was done by the off-line system.
A consumer, a purchaser of a computer product (possibly an individual or an enterprise), is able to access the catalogue of computer products and can use online ordering services for purchase.
Through the analysis of the above roles and their behavior, we believe that there should be objects in the final implementation system at several levels of the profile:

Product catalog, the product catalog is produced by the manufacturer/retailer, which is categorized by the computer product transaction market and is browsed by the consumer.
Orders, orders are generated by the consumer, delivered by the computer products trading market and accepted by the manufacturer/retailer.
Feedback, generated by the consumer, is categorized by the computer product transaction market and used by consumers and manufacturers/retailers.
Users, users are divided into two categories, one is consumer users, one is the manufacturer/retailer users, respectively, for processing two types of transactions.
System Architecture for Application

Combining the above analysis, we can divide the whole system into the following architecture:

Figure 1. System Partitioning Overview


You may find that there is no big difference between the two systems of marketplace system and retailer. That's true, we should be in the design of the time should not forget the concept of "reuse", the more reusable components, the less the cost of development, maintenance costs are lower, scalability is the better, of course, reuse can not lead to the alienation of functions, which we need to pay attention to.

Let me take a moment to explain a little bit about the three main services in the framework: Catalog service, order service, and feedback service.

Catalog Service

For this service, the catalog service in retailer system should be a subset of marketplace system features. In retailer system, the Catalog service should have the following features:

Category (Category) management, including adding a Category, deleting a Category, modifying a Category, and so on;

Product management, including adding one product, deleting a product, modifying one product, moving one product (moving from one category to another category), and so on;

Data exchange, including import and export of all products under a single category, import and export of individual product data, import and export of the entire category tree, etc.;

Data backup, the entire directory of all product data backup/restore and so on.

In Marketplace system, there is a need to add a function: In the data exchange and data backup module should provide data to the owner of the specified operation, such as the export of a category of IBM's products and so on.

Order Service

In the case of this service, the order service in retailer system and an order service in marketplace system can be said to have essentially no fundamental difference. They will all have the following features:

Accept Order
Send orders to other services that accept orders
The difference is that the order service in retailer system accepts orders from the user interface and needs to be routed to the ordered service in Marketplace system. The order service in Marketplace system accepts orders from the ordering service in retailer system and needs to apply the delivery order to its internal enterprise.

Feedback Service

For feedback service, the status in both systems is similar to the catalog service.

Feedback information (Feedback) management, including adding a feedback information, delete a feedback, modify a feedback information, etc., feedback can be hung under the category, can also be hung under the product (there is a report for a class of products, but also for the use of a product evaluation, etc.);
Data interchange, including import Export (Import/export) of feedback information associated with a single category or associated with a single product, and import and export of all feedback related to a single user (retailer user, data owner);
Feedback can be viewed as a comment article associated with each node of the entire product directory tree. Not only in the marketplace system by the consumer published and customer inquiries, but also in the relevant retailer system to save and for retailer use.

Interacting, interacting with what?

We summarize the above functional descriptions and remove the internal implementations, and we can see that the logical view of the data that needs to be transferred over the Internet is as follows:

Figure 1. Data entity diagram


The yellow three entities can be viewed as a tree-like information directory, with three levels of nodes: the Category,product and Feedback,category nodes can be Category, product, and feedback. The child node of product is only feedback, and the root node of the entire directory tree is category.

For each product, there is a data owner who should be a retailer account in marketplace.

Another type of entity is an order that, for an order, can contain multiple product order records, as well as order objects: a retailer.

Interactive data between systems is the first level of interaction: data exchange, but for Web services, optical data exchange is not enough, should provide a higher level: the support of service integration.

Therefore, the content of the interaction includes not only the data interacting with each other, but also the operation of the data (such as data requests, data additions, data updates, etc.). These tend to correspond to a processing module on the server side.

Whether it's the operation of data or the data itself, in order to interact between systems and systems, especially between heterogeneous platforms, we need to normalize all operations (service invocation) and operational data (service invocation parameters and return values). The specification document is released for compliance with all systems that need to be involved in interoperability.

Why choose a Web service based solution?

I have already made a preliminary discussion on why e-commerce needs Web services in the front. E-commerce needs to get rid of the implementation mode of the independent solution and need to discard the implementation method of complex system connection. An effective e-business application should never be based solely on the programmer and the complexity of the code. In the case of E-commerce, the traditional programmer-led development model should be replaced by an outward-oriented development model that is led by the user. A lengthy serial development cycle should be replaced by an immediate, fast application assembly. At the same time such applications should be born with high customization. If you look at the nature of business, this is from the time-tested concept of commercial technology: "Just-in-time manufacturing" and "scale scalable" concepts, we need to do is to extend the traditional business concept to e-commerce.

By using Web services, organizations can integrate their own e-commerce through abstraction and blending in ways that were previously impossible. When the core competitiveness of an enterprise is modular, then these core competencies can be easily shared among different enterprises, while the architecture of e-commerce applications across enterprises, the formation of business web.

In our computer Product Sales Network application, we can foresee that different vendors will adopt a variety of systems, there are web-based applications based on Windows/iis, Java-platform Web applications, as well as Windows platform based desktop applications, It is also possible that the UNIX based ERP application section, to be compatible with so many kinds of applications, with the general integration technology is difficult to meet the needs of all occasions. Even when there are other new retailer that want to join the system, the cost of integration is unpredictable. By publicizing predefined extensible service access specifications, the retailer systems that need to be integrated into the system can be accessed in a convenient and standard way.

You may say that retailer system is not also we to develop it? Yes, part of it may even be a large part of the retailer system may use the same platform as the marketplace system, and only a few pieces of the service module. However, we are in the Internet era of open interconnection, for marketplace, the more retailer entry represents more business opportunities, marketplace operators will try their best to recruit, integrate more retailer system, So instead of using human resources to develop a single point of integration with each heterogeneous retailer system, it is better to develop a specification that allows these newly joined retailer to join the system in accordance with these specifications. Marketplace also have the capacity of the sea, but also do not refer to several times the cost of development.

At the same time, if the specification becomes a publicly accepted specification, other marketplace that are compatible with the standard can also appear, while retailer systems that follow the specification can be widely accessed at very low cost to all compliant marketplace. Get more sales opportunities and channels. Even in accordance with the specifications, retailer systems can also achieve low-cost peer-to-peer interconnection. It can be said that the standards-based service integration based on Web services is truly a way of integrating the services of the Internet era with the open interconnection concept of the Internet.

What is the need to be public?

We've talked about what we need to expose as calling specifications, so how do we define calling specifications, and if you've followed me a little bit about the UDDI specification in this column's previous article on UDDI, you can basically understand 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 an API definition similar to the traditional meaning, but the hosted media is a SOAP message, meaning that the programmer ' API is a set of soap APIs that are used by different APIs to perform different service invocations. In this section, you need to define the behavior of different soap APIs and the functional description of the invocation/response of the implementation;
Data Structure: This section defines the XML schema of the parameters/data and response data that is transmitted in the SOAP message, which complements the message format for each API and provides data-layer parsing/packaging specifications for the final API processing.
In a later article, I'll take a step-by-step look at how to define the programmer ' s API and data Structure in this demo case, which is the focus of this article.

Resources

Web Service Technology/Comment website
Uddi-china.org, a UDDI-oriented Web services technology Web site.
webservices.org, Web Services Integrated class technology Web site.
IBM Developerworks/web Service Zone, IBM's WEB Services technology Resource Center
MSDN Online Web Services Developer Resources, Web Service Developer Resource Web site for Microsoft
Itpapers/web service, Itpapers's WEB Services review article
Interop Stack Series technical standard specification for addressing business-to-business e-business application interactions and integrations
UDDI Executive 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, SEP 2000
Soap:simple Object Access PROTOCOL Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
Extensible Markup Language (XML) 1.0 (Second Edition), the Consortium, 6 OCT 2000
Author Introduction

Chai Xiaolu: Shanghai Easy e-commerce Technology Co., Ltd. (dealeasy) chief System Architect, XML technical advisor. Member of Uddi-china.org Blue Blaze Studio. UDDI Advisor group member, Wsui Working group member. He received a master's degree in computer Science from Fudan University in 2000, and has been in the International Computer Science Conference (ICSC), Asia-Pacific XML Technology Symposium (XML asia/pacific ' 99), China XML Technology Symposium (Beijing), and computer scientific periodicals. Many papers have been published in major domestic conferences and periodicals. specialize in xml-based system integration and data exchange technology research, at the same time, database, object-oriented technology and CSCW technology is better.