Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950703171405x1dce85b0o12f07060e77e9e9b@mail.gmail.com>
Date: Sat, 17 Mar 2007 17:05:23 -0400
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: [PROPOSAL] Client and Conduit changes
In-Reply-To: <04c701c7686d$acaab0e0$8014a8c0@XPWork>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_90733_25465400.1174165523612"
References: <7b774c950703161519s51ff4744p3ee53ac638dd13bc@mail.gmail.com>
	 <04c701c7686d$acaab0e0$8014a8c0@XPWork>

------=_Part_90733_25465400.1174165523612
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I don't think I am the best person to summarize them, but I believe Eoghan's
objections are

1. A Client should not require a Conduit. Hence, we should get rid of
get/setConduit on Client.

2. It is the responsibility of the Conduit to manage the decoupled endpoint.
We should introduce a ClientPolicy object to deal with this instead:

Client.getPolicy(ClientPolicy.class).setDecoupledEndpoint(endpoint);

3. We shouldn't be forced to use a Client for decoupled interactions

I'll let Eoghan make a proper argument for his proposal before I respond...

- Dan

On 3/17/07, Ted Neward <ted@tedneward.com> wrote:
>
> Can you summarize the arguments *against* this proposal? Arguments for
> without arguments against sort of skews the perception pretty strongly....
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: Friday, March 16, 2007 3:20 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: [PROPOSAL] Client and Conduit changes
> >
> > For those of you who haven't been following the long discussion Eoghan
> and
> > I
> > have been having, I'm going to take a moment to summarize my proposal
> > here.
> > I consider it rather important. If we don't reach any consensus on the
> > proposal (it sucks/doesn't suck) or if Eoghan & I are the only ones who
> > participate, I'll probably start a vote. So do your communal duty and
> > participate so I don't have to do that! :-)
> >
> > I propose the following:
> >
> > 1. API to set an Asynchronous EndpointReference
> > I believe we should create a simple method on the Client which allows
> the
> > user to specify the asynchronous endpoint that they wish to have used
> for
> > decoupled responses:
> >
> > Client.getAsynchronousEndpoint(EndpointReferenceType epr);
> >
> > The Client would check to see if this EPR was set. If so, it would call
> > DestinationFactory.getDestination(epr) for the EPR and use that as the
> > asynchronous destination. This would result in a standard way to
> > automatically set up the decoupled destination when using the API.
> >
> > While it has been said that this isn't generic enough for JMS, I don't
> > agree. First, I believe that JMS will eventually get a self contained
> IRI
> > format which can be stuck in an EPR. We could even create our own
> > proprietary format. Second, JMS is an edge case. There are other
> > transports
> > beside just JMS and HTTP, like XMPP or TCP or FTP which work just fine
> > with
> > URIs. JMS is the odd ball in the sense that historically it has needed
> > stuff
> > outside the EPR.
> >
> > 2. Access to the Conduits and Destinations
> > I would like to add the following methods to the Client:
> >
> > void setConduit(Conduit) - this allows a user to easily specify an
> > alternate
> > Conduit.
> > void setAsynchronousDestination(Destination) - this allows a user to
> > easily
> > specify a decoupled endpoint. It's address would be used for
> WS-Addressing
> > interactions. If no Async destination exists, then the Client will only
> > listen on the Conduit.
> > Destination getAsynchronousDestination() - utility method to easily get
> > the
> > asynchronous destination
> >
> > 3. Client.close();
> > We need a way to shutdown the decouled endpoints (regardless of whether
> or
> > not #1 & #2 are adopted). I think there is pretty good conensus we need
> a
> > Client.close() method which will do this. It will call
> > getConduit().close()
> > and getAsynchronousDestination().shutdown().
> >
> > (Ideally we'd like to be able to shut down RM at this same time. I'm
> going
> > to guess that this would require the addition of a client lifecycle
> > interface which allows RM to listen for Client.close(). This is an issue
> > no
> > matter which route we go though, so I'll defer this conversation for
> > another
> > thread)
> >
> > 4. Remove the setup of decoupled destinations from inside the Conduit
> > Currently, the Conduits are responsible for setting up the decoupled
> > destinations. We've already got a perfectly good API for creating
> > destinations, lets use it! Creating another API to create decoupled
> > destinations introduces inconsistencies into our APIs. Right now if you
> > want
> > to create different endpoints for receiving ReplyTos and FaultTos you
> have
> > configure the ReplyTos using the Conduit API and the FaultTos using the
> > destination API. Creating those endpoints in different ways is bad IMO.
> >
> > Putting in decoupled destinations inside the Conduit also makes it more
> > complex for transport writers or people trying to understand the API.
> IMO,
> > people intuitively expect this to be outside the Conduit class.
> >
> > 5. Client Configuration
> > I would propose that we make the decoupled destination configuration
> part
> > of
> > the Client
> >
> > <jaxws:client id="...SomePort">
> >   <jaxws:asynchronousEndpoint>
> >     <wsa:Address>http://my.decoupled/endpoint</wsa:Address>
> >   </jaxws:asynchronousEndpoint>
> > </jaxws:client>
> >
> > <jaxws:client id="...SomePort">
> >
> >
> <jaxws:asynchronousDestination><http:destination...></jaxws:asynchronousDe
> > stination>
> > </jaxws:client>
> >
> > As an added bonus, we can now wire together clients and destinations
> > however
> > we want. I wouldn't *have* to create a <conduit> config element with the
> > port name inside it. Instead I could simply do:
> >
> > <jaxws:client id="...SomePort">
> >    <jaxws:conduit> <http:conduit... /> </jaxws:conduit>
> > </jaxws:client>
> >
> > It also creates a central place to embed Client configuration - such as
> > enabling MTOM or configuring WS-*:
> > <jaxws:client id="...SomePort">
> >    <jaxws:conduit>...</jaxws:conduit>
> >    <jaxws:binding mtomEnabled="true">
> >      <jaxws:requestContext>
> >        <map><entry key="javax.xml.ws.session.maintain"
> > value="true"/></map>
> >      </jaxws:requestContext>
> >    </jaxws:binding>
> >    <jaxws:features>
> >      <wsrm:reliability timeout="10000" .../>
> >    </jaxws:features>
> > </jaxws:client>
> >
> > Users could still use the <http:conduit id="PORT"/> syntax if they
> wanted
> > to
> > though.
> >
> > (Note: I haven't written the jaxws:client Spring schema yet, but its on
> my
> > todo list. The feature stuff will hopefully be part of my commit with
> > WS-Security)
> >
> > 6. Bring back Destination.getDestination(EndpointReferenceType)
> > This method would be needed for the API that I propose in #1.
> >
> > 7. Make the JAX-WS dispatch use the client.
> >
> > ----
> >
> > In summary:
> > a) This simplifies the API. We've created an API to set up decoupled
> > endpoints easily. We've reduced the complexity inside Conduits and have
> > avoided introducing new complexity onto the Conduit interface to specify
> a
> > decoupled destination.
> >
> > b) It creates a consistent API for working with decoupled endpoints.
> There
> > is no reason to go writing a new API for setting up decoupled endpoints
> -
> > which is only used sometimes.
> >
> > c) Dependency Injenction: By putting the Conduit & Destination on the
> > Client
> > we've made it much friendlier to people using Spring or other DI
> > containers.
> >
> > d) Improved configuration: I think the jaxws:client is a more natural
> > place
> > to setup the conduit and destination configuration as opposed to nesting
> > the
> > destination configuration inside the conduit.
> >
> > e) Setting up decoupled destinations is not the job of the conduit IMO.
> > We're giving Conduits a dual task unnecessarily. If all Conduits share
> the
> > same code for setting up decoupled destinations, that is a sign to me
> that
> > we can take it out of the Conduit.
> >
> > I of course would be volunteering to do all this work.
> > --
> >
> > Alternatives: While Eoghan can elaborate, I believe he would rather see
> > 1. The decoupled endpoint remain part of the conduit. He views a
> decoupled
> > endpoint as part of the Conduit contract.
> > 2. An API on the Conduit to set up the decoupled endpoint like so:
> > Client.get(Conduit.class
> > ).getClientPolicy().setDecoupledEndpoint(EndpointReferenceType)
> > 3. The Client.getConduit/setConduit methods go away and have the Conduit
> > be
> > an optional part of the Client
> > 4. No Client.setAsynchronousDestination method.
> > 5. Keep the decoupled endpoint configuration as part of the conduit
> > instead
> > of the client.
> >
> > Regards,
> > - Dan
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.446 / Virus Database: 268.18.11/722 - Release Date:
> 3/14/2007
> > 3:38 PM
> >
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.11/722 - Release Date: 3/14/2007
> 3:38 PM
>
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

------=_Part_90733_25465400.1174165523612--