Content Based Routing: EAI Challenge, what's the best solution Part II
In a previous post I mention an scenario, where Content Based Routing is involved. I asked a couple of people in the BizTalk space around the world about their opinion. Here are some more:
Jon Flanders -
Hi Steef – you could do this with your own database and a dynamic port. Or you could use a ROleLink and use the TPM functionality (BAS) to allow your customer to maintain and add partners.
It certainly is a form of the CBR pattern no matter which implementation you use.
Lex Hegt -
Hi Steef-Jan,
At a conceptual level CBR exists as a design pattern which can be implemented with several message brokers. BizTalk 2006 (and 2004 as well) is one of those brokers, so if you should choose for CBR and your customer already has BTS 2006, they won't need another product.
The solution you choose depends (amongst others) on how fast the data needs to available at the target system. The advantage of CBR is that (off course) you don't need an orchestration. So at run-time no instance needs to be created and no data needs to be persisted along the way, giving you a better performance than a solution with an orchestration. So far small packages of data which need to be delivered quickly, CBR should do the job fine. Where needed, you can use SSO for authentication and when the same data must be send to several parties, you can use a Send Port Group, to keep routing simple. The latter works from an orchestration as well off course.
Another disadvantage when using an orchestration is that although you can create dynamic ports, the 'dynamic' part is sender-related, not protocol-related. So, depending on the protocol of the target system you will need multiple logical ports in your orchestration, which will be bound to multiple physical protocol ports. This leaves you with a more complex solution than you probably would be necessary.
Resuming: I would use CBR for your solution. Page 256 of the book you mentioned, contains a list of when (not) to choose for a solution with an orchestration.
Hope this helps. Feel free to come back!
I must say that I am very happy with the responses so far and looking forward to some more.
Jon Flanders -
Hi Steef – you could do this with your own database and a dynamic port. Or you could use a ROleLink and use the TPM functionality (BAS) to allow your customer to maintain and add partners.
It certainly is a form of the CBR pattern no matter which implementation you use.
Lex Hegt -
Hi Steef-Jan,
At a conceptual level CBR exists as a design pattern which can be implemented with several message brokers. BizTalk 2006 (and 2004 as well) is one of those brokers, so if you should choose for CBR and your customer already has BTS 2006, they won't need another product.
The solution you choose depends (amongst others) on how fast the data needs to available at the target system. The advantage of CBR is that (off course) you don't need an orchestration. So at run-time no instance needs to be created and no data needs to be persisted along the way, giving you a better performance than a solution with an orchestration. So far small packages of data which need to be delivered quickly, CBR should do the job fine. Where needed, you can use SSO for authentication and when the same data must be send to several parties, you can use a Send Port Group, to keep routing simple. The latter works from an orchestration as well off course.
Another disadvantage when using an orchestration is that although you can create dynamic ports, the 'dynamic' part is sender-related, not protocol-related. So, depending on the protocol of the target system you will need multiple logical ports in your orchestration, which will be bound to multiple physical protocol ports. This leaves you with a more complex solution than you probably would be necessary.
Resuming: I would use CBR for your solution. Page 256 of the book you mentioned, contains a list of when (not) to choose for a solution with an orchestration.
Hope this helps. Feel free to come back!
I must say that I am very happy with the responses so far and looking forward to some more.
Comments