OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-bp] Submission of a research paper introducing a new model for Multi-party collaobration




JJ> I think I support this case (using onInitiation)

	If by simply making the Multiparty and Binary different in only
the number of roles we can achieve this I feel we should go for it.

Dale> Definitely agree that we should view Multiparty and Binary as
specializations, differing in multiplicity of Roles mainly.


JJ> the real issue is the CPPA. Dale do you have an opinion on how the
CPPA will work in that case and how realistic it is to change it?



I think that if the connection of Role values is made clear so that we
can always find which Roles go with the underlying BusinessTransactions
(which so far only involve two parties at a time), then CPA can find the
Service, Action, and Role values it needs to identify for the ebXML
Messaging header.This involves connecting our Action to BTs (or more
explicitly the Requesting- or RespondingBusinessActivity

If that Messaging header changes, we CPPA would need to revisit the
entire question, of course. I also suspect we may need to add something
to ActionContext to explain how to find the flow reference point where
the reference to the BT is embedded. We also need to make it clear that
when we bind DeliveryChannel details to Actions, we are always binding
the BTs in context.

Ultimately I think we will also need to change our mapping of where we
obtain the values of Service and Action. I think the original alignment
was based on very early BPSS versions and is looking increasingly
strained as BPSS matures. 

Actually at the moment I am most concerned about being able to find the
Role values appropriate for the BTs in all cases. This is where I think
things have been and remain too implicit. We need explicit syntactical
constructs to locate the right values, so that we can formulate rules to
explain to implementers where to find the governing Role values.

Then I think we can  be indifferent to BPSS flow containers (such as
MultipartyCollaboration, BinaryCollaboration, and CollaborationActivity)
except for the ActionContext. I will need to ask Hima how ActionContext
should be changed as Arvola and Hima were the main designers of the
current approach. 

Of course, all this needs to be considered by the CPPA TC as a whole.
Fortunately most CPPA TC members also follow BPSS or are members.

The 2.0 alignment of BPSS and CPPA will probably need a CPPA 2.x update
document. I do not think it is realistic for BPSS 2.0 or 3.0 to be
constrained so that they fit the current CPPA 2.0 spec. BPSS needs to
get the fuzz removed, and CPPA can issue an alignment update.

With luck, not much will need to change really. With luck, the main work
will probably be with ActionContext. We might also reconsider in New
Orleans how Service and Action values should be aligned with BPSS.next.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]