| Author |
Message
|
| au@kosa |
 Posted: Thu Mar 01, 2007 11:40 pm Post subject: Design Question |
 |
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
A design question.
Want to know the views of the masters
We want to decoupled the transformations from the existing flows. For this we will do the transformations in a external tool (Itemfield Content master) and will deploy it as process. These processes we will invoke inside the message flows through a plugin node. I am looking for any potential bottlenecks that may create problem in future.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
 |
| jsware |
| Posted: Thu Mar 01, 2007 11:45 pm Post subject: Re: Design Question |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| au@kosa wrote: |
| We want to decoupled the transformations from the existing flows. For this we will do the transformations in a external tool (Itemfield Content master) and will deploy it as process. These processes we will invoke inside the message flows through a plugin node. |
What are the flows going to do other than MQInput -> Itemfield -> MQOutput?
What benefit do you think decoupling the transformation from message broker is going to bring since the broker is really quite good at transformations 
What happens if Itemfield is not running, does the plugin pause and wait, or does it throw an exception? What are you going to do with this exception?
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Fri Mar 02, 2007 1:04 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
The advantages are,
1. Itemfield's Content master can do all kind of transformation which message broker provides (they claim so)
2. In future, if you need to change your XSD, rare chances to touch message broker's flows.
3. There is no need to restart th broker by directly deployed and running the itemfield (stand alone product) service (internally process) with the same service(internally a process) name but different transformation logic
4. No need to depend on MB skill, if there is any change in message format (That what the client claims).
he flows is a Complex flows. It involves
1. aggregation
2. Routing
3. JCN (No esql)
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 02, 2007 1:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| 1. Itemfield's Content master can do all kind of transformation which message broker provides (they claim so) |
True. Do you need anything beyond what WMB provides out of the box?
| Quote: |
| 2. In future, if you need to change your XSD, rare chances to touch message broker's flows. |
If the XSDs change, that means that your data has changed. You will need to re-model that data in some way or other. And your message flows may well need to be updated to deal with new or deleted fields.
| Quote: |
| 4. No need to depend on MB skill, if there is any change in message format (That what the client claims). |
Instead you need two sets of skills - one for designing message flows in WMB and one for updating the message format in ContentMaster.
ContentMaster is very good at what it does, and maybe you have requirements which you have not explained yet. But the reasons cited above would not be sufficient to justify the pain of having to use two products instead of one, in my opinion. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 02, 2007 1:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I'd be very much disinclined to go to the trouble of writing and maintaining a plugin just to use a different tool. Which I'd then need to maintain as well as WMB.
I'd have to be convinced there was a very serious need for the transformation capabilities of this tool that could not be met via WMB. If such a need existed I'd be inclined to try and do the whole thing in the other tool and remove the need for WMB & it's associated skills.
Having been convinced that the other tool was equally stable, scaleable, etc, etc, ...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Fri Mar 02, 2007 1:44 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
Hi Vitor
[url]I'd be very much disinclined to go to the trouble of writing and maintaining a plugin just to use a different tool. Which I'd then need to maintain as well as WMB. [/url]
Itemfield provides a MB plugin node along with their product. In terms of use it is very easy, just need to give the Service name in the property window. In addition by adding a compute node before this plugin node, we can dynamically select the service.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 02, 2007 2:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| au@kosa wrote: |
| Itemfield provides a MB plugin node along with their product. |
Fair enough, that makes it easier. Still unconvinced of the benefits of 2 products (in line with other posters) over 1 but it's your system. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Fri Mar 02, 2007 2:08 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
Thanks EveryBody for giving their valuabale suggestions
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
|
|
