Enterprise bus paradigm
Looking at the Enterprise Service Bus architecture, where the bus is simply a static router and then adding on top of it some decision making capabilities it would be called a Dynamic Message Router as per "Enterprise Integration Patterns" and then further down the road, if you add a Business Process Manager on top of it by adding a business rules Engine. Now my question is that in such a scenario you are relying to much on this one central point.
All the applications connected to this BPM or ESB or whatever you might call it would have a ripple effect if the BPM itself or the rules Engine or even the definition files are broken.
So with this design if this hub breaks the whole system comes down, how if at all can you mitigate this risk.
[768 byte] By [
kilyasa] at [2007-10-3 5:54:46]
At least you know something's broken!
I'm only half joking. If you have a bunch of legacy services to integrate and you don't want to do it with a central hub, the other option is having a bunch of hubs and engines and whatever the hell else you want floating around your infrastructure. If one of those pieces were broken, would you know? How much more difficult would it be to track down the problem?
> At least you know something's broken!
>
> I'm only half joking. If you have a bunch of legacy
> services to integrate and you don't want to do it
> with a central hub, the other option is having a
> bunch of hubs and engines and whatever the hell else
> you want floating around your infrastructure. If one
> of those pieces were broken, would you know? How much
> more difficult would it be to track down the problem?
So very true. And Maintainability would be a hazard in such a design. I was however more interested in if the risk can atleast be mitigated. Or this is considered an accepted calculated risk
I would imagine that it should be similar to app servers, with clustering and failover. If one goes down, the other one picks up the load. There would have to be some redundancy built into the system. Otherwise it's a single point of failure.
It's a great question, one worth asking.
%
> Looking at the Enterprise Service Bus architecture,
> where the bus is simply a static router and then
> adding on top of it some decision making capabilities
> it would be called a Dynamic Message Router as per
> "Enterprise Integration Patterns" and then further
> down the road, if you add a Business Process Manager
> on top of it by adding a business rules Engine. Now
> my question is that in such a scenario you are
> relying to much on this one central point.
You could say the same thing about the database(s) in many archtectures.
I've always assumed the bus is a messaging system (e.g. JMS provider) under the covers and those can be as robust and as fault-tolerant as databases and can be clustered across many machines.
> You could say the same thing about the database(s) in
> many archtectures.
>
> I've always assumed the bus is a messaging system
> (e.g. JMS provider) under the covers and those can be
> as robust and as fault-tolerant as databases and can
> be clustered across many machines.
so in short would I be correct in saying that you can stress on ESB or BPM to be robust but as such there is no pattern or practices on the application layer itself to make it more fault tolerant. I hope I am clear in my wordings.
I see ESBs as having a distributed nature, with no SPF.
Distributed architecture vs. EAI hub-and-spoke architecture. So, in theory, there should never be a SPF or "central ESB server is down" event, because there should be no central server to begin with, but only ESB peers.
Did you have any specific product in mind? ESB is a rather [url=http://www.businessreviewonline.com/blog/archives/2005/12/does_sonics_esb.html]fuzzy [/url] concept. Some vendors would wrap their "old" EAI or MOM product and repackage those as ESBs, instead of offering a system build from the ground up with distribution in mind.
> Some vendors would wrap their "old" EAI or MOM
> product and repackage those as ESBs, instead of
> offering a system build from the ground up with
> distribution in mind.
Given that modern messaging platforms are distributed, it seems like a natural fit for the implementation of an ESB. From my own experience, messaging is a much better way to send messages than point-to-point or client-server archotectures because those approaches require all parties to be up and running to guarantee delivery. I've never seen a single message lost in a JMS queue and I've seen many, many thousands get lost in point to point and client-server approaches.
> so in short would I be correct in saying that you can
> stress on ESB or BPM to be robust but as such there
> is no pattern or practices on the application layer
> itself to make it more fault tolerant. I hope I am
> clear in my wordings.
No, I would it is necessary to build a persistence and retry component on the application layer to handles any failure at the ESB abstraction. Going back to the messaging approach, messages only have guaranteed delivery once the messaging system has confirmed receipt. Up until that point, it's up to the application to make sure the message is not lost.
> I see ESBs as having a distributed nature, with no
> SPF.
Agreed, Enterprise Message bus as per its nature is a collection of middleware services that provide intergration capabilities. Its more abstract in nature than the Hub to have a Single Point of failure.
I was however more concerned about Business Process Manager, I am not sure if I am phrasing my question correctly but let me try again and be more specific this time.
In case you are dealing with a Business Process Manager, which has a Business Rules Engine Associated with it. This particular Business Rules Engine would have a definition file associated with it. Which would define different business rules. Now this file would go through thorough testing and a lot of processes but there is always a possibility that somebody could messup and break the file, or the BPM doesnot get deployed properly.
Now as the Business rules Engine grows in size more and more systems are added to it. So any hick ups here would be rippled across the board.
In a system where reliability now only of the systems but also the information would be of prime importance, what would be a good way to handle it.
ESB abstraction though would definitely fix the SPF of a hub but would it fail the SPF in a BPM as well, I am not sure because the BPM might end up as being one of the services in the ESB.
> In case you are dealing with a Business Process
> Manager, which has a Business Rules Engine Associated
> with it. This particular Business Rules Engine would
> have a definition file associated with it. Which
> would define different business rules. Now this file
> would go through thorough testing and a lot of
> processes but there is always a possibility that
> somebody could messup and break the file, or the BPM
> doesnot get deployed properly.
I'm not sure what you are getting at. I don't know of any technology that can be expected to work when misconfigured or otherwise 'broken'.
> Now as the Business rules Engine grows in size more
> and more systems are added to it. So any hick ups
> here would be rippled across the board.
Why? It seems like you re assuming that the rules would be sort of monlithic file.
> In a system where reliability now only of the systems
> but also the information would be of prime
> importance, what would be a good way to handle it.
Testing?
> ESB abstraction though would definitely fix the SPF
> of a hub but would it fail the SPF in a BPM as well,
> I am not sure because the BPM might end up as being
> one of the services in the ESB.
Are you thinking that there is only one BPM engine?
