axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajith Ranabahu" <ajith.ranab...@gmail.com>
Subject Re: [Axis2] Generating a wrong port address for POJO deployment
Date Wed, 14 May 2008 21:28:44 GMT
Hi all,
I'm mostly an observer in this one  (and I honestly don't think that the
format of the URL matters as long as it is a valid url). Here are some
thoughts

1. It seems that this change is sensible in terms of endpoint policy
attachment. Some implementations don't do that right now but my guess is
they would have a adopt a similar mechanism to support this feature [at
least I don't see how else can you do this]. If we remove this behavior (for
the sake of simplicity / readability / may be to become 'less whacky' :)) I
suppose the endpoint policy attachment capabilities go down the drain! [
Sanka - What does it mean to support end point policy attachments ? I mean
is it a necessary condition to claim that we support WS-Policy ? { my
understanding is 'yes' but I am not a policy expert }]. Again it does not
make sense to have multiple bindings and not having seperate endpoints to
independently access each of those.

2. If you add an alias endpoint that serves more than one binding (I think
Saminda suggested this) I don't see a problem apart from the redundancy.
IMHO redundancy of the endpoint reference is a small price to pay. The
policies can still be attached to the EPR's and if you guys think that
things may become complex, we can leave these alias EPR's without policies.
That way the policy binding gets activated only if people use the specific
EPR.

3. If the previous suggestion is too much (in terms of user confusion
factor. There will be a number of EPR's listed for codegen and it is very
much likely that we get a complaint about the long list of EPR's!) the next
thing I can think of is to add a parameter to Axis2.xml like
"generateReadableEPRs" so that this behavior can be customized. It is
another debate whether to set this true by default or not but its a good
enough compromise to me.

Ajith

On Wed, May 14, 2008 at 2:37 AM, Sanka Samaranayake <ssanka@gmail.com>
wrote:

> Hello Everyone,
>
> Please find my comments inlined.
>
> [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg26438.html
> [2] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
>
>
>
> Daniel Kulp wrote:
>
>>
>> Dims,
>>
>> On May 12, 2008, at 11:59 PM, Davanum Srinivas wrote:
>>
>>> I was talking about moving JAXWS services and clients across
>>> implementations. Not on the wire interop. Sorry it was not clearer.
>>>
>>
>> I'm not sure how that applies here.   Axis2 is the only JAX-WS
>> implementation that does this funky Endpoint.Port URL thing.
>>
>
> We had this feature implemented in Axis2 sometime back[1] and most of the
> concerns raised once the new endpoint format started to show in the
> generated WSDLs. Honestly I'm not bothered whether we use [service].[port]
> or [service]/[port] if the latter looks more appealing. My real concern is
> that if we switch back to previous format we will lose the only viable
> implementation to support multiple policy alternatives at the server-side. I
> would really like to hear another way of doing it if anyone can suggest.
>
>
>  CXF certainly does not and neither does the reference implementation.
>>
>
> Neither does CXF nor reference implementation support policies with
> multiple alternatives at server-side, AFAIK.
>
>    Both of them use a deployment descriptor thing to allow the user to
>> specify the full URL that the service is deployed on.
>>
>
> We should be able to provide a set of parameters in the services.xml which
> supply alias to [service].[port] from which we can have more appealing  URLs
> for the service. I am not a JAXWS expert but can't we do something similar
> for JAXWS services via annotation?
>
>
>> The fact that Axis2 does this wacky thing actually made it HARDER for the
>> tck stuff as Jarek had to do a bit more work to deal with the different
>> URL's that Axis uses compared to CXF and the RI (both of which use the same
>> URL's).
>>
>
> I'm bit confused. If Jarek had used the endpoint addresses from the
> generated WSDLs, then it would have been a matter of copying and pasting ..
> isn't it? If he didn't use the WSDLs, why couldn't he use the older format
> of service endpoints ?  Or am I missing something ?
>
> Thanks & Regards,
> Sanka
>
>
>
>> Dan
>>
>>
>>
>>
>>>
>>> thanks,
>>> -- dims
>>>
>>> On Mon, May 12, 2008 at 11:56 PM, Amila Suriarachchi
>>> <amilasuriarachchi@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>>
>>>>
>>>> I don't have any experience with the tck. But I think it should not have
>>>> a
>>>> problem with the
>>>> interop. please see this wsdl
>>>> http://131.107.72.15/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl
>>>>
>>>> This is a wsdl from .Net interop site. They generate different ports for
>>>> different bindings and if
>>>> we send a wrong message (i.e soap11 to soap12 port) to a wrong port it
>>>> gives
>>>> an exception.
>>>>
>>>> IMO it is better to have mechanism to dispatch the binding using request
>>>> url
>>>> information. if we take the
>>>> contract first side, one wsdl can have many Soap11 or Soap12 bindings
>>>> with
>>>> different polices. In that case
>>>> we need to have this kind of mechanism.  At least to configure it using
>>>> services.xml as keith has mentioned.
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>
>>>>  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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Amila Suriarachchi,
>>>> WSO2 Inc.
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>


-- 
Ajith Ranabahu

Reading, after a certain age, diverts the mind too much from its creative
pursuits. Any man who reads too much and uses his own brain too little falls
into lazy habits of thinking - Albert Einstein

Mime
View raw message