Keith, Thanks for the reply. Here are my thoughts and some more questions (heh).
> Are you going to send/receive RPC/Encoded messages or Document/Literal > messages? Currently, I am using the RPC/Encoded style. My thought was that the resultant application would be similar to a client accessing an RMI server. > If you develop RPC/Encoded messages (which many people including me do > not recommend) then you will probably use axis' "rpc" programming > style(axis calls these service styles which gets most people confused > with the RPC or Document WSDL style) on the server side. Being relatively new to the webservice industry, I wasn't aware of a bias against RPC/Encoded messages. Could you explain it to me? I'm not set on my current path by any means and am open to suggestions. > If you develop Document/Literal web services are you going to use the > "message", "document" or "wrapped" programming style that > axis provides? After reading your email, I've started investigating the Document/Literal "message" style. I will probably spend a few hours this evening looking at the MessageService sample. Is this indicative of this style or are there some pitfalls/gotchas I need to be aware of? > We develop Document/Literal web services and currently use > the "message" > programming style and use the Element[] > processMessage(Element[]) method > choice. Why did you choose this version over the other 3? If I understand the message style, you package the service request into an xml collection (array, document, etc) and transmit this to the service. The service then processes this xml directly (as opposed to marshalling the info into a method call (as in COM,RPC,RMI,etc)). Is this accurate? If so, I'm assuming the structure of the xml is application dependant and can be whatever I wish to send. Is this accurate as well? Are application errors normally handled as special return schemas or are do they still come as SOAPFaults? > This may seem crazy but this is what we do: > > Develop the XML schema Which schema are you talking about here? Does the single schema contain all the possible elements that can be transmitted to and received from the webservice? So you are implicitly defining your communications interface (I guess)? > Run castor against the schema to generate the java objects. > Add default constructors to castor objects where neccessary. I take it that Castor is a JAXB implementation? I think I am starting to understand your process and it seems pretty clean to me. > Create the java interface for the business logic to be > performed by the > web service. > > Create the implementation of that interface which includes the > processMessage method. This is basically the "backend" code that processes the SOAP messages that come in, correct? The "processMessage" method is the webservice entry point? Oh yeah, I see that above. > Run Java2WSDL against the castor generated java objects and java > interface to generate a WSDL to start from. We use the -C option to > include our original schema. > > We then fix problems in the WSDL document by hand. This WSDL is generated why? To provide to the service clients? What does the -C option do? The docs say it stops the inheritance search. What does that mean? Sorry. > We then run WSDL2Java to make sure that our hand changes are valid. > Since we are using castor and "message" style we throw everything away > that gets generated from WSDL2Java. We just want to make sure clients > will be able to do this with no problems. > > Add the entries in the server-config.wsdd file for our web service and > include our hand generated wsdl. This part I don't quite get. You don't create a specific .wsdd file for your service; you just add entries to server-config.wsdd to deploy it? Include the wsdl where? Inside the .wsdd file? These seem like basic questions. Sorry. > Pack up the web app and deploy it. > > > On the server side when our processMessage receives an > Element[] we look > at the "wrapper" element which is the root element to know which > business function to call. The element array then gets > unmarshalled to > a castor object and sent to the appropriate method using reflection. That sounds very solid to me. I'm definitely going to look into it more. Thanks again for your reply and I hope I'm not being a bother. Gene <snip the original>
