Shameless self-promotion coming up... > 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.
You might want to go to SourceForge and look for STRUTSWS. It's pretty much exactly what you just described. I've used it in a large-scale production application with great success. I don't bill it as the One True Solution, but it works fantastically well in some situations, and maybe could wind up being the start of something bigger... I have been planning on implementing this idea, expanded of course, within the CoR model, just haven't had time yet. I think getting what I've done thus far up and running within that paradigm should be fairly trivial, from what I've had time to read thus far. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, February 1, 2005 4:52 pm, Michael Oliver said: > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
