beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Schoettger <chad.schoett...@gmail.com>
Subject Re: Service Control generation question....
Date Sat, 11 Jun 2005 03:13:32 GMT
Perhaps I should add a bit more detail on my previous question. I have 
noticed that in the webservice control when a call is made to a webservice 
method, axis will always return the value which was returned from the 
webmethod.

For example:

Object result = call.invoke(args[]);

if the web method returns an int that is what gets returned from the 
call.invoke() 

So in the case of the method in my previous email, even though the service 
control uses an IntHolder to pass the 'return' parameter the value is never 
returned as part of the call.getOutputParams() (i.e. there is no key with a 
value of 'return'). Instead this value is the return value of the call 
invoke() method. So it would seem that Axis is treating return values 
differently from other params of mode OUT or INOUT.

I need to file a bug on this as well but wanted to be sure that there is a 
good reason as to why we are generating the method signature in question 
before I did.

- Chad




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/
> > 
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message