> > I dont see any need for .NET interoperability in the > > future, but it would hurt to have that option. > > I like your typo more than what you actually meant ;)
Ha ha, that is quite funny. > Another thing to look at is the RESTful plugin. It allows the same action to > serve back data in different formats depending on (well, I'm simplifying) the > extension used to call the action. This means your action could return JSON, > XML, HTML, heck, CSV, depending on how it was called. > > This is a lighter-weight approach to SOA that allows for a pretty high degree > of flexibility; it can be used to feed AJAX components, Flash apps, > plain-old-websites, testing, etc. and can serve as a stepping stone* to more > elaborate SOA architectures if it turns out more is necessary. > > Dave > > * RESTful Plugin: the Gateway Drug. I can see how this would work, but it almost seems a little dirty. I would prefer to use the J2EE API to implement the SOA. Could I take the parts of my Strtus app that I want to share, and turn them into services that both my strtus app and any other client can call? I am open to the REST plugin, I would just like to make sure I am not creating more work in the furure if I have to integrate these Services with Workflow apps and other systems. I would like to do it the best way possible the first time, even if it means longer development. Thanks, Rich --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
