axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricky Ho <>
Subject Re: Sending more than just beans (Best Practice?)
Date Wed, 07 Aug 2002 17:06:37 GMT
At 03:37 PM 8/7/2002 +0200, Andreas Leitner wrote:

>I see. Hmmm, I always thought of SOAP more or to be a new RPC method (just 
>like CORBA DCOM and RMI).
>Basically what I want is to have a as seamless as possible integration 
>from Java (as in any platform) to Windows (as in neat GUI and what ppl. 
>know and expect).
>Anyway, not permitting references to decrease the degree coupling is IMO a 
>bit of shallow thingy. Because as complexity increases you _need_ some 
>sort of references. And people will introduce it via strings/integers/... 
>which map the key to an object in some hash-table. The result will then be:
>1) More effort to maintain code, because referencing and dereferencing 
>needs to programmed by hand
>2) Less OO Design of the interfaces (because most objects won't have 
>operations, you will need other services that hold just a buch of 
>operations that do clever things with the objects. Of course then 
>information hiding is a thingy of the past)
>3) Impossible to maintain object consistency (the contract) of compex 
>objects. If attributes must not be set at will, but must be properly 
>encapsulated, this is not possible on the client side.
>Or maybe I have missunderstood a lot of things here. I have the bad 
>feeling in my stomach that I still don't have a clue how to properly 
>design the interfaces using SOAP. Given the recent information you and 
>others gave me in the past posts, I come to the conclusion (which might be 
>very wrong, if it is please tell me :) that I am back at C level design:
>*) I have a bunch of data objects. Nothing more than C like structs. All 
>is public. Those structs represent mainly my buisness data.
>*) I have a bunch of interfaces that do things with these objects.
>I have the bad feeling in my stomach, that as soon as object 
>interdependencies get complex those quasi global operation only interfaces 
>will get messy.
>Please don't take any offense. I am just a bit surprised at the moment, 
>but will gladly take advice if offered.

The interface of SOAP is NOT supposed to be Object Oriented.  (otherwise, 
WSDL should have inheritance). OO tends to be much finer grain that service 
oriented architecture try to discourage.  In other words, the 
implementation of a service can be very OO, but the interface shouldn't 
be.  The data exchanged between a client and server is not supposed to be 
encapsulated, and of course, no behavior is expected (SOAP is based on 
XMLSchema which has no behavior described).  Think about the client is 
exchange a "MESSAGE" to the server.  Then you'll feel better.

Therefore, (as I suggest in my earlier response), you need to WRAPPED the 
plain object you get from the wire and put the behavior in it.

A number of vendors are pushing encoding the service reference into the 
SOAP header, basically copying the CORBA model over SOAP.  I'm not sure how 
far they've move along.

Best regards,

View raw message