struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fzli...@omnytex.com
Subject RE: Shale <--> Struts 1.n
Date Tue, 01 Feb 2005 21:57:00 GMT
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 oliverm@matrix-media.com
> 
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> 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 oliverm@matrix-media.com
>>
>> -----Original Message-----
>> From: Ted Husted [mailto:husted@apache.org]
>> 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 oliverm@matrix-media.com
>>>
>>>
>>> ------------------------------------------------------------------
>>> --  - To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For  additional commands, e-mail: user-help@struts.apache.org
>>
>>
>> --------------------------------------------------------------------
>> - To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For
>> additional commands, e-mail: user-help@struts.apache.org
>>
>>
>> --------------------------------------------------------------------
>> - To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For
>> additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


Mime
View raw message