beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: Service Control generation question....
Date Sat, 11 Jun 2005 20:15:19 GMT
Both forms are accurate, and you are right the 2nd form is better. 

As to why we generate the first form....  The logic right now has a
rather simplistic logic,   if there are just one OUT parameter then
that is the return value of the call,  if there are more than one OUT
then there are all included as argument to the call and the methods
returns void.

The logic can be improved by adding more heuristics, like if you have
an OUT parameter that is named "return" or may be even "result" it
should be the return value of the call (which makes the logic work
well with the WSM defaults)   Or if you have more than one OUT, the
one that is boolean or integer is more likely to be return value. 
Unfortunately, AFAIK, there are no rules that the WSDL has to be
structured as such.

Daryoush

On 6/10/05, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> Sure, I'll file a bug on this issue.
>  
>  I'm still a bit curious as to why the method signature generated by the
> ExtensionMaker is:
>  
>  public void 
>     UpdatePhoneNumbers(
>               
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
> address1,
>                web.webparam.Phone phone, javax.xml.rpc.holders.IntHolder
> return, 
>              
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>address2)
>  throws Exception;
> 
>  INSTEAD OF:
>  public int 
>     UpdatePhoneNumbers(
>               
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
> address1,
>              
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>address2)
>  throws Exception;
>  
>  It seems the second form would be a more accurate representation of the
> webservice call than the first.  But perhaps there is some technical reason
> for this? 
>  
>     - Chad
> 
>  
>  
>  
>  
>  
> On 6/10/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> > I don't discount the use of headers,  in fact last time I checked EBay
> > does use it for it authentication..  As you pointed out Header makes a
> > lot of sense for things like Authentication, transaction mgmt, etc.
> > But if you were to implement these services you would implement them 
> > using a Handler as oppose to arguments on the methods, very similar to
> > the EJB model were the beans are not involved in security or
> > transaction aspects of the call.
> > 
> >   Lets say you want to have a security header parameter that is your 
> > message checksum, at the time the JWS methods is called there is no
> > message for you to checksum, you would have to have a handler to get
> > the outgoing message (or incoming) to generate (or validate) the
> > checksum.  So having the checksum as an argument to the methods wont 
> > make any sense.  Something with transaction you want that handled
> > outside the method call.
> > 
> > The 181 spec does require header=true, which means we do have to
> > implement it on the server side.  But I don't believe this will be a 
> > common use case and I question the priority of this test on the
> > service control compare to other tests we could be developing.
> > 
> > Daryoush
> > 
> > 
> > 
> > On 6/10/05, Jacob Danner < jacobd@bea.com> wrote:
> > > Just to chime in here on top of my last 181 post.
> > >
> > > "I am curious to know why you think having INOUT parameters in the
> > > Header would be useful."
> > > 
> > > The soap spec says the following about SOAP Headers (4.2):
> > > SOAP provides a flexible mechanism for extending a message in a
> > > decentralized and modular way without prior knowledge between the
> > > communicating parties. Typical examples of extensions that can be 
> > > implemented as header entries are authentication, transaction
> > > management, payment etc.
> > >
> > > So using Headers allows for future extensions. With WS being relatively
> > > new, the possibilities are endless. 
> > > I don't think it's feasible at this early in the game to say that using
> > > an INOUT header doesn't make sense only because few standards really
> > > make use of it at this point. There are many standards still in draft 
> > > and being developed that may make use of information in the header. We
> > > shouldn't discount it soo soon.
> > > -Jacobd
> > >
> > >
> > > -----Original Message-----
> > > From: Daryoush Mehrtash
> > > Sent: Friday, June 10, 2005 1:05 PM
> > > To: Chad Schoettger; Beehive Developers
> > > Subject: RE: Service Control generation question....
> > >
> > > I haven't looked at this, but I do have a question, (and this may not 
> > > have anything to do with the problem you are having) why are you putting
> > > INOUT parameters in Header?      This is an area were we do have known
> > > issues (I believe there are two bugs already filed on this)  also I 
> > > can't imagine this case being a realistic usage scenario.  I am curious
> > > to know why you think having INOUT parameters in the Header would be
> > > useful.
> > >
> > > Does the test work if the parameters were not in the header? 
> > >
> > > Daryoush
> > >
> > > > -----Original Message-----
> > > > From: Chad Schoettger [mailto:chad.schoettger@gmail.com]
> > > > Sent: Friday, June 10, 2005 12:52 PM 
> > > > To: Beehive Developers; Daryoush Mehrtash
> > > > Subject: Service Control generation question....
> > > >
> > > > So I'm working some new drt's for the webservice system control and
> > > > have run into a bug but I'm not sure how to classify it: 
> > > >
> > > > It occurs when I try to generate a service control from the
> > > > wsm-samples/webparams webservice's wsdl.
> > > >
> > > >
> > > > The annotated web service method is:
> > > > 
> > >
> ------------------------------------------------------------------------
> > > --
> > > > -------------------
> > > > @WebMethod
> > > >  public int updatePhoneNumbers(
> > > >             Phone phone, 
> > > >             @WebParam(name="address1", header=true,
> > > > mode=WebParam.Mode.INOUT) AddressHolder addressHolder1,
> > > >             @WebParam(name="address2", header=true,
> > > > mode=WebParam.Mode.OUT) AddressHolder addressHolder2
> > > >     ) { .... }
> > > >
> > >
> ------------------------------------------------------------------------
> > > --
> > > > ---------------------- 
> > > >
> > > > The WSDL is attached.
> > > >
> > > > The generated webservice control method is:
> > > >
> > >
> ------------------------------------------------------------------------
> > > -- 
> > > > ---------------------
> > > > public void
> > > >
> > >
> UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web.
> > > we
> > > > bparam.Address>
> > > > address1, web.webparam.Phone phone, javax.xml.rpc.holders.IntHolder
> > > > return,
> > > >
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
> > > > address2) throws Exception;
> > > > 
> > >
> ------------------------------------------------------------------------
> > > --
> > > > ---------------------
> > > >
> > > > When the generated webservice control is compiled, apt blows up due to
> > > > the 'return' parameter name in the arg list.
> > > >
> > > > Questions:
> > > >
> > > > 1) Is the control method being generated correctly? Should the
> > > > 'return' parameter be the return value for the generated method? like:
> > > >
> > > > public int
> > > >
> > >
> UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web.
> > > we
> > > > bparam.Address>
> > > > address1, web.webparam.Phone phone, 
> > > >
> org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
> > > > address2) throws Exception;
> > > >
> > > >
> > > > 2) If the method is being generated correctly - it seems the proper 
> > > > fix would be to modify the ExtensionGenerator class to check for param
> > > > names which are Java keywords and modify them to non-keywords so that
> > > > the control can be compiled.  Or would the proper fix be to modify the
> > > > wsm model to correctly 'encode' the param as a non-java keyword?
> > > >
> > > > Thanks for any input on this.  Once I have determined where the fix
> > > > needs to be made I will file a bug. 
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > --------
> > >
> > > Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique
> > > online
> > > event, giving you the first look at a new category of enterprise 
> > > software
> > > built specifically for Service-Oriented Architecture (SOA).
> > >
> > > Register Now.  It's Free!
> > >
> > > http://www.bea.com/events/june15 
> > >
> > >
> --------------------------------------------------------------------------------
> > >
> > > Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique
> online
> > > event, giving you the first look at a new category of enterprise
> software 
> > > built specifically for Service-Oriented Architecture (SOA).
> > >
> > > Register Now.  It's Free!
> > >
> > > http://www.bea.com/events/june15
> > >
> > 
> > 
> > --
> > Daryoush
> > 
> > Weblog:  http://perlustration.blogspot.com/
> > 
> 
>  


-- 
Daryoush

Weblog:  http://perlustration.blogspot.com/

Mime
View raw message