Hi Allan, In my opinion, BizTalk Server is only one component of an Enterprise Service Bus (ESB). Take for instance the Fiorano ESB, which is now called the Fiorano SOA 2006 Platform (http://www.fiorano.com/products/fesb/fioranosoa.htm).
>From a 10,000 foot level, they use a JMS based MQ for their message flow (Fiorano MQ). On top of the MQ sits the Enterprise Server - basically the "director" of operations - and one or many Peer Servers. They use the Event Process Orchestrator to piece together the different components and adapters that they offer with no development effort. For this new version they also include the BPEL engine and BPEL editor which does basically what the Event Process Orchestrator can do but, obviously, going the BPEL route. In Windows/.NET you would use MSMQ for your messaging. The Domain Controller(s) would basically act as the "director" of operations and the Peer Servers would basically be servers on trusted domains. Since BizTalk is not an option, you lose the ability to "orchestrate", but you still have all the components that .NET offers - ADO, File System, MSMQ, etc. For this example you have a corporate office in LA and a satellite office in NY. You need to accept 2 different type of orders via FTP (for now) but once uploaded, you need the data to end up in the main DB you have in LA. Using Fiorano, a Project Manager or Business Analyst would "orchestrate" the flow by adding an FTP listener, some XSLT transformation, a Web Service Consumer because you need to validate something from a range of something, and finally a Data Adapter to insert into the DB. This is where the ESB is priceless because you can set breakpoints at each individual step and see what's happening. It also runs on different platforms, so you don't have to replace the infrastructure in NY immediately after acquisition since they were a Linux shop :) However, since this is a development list, I presume you are a developer. BizTalk, in my opinion, is primarily for PMs/Business Analysts so you don't lose much. You would use MSMQ for your messaging. You would build different components that do all the things I listed above since you already have everything in .NET - File System for parsing the FTP upload, XMLDOM for generating XML, dump in MSMQ, pickup from MSMQ, consume the Web Service, place back in MSMQ, pickup from MSMQ, use SQL Adapter to insert in the DB. Debugging would not be that easy, but not impossible either. Security is already present because of MSMQ and AD Domains. You also lose the cross-platform ability, although you could leverage MSMQ over HTTP - never used it so I may just be talking out of my you know what... I hope this helps. If I need to explain in more detail, please let me know. Cristian Sturek Principal SOA Architect http://www.xwebservices.com http://www.soahub.com -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Allan N. Sent: Thursday, January 12, 2006 1:13 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] ESB blueprint Hi Does anybody know if there is an architectural blueprint framework/application out there that implements the basic ideas of an Enterprise Service Bus on the .net platform ? no not biztalk, unfortunate that's not an option :( Best regards Allan =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
