One thing that I forget to mention which I think is very important. Axis implements the SAAJ and JAX-RPC spec (go to sun to find these). While you dont have to be to aware of these to use Axis I think it is important to know what Java specs are out there for implementing Java web services on the server side and be familiar with them. At some point in the future hopefully you will be able to write code using these APIs and plug in and out different implementations without too much trouble. It would be nice to write Java web services on the server side and be able to swap Axis out for something else without killing yourself.
The key thing to understand is that RPC/Encoded and Docuement/Literal refer to how your soap message looks on the wire. Programming styles like "rpc", "message", "document" and "wrapped" refer to what the Axis SOAP engine does with it when it is received. For Document/Literal messages, the "message" style essentially does nothing with the raw xml and leaves it up to you (the application developer) to do what you want. "document" and "wrapped" style will bind the xml to java objects and give you rpc-like functionality on a document/literal message. The key thing to understand about programming styles that support document/literal messages is this: The server side receives a soap message with an "employee" root node which contains employee information. Ok great, now what do I do with it on the server side? If you have more than one operation in your web service you dont know which one to perform. Since there is no "operation" part of a soap message you need some extra help to tell you which business operation to perform on this data. In order to better support this most people will create an xmlschema that specifies a "wrapper" root element around the employee root element. Like "getSalary" would be a root node of "employee" which tells the server side that the client wants salary information. Since the server side create the xml schema specifying this, the server side will look at the root node of the incoming soap body to determing the action to be performed. Each business operation would be mapped to a wrapper root element. With the message style you (the application developer) would write code to inspect this root node and call the appropriate business logic. The "wrapped" and "docment" programming style will do this part for you and bind the xml to a java object. Each takes a slightly different approach. You should read the axis user guide for more info on this. > 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. > 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. Here are some articles about document/literal vs rpc/encoded http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.ht ml http://www-106.ibm.com/developerworks/library/ws-castor/ > 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? Sorry, I never looked at the MessageService sample. > 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? We use the "message" style at the moment because it gives us the most flexibility to do what we want with the incoming raw xml. This also means we have to write more code. It also gives us the flexibility to use Castor for the binding. Using the CVS version of Axis there is a way to configure axis to automatically use castor binding. (search the archive and read the above link for more information on this). We essentially are implementing the "wrapped" programming style ourselves. > 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)? Yes this is the schema that you create to exchange data (xml) with a client. Instances of this schema will be what is in your SOAP body. I dont know the answer to your question about how many "operations" you have for a given end point (web service). So lets just say you have one operation for ease. The xmlschema would have a root element for data a client sends you and a root element for data you send back to the client. > 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. Castor is a binding tool but as far as I know it does not implement the JAXB spec. I dont believe the JAXB spec is ready for xml schema yet and I dont know many tools that implement it. If you read the JAX-RPC spec it specifically says that JAX-RPC implementations (like Axis) can use whatever binding they want. In the future they hope to mandate JAXB. > 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. Yes. The java interface will equate to the messages and operations sections in your WSDL document. The implementation of course is what does the actual work. > 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. You can hand write the WSDL from scracth if you want. We generate the WSDL as a starting point and then modify it from there instead of trying to write it from scratch. The -C option imports the schema you specify into the WSDL document that it generates. Look at the reference page link on the Axis home page for details about the java2wsdl options. Also, I think it is good practice to "import" your schema rather than having it embedded in your WSDL document. We have to do this by hand after using the -C option. See the WSDL spec for more info on "importing" your schema. > 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? This is just the way we do it. I dont know if these are best practices.
