I think there are also other aspects of HTTP, for example, that won't
be covered by the WSDL2.0 binding.
For example, the use of a proxy, or choice of chunked encoding, etc.
I like the idea of using WSDL2.0 binding information, but I also like
the idea of a simple element defined by us capturing everything fairly
concisely! Maybe there is a balance?
One thing we could do is look at the wsdl2.0 http binding and at least
make sure we support everything there - e.g. Method, headers, etc.
Paul
On Fri, Jul 18, 2008 at 9:16 AM, Ruwan Linton <[EMAIL PROTECTED]> wrote:
> 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 policy.
>> * The HTTP version can be set using the
>> {http://www.w3.org/2004/08/wsdl/http}version 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/
--
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]
