The reality of the enterprise is however that Web Services offer a Loosely Coupled way for disparate systems to interoperate and to be involved in Business Processes that are also Loosely Coupled.
So building a Struts Application for the Enterprise is fine, but...what if you need to expose some Action such that another system can act on it and interoperate with it. It doesn’t have to be a fully functionally Axis/SOAP interface or have a UDDI discovery capability to be useful. What is needed however is a well defined way to do it so we don't re-invent the wheel at every turn. Most any developer in any language can post to a URL and therefore post to a *.do action and likewise any Java Server Page developer can return XML in any schema or format as needed also on a One Off mode. But the real attraction to the Shale<-->Struts ability, is the simple fact that Shale is attractive for new development of event driven processing, and Struts is attractive for a number of reasons, not the least of which is the plethora of Struts resources available. So if Shale<-->Struts can work, new problems that fit the Shale model can be developed in Shale and become part of the Solution that started life as Struts and will live long after Shale. Michael Oliver CTO Alarius Systems LLC 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036 *Note new email changed from [EMAIL PROTECTED] -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 1:32 PM To: Struts Users Mailing List Subject: RE: Shale <--> Struts 1.n On Tue, 01 Feb 2005 11:09:22 -0800, Michael Oliver wrote: > Well Ted, Craig certainly wasn't singing that tune, although that > doesn't mean you are wrong either. Craig believes that Shale is the best way to write new web applications for Java. And he may be right. But, I don't think Craig is suggesting that thousands and thousands of teams all over the world should stop everything and migrate perfectly good Struts applications to Shale. :) For the past five years, we've been saying that Struts and MVC are cost-effective because it makes web applications cheaper to *maintain*. Now, that so many of us have our application in cheap maintenance mode, it would be silly to suggest people are suppose to fix things that aren't broken. Just because Shale might be a better way to write *new* applications, it doesn't mean existing applications are suddenly obsolete. Obsolete means it would be cheaper to rewrite it than to maintain it. I doubt that anyone is suggesting that it would be cheaper to rewrite a stable application in Shale rather than maintain it in Struts. If a poorly-written Struts 1.x application were due for a major upgrade, sure, *someday* it might be cheaper to rewrite in Shale. But a well-written Struts 1.x application is still going to enjoy a long lifecycle. And, probably several upgrades, as there is worked planned for Struts 1.3, 1.4, 1.5, 1.6, and so on. :) [http://struts.apache.org/milestones.html] > As you and I discussed back when we tried to solve the problem of > opening existing Struts applications to Axis/SOAP with Axis4Struts > so a SOAP Actor can be just another View into Struts Applications, > it would seem natural for Shale to have at least some vestige of > interoperability, be that some interfaces or some "gateway" > Actions, so the baby of existing production Struts Applications can > take advantage of JSF/Shale without being thrown out with the > bathwater. Web platforms are very flexible, and Java platforms doubly so. I've mixed and matched workflows with things like Struts and Maverick, and I'm sure you could do them with Struts and Shale too. Or Shale and Tapestry. Or name any combination of frameworks. :) Web services are a horse of a different color. But, as far as mixing-and-matching web frameworks goes, it would not sound like a good long term solution. The key advantages of Shale are best realized by new development. But, since Shale is unreleased software, the better place to discuss such things would be the dev@ list. -Ted. > > Michael Oliver > CTO > Alarius Systems LLC > 3325 N. Nellis Blvd, #1 > Las Vegas, NV 89115 > Phone:(702)643-7425 > Fax:(520)844-1036 > *Note new email changed from [EMAIL PROTECTED] > > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 01, 2005 10:41 AM > To: Struts Users Mailing List > Subject: Re: Shale <--> Struts 1.n > > On Tue, 01 Feb 2005 09:44:43 -0800, Michael Oliver wrote: > >> What are the plans for migration and/or interoperation for Shale >> and Struts 1.n? >> > > There's been some talk on the dev list about using both frameworks > together, on a temporary basis, but it's not recommended. > > It's a lot like asking what are "our plans for migration and/or > interoperation for Tapestry and Struts 1.n?" > > They are two different frameworks, and there really isn't much > reason for them to interoperate. > > Eventually, after Struts Shale ships, I'm sure people who migrate > applications from other frameworks will beat a path and document > some tips. > > But, right now, Shale is seen as a tool for new development for > teams standardizing on JavaSererFaces, not as a successor to Struts > 1.x. > > Like everyone else, most of the committers have significant Struts > 1.x applications in production and see no reason to migrate them > anytime soon. > > -Ted. > >> Michael Oliver >> CTO >> Alarius Systems LLC >> 3325 N. Nellis Blvd, #1 >> Las Vegas, NV 89115 >> Phone:(702)643-7425 >> Fax:(520)844-1036 >> *Note new email changed from [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] > > > -------------------------------------------------------------------- > - 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]
