Paul,
What is actually the level of support for WSDL2.0 binding information
in Axis2 and where can the related code be found?
Andreas
On 18 juil. 08, at 10:26, Paul Fremantle wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
