none
ESB implementation RRS feed

  • Question

  • Hi,

     

    I have around 10 (more will come) services running in an initial SOA structure. The next step requires me to take on a subject that I have postponed too long. I now have the requirement that some of these services must send data to each other. In time, other implementers will also have access to some of these services or orchestration of services.

     

    The above reasons together with some other needs means that I must - to some extend - implement/buy ´software that can deal with subjects like Mediation, Security/policies, Management & routing. For lack of better words, what I need is a service bus or ESB. Yes I know these terms can be defined to cover most anything - but nevertheless I would like to implement the ESB myself because I will probably need to distribute services and ESB to other sites (companies). It will be some ad-hoc implmentation but thats alright, I dont need all subjects covered by the first release.

     

    So I have looked at some implementation called nServiceBus which seem to be the only real implementation with source code available. However this implementation relies on msmq for communication and seems only to cover the mediation of an ESB (at least the samples I have looked at). Mediation would be my first step anyways so I guess I can use it for inspiration. But I cannot start some mediation implementation without a plan for the other subjects aswell. I could rely on msmq for "internal" communication but other external users must be able to connect using SOAP.

     

    I guess what Im after is some (best) practice for implementing an ESB. There are a lot of best practices that describe an ESB in some context and the goals and pitfalls, but I havent found any that deal with the actual implementation. What to start with? What to incorporate from the beginning (e.g. security)? I need something concrete to get me starting.

     

    All thougts are more than welcome...

     

    --

     

    Saturday, November 29, 2008 10:53 AM

All replies

  • Here is what I would be looking for in a commercial grade ESB (the list is from service bus application pattern from a Microsoft PDC presentation) are Federated identity/acl, service registry, service naming, messaging fabric and orchestration.  I believe nServiceBus may be using msmq because of message durability/guaranteed delivery.  end of the day you need to use some type of persistance layer to keep the message if your caller or callee is not available.  You could use nServiceBus but replace msmq with some other implementation that works for you.  A proper open source ESB that has enterprise recognition is Mule.  Although it is implemented in Java, this could give you an idea of open architecture and source that can help you jumpstart.

    Sunday, November 30, 2008 4:25 AM
  • Hi,

    I think you should take a look at Managed Services Engine. It's an open source project developed at CodePlex.com. Cite from project's homepage:

    MSE provides the ability to support versioning, abstraction, management, routing, and runtime policy enforcement for Services.

    So it can be something what you are looking for. As I remember nServiceBus uses MSMQ because it is strongly asynchronous-oriented. In contrast, 'classic' SOA is request-response oriented. I encourage you to read some Udi Dahan's articles about event driven SOA. Maybe this approach will fit in your scenario.
    Sunday, November 30, 2008 9:16 AM
  • Werner,

    I would advise strongly against implementing an ESB yourself, unless you work for an ISV and that's the business they're in.

    In order to know what you need in an ESB, you need to address the architecture of your services. Some things that can be easily done within a service can be extremely difficult outside the service (while handling performance, failover, security, etc). One of the main design decisions of nServiceBus was to have an agent run within the service for exactly those reasons.

    Hope that helps.
    Wednesday, December 3, 2008 1:27 PM
  •  Udi Dahan The Software Simplist wrote:

    I would advise strongly against implementing an ESB yourself, unless you work for an ISV and that's the business they're in.

     

    Well, the ESB would just be a (very interesting) necessity in the architecture, however the problem is that we need to install and manage services installed at customer sites so I cant use some expensive combo like Biztalk server + others. That would make our software solution way too expensive (we already have prerequisites like Win2003, SQL2005 etc).

     

    On the other hand using nServiceBus (or some derived implementation) is not enough, I would still need something like Microsoft MSE for facades, catalog etc. Would it bee too complicated to mix those two you think? Or do you have some ESB you can recommend for all these common things?

     

    --

    Thursday, December 4, 2008 8:46 AM
  •  Werner Clausen wrote:

    Hi,

     

    I have around 10 (more will come) services running in an initial SOA structure. The next step requires me to take on a subject that I have postponed too long. I now have the requirement that some of these services must send data to each other. In time, other implementers will also have access to some of these services or orchestration of services.

     

    The above reasons together with some other needs means that I must - to some extend - implement/buy ´software that can deal with subjects like Mediation, Security/policies, Management & routing. For lack of better words, what I need is a service bus or ESB. Yes I know these terms can be defined to cover most anything - but nevertheless I would like to implement the ESB myself because I will probably need to distribute services and ESB to other sites (companies). It will be some ad-hoc implmentation but thats alright, I dont need all subjects covered by the first release.

     

    So I have looked at some implementation called nServiceBus which seem to be the only real implementation with source code available. However this implementation relies on msmq for communication and seems only to cover the mediation of an ESB (at least the samples I have looked at). Mediation would be my first step anyways so I guess I can use it for inspiration. But I cannot start some mediation implementation without a plan for the other subjects aswell. I could rely on msmq for "internal" communication but other external users must be able to connect using SOAP.

     

    I guess what Im after is some (best) practice for implementing an ESB. There are a lot of best practices that describe an ESB in some context and the goals and pitfalls, but I havent found any that deal with the actual implementation. What to start with? What to incorporate from the beginning (e.g. security)? I need something concrete to get me starting.

     

    All thougts are more than welcome...

     

    --

     



    It's a bit contradictory to say you have services running in a SOA structure but you have not got any ESB yet.

    The real ESB players are Progress Sonic and Tivoli, I highly recommend those as writing one from scratch is rather complex.

    Contrary to popular belief, systems built around Biztalk are not SOA nor have a ESB.  BizTalk is a hub-and-spoke message broker.

    There is nothing wrong with using MSMQ but remember MSMQ like other messaging systems are just that, messaging systems.  ESB is the next logical level above that.

    If you are keen on writing your own then I highly recommend:

    Chappel, David A, "Enterprise Service Bus", O'Reilly
    Hohpe, Woolf, "Enterprise Integration Patterns", Addison Wesley
    Tuesday, December 16, 2008 7:44 AM
  •  Micky D wrote:


    It's a bit contradictory to say you have services running in a SOA structure but you have not got any ESB yet.

    The real ESB players are Progress Sonic and Tivoli, I highly recommend those as writing one from scratch is rather complex.

    Contrary to popular belief, systems built around Biztalk are not SOA nor have a ESB.  BizTalk is a hub-and-spoke message broker.

    There is nothing wrong with using MSMQ but remember MSMQ like other messaging systems are just that, messaging systems.  ESB is the next logical level above that.

    If you are keen on writing your own then I highly recommend:

    Chappel, David A, "Enterprise Service Bus", O'Reilly
    Hohpe, Woolf, "Enterprise Integration Patterns", Addison Wesley

     

     

    Thanks for your post. However I dont feel its contradictory at all - but never mind that - the definition about SOA boundaries isnt important in this case. Im not saying that there is anything wrong with MSMQ, but it might not be enough to solve my needs. For example I dont think MSMQ is transactional between several computers. Nor is it a standard that is platform independant. Things like that. But I understand your point that the ESB is just using whatever communication method there exists.

     

    I think I'm keen on writing my own. Its just too interesting Smile - thanks for the book references - one of them I have ordered already Smile

    Thursday, January 8, 2009 8:10 AM
  • agreed

    yes it's a very interresting subject and loads of fun to implement.  hope all goes well!
    Thursday, January 8, 2009 8:49 AM