A Dynamic Procurement B2B System using Primitive Web Services

1. A Dynamic Procurement B2BSystem using Primitive Web Services BAI 2005 14-15 July ２００5 Takashi KOSHIDA Matsue National College of Technology

2. The content of my presentation • Introduction • Some background/Problems • ２.Primitive Web Service (PWS) • Definition • ３.Design of a dynamic • procurement B2B system • Use-case, System’s architecture • 4. Dynamic Invocation for PWS • 5. Conclusion

3. 1.Introduction • The B2B system is now widely used. • But it is limited to regular transactions. • However, SOAP,UDDI and WSDL has enabled world-widedynamicbusiness transactions.But, we think, not enough. • Because , there are three problems. It is difficult • to find the Web Service that users want to use or need, • to understand how to use it, • and to make a client program (stub) for executing a web service.

4. We have solved the 3rd issue [8-12]. • And, in this paper, we focused on the 1st and 2nd problems. • And to solve these, we proposed the concept of primitive web service.

5. WSDL UDDI registration/publish retrieval SOAP SOAP execution Service Requester SOAP Service Provider The make up of the Web Service • Web Service is the distributed processing technology on Web. • XML is used for data exchange.

6. 2. Primitive web service(PWS) • Proposal of a primitive web service • UDDI registry needs as a foundation for unifying management of web services on Internet. • But, there is no rules for naming, function representation and input-and-output parameters of web service. • So, user confirms each time the function ofweb service and input-and-output parameter. • By standardization, we can understand and confirm easily these items.

7. Definition • PWS is defined as follows, • fundamental web services witha unified name, function, and input/output IF,which can be used commonly for various activities in many business fields. • Merits • Ambiguity and uncertainty are resolved. • Once users understand a function and input/output interface, next time they can easily use it. • For arbitrary business process, users can combine these PWS.

8. 3. Design of a dynamic procurement B2B system • Use-case • We have assumed a good procurement process involving beer brewers, a wholesaler and retailers as a use-case. • Scenario is that a wholesaler selects the maker of lowest price goods and orders it. • PWS:inventory-check, goods-order, credit-check • Brewers provide a stock-management and a goods-order-received method that belongsthe same PWS. • All of credit research firms providethe samePWS.

9. (1)Delivery-of-goods demand (4)Inventory check and price estimate demand (8)Completion of a goods order received (2)Trust check demand (5) Inventory check and price estimate reply (3)Trust check reply (7)Completion of a maker goods order received (6)Goods selection and order System architecture and work-flow in a use-case Three makers provide the same PWS. Figure 1.

10. These data are used a credit check. Order interface for retailers : (1)Delivery-of-goods demand Figure 2.

11. results Exampleof the credit check results for retailer Figure 3.

12. Deployment of a PWS(maker) These are actual examples for a deployment of PWS. This PWS works in a maker. Figure 4.

13. Deployment of a PWS(credit research firm) This PWS works in a credit research firm. Figure 5.

14. Agents that work at the wholesaler Three agents work at the wholesaler and control the execution of PWS. Next we present in detail. Figure 6.

15. 4. Dynamic Invocation for PWS Name of PWS credit research firm (1) A goods order received and a credit inquiry • First, a wholesaler receives a goods order request from a new retailer, and performs a retailer credit inquiry using an agent (CreditServiceAgent1) under a client agent's (client1) control. • The agent retrieves a UDDI registry using the “Company A” value as a businessName argument and the “CreditCheck1” value as a serviceName argument, and gets the WSDL file.

16. Then,the agent analyses an input/output data type, if data type is a complex type, it creates dynamically a JavaBeans class that represents the data type (Figure 8). • And the getCreditmethod of a credit research firm is dynamically performed by this agent (Figure 7~9), and a response (Figure 3) is sent to the wholesaler.

17. (2) An inventory check and a price estimate Brewery’s name Name of PWS • If the credit of the retailer is confirmed (Figure 3), the “stock-management” method (getStockdetails) of the three beer makers will be executed dynamically one by one using agent (StockSeriveAgent7) according to Figure 7~9. • The agent retrieves a UDDI registry using “maker1”, “maker2” and “maker3” values as a businessNamearguments and the “GoodsService6” value as a serviceName, and gets the WSDL files.

18. Then,the agent analyses an input/output data type and an access-point of web service, if data type is a complex type, it creates dynamically a JavaBeans class that represents the data type. (same as (1) ) • And it executes dynamically the getStockdetailsmethod on three brewers one by one. The input data for the getStockdetails is set from Servlet order interface (Figure 2). • The input data will be automatically set for the three maker’s getStockdetails once it is specified.

19. (3) Goods selection and order • The output result of the getStockdetails for three makers are shown as like Figure 10. • An agent (StockServiceAgent7) compares these results, selects the goods with the lowest price, and reports to the wholesaler. • The selected result is shown in the top part of Figure 11. The least expensive is “Blue Beer” of maker 2. • The wholesaler will place an order for goods to the selected maker using the agent (StockServiceAgent7). The agent invokes dynamically the getOrdersmethod of the selected maker (Figure 7~9).

20. This is lowest price among three brewers. Execution results of getStockdetails for three brewers Execution results Figure 10.

21. Selection result by agent Order request (Execution of getOrders) Goods selection result by agent Figure 11. Goods selection result by agent

22. 5.Conclusion • As a method to find quickly the Web Service from UDDI registry user needs, we propose a primitive web service in which the name, function, and input/output interface is unified into a meaning should be prepared for every minimum unit of a business process. Then we have implemented the primitive web services and agents that control these as a B2B system.

23. This is a proto-type and incomplete, so as a future work, • Various other business processes need to be analyzed so that appropriate general-purpose PWS can be developed. • To do this, we will have to examine in detail, • The nature and contents of input/output data for each business process unit, • the module size needed for a primitive web service, and • which design techniques best enable widespread use and reuse.