Mailing-List: contact tapestry-user-help@jakarta.apache.org; run by ezmlm
From: Bill Lear <rael@zopyra.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16183.52458.32796.997434@lisa.zopyra.com>
Date: Mon, 11 Aug 2003 12:05:46 -0500
To: "Tapestry users" <tapestry-user@jakarta.apache.org>, linda@possibility.com
Subject: Re: Architecture using Tapestry + other clients via SOAP??
In-Reply-To: <3F37B1F6.6040409@possibility.com>
References: <3F37B1F6.6040409@possibility.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