You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/12/02 02:26:00 UTC

Re: Communication Between WebApps


On Thu, 28 Nov 2002, Ken Fitzpatrick wrote:

> Date: Thu, 28 Nov 2002 22:12:32 -0600
> From: Ken Fitzpatrick <Ke...@KenFitzpatrick.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
>      Ken@KenFitzpatrick.com
> To: struts-user@jakarta.apache.org
> Subject: Re: Communication Between WebApps
>
> I'm hearing more and more about real-world requirements for sharing
> information between WebApps -- not just the authentication thing, but
> entire business object graphs.
>
> Consider the user's choice for the web site Skin.  Wouldn't it make
> sense for subsequently visited WebApps to honor the choice made in a
> previously executed WebApp?  What about an extensive UserProfile object
> graph, populated after the authentication process, from which a vast
> amount of personalization and customization content originates?
>
> I work for a **really** large J2EE shop with many WebApps and we are in
> the endless pursuit of the "one company image".  There seems to be no
> way to meet that requirement while also adhering to Servlet requirement
> of not sharing objects between WebApp sessions (I know, I know ... it's
> right there on page 51 of the J2EE Servlet Spec PDF.)
>
> EJBs might go a long way to helping this, but precious few of the
> WebApps actually use them ... somebody said something about something
> that some else said about something they read from someone who sat next
> to someone who heard about someone who tried something sometime ago,
> somehow, somewhere, someway ... And now it's policy.  Besides, what if
> all that needs to be shared is the Struts SkinChooserFormBean?  Is that
> the ideal candidate for an Entity Bean?
>

If you're not using EJBs for this (and you're correct, you don't have to),
why not just share information via a database yourself?  In most cases,
it's the *data* that you want to share, not necessarily the bean instance
that it is stored in.

> So, is this the cross-roads of the real-world and the J2EE Servlet Spec?
>

Not really.  It's quite feasible to share even object instances if you
want to, albeit depending on a non-portable mechanism (in Tomcat, for
example, classes and objects loaded from common/lib are shared).  But
that's only appropriate where you really do need to share object
instances.  I believe that such a scenario is less common than many people
might think it is.

What's wrong with having an instance of SkinChooserFormBean in each
webapp, but all initialized from the same common database definition of
it's properties?  You've just accomplished the effects you are after
(common look and feel, single place to change, ...).

> Maybe we should think about some methodical means of being able to share
> a given object or object graph across WebApps in a non-strategic, almost
> casual context.  Something like contacting a broker, asking it to
> contact the WebApp that is registered as "primary" for a given type of
> object (e.g., "UserProfile", "SkinChooserFormBean", etc.) and having it
> extract and deliver a ReadOnly copy of the object?  Do I hear Betwixt
> buffering us from object version issues?
>
> Any thoughts?
>
> Thanks!
> Ken
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>