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 Fri, 10 Jun 2005 21:42:46 GMT
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
View raw message