Architecture using Tapestry + other clients via SOAP??

["Linda G. Coleman" <lg...@possibility.com>]

Hi,

We are starting development on a web app using Tapestry but also 
considering additional clients like command line and Java Swing 
applications. Our plan would be to use SOAP to communicate between the 
various clients (including Tapestry) and was wondering if anyone else 
has done anything similar. In particular I'm wondering if the all be 
mappings between the Tapestry pages to SOAP messages and SOAP message to 
the underlying business logic became too cumbersome?

I'm interested in how others have approached the problem of multiple 
client types in general. Maybe you have come up with a different 
approach that worked. I'd appreciate any info on your success stories 
and/or not-so-success stories.:)

Thanks in advance.
L:)

-- 
Linda Coleman
Possibility Outpost, Inc.
======================================================
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. 
  --Benjamin Franklin. (1706-1790)

Re: Architecture using Tapestry + other clients via SOAP??

[Bill Lear <ra...@zopyra.com>]

On Monday, August 11, 2003 at 08:10:46 (-0700) Linda G. Coleman writes:
>Hi,
>
>We are starting development on a web app using Tapestry but also 
>considering additional clients like command line and Java Swing 
>applications. Our plan would be to use SOAP to communicate between the 
>various clients (including Tapestry) and was wondering if anyone else 
>has done anything similar. In particular I'm wondering if the all be 
>mappings between the Tapestry pages to SOAP messages and SOAP message to 
>the underlying business logic became too cumbersome?

Not sure what you literally intend here.  Tapestry is in effect the
"client" layer, so why you would "use SOAP to communicate between the
various clients (including Tapestry)" is unclear.  What would be
better is to separate the business logic and provide communication to
that through a standard interface, the RPC/transport for which is
SOAP, or perhaps direct JDBC.  I see no reason to "map" Tapestry pages
to SOAP messages.

I've written applications that use both SOAP and Tapestry, but
have never approached it as you (seem to) want to.  Perhaps I
have misunderstood, or perhaps your note above is unclear.

In my case, the way I implemented it, I had a package, called "model",
let's call it 'com.foobar.application.model', then I have one called
"store", e.g., 'com.foobar.application.store'.  Within model, I have
all the objects that make up the object model (duh).  In store, I
specify an interface that provides access to the business logic and
long-term storage.  So, I might have:

   interface IStore {
        User registerNewUser(Registration registration)
            throws StoreException; // or whatever is appropriate
   }

Then, I implement the interface using SOAP (and under that, perhaps,
JDBC), or if I want direct access to the DB, I use JDBC.  If I wanted
both (one for clients other than Tapestry, and one for Tapestry), then
I could implement and dynamically instantiate the needed class at
runtime, or (better), I could have a shared business-logic layer and
distinct access layers, whatever.  Of course, there are other ways to
do this (EJB, other abstractions, etc.), but this has worked
reasonably well for me.

I have used Apache Axis successfully for my SOAP transport (about
2 months ago) and have been relatively impressed with it.

Incidentally, I have used the "command" pattern along with the notion
of a storage interface to (I think) great effect.  Essentially, you
map each method in the store interface to a class that implements the
logic.  This allows for (1) good localization of SQL code (which I
like, as I like to read the SQL code in the same place it is used),
and (2) clean separation of the distinct commands which in turn avoids
the problem of a huge nasty implementation class full of SQL commands
to implement the logic, and (3) easier/cleaner testing.

If you'd like more details or would like to discuss, contact me
offline if this is at all useful.


Bill