| Author |
Message
|
| jacquesvdm |
 Posted: Wed Mar 14, 2012 10:26 pm Post subject: Message Broker 8 Custom Nodes |
 |
|
Apprentice
Joined: 18 Jan 2012
Posts: 29
|
Hi
Do anybody know if it would now be possible in WMB8 to code custom nodes in DOTNET C# or C++. Previously only Java and C was supported.
I know you can now invoke DOTNET classes using the new DOTNET node but that is not what I am after.
thanks |
|
| Back to top |
|
 |
| mgk |
| Posted: Thu Mar 15, 2012 1:36 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| I know you can now invoke DOTNET classes using the new DOTNET node but that is not what I am after |
In V8 you can create nodes using the .NETCompute node, which can be "midflow" or "end of flow" nodes in any .NET CLR v4 language (C#, VB, F# etc). What exactly is it you are trying to do in a custom node?
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| jacquesvdm |
| Posted: Thu Mar 15, 2012 5:03 am Post subject: |
|
|
Apprentice
Joined: 18 Jan 2012
Posts: 29
|
Hi
I have to use third party IP's soon which are written in C++ and just need to assess the options available. I wanted to develop plugin nodes for this purpose (e.g PABX communication node) which can be re-used by other developers. Some of the PABX api's are plain JAR files which are fine but the others are C++ APIs.
Currently it looks like I have to create a sub flow which can then use the DOTNET node. I would then have to distribute the sub flow to all projects that want to use the PABX communication service. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 5:07 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
An alternate way to think of the design is to encapsulate the PABX functions into a Web Service, then use SOAPRequest node in your message flows to interact with the Web Service you created.
That way, no custom nodes are needed, and your performance is measurable.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jacquesvdm |
| Posted: Thu Mar 15, 2012 5:09 am Post subject: |
|
|
Apprentice
Joined: 18 Jan 2012
Posts: 29
|
That is an excellent sugestion.  
Thanks for that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 15, 2012 5:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
An alternate way to think of the design is to encapsulate the PABX functions into a Web Service, then use SOAPRequest node in your message flows to interact with the Web Service you created.
That way, no custom nodes are needed, and your performance is measurable. |
And you've also introduced an additional layer and an additional component that needs to be managed, adminstered, and secured.
It is possible to compile and package subflows as user defined nodes. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 5:14 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
There are always trade offs. Segregating the functionality in the way I described supports automated build and deploy through regressions tests, possibly using Junit.
If people think in the human-supervised automation vein, you get more bang for your buck rather than having the human do all the work. If the human does all the work, you are dependent on specific humans. If that person goes on vacation, sometimes things get bogged down.
If you use human-supervised automation to manage your IT systems, then the specific human is not relevant. Of course, some of the humans might feel that they are not needed as much.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| There are always trade offs. Segregating the functionality in the way I described supports automated build and deploy through regressions tests, possibly using Junit. |
And packaging subflows as user defined nodes doesn't?
Seriously, I'm asking. I don't know.
Or packaging them as seperately deployed subflows? Which may be the same thing (another thing I don't know)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jacquesvdm |
| Posted: Thu Mar 15, 2012 5:25 am Post subject: |
|
|
Apprentice
Joined: 18 Jan 2012
Posts: 29
|
Hi MQJeff
That is also valid, thanks for all the valuable input.
Regards |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 5:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| There are always trade offs. Segregating the functionality in the way I described supports automated build and deploy through regressions tests, possibly using Junit. |
And packaging subflows as user defined nodes doesn't?
Seriously, I'm asking. I don't know.
Or packaging them as seperately deployed subflows? Which may be the same thing (another thing I don't know)? |
IMHO PABX functionality is more useful outside of the Broker engine rather than in it.
http://en.wikipedia.org/wiki/Separation_of_concerns
Other people may have different opinions.
| Quote: |
Software build automation
Most project organization tasks are seen as secondary tasks. For example, build automation is an approach to automating the process of compiling source code into binary code. The primary goals in build automation are reducing the risk of human error and saving time.
Normalized Systems
In Normalized Systems separation of concerns is one of the four guiding principles. Adhering to this principle is one of the tools that helps reduce the combinatorial effects that, over time, get introduced in software that is being maintained. In Normalized Systems separation of concerns is actively supported by the tools.
|
By separating the PABX functions into a callable Web Service, you more support the loose-coupling, Service Oriented Architecture concepts.
http://en.wikipedia.org/wiki/Service-oriented_architecture
| Quote: |
Principles
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:
reuse, granularity, modularity, composability, componentization and interoperability.
standards-compliance (both common and industry-specific).
services identification and categorization, provisioning and delivery, and
monitoring and tracking.
|
I ask the question, what does PABX code have in common with WMB engine code? I answer myself, "Not much." Thus, why infuse PABX code into the WMB engine? I ask myself another question, Why not make full use of loose-coupling rather than the tight-coupling of user defined nodes? I answer myself and say, SOA Loose-Coupling is a wonderful concept that helps manage systems in an automated way.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 15, 2012 7:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| SOA Loose-Coupling is a wonderful concept that helps manage systems in an automated way. |
A WSDL defines an extremely *tight* coupling between two well described end-points.
If the Message Flow is already acting as a webservice endpoint that is designed and intended to provide an SOA contract wtih the rest of the enterprise, what value does it add to include an additional separation of concerns?
Why not write a third webservice to abstract the details of PABX from the details of the webservice that is abstracting the details of PABX from Broker?
It's turtles all the way down. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Thu Mar 15, 2012 8:42 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| lancelotlinc wrote: |
| SOA Loose-Coupling is a wonderful concept that helps manage systems in an automated way. |
We have 2012 now and not 2002: It turned out that there is a lot of integration work left to be done (even when using WebServices) and that a lot of big companies just do not call web services here and there (but often replicate data between their different systems... to have instant access)... whats the benefit of calling a web-service (which might not be available) at the end of the other side of the world ?
_________________
Just use REFERENCEs
Last edited by mqsiuser on Thu Mar 15, 2012 8:55 am; edited 1 time in total |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 8:54 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqsiuser wrote: |
| lancelotlinc wrote: |
| SOA Loose-Coupling is a wonderful concept that helps manage systems in an automated way. |
We have 2012 now and not 2002: It turned out that there is a lot of integration work left to be done (even when using WebServices) and that a lot of big companies just do not call web services here and there (but often replicate data between their different systems... to have instant access)... whats the benefit of calling a web-service (which is not available) at the end of the other side of the world ? |
I am assuming the OP's PABX system is in the same area as the Broker runtime (ie. not on the other side of the world, although I could see a datacenter in Cebu in my future). I am suggesting a way to scope the project's artifacts that make it more maintainable and more SOA-compliant.
Your statement about replicating data is true for many organizations. They should not do that.
Also, I would expect more re-use out of the Web Service. For example, an application that uses the Web Service to query the status of various PABX states. I would expect the WMB interface to the PABX Web Service to set various things inside the PABX according to the transaction being processed by WMB. Some other application (a GUI perhaps) would want to inquire the status of those things, perhaps not using WMB.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 15, 2012 8:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| perhaps not using WMB. |
Again, that's likely exactly what is trying to be avoided here.
The advantage of an ESB is that you know that everyone is using the right interface in the right way and is following the contract defined for the service you have developed. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 9:42 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
| perhaps not using WMB. |
Again, that's likely exactly what is trying to be avoided here.
The advantage of an ESB is that you know that everyone is using the right interface in the right way and is following the contract defined for the service you have developed. |
In general, I promote the concept that the ESB be the central point of contact within an organization. There are circumstances where direct connections are useful. Not all Web Services traffic has to make the intermediate stop in the ESB. Now, if the ESB were located in the Pac-Rim....
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
