RE: WS-A Issue 28 - Multiple ports needed in an EPR

It is a trade-off between complexity and simplicity.  We have found over
and over again that we cannot build the kinds of systems we'd like to
with just URIs.  We can build the systems we want with URIs + ref
properties (or in parallel incarnation of HTTP cookies).  Turns out not
having echoing capabilities is too simple.   

 

But I have a feeling that you aren't seriously suggesting dropping Ref
props.  Or are you?  Perhaps you are suggesting that your priority is:
1) multi-port EPRs; 2) URI only EPRs; 3) EPRs as they exist today wrt
ports/ref props?  This might now be the 2nd time that somebody has
proposed a mandatory or new feature that I've pushed back on, and the
counter-argument has been to remove an existing mandatory feature.  The
previous being the suggesting of making address optional if Service
Qname can't be made mandatory.  

 

I believe we can build multi-address structures on top of or using EPRs.
EPRs have extensibility that seem to enable things like EPRs within EPRs
even (similar to IOR Profiles?).  And many specs, like ws-rm and ws-rf
etc. are making their own structures that contain EPRs.  I find it
interesting that not many of those derived works have created a multi
address/port structure.  Perhaps there isn't much demand?

 

I agree that cases for multi-EPRs will require a spec and
interoperability tests and so forth.  The same argument goes for just
about every kind of functionality though.  There's a reason why the WS-A
working group isn't defining wsdl and metadataexchange and policy and
reliablemessaging and universal EPR lifecycle and pub/sub and uddi and
...  Our charter takes into account layering and picking the smallest
piece that delivers the most bang for the buck, sometimes called 80/20.
Now I also know full well that one person's 80/20 is another's
worthless/wasteoftime, so I hesitate to use it but it seems to fit in
this scenario.

 

I think it would make my users life more complicated by forcing every
EPR minter and user to have to deal with multi-EPR scenarios.
Obviously I could be wrong, but I do find the simplicity of EPRs to be
compelling.

 

I am interested in learning more about CORBA IORs and profiles though.
Could you send link(s) on them and their usage?  I also idly wonder how
many CORBA vendors/users would have wanted single profile IORs rather
than the current IOR design.  

 

Cheers,

Dave

 

  _____  

From: Vinoski, Stephen [mailto:Steve.Vinoski@iona.com] 
Sent: Saturday, November 06, 2004 1:54 PM
To: David Orchard; Martin Gudgin; Bergersen, Rebecca;
public-ws-addressing@w3.org
Cc: Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR

 

Hi Dave,

 

I understand the desire for simplicity. But if it's simplicity that you
want, why not forego the EPR entirely and use a URI? You stated your
opinion for why we need an EPR over just a URI in a separate thread. By
what criteria do you judge your need for an EPR rather than just a URI
to be acceptable, while judging our need for multi-address EPRs to be
too complicated?

 

Obviously you can raise all kinds of hypothetical complications
regarding multi-address or multi-mechanism services. In practice, it's
really not that complicated. Middleware has supported such constructs
for well over a decade now, the best example of which is probably the
CORBA IOR. IORs may consist of one or more profiles, where each profile
may contain a separate address, but all profiles in the same IOR "point"
to the same target object. In practice, most IORs consist of only a
single IIOP profile, but the flexibility for multiple profiles is there,
and it's amazingly handy when you need it.

 

If you want to keep the EPR simple, as you stated, are you instead
proposing that this WG also standardize some kind of composite EPR as
well? Because if this WG doesn't address the multi-address issue, then
the layering you're proposing will be strictly proprietary and
non-interoperable, and will proliferate the complication. I already
pointed out the problem with the layering approach in my reply to Gudge,
and that is that it just pushes the problem into the higher levels of
software where it has to be handled again and again and again, which
makes it less likely that it will be handled at all, which will result
in rigid inflexible systems that cannot deal with protocol, format, and
service evolution. Imagine, for example, if all IORs could contain only
a single profile. That would force all CORBA applications to be able to
accept sequences of IORs in all the places they would normally just
accept a single one-or-more-profile IOR. It forces all the complication
up into the applications. Do you really want to make your users' lives
more complicated?

 

--steve

	-----Original Message-----
	From: David Orchard [mailto:dorchard@bea.com]
	Sent: Saturday, November 06, 2004 3:31 PM
	To: Vinoski, Stephen; Martin Gudgin; Bergersen, Rebecca;
public-ws-addressing@w3.org
	Cc: Newcomer, Eric
	Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR

	Steve,

	 

	I agree that in some indeed many cases there may be a need for
multiple "addresses" for a service.  But don't we need an atomic address
at some point?  I think we do have a pretty good handle on what the
minimum is to address a single "thing".  I'd suggest that any kind of
multi-address construct can be layered on.  And there will be lots of
complexity: What's the order of precedence?  Are there any
commonalities, like policy across all the address?  Are there policies
specific to an endpoint?  Are there different bindings/required
properties per endpoint?  I propose that multi-address information
should be layered on top and EPRs remain as simple as we can keep them,
rather than pushing the multi-stuff into EPRs.

	 

	By analogy, I agree that molecules are great.  And sometimes
just atoms are the thing we want, like gold or oxygen.  The universe
deals well with both constructs, but they do have a layering/composition
model. 

	 

	Another saying I like for standards is "you know your standard
is successful when people go great, but can you add foo, bar, baz..".
That means it hit the minimum necessary for success.

	 

	Cheers,

	Dave

	 

	
  _____  


	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Vinoski,
Stephen
	Sent: Friday, November 05, 2004 1:50 PM
	To: Martin Gudgin; Bergersen, Rebecca;
public-ws-addressing@w3.org
	Cc: Newcomer, Eric
	Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR

	 

	Gudge, take a look at your own business card. Does it have your
address, work phone number, fax number, mobile number, email address,
instant message ID, and your home page all listed on it, or do you
actually have multiple business cards, one listing your address, a
separate one listing your work phone, another listing your email
address, etc.?

	 

	You seem to imply that an endpoint is accessible via only a
single transport and protocol. Where I come from, endpoints can be
accessed over any number of transports and protocols. Why limit an EPR
to describing only a single path to an endpoint? There is much
middleware prior art in exsitence that proves that such a limit is
completely unnecessary.

	 

	--steve

	 

		-----Original Message-----
		From: Martin Gudgin [mailto:mgudgin@microsoft.com]
		Sent: Thursday, November 04, 2004 2:35 PM
		To: Bergersen, Rebecca; public-ws-addressing@w3.org
		Cc: Newcomer, Eric; Vinoski, Stephen
		Subject: RE: WS-A Issue 28 - Multiple ports needed in an
EPR

		I take issue with the assertion "where there are
different protocols/transports/formats available for the same service,
the "access to a Web service endpoint" requires the client to choose
among alternatives". 

		 

		If I, the service, give you, the client, a single EPR
then as far as you are concerned, there is only one mechansim with which
you can communicate with me. So you don't need to make any choices (
except whether to communicate or not, I guess ). 

		 

		If I am available on multiple EPRs, then I'll provide
you with multiple EPRs (perhaps in a WSDL document), *then* you have to
choose one from the set.

		 

		Gudge

		 

		
  _____  


		From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Bergersen,
Rebecca
		Sent: 04 November 2004 11:53
		To: public-ws-addressing@w3.org
		Cc: Newcomer, Eric; Vinoski, Stephen; Bergersen, Rebecca
		Subject: WS-A Issue 28 - Multiple ports needed in an EPR

			Issue 28 - Multiple ports needed in an EPR

			 

			According to the ws-addressing submission,
"Endpoint references convey the information needed to identify/reference
a Web service endpoint, and may be used in several different ways:
endpoint references are suitable for conveying the information needed to
access a Web service endpoint...."  However, in the situation where
there are different protocols/transports/formats available for the same
service, the "access to a Web service endpoint" requires the client to
choose among alternatives, each accessible in the standard manner
through a port - but there are different ports for each
protocol/transport/format alternative.  When such alternatives exist,
the EPR must be able to identify those multiple ports.

			 

			Rebecca Bergersen
			Principal Architect, Middleware Standards
			rebecca.bergersen@iona.com
	
-------------------------------------------------------
			IONA Technologies
			200 West Street Waltham, MA 02451 USA
			Tel: (781) 902-8265
			Fax: (781) 902-8001
	
-------------------------------------------------------
			Making Software Work Together TM