Messaging Pattern (RE: Requirements)

[Yuhichi Nakamura <NA...@jp.ibm.com>]

James,
I separeted Messaing (interaction) Pattern topic.
I have different 4 or 5 patterns in mind:
  a. Synchronous request/response
  b. Asynchronous request/response
  c. Synchronous one-way
  d. Asynchronous one-way
  (e. one-way without ack)
Note that c, d and e are distinguished how ack is returned to the
requester.
e is in a sense dangerous because you do not know whether it is delivered
or not.

As for your 1, actually there are three patters in my definition (c, d, e).
Your 2 can be implemented with one-way (c, d, e).  Why should we
distinguish notification from one-way messaging.
I excluded your 3 because it can be provided by performing multiple one-way
messaging.  I feel it should be developed on top of a basic platform.
Your  4 corresoponds to my a and/or b.  When discussing interaction
pattern, we should not introduce another-level concept RPC.
Even at the messaging, we have request/response.  Right?

Again, semantics of messaging affects the basis of the architectures.
Therefore we need a consensus on this.

p.s. In another mail, you mentioned that it is not difficult to combine
two one-way messaging into request/response.  I am not sure about
that.  If you come up with a design for this, please post it.

Best regards,

Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413


From: "James Snell" <js...@lemoorenet.com> on 2000/11/15 13:34

Please respond to soap-dev@xml.apache.org

To:   <so...@xml.apache.org>
cc:
Subject:  RE: Requirements



2. Regarding supported interaction patterns.  There are four interaction
patterns (in no particular order):

   1. Messaging.  one-way messages sent from a service consumer to a
service
provider
   2. Notification. one-way messages sent from a service provider to a
service consumer
   3. Broadcast. one-way messages sent from either a single service
provider
to a group of service consumers or from a single service consumer to a
group
of service providers.
   4. RPC. request-response messages exchanged between a service consumer
and a service provider
      Subtype: RPC Broadcast.  request-response messages sent from either
one service consumer to multiple service providers or from a single service
provider to multiple service consumers.

   Practical examples of each interaction pattern:

   1. Messaging: Purchase Order submission into an enterprise system
   2. Notification: Notifying the service consumer that a long-running
async
process has completed
   3. Broadcast:
        Provider To Consumers: Notifying multiple service consumers that a
service is going offline/online
        Consumer to Providers: Notifying multiple service providers that a
consumer is going offline/online
   4. RPC:
        1 Consumer To 1 Provider: Standard application RPC
        1 Consumer To n Providers: Napster-style P2P applications.  For
example, one client that initiates
                                   a simultaneous search on multiple
service
providers.

   Out of these four, I think number 1 and number 4 are the most important,
but I would like to see all 4 addressed.