I haven't personally tried to think of Shale as a general purpose
adapter for between remote clients and server side business objects.
I'm not sure there's really a need for one, either. Here's a really
primitive ASCII Art picture of how I look at it:
Browser Client --> WebApp Server ---\
\
Web Services Client --> WebServices Server --> ServiceLocator -->
BusinessLogic
/
JMX Remote Client --> JMX Server ---/
Where JSF+Shale would be used in the "WebApp Server" role, and you'd
use something JAX-RPC based for the "WebServices Server" and JMX
Remoting for the "JMX Server".
You can certainly share a ServiceLocator implementation (perhaps based
on an IoC framework, perhaps based on EJBs, or whatever you want)
between the various servers ... but I don't think that the APIs for
such a thing need to be baked into the APIs for the front end server
that is primarily acting as an adapter.
The technology choice for the ServiceLocator and BusinessLogic should
be up to the application architect, not the architect of the front
controller framework.
That being said, the fact that these three technologies all use HTTP
means you could really coexist in a single web application if you
wanted to. My gut says that this woud be more fragile than an
environment where the app for each incoming technology is deployed
independently (and upgraded on their own schedules as needed, and
deployed on different hardware depending on volume, etc.), so I don't
think it is something we would want to encourage. But sharing the
back end processing is certainly a good idea.
Craig
On Thu, 28 Oct 2004 13:02:56 -0600, BaTien Duong
<[EMAIL PROTECTED]> wrote:
> Ted Husted wrote:
>
> >On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote:
> >
> >
> >> ... that we rename the package called "impl" as "faces".
> >>
> >>
> >
> >As to the impl package:
> >
> >I think what really bothers me here is that the classes implemented here are not
> >part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around
> >for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a
> >Faces interface. So far, all of the members here extend Faces interfaces or classes.
> >
> >To me, "impl" says we're implementing the interfaces for the Shale layer (rather
> >than the Faces layer).
> >
> >
> >
> Greetings:
>
> I have not had a chance to look at the Shale API yet, but i already play
> around with the idea of controller and adapters. To me, the view handler
> (either you use JSF which is available now or future framework) is only
> 1 part of the adapters to manage services that use HTTP/HTTPS ports.
> Other services that use the ports are WebService, WebDAV, JMXRemote.
>
> It makes sense for Shale API to handle all standard services using
> HTTP/HTTPS by providing a centralized service requester and service
> router that routes the incoming services to appropriate adapter (view
> adapter for browser and mobile devices, webService adapter, webDAV
> adapter and JMXRemote adapter). Is there any one thinking along this line?
>
> BaTien
> DBGROUPS
>
>
>
> >Naming this package "faces" clarifies that it contains classes that are dependant
> >on the lower-level Faces API, as opposed to the higher-level Shale API.
> >
> >What I would suggest is that we call the package "faces", and the member classes:
> >
> >* "ShaleApplicationFilter"
> >* "ShaleConstants"
> >* "ShalePhaseListener"
> >* "ShaleViewHandler"
> >
> >I'm thinking that in an import statement
> >
> >* org.apache.shale.ViewController
> >* org.apache.shale.faces.ShaleApplicationFilter
> >
> >would clearly say who's riding whom.
> >
> >-Ted.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
