Author |
Message
|
nize |
Posted: Fri Oct 16, 2009 3:58 am Post subject: WMB 7 enables increased reuse? |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
Overview
I have three questions regarding WMB 6.1 and 7 and the possibilities for function-orientation/SOA "within" flow projects.
Background
Say that we have an environment where the WMB is used as an ESB by many applications. Furthermore, say that you have implemented a transformation in an ESQL procedure which you would like to call from many flows or alternatively that you have a "master" flow (deployed in multiple instances) from which you want to be able to call a number of frequently changing ESQL procedures.
I see two alternatives to realize these requirements in WMB 6.1:
1. Wrap the ESQL procudure(s) in separate flows (having e.g. a webservice interface) and call them from the other flows, e.g. from the "master" flow. This enables us to only maintain a SINGLE COPY OF THE CODE implementing the specific functionality. Moreover, we only need a SINGLE DEPLOYMENT of the code. The only drawback I see here is the overhead caused by the seralization/parsing occurring each time a function is called.
2. Configure the flow project, e.g. the "master" flow project, which will utilize the function so that it links/depends on the WMB project containing the ESQL function, and thereby calling it using ESQL. In this case the WMB project containing the ESQL function must be deployed together (in the same bar file) with each flow calling it. That is a drawback since it means that many re-deploys may have to be done even if only the ESQL function changes. Another drawback is that the project dependencies may be complicated to administrate. Other than that this alternative have the advantages of a SINGLE COPY OF THE CODE and no SERIALIZATION/PARSING when the function is called.
Questions
Maybe there are other alternatives in WMB 6.1?
Will there be new functionality in WMB 7 giving us all three advantages in the scenario described?
- SINGLE COPY OF THE CODE
- SINGLE DEPLOYMENT
- NO SERIALIZATION/PARSING
On the same subject (reuse): Is there a way in WMB 7 to change a message set without needing to re-deploy the flows which utilize it in order to make it effective?
Thanks in advance for your input!
 |
|
Back to top |
|
 |
Gaya3 |
Posted: Fri Oct 16, 2009 4:09 am Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
MB 7 is pretty new..
Does any trial Version is available right now.......[lets think of exploring it]  _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
kimbert |
Posted: Fri Oct 16, 2009 4:28 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
Is there a way in WMB 7 to change a message set without needing to re-deploy the flows which utilize it in order to make it effective? |
That has been possible since v2.1
...now you're going to explain why it doesn't work. I just know you are. |
|
Back to top |
|
 |
nize |
Posted: Fri Oct 16, 2009 6:02 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
kimbert: you may be right... is it correct that you can both (a) deploy the flow and the message set separately and (b) the flow project does not need to be configured as dependent of the msg set project?
I guess in this case kimbert answered one of my questions. However, two questions remain.  |
|
Back to top |
|
 |
mqmatt |
Posted: Fri Oct 16, 2009 6:17 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
WMB v7 certainly has impact analysis to allow you to more easily track changes between dependent source files. This will almost definitely help in this scenario. |
|
Back to top |
|
 |
nize |
Posted: Fri Oct 16, 2009 6:26 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
mqmatt: yes, I guess this could help if you use something similar to alt 2, but still I would need to re-deploy the flows utilizing the ESQL procedure every time I want to change the ESQL procedure.  |
|
Back to top |
|
 |
nize |
Posted: Fri Oct 16, 2009 6:54 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
kimbert: ok, here (from info center) is the only reason to reference a msg set project:
Quote: |
Another use of project references is to enable Content Assist in the ESQL or Mapping editor. ("Content Assist" is context-sensitive help that displays valid ways in which a code statement can be completed.) For example, if you set up a project reference from a project containing ESQL code to a project containing a message set, the ESQL editor is able to display a list of valid message references. You can also set a reference between a data design project and your message flow projects, so that you can access database definitions in your ESQL or message maps.
|
... earlier I thought it was necessary in order to use the msg set at all
however, this is not valid for the reuse of ESQL procedures? for such reuse all ESQL must be in the same bar file? |
|
Back to top |
|
 |
kimbert |
Posted: Fri Oct 16, 2009 7:02 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
That quotation from the infocenter is talking about the Eclipse projects in the Message Broker Toolkit. In the runtime, message sets can be redeployed independently of the flows which use them, and they come into effect immediately.
And you are quite correct - this is not related to reuse of ESQL. |
|
Back to top |
|
 |
nize |
Posted: Sat Oct 17, 2009 2:25 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
Quote: |
That quotation from the infocenter is talking about the Eclipse projects in the Message Broker Toolkit. In the runtime, message sets can be redeployed independently of the flows which use them, and they come into effect immediately.
|
yes, I got that, thanks.
Quote: |
And you are quite correct - this is not related to reuse of ESQL.
|
is there another way to get flexible in a similar way with ESQL as with msg sets? I mean: deploy ESQL procedures in separate bar files, and still be able to call them from each other? Or is the only way to either deploy them together (as procedures or subflows) or to setup a "facade" calling them as flows using protocols such as MQ or HTTP? |
|
Back to top |
|
 |
|