> In the future, there will be more Struts appplication using even more
presentation layers,
> the Struts tags, the EL tags, the JSF tags, the Velocity View tools,
XLST, Jelly,
> and whatever else we think of next =:0)
> But behind all this chrome, there can still be the same core framework
holding all the pieces together.
I've been putting some thought to this as well. One of the issues that the
people on the Axis project ran into when they, for example, began looking
at implementing SOAP over JMS or SMTP instead of HTTP was that they had an
over-reliance on the HTTP request/response objects. If there was a desire
to use Struts, for example, as a MVC architecture for use with JMS
applications, then there would be no HTTP Request or Response objects
(unless a 'connecter' between JMS and HTTP were created - which would
defeat the purpose of using JMS anyway).
One of the values in using, for example, JMS is that HTTP is limiting in
terms of the level of transactional support it can provide. HTTP does not
guarantee 'once and only once' delivery. If an application required a
higher level of transactional support than HTTP itself could guarantee,
then Struts may not be able to be used.
Also, both JMS and SMTP can be Asynchronous - that is, you send a command
and then the response can come later (or be retrieved by a different
process). HTTP can't do this.
If Struts is to move to being used as a generic MVC architecture that can
be used in a wide range of other environments it may be appropriate to
consider 'abstracting' the request and response objects (or at least
provide an option to) to isolate them from the HTTP protocol. Otherwise,
Struts will likely remain tied to J2EE 'Web Applications' (which I'm not
saying is a bad thing). In fact, the value of Struts as a "web application
framework" may be great enough that the creation of a generic MVC framework
may better be made a Commons project - if there is a desire to do this at
all.
All this being said, I've previously offered to collaborate with others on
the building of a Web Services front end to Struts based on Axis. I've been
doing a lot of Web Services work and have used Axis previously. I think
that being able to use Struts to build Web Services applications that could
act as a back-end to .NET or other HTTP-based web services would be great.
It would make it much easier if you could build the web service 'server'
components using Action classes, 'form bean's, etc. This isn't something I
have time for on my own (job. wife, kids, house, etc regularly get in the
way of all the fun I could have coding this stuff...).
I've already built a 'command pattern' prototype based on Axis that
minimizes the need to define new WSDL for each Web Service 'endpoint' you
want to define. We could potentially create a standard WSDL definition that
is flexible enough to handle a pretty wide range of applications and then
build a backend that maps the web sevice 'command' to a Struts form
bean/Action class combination. This would allow you to build web service
'command processors' by implementing Action classes. I've got a lot of the
design already in my head.
Kevin
http://www.strutskickstart.com
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
