toshiba coupon codes

While searching for guidance on implementing an Enterprise Service Bus in .NET, I stumbled onto your website. Is there any topic that you guys miss? Guess not!

Anyway, I’ve become interested in ESB because it is useful in implementing an SOA architecture. Over the past year I’ve created multiple services which are hosted as windows services communicating with clients using .NET Remoting. I also had to create service installers to install these services. This seems very inefficient. Why not just have a single service host that I can publish services to and that clients can subscribe to? Isn’t this what Java Application Servers do? Why not have a centralized service host in .NET?

Also, if I am going to invest time creating a service host (or rather a service hosting framework that will survive platform and techology changes), why not use a framework like WCF that provides a standards based solution which enables integration across open standards so that clients written in other programming languages can consume the service I create? Further, why not decouple my .NET clients from the services using a messaging architecture that supports a publish-subscribe model which an ESB would provides?

WCF does require direct communication between the client and the service which is a form of coupling. The ESB breaks this coupling, or rather, replaces it with a different one that couples all clients to the ESB which then dispatches the messages sent by clients to the appropriate service. The model becomes a bus architecture instead of a peer-to-peer architecture.

Is all of this necessary? In my opinion, if your goal is simply to centeralize your services to ease maintenance and deployment then this can be done using WCF without using an ESB. Using an ESB makes your architecture more complex and forces you to confront issues that BizTalk (Microsoft’s ESB) developers have to deal with. However, if you have many departments each publishing services which work together like a federation of services, then decoupling these services from each other using an ESB could be worth doing. However, this would make it necessary to add other services such as a Service Discovery service to your architecture, further complicating matters. For example, when implementing a messaging system at Countrywide we had to develop many infrastructure services for message tracking, message correlation (matching sent and recieved messages), service registration and discovery, message logging, etc… Implementing these services and there associated UI’s was a very complex undertaking.

I guess, my opinion on using an ESB are mixed since it introduces unncessary complexity for most projects but has some nice advantages for an environment sprawling with many service publishers and just as many, if not more, consumers.

Alright, what am I doing? I guess I just became a blogger.

M2 Technology
Keith Smith

The big thing, to me, that WCF doesn’t handle is the subscription concept. With WCF you have to say who you want to send it to, but with the bus you just publish the event.

WCF is also by default in preference of shared contract instead of shared type. This means that I can’t pass an interface around, which stinks. One of the big things that I have learned for Udi about SOA is that as far as the bus is concerned its all about the message not the data (Hence the IMessage concept). The app, not the bus, cares about the data. Its like TCP/IP in that way(1).

Plus, I see WCF as more of a transport mechanism than a service bus. You can look at NServiceBus as another project that is taking the same approach.

Lastly, its yet one more abstraction, that in our case wasn’t needed.

Also take a look at the NSB mailing list

Some good reads:
1. http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html
http://udidahan.weblogs.us/2007/11/09/podcast-versioning-and-soa-there-is-no-idog2/
http://tech.groups.yahoo.com/group/nservicebus/