Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of davanum@gmail.com designates
 64.233.170.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tEEwE72zYDfGKuXseKNs7EEAuPviYR+omP6XawUohZAdh4EaiggRxgNYG+DBzjYeLtVM3l7bC7d0yHZff81Vpv7F7qH1WqsVXpJ+p5WVeX4kIDZXqR/h8qru6IjYUpnIkRkyK0p90YfREORmfFD+kufP65H0lP/0VJrUbnZu14k=
Message-ID: <19e0530f0805120850g7ea93ce6q86ecea5719f5d88c@mail.gmail.com>
Date: Mon, 12 May 2008 11:50:01 -0400
From: "Davanum Srinivas" <davanum@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Generating a wrong port address for POJO deployment
In-Reply-To: <b72c94b30805120753tc8f0e37gb47f2ffa28f8fa75@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4823ED0C.9080205@gmail.com>
	 <b72c94b30805100949j57cec30bl96ef9e953b3512c9@mail.gmail.com>
	 <4827EE9C.2090408@opensource.lk> <48280E53.1090404@gmail.com>
	 <4828155F.90601@gmail.com> <48282464.3050901@gmail.com>
	 <19e0530f0805120518o61b24a29uc8e24d56cd89eaff@mail.gmail.com>
	 <b72c94b30805120753tc8f0e37gb47f2ffa28f8fa75@mail.gmail.com>

Keith,

That would be good, but remember the JAXWS services don't have
service.xml's :) they specify the expected service name in the
annotation.

-- dims

On Mon, May 12, 2008 at 10:53 AM, keith chapman <keithgchapman@gmail.com> wrote:
> Dims,
>
> How about making it flexible. Introduce a service.xml property where you can
> set a aliases for the endpoint urls? We may need three properties for the
> tree default bindings. That way the user can have very nice URLs...
>
> Thanks,
> Keith.
>
>
>
> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas <davanum@gmail.com> wrote:
> > Sanka,
> >
> > for one thing, i haven't seen anyone else use it. another thing, makes
> > it *slightly* more difficult for interop work and for tck work. It
> > also makes it more difficult for people who want to design their own
> > URI's for their web services and need complete control (yes, there are
> > a few of those!). Yes, we can shove it down their throats, but that
> > does not mean we should...
> >
> > thanks,
> > dims
> >
> >
> >
> >
> > On Mon, May 12, 2008 at 7:05 AM, Sanka Samaranayake <ssanka@gmail.com>
> wrote:
> > > Deepal jayasinghe wrote:
> > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >    When I deploy a very simple POJO service it generates
> following
> > > as
> > > > > > >    the service section in WSDL. As I know this is not nice and
> we
> > > > > > >    need to fix this as soon as possible.
> > > > > > >  Why is it not nice? This gives us the ability to apply binding
> > > level security correctly which is not possible with the endpoint
> addresses
> > > we used to have.
> > > > > > >
> > > > > > As I replied earlier , you can figure out the SOAP version from
> the
> > > SOAP message , so you do not need to send the SOAP version in the end
> point
> > > address.
> > > > > >
> > > > >
> > > > > Why do you say it is redundant  code?  Previously we had
> > > http://localhost:8080/axis2/services/foo as the SOAP 1.1 and SOAP 1.2
> > > binding endpoints. Now say that client picks the SOAP 1.1 binding
> endpoint
> > > and accidentally sends SOAP 1.2 request.
> > > > >
> > > > IMO which is wrong. If he picks 1.1 then should send a 1.1 request.
> > > >
> > >
> > >  That is exactly my point. If he picks SOAP 1.1 then you *should* send a
> > > SOAP 1.1 request. If he sends a SOAP 1.2 request we *should* throw an
> > > exception saying incorrect SOAP version. Earlier we were *not* doing
> that
> > > because we had the *same* endpoint address for both bindings. However
> now we
> > > can do that because by looking at the endpoint we can decide the exact
> > > binding which the client has picked.
> > >
> > >
> > >
> > >
> > > >
> > > > > Here the right thing would be to throw an exception saying incorrect
> > > SOAP version where as Axis2 server won't complain which IMO is a bug.
> Now if
> > > you use http://localhost:8080/axis2/services/foo.SOAP11Endpoint as the
> SOAP
> > > 1.1. binding endpoint we can do a prior evaluation of the request and
> throw
> > > an exception if we receive a SOAP 1.2 request which IMO is the correct
> > > behavior.
> > > > >
> > > > Only problem I have is having the SOAP11Endpoint name in the address ,
> > > >
> > >
> > >  Please explain why do you have a problem with [service].[port] format ?
> > >
> > >
> > >
> > > > I do not mind sending that as some where else.
> > > >
> > >
> > >
> > >  Where would you suggest that we should have the port name s.t. we can
> > > decide the intended port (or the binding) of the request and do throw an
> > > exception if the client has sent a SOAP 1.2 request by error where he
> would
> > > have actually intended the SOAP 1.1 endpoint ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > >
> > > > > I know that the structure of endpoint address is important that it
> is
> > > something that we should not be mess around. That is the exact reason
> why I
> > > posted[1]  it to developer mailing list. However I think we should be
> > > flexible enough to change what we agreed on if there are valid reasons
> to do
> > > so and if we don't lose anything by doing it.
> > > > >
> > > > > One reason for using [service].[port] would be that it allows the
> server
> > > to do prior evaluations of SOAP requests hence make it less error-prone
> (As
> > > I mention in my earlier)
> > > > >
> > > > > Another reason would be that [service].[port] format makes lot of
> sense
> > > if we want to support multiple policy alternatives scenario at the Axis2
> > > server-side. Lets say a service requires strong authentication, but
> gives
> > > the client multiple options of  SSL mutual authentication, username with
> a
> > > signature, SAML with a signature or Kerberos. It does it via a policy in
> the
> > > services.xml which contains an alternative for each scenario.
> > > > >
> > > > > Now one option would be to do some processing of the request to
> figure
> > > out the option the client has chosen and then do a complete evaluation
> > > against that policy alternative. But it can be very expensive depending
> of
> > > the complexity of each policy alternative and of cause the number of
> policy
> > > alternatives which service exposes. Further there is a possibility that
> some
> > > policy alternatives are indeterminate by only looking at the request.
> > > > >
> > > > > The other option would be to generate multiple endpoints s.t. each
> > > endpoint would correspond to exactly one policy alternative during the
> > > deployment time.
> > > > >
> > > > > e.g.
> > > > >
> > > > > <wsdl:service name="Version">
> > > > > ....
> > > > >   <wsdl:port name="VersionHttpSoap11EndpointWithSSL"
> > > binding="ns:VersionSoap11Binding">
> > > > >       <soap:address
> > >
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSL"/>
> > > > >    </wsdl:port>
> > > > >    <wsdl:port
> name="VersionHttpSoap11EndpointWithUsernameAndSignature"
> > > binding="ns:VersionSoap11Binding">
> > > > >       <soap:address
> > >
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithUsernameAndSignature"/>
> > > > >    </wsdl:port>
> > > > >   <wsdl:port name="VersionHttpSoap11EndpointWithSAMLAndSignature"
> > > binding="ns:VersionSoap11Binding">
> > > > >       <soap:address
> > >
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointSAMLAndSignature"/>
> > > > >    </wsdl:port>
> > > > >   <wsdl:port name="VersionHttpSoap11EndpointWithKerberos"
> > > binding="ns:VersionSoap11Binding">
> > > > >       <soap:address
> > >
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSLWithKerberos"/>
> > > > >    </wsdl:port>
> > > > > .....
> > > > >
> > > > > </wsdl:service>
> > > > >
> > > > > That way we can straight way say the option client as picked and
> > > evaluate the quest based on the target policy alternative with IMO is a
> > > better way of supporting multiple policy alternatives at the
> server-side. We
> > > need to use [service].[port] format if we are to implement the support
> for
> > > multiple policy alternatives feature.
> > > > >
> > > > Thank you so much for such a descriptive mail. I will think though and
> > > send a reply soon..
> > > >
> > > > -Deepal
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >  --
> > >  Sanka Samaranayake
> > >  WSO2 Inc.
> > >
> > >  http://sankas.blogspot.com/
> > >  http://www.wso2.org/
> > >
> > >  ---------------------------------------------------------------------
> > >
> > >  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >  For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
>
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org


-- 
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org