A Gridbased ECommerce Architecture and Formal Specification

1
A Grid-based E-Commerce Architecture and Formal
Specification

• Yu-Yue DU 1,2,3 , Chang-Jun JIANG 1,3
• 1 Tongji University, Department of Computer
  Science Engineering, China
• 2 Liaocheng University, Department of
  Computer Science, China
• 3 Laboratory of Computer Science, Institute of
   Software, 
• Chinese Academy of Sciences, China

2
Main Contributions

• Present a new E-commerce architecture based on
  the Grid Computing environment.
• It can implement various electronic bargains on
  Grid resources between geographically dispersed
  users.
• Apply Petri nets to formal modeling and analysis
  of the architecture.
• Some main properties are represented and verified
  formally using Petri net language.

3
1 Introduction (1)

• Grid computing can offer seamless access to rare
  and limited resources as the high-performance
  cooperation of geographically distributed
  computer systems.
• We wish to have an environment where cooperative
  jobs between participants can be executed either
  on local or remote computer systems
  electronically and quickly, and in most cases
  automatically.

4
1 Introduction (2)

• We will present and analyze an E-commerce
  environment on the basis of the Grid Computing,
  notation G-E-commerce architecture, for a model
  of future E-commerce platforms.
• The G-E-commerce is offered collectively by
  multiple distributed modules or geographically
  dispersed business models, possibly provided and
  owned by different organizations.

5
1 Introduction (4)

• G-E-commerce can assist users with the
  negotiation and maximize well-balanced profits
  between players, and improve the trade response
  time.

6
1 Introduction (5)

• It is very important that a software system is
  analyzed and verified formally before the
  implementation.
• We use Petri nets and workflow technologies to
  model and analyze the G-E-commerce.

7
2 A Grid Computing Setting (1)

• In the Grid Computing setting, source provider
  must posse ultimate control over their resources.
  
• It is not feasible for the Grid Computing system
  to insist that the resources are restricted on a
  centralized scheduling authority that is
  responsible for allocating resources to
  consumers.

8
2 A Grid Computing Setting (2)

• Suppose that the Grid Computing architecture
  cannot force resource providers to remove or
  replace elements of their existing software base.
  
• The architecture must accessible as a set of
  services layered on top of installed, extant
  software rather than as a replacement.

9
2 A Grid Computing Setting (3)

• We adopt the decentralized approaches with
  several centralized resource brokers, when
  designing a Grid resource allocation scheme.
• A centralized resource broker is responsible for
  fielding the resource requests of the users
  registering in it and making resource assignments.

10
2 A Grid Computing Setting (4)

• Each broker may combine with the other to
  implement a cooperative task crossing broker
  boundaries.

11
3 An E-Commerce Grid Architecture (1)

• We present an E-commerce architecture within a
  global grid environment.
• It couples a wide variety of geographically
  distributed trade resources such as goods and
  special instruments, and represents them as a
  unified integrated resource.

12
3 An E-Commerce Grid Architecture (2)

• If all trade resources from various entities are
  managed by G-E-commerce architecture, this will
  result in a performance bottleneck to locate the
  resources satisfying the needs of a user.
• In fact, there are frequently trade relations
  between some affined business organizations but
  rarely between the other ones.

13
3 An E-Commerce Grid Architecture (3)

• G-E-commerce architecture consists of Grid Trade
  Brokers (GTB) and User Grid Agents (UGA).
• Each GTB is responsible for the negotiation and
  exchange of the resources from the affinitive
  organizations, while each UGA submits user
  requests to the GTB and accepts the trading
  results from the GTB.

14
3 An E-Commerce Grid Architecture (4)

• When the UGAs of coordinative users are managed
  by the same GTB, it can implement autonomously
  the business negotiation and execute this
  bargaining.
• if the UGAs of the users participating in a
  bargaining are not in the same GTB, this means
  that there exist the negotiation and exchange
  crossing GTB boundaries (see Fig.1).

15
Fig.1 G-E-commerce scenario composed of two GTBs
and five UGAs

16
3 An E-Commerce Grid Architecture (5)

• Each user essentially interacts with its
  corresponding UGA, whereas each UGA interacts
  directly with a GTB.
• A GTB acts on the other GTBs when there is a
  bargaining crossing GTB boundaries.

17
3 An E-Commerce Grid Architecture (6)

• UGAs have stronger ability for expressing user
  requirements.
• Communication between UGAs and a GTB is performed
  based on the Agent Communication Language (ACL),
  which is independent of user software systems.

18
3 An E-Commerce Grid Architecture (7)

• A user may want randomly to add to or to remove
  from the architecture, but she must first put in
  for registering or withdrawing.
• The UGA services are implemented by the User
  Agent Daemon, which runs on grid machines, and
  the User Agent Server, which runs on the machines
  in a GTB.

19
3 An E-Commerce Grid Architecture (8)

• UGAs provide also security-sensitive services
  such as remote execution, the Daemon and the
  Server rely on public-key cryptography to
  authenticate each other.
• The requirements of each user are described in
  terms of the code form provided by the specified
  UGA when it registers.

20
3 An E-Commerce Grid Architecture (9)

• The describing elements provided contain
  generally
• service types
• user identity
• range of trade price
• size of resources such as the number of sale
  products
• trade deadline.

21
3 An E-Commerce Grid Architecture (10)

• The GTB services are implemented by the User
  Agent Server, the Task Manager and the Trade
  Information Server, which run all on grid
  machines.
• The User Agent Server is used to receive user
  service requests from UGAs and to forward trading
  results to UGAs.

22
3 An E-Commerce Grid Architecture (11)

• Trade Information Server provides the exhibition
  of bulletin information and market directory for
  registered grid users, and can rearrange trade
  information in the order required.
• Users may competitively set the resource price
  and advertise their services and requirements in
  the market directory.

23
3 An E-Commerce Grid Architecture (12)

• Task Manager consists of a set of the tasks sent
  by UGAs, which can be executed independently.
• Task Manager is responsible for choosing resource
  providers for consumers vice versa, through
  price-benefit analysis providing the
  well-balanced the profits.

24
3 An E-Commerce Grid Architecture (13)

• Task Manager also provides control commands for
  each bargaining to pause, kill, and monitor the
  execution of applications and tasks.
• When some players are matched optimally for the
  same kind of goods, GTBs inform instantaneously
  the involved users via their UGAs and initiate
  this bargaining.

25
3 An E-Commerce Grid Architecture (14)

• During the bargaining execution, resource
  providers and consumers may further negotiate for
  resource trade price, time and performance to
  maximize their objectives.
• Each bargaining in the Task Manager is composed
  of two executables or scripts the home task and
  the grid task. The home task runs on the user
  machine.

26
3 An E-Commerce Grid Architecture (15)

• Task Manager invokes the home task when the
  requirements of the corresponding user are
  satisfied optimally by the services of the other
  users.
• The grid task runs on a grid machine and performs
  this bargaining.
• Once finishing this bargaining, the grid task
  will send in time the trading results to the
  corresponding providers and consumers.

27
3 An E-Commerce Grid Architecture (16)

• Fig.2 shows a sequence of the actions that place
  in executing a bargaining under the G-E-commerce
  architecture composed of two user grid agents
  belonging to the same GTB.
• Step (3) is used to add user requirements to and
  to delete user requirements implemented or
  withdrawn from the Trade Information Server.

28

29
3 An E-Commerce Grid Architecture (17)

• Step (4) is used to transfer the matched user
  requests from the User Agent Server to the Task
  Manager, and to transmit in turn the message
  describing the end of a bargaining.
• The negotiation between the providers and
  consumers can be implemented automatically inside
  GTBs, if they want to do so. In this case, steps
  7, (8a), (8b), (9a) and (9b) can be omitted

30
4 Petri Net Model of G-E-Commerce (1)

• we focus on the modeling of a Grid Trade Broker
  using Petri nets (see Fig.3).
• Two types of places control places and data
  places, and two types of tokens control tokens
  and data tokens.
• Control places are used to deposit control
  tokens, data places to deposit data tokens.

31
4 Petri Net Model of G-E-Commerce (2)

• By means of workflow technologies, each component
  has only one control token at any moment, and is
  a cyclic workflow process.
• Each transition represents an action, and its
  firing means that the action is executed.

32
4 Petri Net Model of G-E-Commerce (3)

• Fig. 3 shows the Petri net model of a Grid Trade
  Broker only including a pair of collaborative
  User Grid Agents (a provider and a consumer).
• The passing value dependencies between the three
  components are represented by data places.

33
4 Petri Net Model of G-E-Commerce (4)

• Each component has a cyclic workflow and has
  placed one control token in its initial marking.
• The three workflows may run in parallel on
  different grid machines while implementing their
  cooperative work within the Grid Trade broker.

34

35
4 Petri Net Model of G-E-Commerce (5)

• Notice that there is only one trade process in
  the Trade Manager of this example.
• In practice, we may deploy in parallel several
  same trade processes running on different grid
  machines, to enhance the performance of Trade
  Manager and to avoid the overload of the matched
  user requests.

36
5 Analysis of G-E-Commerce (1)

• By Fig.3, we can obtain the following properties
  of G-E-commerce and their formal representations.
  
• Property 1 (All firing sequences of the actions
  in each component is monitored strictly by the
  specified workflow process.)
• For any reachable marking M in the Petri net
  model, i?1,2,3, there exists a unique
  j?1,2,?,8 such that M(Cij)1.

37
5 Analysis of G-E-Commerce (2)

• Property 2 (Each user request from a registered
  User Grid Agent can be processed by the User
  Agent Server.)
• If M is a marking in the Petri net model of the
  User Agent Server, M(C21)1, and
  M(UGA-1)?1?M(UGA-2)?1, then there is a marking M?
  reachable from M such that M?(C28)1.

38
5 Analysis of G-E-Commerce (3)

• Property 3 (The User Agent Server does not
  discriminate any UGA, while the Trade Manager
  does not discriminate any pair of matched users.)
  
• Let M be a marking in the Petri net model, for
  any i?1,2, if accept-i is firable at M, then it
  can fire eventually at a marking reachable from
  M. And each token in matched-user will be removed
  eventually by firing start-trade.

39
5 Analysis of G-E-Commerce (4)

• Property 4 (The bargaining of each pair of
  matched users is finished eventually in the Trade
  Manager.)
• If there exists a marking M reachable from the
  initial marking M0 such that M(C31)1 and
  M(matched-user) ?1, then ?M??R(M) and M?(C37)1.

40
6 Conclusion and Future Work (1)

• G-E-commerce can be employed as the next
  generation E-commerce platform, once the
  corresponding software system is developed.
• It makes sufficiently use of the Grid sources to
  implement quickly various electronic transactions
  between the remote users.

41
6 Conclusion and Future Work (2)

• The usage of the Grid Trade Broker can avoid
  leading to a performance bottleneck.
• Further work will be to apply high-level Petri
  nets and branching-time temporal logic to
  modeling and verification of the G-E-commerce
  architecture.
• we will also develop a model-checking tool of
  G-E-commerce.

42

• Thank You