Re: Best Practice

[Dennis Sosnoski]

As long as you've got the same object model behind all your services, 
and the clients don't have any existing model for working with the same 
data, you won't have the problem of conflicting models. You'll still 
have the issues with the limited types of objects that can be converted 
to and from XML using the rpc/enc encoding (basically just Java Beans).

For instance, I'm working with one client company that has many existing 
EJB services they're gradually exposing as web services. The data being 
passed back and forth by these services includes several types of maps, 
typesafe enumerations, and other structures that don't fit the Java Bean 
model. They aren't willing to change their existing EJB interfaces to 
match the limitations of what can be handled automatically by Axis or 
JAX-RPC, so they're instead using flexible data binding to convert to 
and from their object model (in their case by using JiBX data binding 
for serializing and deserializing the data handled by Axis). This will 
also allow them to refactor and evolve their EJB services in the future 
without needing to modify clients written to the current WSDL.

Where the conflicting models come into play is when the client is 
working with multiple services that don't necessarily come from the same 
source. Consider applications in the travel industry, for example, where 
a client may need to work with several providers that each have their 
own internal data models. Letting each provider export it's own model 
would lead to complete chaos on the client side - that's why industry 
groups are developing standard data representations (in the form of 
schemas) for areas like this. It's then natural to make these schemas 
the basis of the web services in these areas.

Many large companies have internal architecture groups that define 
standard object models to be used for their business data in a 
particular programming language. These standards are necessary because 
of the interoperability problems created when each group within a 
company creates their own code for dealing with the business data. I 
think the same sort of thing is likely to happen with XML/web services, 
and for the same reasons. The architecture groups will define the 
schemas and make sure they're compatible with the object models, then 
the relevant schemas will also be shared with business partners who need 
to interoperate with the companys' systems. That way the only coupling 
is in the data representations, not in the actual structures used by 
applications to work with that data.

Hope that clarifies my point of view.
- Dennis
Sagar Pidaparthi wrote:
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