Re: [bt-spec] feedback for BTP draft spec version 0.9.0.2

[Alastair Green <alastair.green@choreology.com>]

Hi Pyounguk: comments on your comments on conformance

In my view (I wrote it, so I would say this) the conformance section is fine apart from

1) the failure to specifically mention that bindings must be included in any statement of capability by an implementor

2) the failure to specify that an implementor could be expected to produce a statement of capability as a matrix:

roles x bindings

with perhaps an example of such a statement.

For example, the Choreology Cohesions 1.0 product will state "All roles times SOAP-over-HTTP binding", I believe. We will likely add a non-standard Java RMI binding and I find it difficult to believe someone won't press us to come up with a faster, leaner encoding some time soonish ...

On the specific question --

> >   
> > line 4402 - 4428 :
> >    
> > Role Groups should be better defined. For instance, what's the difference
> > between Cohesive Hub and Cohesive Superior? Is there any better scheme
> > to define BTP conformance model?
> > PF:
> > conformance is an open issue, but no-one has come up with alternative text
> > yet.

Here is the definition of Cohesive Hub

Factory
Composer (as Decider and Superior)
Coordinator (as Decider and Superior)
Sub-composer
Sub-coordinator
 
Here is the definition of Cohesive Superior

Composer (as Superior only)
Coordinator (as Superior only)
Sub-Composer
Sub-coordinator

(reordered to make comparison easier).

If you will pardon me saying so, the difference is the difference.

A Cohesive Superior is not an interoperable Factory, nor does it require support for the Decider aspect or interface of a Coordinator/Composer. It's what you would implement if you weren't trying to do interoperable Terminator:Decider and Initiator:Factory relationships. Of course, it will have to have an API of some kind to provide access to those capabilities in some other form (but then it's in the hands of the implementor which methods are invoked on which objects to create coordinators and instruct them to try to confirm etc etc -- that is none of our business as specifiers of the interoperable).

Bear in mind that Role Groups and Conformance Profiles are only conveniences for grouping roles. You can state any meaningful subset of roles that you like, in longhand, one by one.

My largest point on this would be: there is no sensible alternative that I can see to using roles to define capabilities. I can create all kinds of sensible partial implementations using roles, because those are the granules of the spec -- they are the clots of contractual obligation. I can't see why you would want to be more restrictive, because any restriction on the statement "I support the following roles ..." is ultimately unenforceable and undetectable. The most you could do is work out which roles cannot be implemented in isolation. For example, you cannot implement Decider without implementing Superior, but I think that is covered by the definition of a Decider as a specialized (extended) Superior. Off hand I can't think of any role that is incapable of implementation in isolation. You could enrol someone else's Inferiors for example. It would be pretty peculiar, but no-one could stop you, and I'd never know the difference if I were the the Superior on the receiving end.

The idea of the Role Groups and Conformance Profiles was, of course, to be a bit less bloody-minded than the purist view expressed in the preceding paragraph, and make it easier for vendors and customers to discuss their likely requirements, and for deployers to discuss their ability to joint their services.

Yrs,

Alas.

begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard