This will work only for some of the configurations, but when it comes to
things like JMS REPLY_TO this wont help. And hence I believe the above
discussed approach still holds. I would like to post the design that I am
having in my mind;
Basically we can have a new TransportConfigurationBuilder and Serializer
interface from which all the transport specific configurations are build and
serialized, and there should be two factories to get the proper trp config
builder/serializer. Then when it comes to execution again there should be a
TransportConfiguration interface (or may be an abstract class) which will
set the required properties to the message context, and the particular trp
config instance that has been built from one of the trp config factories
will contain in the Endpoint declaration (for example AddressEndpoint) and
it can be used to do the transport configurations over the message.
(Basically composition)
WDYT?
Thanks,
Ruwan
On Fri, Jul 18, 2008 at 4:44 AM, Andreas Veithen <[EMAIL PROTECTED]>
wrote:
> Actually most of the transport settings that can currently be configured on
> endpoints or that we want to be configurable in the future would be
> configured in a WSDL using either policies or attributes on the binding. For
> example:
>
> * MTOM can be configured using the {
> http://www.w3.org/2007/08/soap12-mtom-policy}MTOM<http://www.w3.org/2007/08/soap12-mtom-policy%7DMTOM>policy.
> * The HTTP version can be set using the {
> http://www.w3.org/2004/08/wsdl/http}version<http://www.w3.org/2004/08/wsdl/http%7Dversion>attribute
> on the <binding> element (at least in WSDL 2.0).
>
> Assuming that Axis2 has complete support for this, there should already be
> an extension mechanism that allows to configure transport specific settings.
> I think it would be a good idea to try reusing this mechanism for Synapse
> endpoints. If we do this we could have configurations as the following one
> without having to code our own transport specific extensions:
>
> <endpoint>
> <address uri="..." whttp:version="1.0" xmlns:whttp="
> http://www.w3.org/2004/08/wsdl/http"/>
> </endpoint>
>
> WDYT?
>
> Andreas
>
>
> Quoting Ruwan Linton <[EMAIL PROTECTED]>:
>
> Sorry for being late in getting in to this. Am having some
>> connectivity problem and hence I am over my phone.
>>
>> +1 for paul's idea on transport specific configuration rather than
>> keeping these to generic properties. We need an extension to enpoind,
>> ep builders and serializers. Basically through a set of interfaces.
>>
>> I do have a complete design in my mind and will post it once i get the
>> connectivity through my machine :-)
>>
>> Thanks,
>> Ruwan
>>
>> On 7/17/08, Paul Fremantle <[EMAIL PROTECTED]> wrote:
>>
>>> Eric
>>>
>>> Excellent point about load-balanced/failover endpoints. +1.
>>>
>>> I think it would be very good to be able to set transport properties
>>> on an endpoint level. How about having some specific transport
>>> specific configuration elements:
>>>
>>> e.g.
>>>
>>>
>>> <http version="1.0|1.1" chunked="true|false">
>>> <proxy....>
>>> <accept....>
>>> </http>
>>>
>>> <jms....>
>>>
>>> We could build some extension model which allows settings for
>>> arbitrary transports to be added in a way that is natural for that
>>> transport, so we could later add <smtp> or <fix>.
>>>
>>> Paul
>>>
>>> On Thu, Jul 17, 2008 at 12:50 PM, Hubert, Eric <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> sounds like an interersting idea. We actually define it in exactly that
>>>> way
>>>> on an endpoint level in our custom "repository" and generate a
>>>> synapse.xml
>>>> containing the property mediator to set this property. It would be more
>>>> straightforward to be able to set this at the endpoint level. There one
>>>> should consider LoadbalanceEndpoints as a kind of container from which
>>>> "child endpoints" should inherit the defaults. Right now some properties
>>>> need to be specified at the individual endpoint level like suspend
>>>> duration
>>>> and timeout. Most of the time all endpoints of a loadbalancing group
>>>> should
>>>> be handled in the same way (either all http 1.0 or all http 1.1 etc.)
>>>> Just
>>>> a
>>>> thought…
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> From: Asankha C. Perera [mailto:[EMAIL PROTECTED]
>>>> Sent: Thursday, July 17, 2008 1:08 PM
>>>> To: [email protected]
>>>> Subject: Re: Making force HTTP 1.0 a part of the endpoint definition?
>>>>
>>>>
>>>>
>>>> Paul
>>>>
>>>> Infact I was thinking of the same thing.. and was suggesting to Ruwan
>>>> about
>>>> allowing properties to be set at an Endpoint level.. and the most useful
>>>> properties could be for HTTP 1.0. use of just the PATH instead of full
>>>> URL,
>>>> setting JMS reply destinations etc..
>>>>
>>>> asankha
>>>>
>>>> Paul Fremantle wrote:
>>>>
>>>> I'm generally against hard-coding transport specifics, but the high
>>>>
>>>> number of people running into trouble with HTTP1.0-only servers makes
>>>>
>>>> me wonder if its worth us adding a flag to the endpoint definition to
>>>>
>>>> force HTTP 1.0?
>>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Asankha C. Perera
>>>>
>>>> WSO2 - http://wso2.org
>>>> http://esbmagic.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and CTO, WSO2
>>> Apache Synapse PMC Chair
>>> OASIS WS-RX TC Co-chair
>>>
>>> blog: http://pzf.fremantle.org
>>> [EMAIL PROTECTED]
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>> --
>> Sent from Gmail for mobile | mobile.google.com
>>
>> Ruwan Linton
>> http://wso2.org - "Oxygenating the Web Services Platform"
>> http://ruwansblog.blogspot.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
