On 3/17/07, Johnson, Eric <[EMAIL PROTECTED]> wrote:
I've been trying to follow the thread about this stuff, but was getting lost in the details. This is a great way to bring clarity. I'd be very interested in hearing Eoghan's alternate proposal-or rebuttal. I've commented in-line. > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: Friday, March 16, 2007 6:20 PM > To: [email protected] > 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. Just because JMS is the only current edge case I don't think it should be dismissed so lightly. There are other possible transport impmentations that will need information outside the EPR.
The only way to address this is casting to some specific JMS class. In Eoghan's case, I believe he is suggesting that there be a JMSConduitPolicy class which extends ConduitPolicy which people can use to set up the decoupled information. To quote him: "Other transports would also extend ConduitPolicy with their own client policy type if necessary and could I guess add any additional info they need (thus neatly solving the JMS issue). The generic ConduitPolicy could be exposed via the AbstractConduit. Then programmatic approach (as used for example in the RM SequenceTest) could then also become generic (i.e. call AbstractConduit.getConduitPolicy() as opposed to HTTPConduit.getClient() to get a hold of the policy object)." Unless I'm completing misinterpreting him, this would become something like: EndpointReferenceType epr = ... create your EPR; JMSConduitPolicy policy = new JMSConduitPolicyImpl(); policy.setDecoupledEndpoint(epr); // configure JMS settings on JMSConduitPolicy client.setPolicy(ConduitPolicy.class, policy); I'm suggesting that people simply cast to JMSDestination instead of introducing more APIs. i.e.: EndpointReferenceType epr = ... create your EPR; DestinationFactory factory = ... get DF from Bus; JMSDestination dest = (JMSDestination) factory.getDestination(epr); // configure JMS settings on JMSConduitPolicy client.setAysnchronousDestination(dest); Either way you can't really get around that JMS needs custom settings that aren't very amenable to the EPRs. I just don't see why we want to invent another API (i.e. the ConduitPolicy classes) to manipulate those settings when we've already got a perfectly good Destination API to do that for us. Especially when we're telling users that if you want to set up other destinations that you need to use the Destination API and not the Conduit API. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
