| Author |
Message
|
| madiba |
 Posted: Tue Jan 03, 2006 12:38 pm Post subject: Java vs .NET |
 |
|
Novice
Joined: 14 Oct 2005
Posts: 23
|
This topic probably has been discussed here in the past, but I searched the forums and couldnt find it. We are at the beginning stages of a new MQSI version 6 on Windows implementation. We have the luxury of being able to choose either between doing our MQ development in Java or .NET...however would prefer .NET. I wanted to put the question up for debate to see what the pros and cons are for the Java or .NET development paths. For example, are there more support for .NET than Java i.e. more MQ classes for .NET than Java? Are there any significant performance differences between the two approaches? etc, etc.
Hope to hear from all you gurus out there.
THANKS IN ADVANCE. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 03, 2006 1:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This isn't really an MQSI /WMB question, though.
You can't write anything for WMBv6 in .NET. You can write Java compute nodes and plug-ins.
As to the comparitive merits of the development platforms themselves, for general purpose MQ application development...
They're both Turing complete - and what's best for me may not be best for you.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| madiba |
| Posted: Tue Jan 03, 2006 2:22 pm Post subject: |
|
|
Novice
Joined: 14 Oct 2005
Posts: 23
|
| Sorry. I guess my question was kinda confusing. What I really meant was that if I was suppose to develop apps that will interact with MQ i.e. putting messages in the queue, retrieving messages from it, etc. which technology Java/.NET would be better. For example, I need to develop an application that will pick up a file and process it by sending the individual records that make up this file as messages to MQ. Also, another scenario is the transfer of files i.e. put the file in a message queue for transfer to another server. Files are all below 20MB in size. Are there any dis/advantages to going with Java/.NET? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 03, 2006 3:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This really depends on your familiarity with the development environment.
The other aspect would be portability.
Using .NET you have portability across the Windows environment
Using Java you have portability on all platforms
Using JMS you have portability across JMS providers...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 04, 2006 12:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We use both Java and .NET with MQ for application adapters.
The advantage of Java is that IBM have supported it for longer with MQ, it has much better integration with WBIMB and it is cross-platform.
Sometimes using JMS can be a little confusing as the options are mapped over to MQI options so you have to understand both JMS and MQ.
However as an application adapter language, there is not much difference, I would use whatever you feel most familar with and have the best support for in the longer-term. |
|
| Back to top |
|
|
| madiba |
| Posted: Wed Jan 04, 2006 11:33 am Post subject: |
|
|
Novice
Joined: 14 Oct 2005
Posts: 23
|
| jefflowrey wrote: |
This isn't really an MQSI /WMB question, though.
You can't write anything for WMBv6 in .NET. You can write Java compute nodes and plug-ins.
|
....just brainstorming here.....I noticed that it is possible to import a web service into WMB in what I assume would be a node. If you really wanted to stick with .NET development, would this be a route you could go to insert a .NET web service into your message flow instead of a Java compute node? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 04, 2006 11:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No. It's not possible to import a web service - merely the Web Service Description Language.
You could invoke a .NET web service, but in no way is it "inserted into" your flow. It's just another web service, and would need to be invoked using the HTTP* nodes.
In other words, your .NET web service would have to be running in some web service container OUTSIDE broker.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
