Thanks Dennis for your message. I need some clarification on what you mean by the following
"The problem with this approach is that you're exporting your object model. This works fine for simple applications...." I have a legacy application with about 50 services and over 400 data objects. I have been having problems with some of the legacy code, but am able to deploy and test about 28 of them for the last few weeks using RPC-ENC mode. Many of these services share data objects as you mention in your message below. I use wsdl2java and it produces proxies that I need. If the wsdl2java utility produces a data class second time, I observe that it overwrites the first one. I have not observed the phenomenon that you mention whereby several similar kinds of proxy data objects, thereby flavours of objects are created. In particular I don't observe the following that you mention in your message-- "If each one exports its own object model you then have to write code to shuffle the data from one model to another." In fact I observe that there is almost a replication of classes in proxies that we originally have in our java code. I am able to obtain data objects from one service and use it in another service. (I mean complex and deep objects.) Am I missing something which will come and bite me at a later time? Or have I been plain lucky? Regards Sagar -----Original Message----- From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 17, 2004 1:14 PM To: [EMAIL PROTECTED] Subject: Re: Best Practice Anand Natrajan wrote: >SOAP is always going to be slower than RMI, no question. But by adopting >SOAP as a facade for my application, do I not gain language-independence, >flexibility, loose coupling and document-orientation? > > SOAP is not necessarily that much slower than RMI - see my performance results at http://www.sosnoski.com/presents/cleansoap/results.html, for example. You do gain a certain level of language-independence just from using SOAP, and much more from using doc/lit as opposed to rpc/enc. You don't really gain loose coupling with most of the current SOAP frameworks in Java, though. The problem is that with current SOAP frameworks for Java the wire format (and the schema that goes into the WSDL) is tightly coupled to the structure of your Java classes. If you change your classes, the XML also changes. Beyond that, many types of application data structures just can't be handled in any reasonably way by the existing frameworks. The next generation of SOAP frameworks for Java are going to be addressing these issues. In the case of JAX-RPC 2.0 they'll be addressed by using JAXB 2.0 for converting between XML and Java. Axis 2 is also likely to support a variety of data binding implementations, and I'll probably be taking my own JibxSoap further in the next couple of months. >What's wrong in thinking "code-centric" (don't like that term, but I'll >continue usage for now) when designing my application and my API, but then >generating a SOAP version of the API to gain all of those advantages? The >only significant risk I see is that when designing my "code-centric" API, I >may use language-specific artifacts, e.g., hashes in Perl, or Sets in Java. >These structures may not translate well into other languages. But as long as >I keep _that_ best practice in mind, I don't see an issue. > > The problem with this approach is that you're exporting your object model. This works fine for simple applications where you've got clients that only talk to one web service and services that only work with one client. Beyond that level it starts to get really messy, since the same data may be used with multiple services. If each one exports its own object model you then have to write code to shuffle the data from one model to another. This approach becomes completely unmanageable when you get to complex data structures (like many forms of enterprise data) that may involve dozens of components. If you're going to be making web services a serious part of your future development you're better off developing standard data representations (in the form of XML schemas) that can be shared across services. That way applications which are working with the same type of data will be using compatible formats for the XML exchanges, even though their internal data structures may be different. Of course, you won't gain the most benefit from this approach until you can use a SOAP framework that lets you to decouple the XML format from your data structures. Even if you can't do it with the current production frameworks, though, you can still plan for this flexibility in the future. - Dennis -- Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197
