New to soap

["Smith, Jonathan" <js...@PaineWebber.com>]

Can someone please tell me how to get started with soap and java
 

Johnathan Mark Smith 
Messaging & Collaboration 
PaineWebber Incorporated 
1000 Harbor Boulevard, 6th Floor 
Weehawken, NJ 07087-6791 
Phone: 201.352.1387 
Fax: 201.902.5273 
E-mail: jsmith4@painewebber.com 

 

-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Monday, August 21, 2000 1:56 PM
To: soap-user@xml.apache.org
Subject: Re: Servlets and SOAP


I don't much like the idea of adding EnvelopeContext as the first parm on 
every provider method, although I do see why that would be a safe approach. 

If you decided that loose coupling is important, and you wanted to avoid 
compile time dependencies on the 'SOAPContextual' interface, then you 
could reflect the provider class for a method that meets a required signature, eg., 


public void setSoapContext( Hashtable context ); 


Using a Hashtable instead of EnvelopeContext keeps avoids compiler dependencies 
and there's no need to implement an interface. 


What is it you don't like about putting a synchronized block around the setSoapContext and 
the method invocation? I think I can guess, but can we quantify the downside? 
  
  
  


Jean-Noel Gadreau wrote: 


 As I am working on this stuff with the SOAPEngine, I have a question for you guys:What do you think is the best way to pass the context (EnvelopeContext) to the provider class ? I think that we can take the assumption that the provider has to be aware of the context, somehow.At first, I was thinking about giving the context as the first parameter of each method of the provider (in a special "ExtendedRPCCallProcessor", of course the normal "RPCCallProcessor" would remain). So you would have:ExtendedStockQuoteService:    float getQuote(EnvelopeContext ctxt, String symbol);The advantage of this is that the provider is completely stateless (or at least, the RPC stuff does not require it to be state-full). The drawback is that it changes the signature of every method.I wanted to have an interface with 2 implementations, one on the client that creates the 'Call' and sends the SOAP request, and one on the server that performs the service. The problem is that with this approach, the !
!
server cannot implement the same interface.Another option would be to define an interface "SOAPContextual" (could not figure a better name :-) like this:    setContext(EnvelopeContext ctxt);and then have the server check if the provider is a "SOAPContextual" and if so call the "setContext" method. What I don't like here is that it means that "setContext" and "getQuote" are called in the same "transaction" (or synchronized block) and it requires the implementation to keep the context.As I cannot really choose which is best, maybe you can give me your point of view. Any of the 2 are possible with the SOAPEngine (just 2 different EnvelopeProcessors) and it coudl even be possible to have both at the same time.Regards,Jean-Noel 

============= 
Jean-Noel GADREAU 
Software Engineer, ActivCard Inc.( http://www.activcard.com <http://www.activcard.com/>  ) 
E-mail: jngadreau@activcard.com 
Tel (main): 510-574-0100 
Tel (direct): 510-574-1736 



-----Original Message----- 
From: Cory Isaacson [ mailto:cisaacson@capita2.com <ma...@capita2.com> ] 
Sent: Monday, August 21, 2000 7:23 AM 
To: soap-user@xml.apache.org 
Subject: Re: Servlets and SOAP 
 
Rich, I agree, its a must. If a provider object can be a servlet, the problem goes away, and if not, you're correct - it needs the context and session objects. Thanks, Cory 

----- Original Message -----
From: Rich  <ma...@vignette.com> Johns
To: soap-user@xml.apache.org <ma...@xml.apache.org> 
Sent: Monday, August 21, 2000 10:05 AM
Subject: Re: Servlets and SOAP
 What you want is the provider to get context. If the provider is a java class (as is the case in the 
current architecture) then the context must be passed to the provider somehow ( a sticky issue). 
OTH, if the provider were a servlet, then the issue of passing context to provider classes becomes 
a moot point. 

The next problem you have for the provider that needs context, is to get that same context back 
to the provider on the successive soap calls that form a conceptual client session. You have to 
get the response headers generated by the web server/servlet engine for a given soap call out of the 
Call strucutre and submitted as response headers to the subsequent calls. 


See earlier posts from me that describe a protoype that I have for doing this for the NON-servlet 
provider class case. A generalized solution that allows a provider to be  a 
servlet might be a more palatable change to the architecture than passing context to java class providers. 


I could work with either, but I'd like to see some form of this  functionality as part of the standard distribution. 


Cory Isaacson wrote: 


Steve, I do mean a server, so instead of using a provider class, invoke a servlet. I can certainly see how I could modify the RPCServlet code to do this, I just wondered if there were plans to make it a standard feature. My reasoning is that I need to buffer certain things, and need access to the servlet context/session objects to do part of the job. If I modify the RPCServlet, then I assume that my site won't respond to other standard SOAP calls (which may not matter in this case) but it would be neat if you could invoke a class or a servlet as part of the architecture, and the invoked servlet got passed the request object through servlet chaining. Just an idea, but I bet not hard to include in the SOAP product itself if others agree. Cory 

----- Original Message -----
From: Steven J. McDowall <ma...@visi.com> 
To: soap-user@xml.apache.org <ma...@xml.apache.org> 
Sent: Sunday, August 20, 2000 5:07 PM
Subject: RE: Servlets and SOAP
"Provider" ?? That is an ambigious request.. :-)Do you mean client? Of course, just use "invoke" like anyway else..Do you mean server (which I think you do) the answer is of course again, although a bitof work..Most of the logic is the same (exactly) as in the RPCServlet code itself.. That really is a "Soap Server" of a sort.. Just take the part where it decodes the soap message and ferretsout the data it wants with DOM calls to get the elements you want..Perhaps not totally elegant, but it should work..  

-----Original Message----- 
From: Cory Isaacson [ mailto:cisaacson@capita2.com <ma...@capita2.com> ] 
Sent: Sunday, August 20, 2000 3:30 PM 
To: soap-user@xml.apache.org 
Subject: Servlets and SOAP
Is there any way to have a Servlet be a provider for a SOAP call? Cory