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 02:15:45 GMT
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