RE: [business-transaction] Re: [bt-spec] URIs and address-as-X (MAJOR)

[Peter Furniss <peter.furniss@choreology.com>]

Jim,

> -----Original Message-----
> From: WEBBER,JIM (HP-UnitedKingdom,ex1) [mailto:jim_webber@hp.com]
> Sent: 28 January 2002 20:04
> To: Peter Furniss
> Cc: BT - spec
> Subject: RE: [business-transaction] Re: [bt-spec] URIs and address-as-X
> (MAJOR)
>
>
> Hey Peter:
>
> > is there one, opaque, Identifier for the
> > transaction/inferior/etc and the location information is
> > separate or several, each containing location information.
>
> I think each identifier should be able to resolve to an endpoint
> irrespective of the "supporting literature."

I think no identifier should be expected to be resolved to any endpoint by
any means.

> > We really meant *any* URI, from *any* scheme, URL or URI,
> > just provided it obeys the rule that it is a globally
> > unambiguous identification for the state, and recognised
> > where the (separate) addresses take you.
> >
> > So, since I knew somewhat of them at one time, using arjuna
> > guid's directly, with an appropriate short prefix
> > (urn:hp:xts:24823943:42304208:2409234:42342
> > ? :-) would be a possibility.
>
> Yes, if you so chose. Of course this is a proprietary binding that is only
> published inside the Arjuna lab, so it won't be much use to anyone else.

No, on our scheme you would use that in a fully interoperable exchange. The
identifier is independent of the binding. It is used only to identify the
state (not the communication endpoint). The address(es) define an
endpoint(s) where the state can be found, using the identifier.

> BTW someone in marketing decided to change its name to WST :-)
>
> > Then the addressing fields can be left to themselves, and the
> > binding-address almost certainly would be a regular URL, just
> > waiting to be dropped into your soap toolkit.
>
> Eh? Only if I then decide to take my proprietary Arjuna bindings
> and mangle
> them into some other scheme. The URN you describe above is valid in my
> domain.

on our scheme the addresses are purely binding related, so, as in 0.9.1, for
soap http, an example address might be:

	<btp:address>
           <btp:binding>soap-http-1</btp:binding>
           <btp:binding-address>
	        http://client.example.com/soaphandler
	    </btp:binding-address>
		<btp:additional-information>
		   testfour
		</btp:additional-information>
       </btp:address>


> (whereas
> > btp-soap-http-1://pluto.acme.com/sdfsd/fskdlf?940238:349204:32
> > 943:342432 has to be mangled, and the binding specification
> > has to say how)
>
> Yes and the he supporting logic has to concur. Your SOAP-over-HTTP service
> has a known endpoint which might well be what you've written
> above. How the
> information gets from the wire up to your service is the business of
> whatever you've built the service on, according to the bindings you've
> picked.

Don't worry about the place the address belongs to - it can make its address
and its logic align how it pleases.  Worry about the sending side, which
must take the address (our scheme) or URI (your scheme) and work out what
goes where in what protocol.  The address above, and the rules on addresses
are defined as - put the additional-information in the message (special
rules for relatedgroup, which is treated as a unit for this purpose),
combine any number of messages with the same binding address in a bundle;
put the bundle in SOAP header or body on an http request (or, defined
circumstances, response) in accordance with various rules.   For your
scheme, btp-soap-http-1 specification has got to say the equivalent of all
that, plus  something about splitting the URI to find the http bit. (your
scheme can merge additional-information and identifier proper)

> However, that is a concrete example of a URI in use. If the spec does not
> try to legislate over what's a valid URI in the abstract sections, then
> what's the problem? Of course in a concrete binding, we (or someone else
> interested in creating a binding) will have to make some
> decisions on this,
> but c'est la vie.

Yes - your approach may simplify the presentation of the abstract message
set, but it greatly complicates the specification of the binding, including
the soap/http binding we are including.

Peter