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 20:36:41 GMT
Thanks Daryoush - it makes sense to me now.

- Chad

On 6/11/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message