| Author |
Message
|
| rasu |
 Posted: Thu May 08, 2014 5:04 am Post subject: Composite service in IBM Integration Bus |
 |
|
Newbie
Joined: 08 May 2014
Posts: 3
|
In one of my projects, we are trying to do service orchestration (complex composite service consisting 12/13 different webservices controlled by dynamic decision blocks after each service call ) in IIB. I am looking to identify issues that we might face if we do that. So far, i have thought of following. Could you please give your views/suggestions to enrich this list? Specially if anyone has any thought from performance point of view.
1. Failure points - We are introducing lot of network operations hence lot of failure points.
2. Interface will be tightly coupled with business logic and hence we can not reuse this interface in future.
3. This is not the best practice. In practice, we should use BPEL engine (tools like BPM, Webspeher Process Server) if we consider complex service orchestration. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu May 08, 2014 5:13 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Webservices and network fallability come with the territory.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2014 5:22 am Post subject: Re: Composite service in IBM Integration Bus |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rasu wrote: |
| 1. Failure points - We are introducing lot of network operations hence lot of failure points. |
Expanding on this valid point, you may also need logic to handle not just the failures but the consequences; if you fail 6 operations in do you intend to restart from the point of failure? If so, where are you storing state and triggering restart? If you're planning to roll back, it's almost certain you can't do a roll back in the technological sense but must issue compensating transactions for the completed operations (I'm assuming this isn't 12 lookups ending in an update!). If you're doing this, what will you do if the compensating transaction falls victim to the network?
| rasu wrote: |
| 2. Interface will be tightly coupled with business logic and hence we can not reuse this interface in future. |
Yes.
| rasu wrote: |
| 3. This is not the best practice. In practice, we should use BPEL engine (tools like BPM, Webspeher Process Server) if we consider complex service orchestration. |
Very much yes. IIB is not designed for this kind of "long-running" transaction, the other tools you mention are and also have capabilities in the failure scenarios I mention above.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rasu |
| Posted: Thu May 08, 2014 6:04 am Post subject: Re: Composite service in IBM Integration Bus |
|
|
Newbie
Joined: 08 May 2014
Posts: 3
|
Thank you very much Vitor!!!!!
| Vitor wrote: |
| rasu wrote: |
| 1. Failure points - We are introducing lot of network operations hence lot of failure points. |
Expanding on this valid point, you may also need logic to handle not just the failures but the consequences; if you fail 6 operations in do you intend to restart from the point of failure? If so, where are you storing state and triggering restart? If you're planning to roll back, it's almost certain you can't do a roll back in the technological sense but must issue compensating transactions for the completed operations (I'm assuming this isn't 12 lookups ending in an update!). If you're doing this, what will you do if the compensating transaction falls victim to the network?
|
I agree with this. I am sorry that I have not set the context properly. In our scenario those webservice operations are to check some reference data and add/update that reference data in the target system and then a final webservice call to actually insert the transactional data. For example, please consider a complaint handling system (target) needs to be updated from different channels (source). One of the channel raise a complaint with some reference data stored in its local database. The responsibility of the interface is to update the complaint handling system with this new complaint. So first, the Interface needs to check if all the reference data (e.g. contact of that complaint, customer of that complaint, Device etc.) are present in the target system, if not add those through CRUD operations available from target system. Then finally create the new complaint in the target system. So even if the transaction fail after lets say in sixth call, in the next retry it will find that those 5 reference data are already present in target system, so it will go ahead without updating the reference data again. As you have already stated, if we need compensation handling at all, then it can not be achieved.
Any view from performance point of view? Any new consideration you suggest? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu May 08, 2014 6:12 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| In our scenario those webservice operations are to check some reference data and add/update that reference data in the target system and then a final webservice call to actually insert the transactional data. |
The usual rule with transactions is that you can safely repeat an operation if ( and only if ) you do not change your inputs while producing your outputs.
Sounds as if your proposed scheme goes at least some way to fulfilling that requirement.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2014 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So you're sure that, through the life of the system, this service orchestration pattern will only ever be used to perform 12 reference data calls and one transactional update at the very end? At no point will anyone attempt to use this pattern for a workflow which performs intermediate updates that must succeed or fail as a block?
I admire both your clairvoyance and/or your design review process.
This eliminates most of my comments to your original point one. But emphises your point 2 - this is tightly coupled to a single solution and for other use cases (such as the one I outline above) something else will need to be developed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rasu |
| Posted: Thu May 08, 2014 6:33 am Post subject: |
|
|
Newbie
Joined: 08 May 2014
Posts: 3
|
Thank you kimbert.
Thank you Vitor.
At this point, we do are not foreseeing the need for intermediate updates that must succeed or fail as a block. However, if we have that requirement in future, is there any way to achieve this?
I remember implementing the similar logic in another Integration platform (webMethods) without BPM stack and there we have a facility through which we can store the current state of transactional data at any point of time in a file and resume from that point of time later on. But not sure if we can do anything to achieve the same in WMB. Any suggestion?
Is anyone has any view on probable performance impact if any? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2014 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rasu wrote: |
| At this point, we do are not foreseeing the need for intermediate updates that must succeed or fail as a block. However, if we have that requirement in future, is there any way to achieve this? |
The tools you mention above.
| rasu wrote: |
| I remember implementing the similar logic in another Integration platform (webMethods) without BPM stack and there we have a facility through which we can store the current state of transactional data at any point of time in a file and resume from that point of time later on. But not sure if we can do anything to achieve the same in WMB. Any suggestion? |
webMethods can do this (we have it on this site) because the vendor positions it as a product that can do the job of both an integration engine and a process flow controller. We're currently migrating off of webMethods and onto the IBM products because those who control the budget and the strategy have determined those products do it "better", where "better" is a subjective judgement made by those people.
I have no opinion due to my limited exposure to webMethods and the fact that, whatever my opinon, I will be instructed by those that pay me to pursue this course of action.
| rasu wrote: |
| Is anyone has any view on probable performance impact if any? |
Well with all those web service calls in sequence(and it must be in sequence to allow for the decision blocks you mention) it's not going to fly.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 09, 2014 4:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@Vitor
Think of it as an aggregation call.
input 1 complaint fan out 12 lookups and calls for verify/update/create master data in parallel, fan in verified complete, process complaint entry... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 09, 2014 4:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| input 1 complaint fan out 12 lookups and calls for verify/update/create master data in parallel, fan in verified complete, process complaint entry... |
I was thinking that, but the OP mentioned "dynamic decision blocks after each call" which led me to believe a conditional logic chain of calls rather than a straight fan-out/fan-in
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
