On Sun, 2005-11-27 at 18:09 +0000, Paul Fremantle wrote:
> Personally I think it makes sense to have two distinct endpoints. I
> also think it makes sense to have more than one class. I don't care
> that much how many servlets - tho to be honest I think if there are
> two different endpoints with different behaviours then people who
> don't know the system well will find two servlets clearer and easier
> to manage, deploy, and secure.
>
> For example I may wish to have very different security for REST than
> for WS if I am using WS-Sec for WS and HTTPS+Client Certs for REST.
Let's make sure we're all on the same page w.r.t. the functionality.
There are two independent protocols/formats being supported here:
1. SOAP, with both POST and GET (for SOAP Response MEP support)
2. XML over HTTP, with both POST and GET (and potentially other
HTTP methods) per the WSDL 2.0 HTTP binding rules
If I read the SOAP Response MEP [1] stuff correctly, its impossible to
tell the difference between a SOAP Response MEP request and an HTTP GET
with some query params as in (2).
If that's indeed the case then this debate is over: we MUST have two
endpoints. It also settles the debate over the # of servlets: we MUST
have two servlets as the logic is conflicting.
Also, when we do support the SOAP Response MEP, I *think* we'll have to
lose the functionality of browsing to the service EPR and seeing a
simple and nice Web page describing the service. That sucks, Am I
missing something?
On a related note, can we stop forcing people to use /services/* for the
service names? I noticed that SteveL finds that not acceptable and I
imagine that there will be many places where the admin wants to map some
other URL path to get to the Axis2 SOAP servlet. I can't think of any
particular reason that that mapping cannot be user settable.
Sanjiva.
