Re: Participants and roles

Well I just realised this post: sorry a bit off-topic now.

This is a lucid illustration.  I think we have discussed about this topic, participants and roles,
over the phone and mails (Steve and others) last year, sometime in November. One of the
points which came out then (perhaps I pushed it but I am not sure and it does not matter) is
instantiation of roles rather than role instances.

Since this point may not be communicated by Steve's post too explicitly (which *is* a
very good illustration of another point), I would augment it with a bit of illustration. I note
the following is not for e.g. concrete proposal, but for elucidating the related concepts.

As far as I see, this goes well with Tony's, Matthew's, and Steve's observations. So in
that sense too it does not mean to add new things, rather a new viewpoint.

Suppose Amazon has a seller of books. Suppose it has added a seller of furnitures which
obeys the same interactions. But suppose their *URLs* (channels) are different.  So Amazon
uses two instances of the same role. We want our description to be incremental, don't we?
So Amazon's business protocol as a whole adds this instantiation of the same role, with the
same interaction, only differing in their instantiations.

Suppose we have a business protocol with 101 dogs and a cat, each playing the role of, say,
a good dog. They are different participants, using different role instances (the tones of their
barking differ), but the role used is the same: only instantiations are different.

In object-oriented languages such as Java (and in fact in ML and other functional languages,
though in a different way), this can be represented easily. There are classes (roles). There are
their instances. Instances are created by constructors. Nothing difficult.

This is about binding: you know it already in Java. Consider:

class dog {
    String name;
    dog (String aName) {
        name = aName;
    }
}

This is the same thing as

class dog {
    String name;
    dog (String aNNName) {
        name = aNNName;
    }
}

In the constructor, aNNNname is bound. This simply says that there is something which should
be instantiated, of type String, and it becomes the value of a field "name". Instantiation is done
by:

    x = new dog (Tramp);

then a new instance is created and is stored in x.

I am not sure how this is usually represented in XML. I asked Steve and Gary, but there
seem no standard convention on this. Anyway we need a clear distinction among:

(1) roles  (dog above)
(2) act of instantiation of roles, using bound names and their instantiation.  (new... above)
(3) the result of (2), that is, role instances (what is referred by x above).

In general, it is better to distinguish (2) and (3). That is one of the reasons why we have
constructors in OOPLs. Another reason to distinguish (2) and (3) is to be concise.

Participants are often singletons, in the sense that Microsoft has only one instance, so their
instances may be less important. However, they are also good to have this distinction, if we
have occasions to wish  to make two or more participant instances based on the same
template. I am rather sure that inside a single protocol, you may not need two instances of
one participant ---- if a participant has any special meaning other than roles.

But this does not mean we should not allow designers to create participant instances. And
perhaps, you wish to use a generic participant in your protocol, such as a "Buyer", then
instantiating it is not  a bad idea. But then don't you want to have a participant whose definition
uses multiple participant instances? That is, when its instance is given, it will generate other
participant instances? You are a big company, and it has several organisations, and in the
protocol you use these organisations to interact. Or just as in your Java class called "car",
you use instances of a wheel, a tire, an engine, a light, etc.

And we can allow the same thing to a role. Inside a role of a complex buyer, it uses not only
a simple buyer but also a seller, an auctioner, etc. etc. again like the class of car, ....
So indeed we can dispense with participants, and have only roles, if we allow nesting of roles.

But in the design process of CDL, there has been a strong intuition which says a participant is
different from roles. That, I see as as quite important. As all know, a participant is given the
role  (sorry no pan intended) of an organisation, a principal representing an endpoint.

So, a role is just giving a name to a parameterised interactional behaviour: there is nothing
more than that.  A participant is the same, but we wish to give a special meaning to it, that
it is defining an organisation which uses (acts as) role instances.  Let's just consider

     a role = a class (for defining a communication behaviour)
     a participant = a class (but we give it a special meaning, we wish to name
                            an "organisation" or, to be precise, its template with this,
                            and its behaviour comes from role instances used by it.)

There is nothing mysterious here, let's think pragmatically, there is a named template and
we instantiate it to get something which "behaves" and "interacts" in some way. Having
that device is a novelty of Simula w.r.t. its predecessors.

A participant is a template for the code to represent an organisation, which uses zero or
more role instances of zero or more roles.  We only describe interactions through a role. 
An instance of a role and another instance of the same role should behave in the same
way, up to their difference in instantiated values. This is no different from classes and
their instances in OOPLs.

I do not think this is a big deal, *except* how the key action here --- instantiation ---
should be cleanly expressed in XML.  I do not understand XML's convention so much.
It still baffles me. This is the same problem as representing

    lambda x.x  (this is the lambda calculus, no need if you do not know about it..)

as well as

    M [3]

(M instantiated with 3) in XML. Surely we can do this, any BNF can be represented
in XML, but what is the most well-known, understandable way?

Once this is understood, there is a further point, which is how to have good economy
in description. Not meant for CDL as of now, but just to show all the good things
that can be done with instantiation: suppose you write, in a choreography, an interaction
of Tramp with Lady, and Jock's  interaction with Lady, both instantiations of a dog class.
The interactions however differ, reveal different aspects of a dog, so it is all right. But
suppose we have --- well, 101 dogs which are essentially identical, differing only in, 
well, URIs. Then perhaps you wish to describe only a protocol for one and omit others,
even if the choreography as a whole involve all 101 dogs?

kohei

Steve Ross-Talbot wrote:
       In the current WS-CDL schema a role type may only belong to one participant type. This means
       that the natural way of describing behavior is not readily supported in WS-CDL today. For
       example I might have a bank as a participant type that wishes to behave in the role of a
       trader. I might also have a broker that wishes to behave in the role or trader and a
       counterparty that wishes to do the same thing.

       To do this today I need to add to the role name something unique to the participant in order to
       model the different role types across the participant types.
       That is I cannot have the following:

           Participant Types:
               BankParticipant            (TraderRole)
               BrokerParticipant            (TraderRole)
               CounterpartyParticipant     (TraderRole)

       But I can have:


           Participant Types:
               BankParticipant            (BankTraderRole)
               BrokerParticipant            (BrokerTraderRole)
               CounterpartyParticipant     (CounterpartyTraderRole)

       While it is possible to model things as WS-CDL stands it does lead to a significant explosion
       in description because RoleTypes cannot be shared. The only reason for RoleTypes to be unique
       today is because all variables and conditions are projected through the RoleTypeName back to
       the ParticipantTypeName.

       In effect the nature of a ParticipantTypeName is more akin to an instance. It is half way
       between an instance and a binding to an instance and this is what has caused the problem to
       surface.

       What we need to be able to do is enable RoleTypeNames to be shared. This would require changes
       to the spec but would significantly add to the usability of WS-CDL in practice. The sort of
       changes that would be required would be to add the ParticipantTypeName to the CDL functions
       that take RoleTypeName and to do the same for variable declarations and any other conditionals.
       There may also be a need to change how we bind when doing a perform as this also takes
       RoleTypeNames.  I have not done a full sweep of the spec as yet.

       This may have an effect on the type system so we would need to pass this by our invited experts
       to ensure that we understand what effect it has if any.

       Cheers

       Steve T

Received on Thursday, 1 February 2007 15:43:00 UTC