A Dynamic Procurement B2B System using Primitive Web Services

1
A Dynamic Procurement B2B System using
Primitive Web Services

• BAI 2005
• 14-15 July 2005
• Takashi KOSHIDA
• Matsue National College of Technology

2
The content of my presentation

• Introduction
• Some background/Problems
• 2. Primitive Web Service (PWS)
• Definition
• 3. Design of a dynamic
• procurement B2B system
• Use-case, Systems 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-wide dynamic business 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
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 of web
  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 with a 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.
• PWSinventory-check, goods-order, credit-check
• Brewers provide a stock-management and a
  goods-order-received method that belongs the same
  PWS.
• All of credit research firms provide the same PWS.

9
System architecture and work-flow in a use-case
Three makers provide the same PWS.
Figure 1.
10
Order interface for retailers
(1)Delivery-of-goods demand
Figure 2.
11
Example of 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
(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 getCredit method of a credit research
  firm is dynamically performed by this agent
  (Figure 79), and a response (Figure 3) is sent
  to the wholesaler.

17
(2) An inventory check and a price estimate

• 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 79.
• The agent retrieves a UDDI registry using
  maker1, maker2 and maker3 values as a
  businessName arguments 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 getStockdetails
  method 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 makers 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 getOrders method of the selected
  maker (Figure 79).

20
Execution results of getStockdetails for three
brewers
Execution results
Figure 10.
21
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.