In case you haven't seen the other thread on SOA, please have a look. I wrote a new blog article on SOA which can be found here: http:// removethispartNebula-RnD.com/blog/tech/2007/02/soa1.html There I referred to another series of articles I wrote for Spectrum Magazine on Web Services, and differentiated Web Services from SOA. I have done this sort of work for other companies. One of the solutions I helped to implement processes over 10,000 orders per day for Dell and has been running for about three years with no issues. That integrates an MV app with a WebMethods B2B server. Another smaller solution integrates order processing between a corporate office and satellite offices for a company that manufactures firetrucks. For this one we used a Perl interface. The bottom line is that these companies regard the functionality provided by the remote MV applications as a component of their own infrastructure.
The tools we used in the past were platform-specific (OS and/or DBMS) but that always seems to come back to bite us, if only in terms of questions about why we are using specific tools - the fact that it all works for years with zero failures doesn't stop the questions. These days I tend to lead with .NET for everything since there are interfaces for every environment including MV - .NET was designed for this sort of usage. There are few technical or political issues getting people to coordinate on a .NET solution and moving the code from one MV platform to another is quite easy (migration or VAR porting to multiple supported platforms). Our tool of choice continues to be mv.NET, which IBM has also recently adopted. For anyone still looking at PDP.NET, I have provided a product comparison for PDP.NET and mv.NET on my blog - please email for a password to access the resource. In all fairness, the Sonic ESB solution is similar but different from mv.NET or other traditional MV market offerings. It serves as a hub for connectivity from multiple technologies whereas other solutions typically seen in these forum Java _or_ whatever. There are bridges which are available for free or reasonable cost which allow (for example) Java and .NET to interoperate, so an expensive "hub" architecture isn't required for many of these projects, maybe just a connector. One key feature that is provided by hubs like WebMethods (not sure about ESB) is that they provide transaction management much like MessageQueue processors. That sort of functionality is _very_ important for ensuring that SOA works - but again, the purchase of major hub products isn't always required. Nebula Research and Development can provide consultation and implementation services for all of this. Feel free to contact me to discuss your requirements. Tony Gravagno TG@ removethisNebula-RnD.com (please do not email yahoo or other addresses) Nebula R&D is a worldwide Distributor for mv.NET and provides related product, support, and development services. From: Andy Pflueger We are currently looking into implementing a SOA (service-oriented architecture) and in the research phase to determine the best approach for this implementation. Does anybody out there have any particular recommendations for implementing a service bus layer with Unidata? Recently, I've discovered a product Sonic ESB by Sonic Software (http://www.sonicsoftware.com/products/sonic_esb/index.ssp). Has anybody had any experience or know anything about this software and how it might interact with the U2 platform? ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
