Could you elaborate a bit.  Would the POJO contain the Business logic
for calling My DAO and other classes?  Would the POJO replace the
action functionality?  Then my action would use a POJO to do all of
the work?  So any logic in MyAction.save() would go into POJO.save()
which would then be called form my action?  That way My POJO could be
accessed from my struts application and any other clients that need it
functionality?  I dont see any need for .NET interoperability in the
future, but it would hurt to have that option.  The main reason for
this is we are designing a new J2EE Application seprate from our
current system.  In the future we want to beable to access certian
functionality of each of these systems.  So System A will be asking
System B for info and doing some work based on that info.

After talking briefly with a more experienced analyst, he mentioned
that SOA might be worth checking out.  I am kind of getting away from
a struts topic now but, since I am designing this system from scratch,
and it has to communicate with a J2EE / Struts that we currently have
in place is SOA a good solution?    Are there other solutions that
might be better?  And way off topic but something that I also want to
plan for is integrating parts of our application in to Workflow
applications.

Sorry for taking this out of the Struts realm on this mailing list.
If there is somewhere else to find these answers let me know.  The
struts aspect of this is ,  how am I going to get my strus app to
share its functionality,  what is the best way to achieve this?

Thanks

Rich



On Tue, Feb 26, 2008 at 11:18 AM, Lukasz Lenart
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  I think, it will be better if try to use XFire / CXF or Axis2, you can
>  create simple POJO and expose it as WebService and from the other side
>  you can use such POJO in your Struts2 actions. And of course you can
>  use Spring to initialize it and inject to your actions ;-)
>  If you want to have better interoperability with .NET you should
>  consider using literal/document style for your WebServices (base on
>  XSD and XML messages).
>
>
>  Regards
>  --
>  Lukasz
>
>  http://www.linkedin.com/in/lukaszlenart
>
>  ---------------------------------------------------------------------
>  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]

Reply via email to