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]
