none
Enterprise Service Bus RRS feed

  • Question

  • Hello all,

    our goal is to start building a service oriented architecture.

    So we are going to provide functionality of our existing applications as web services.

    We don't want point to point relationships betweend consumer and provider. So that is the point where something like a entprise service bus comes up.

    What is the enterprise service bus product of microsoft? Is it the UDDI server?

    Thanks in advance

    Hennesey 

     

    Tuesday, October 31, 2006 9:53 AM

All replies

  • Microsoft doesn't have a esb, but the most common server product to use is biztalk... and I've read a few weeks ago an article that they are comming with some guidelines on soa and esb ... should be on the net some where
    Tuesday, October 31, 2006 7:01 PM
  • Hennesey,

       Although MS doesn't have a product falling strictly in the category of ESB (Biztalk is actually a supraset of that) there are ways of implementing an ESB using MS platform components

       There was, one month ago, a SOA conference at MS Corp, Redmond where one of the sessions was called "Building an ESB on the Microsoft Platform". It was recorded, I will ask if its available to publish

       There is also a couple of links I can show you

       The last one offers scenarios and guidances to implement a SOA strategy end-to-end

     

       Hope it helps

    Sunday, November 5, 2006 6:02 PM
  • Hi, all

    I'm very confused at this time.

    We currently have a fairly large Biztalk env. in our company - which by the way works very well - and I'm trying to understand the ESB concept.

     I know that Biztalk is a hub and spoke but over the years we created services (which we call the client connector) that pickup messages (flat file, XML, CSV, ...) and send them to the hub. The services are configured dynamically with webservices and we use ac/nack while sending them over HTTP or HTTPS. We can write adapters for these services, we have SQL stored proc adaptor so save data in SQL, we can read and write MSMQ, FTP ... we can write as may connectors as we want. We also have error handling etc. by sending errors back to the hub(s)

    Moreover we also build a tool to monitor all the hubs (Biztalk) through webinterface and business users can correct problems in the integration layer when they have rights to do so. And because we use biztalk as a hub all interfacing in central (we wanted to move away from point to point interfacing).

    We have supppliers and customers with install the client connector to send orders, invoices etc.

    Now I wonder what an ESB can give me more than what we have.

    If I'm correct ESB relies heavily on XML and open standards, well I can tell you that almost non of our business partners have web-services, and they might know what XML is. That's why the client connector is a windows service to you only need a windows OS and HTTP (which 95% do have).

    We also wanted to move away from point to point interfacing, but in some regards ESB is going back to that. I've seen articles published that said : we don't even need ESB, the services will connect directly. Now how are you going to manage that. With central hub, you can easily sustain change, in ESB or point to point I don't see how you can manage that.

    What is see is that I have extended the 2 failover hubs with services that can route and can deliver NOW, which don't rely on heavy changes required by other apps. Having dynamic routing, transformation, management on the interfaces etc. And it works !

    Now please can someone tell me why I should invest in an ESB, what is lacking?

    Regards,

    Hans.

     

     

    Sunday, November 5, 2006 7:30 PM
  • Hi Hans,

       be prepared, buddy, I will say something now and the crowd will jump on me @#$%^@#@%@#!!!!

       An ESB won't give you more than what you have. Your Biztalk, in your environment, plays the role of the ESB

       The confussion starts because usually is thought that the ESB role must be played by a specific product, forgetting the fact that ESB is just a role which needs to be fulfilled

       With what you have so far, can you make your different applications converse? Can you easily (I mean, with no or little code) translate messages from a platform to another one? Can you easily orchestrate (again, with no or little code) business processes based on those messages (and their responses)? Can you monitor at both, a business level and a system level what it's happening in your broker?

       Here, in wikipedia, there is a definition of ESB (let's consider that these are consensuated opinions emerged from communities, not necessarily absolute truths). Try to find there, Hans, a feature an ESB must offer that is unavailable in your infrastructure

     

     

       Now I must run away before the crowd catch me

    Monday, November 6, 2006 5:22 PM
  • Hi Hennesey

    UDDI is more like a service registry, MS are moving BizTalk towards ease of SOA

    Have a look at the video off the external links on wikipedia:

    http://www.infoq.com/presentations/Enterprise-Service-Bus

    Regards

    Ed
    Saturday, December 2, 2006 10:51 AM
  • I agree with Diego.  Achieving a good Service-Oriented approach doesn't some from using BizTalk or web services.  You have to create a programming model that allows others to significantly alter the business processes once the system is deployed.  One aspect of getting that done is using an Inversion-Of-Control (IOC) container like BizTalk or Workflow Foundation.  BizTalk is great for listening to physical endpoints like queues and directories and it's perfect of managing conversations between your app and external systems.  But I think Workflow Foundation is a better engine for service-orientation -- it was built to be the agent layer of a service-oriented application stack. 

    In the end though, you have to design a component programming model built around message payloads and workflow contexts rather than traditional straight-through processing.  The idea is to allow others to add or change what happens in interactions *between* the entities -- because that's where business policy is really manifest.

    Saturday, December 2, 2006 3:18 PM
  • Have you taken a look recently to the MSDN Service-Oriented Architecture (SOA) page? (It's at http://msdn.microsoft.com/architecture/soa) Some days ago they published there a webcast on ESB over the Microsoft platform: http://download.microsoft.com/download/e/b/e/ebe3b63f-1aab-4b94-a54a-c58ec67d0d9b/BuildingAnESBOnTheMSPlatform.zip
    Sunday, December 3, 2006 4:29 AM
  • if you ask about ESB on Microsoft platform then its BizTalk server 2006, Web service foundation and Architectural guidance how to use these products and tools to build a solution on BizTalk server 2006 with supporting assemblies and artifacts that will give you features of ESB. The core ESB engine is built over BizTalk having Dynamic transformation, dynamic routing, exception management with generic handlers, Provisioning framework to define end points (could integrate with registry like UDDI), Orchestration (of course!), ESB Management and web services metrics site on WSS that will use BAM.

    If you already have a solution running on BizTalk server 2006 then you can introduce de-coupling by using the architectural guidance however a solution on BizTalk that already taken care of loosely coupled concept of enterprise services will not need much effort to move towards an ESB as you already have the basis.

    The architectural guidance is in the review process within MS and it will be available to MS partners very soon. But let me tell you this is not going to be a new product as far as I understood and your investment over BizTalk 2006 will not lost.

    Naseem Siddiqui

    Sunday, December 3, 2006 1:44 PM
  • Hans,

    first, if you are happy with what you have and it fulfills your business needs - then don't touch it.

    That said, ESBs have a different underlying principle - the one of a bus instead of a central hub - which makes it easier to do stuff like the things you do and get better scalability. Take a look at http://www.oreillynet.com/xml/blog/2005/11/esb_vs_biztalk_debate_gets_hea.html 

    (by hte way, if you perform point-to-point integration on top of an ESB you are abusing the concept. However the fact that you can do that doesn't mean the concept is flawed)

    Arnon

    Tuesday, December 5, 2006 8:00 AM
  • This is a very interesting topic and one that I imagine will get a lot of press over the next 12 months as things like .NET 3.0 get a little more mature and companies start to take advantage of some of these out of the box capabilities in WCF and WF.  In my opinion the whole thing breaks down into our ever so familiar architecture trade off matrix.  So let's look at the pro's and con's:

    BizTalk (aka hub and spoke middleware)

    Pro's

    - Centralized

    - Manageable

    - Extensible

    - Promotes Loose Coupling of Apps

    - Durable

    Con's

    - Centralized

    - Has problems scaling under extremely high volumes

    - Complexity of central administration and configuraiton of enviornment meant to service so many disparate scenarios

    Now let's look at the ESB (which some experts are starting to look at building on top of .NET 3 technologies with things like the WCF peer channels and WF workflow managers)

    Pro's

    - De-centralized (at least physically it is ... virtually is another story)

    - Still maintains loose coupling

    - Increased discoverability leads to ease of use

    Con's

    - Complexity

    - Uh ... I'm still not sure I know exactly how to build one :)  No tooling out there for it yet in the MSFT space.

    I myself meet folks where their environment already has some investment in an SOA/Integration strategy and that means you're already on the path of hub and spoke.  It would be very difficult to picture re-inventing those types of things without an easy migration path to an ESB type implementation.  Of course that is if you really went full-blown and didn't build just some things through hub-spoke and other things with point to point services (I hear about a lot of cases where people are building hybrids like this).  Now,  if you were starting from scratch with a SOA initiative for 2007.  Well,  you're in an interesting place then.  I think there are some very compelling ways to use Microsoft's new technologies to provide a bus-like implementation in your enterprise. 

     

    Thursday, December 7, 2006 10:41 PM