Kevin. Thanks for sharing your thought. I am sure that a lot of developers already find Strut-Tiles conbinations great for web apps. Since SOAP will be the next big thing, we are also thinking along your line in our conceptual design stage. Please let the group know any development for Struts-SOAP-JMS.
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, November 22, 2002 8:24 AM Subject: RE: future of struts > > > > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
