[Mono-list] J2EE/.NET/WDNA De-mystified
A Rafael D Teixeira
Sun, 30 Mar 2003 02:02:38 -0300
David Jeske wrote:
>JMS - Java Messaging Service
> Often you need to send messages out from one component, to be
> received by another component, without knowing where these
> components live. You do this with JMS....
Well I would like to point that messaging truly important varying dimensions
are time and identity so the sentence would be more like:
Often you need to send messages out from one component, to be
received by another component(s), without knowing WHEN these
components will receive them or WHAT components really want those.
JMS advantages are:
- Support for many 'providers', acessing different queue services backends.
System.Messaging only works with MSMQ. Mono.Messaging will add this
capability to Mono, and may be proposed to ECMA to retrofit in .NET.
- Besides FIFO/Priority Queues (that MSMQ/System.Messaging also have) JMS
provides a Publish/Subscribe mechanism around a so called Topic. Again
Mono.Messaging and MonoQLE are planned to give Mono this needed
>JNDI - Java Naming and Directory Interface
> A means to store and retrieve configuration information. The JNDI
> provider can have a backing store in any number of places. JNDI is
> often used as an interface to access the Windows Registry.
Again JNDI is an API supporting multiple providers. JNDI is a "find me a
resource I need" API.
You've mentioned the Windows Registry provider, but the LDAP provider is
probably a lot more sensible as an example of when and where you use JNDI.
For instance: a lot of samples for using JMS start by querying a LDAP
database with JNDI, what JMS providers/servers are available, and then what
Queues/Topics should be used on them. You also have a DNS provider and a
File System provider for JNDI, among others.
============================ Second Part
I think the real selling point of J2EE is uniform manageability/
configurability across a large range of system architectures. You deploy and
manage a new application always in the same manner. And, for some
implementations, that holds true even between very disparate hardware
configurations: from a all-in-one appliance box, to a very large farm of
scaled-out (identical) servers, to a really distributed (read non-uniform)
My uttermost goal in helping Mono, is to give it, and therefore ECMA/.NET,
the ability to compete for enterprise developers.
Because as cool as C# is as a language and CLI as an
infrastructure/runtime/class library, IT managers won't bet on running their
business applications on it, unless:
1 - they have choice: of implementation (to a lesser degree) and of
platform/operating system (to the highest degree).
2 - they are able to mix things: either to use legacy equipment/ software in
brand new solutions, and to judiciously buy the best hardware/server
software/infrastructure only when scalability changes demand and to be used
where it improves the most the overall solution.
3 - they can easily swap as needed commoditized technology like: databases,
queue servers, security mechanisms, etc.
3 - they are able to scale all the way up. And without having to rewrite the
application, not even a small part of it.
4 - they feel it can decouple from MS' historical track of security mishaps.
And the list can grow endlessly, so I'll stop here.
Just an historical note: VB became a success in IT only because it gave RAD
features before any other language. You see: the alternative back then was
to write hard to debug c/c++ code with the dreaded big switch statement in
the window procedure . Then when it was losing its grasp on developers
starting to design n-tier solutions and so facing scalabity issues, its
integration with MTS/COM+ brought some limited scalability. But again the
alternative was to write CORBA applications in some other language, a
terrible fate to a VB programmer.
Today, while C# and VB.NET, IMHO, surpass Java a bit in features, they are
mostly catch up to a true OO environment/language. And most importantly: the
.NET framework, as told by others in this thread, currently is tied to COM+
and family (ActiveDirectory/MSMQ/etc..) for most enterprise features, so it
is severely limited when competing with J2EE. Worse: VB.NET isn't plain VB
anymore, it is OO now, and that scares the hell out of many VB developers;
Summary of the opera: I saw many people I know at Microsoft Brazil,
struggling during the last two years to sell .NET to many clients (and I
tried to help them sometimes...) and receiving a "It's cute, but maybe next
year..." message. And, believe me, sometimes the clients where sincere
enough to add "... because .NET isn't ready to deal with my current and
Sorry for the long message...
Mono, MonoQLE Hacker
Protect your PC - get McAfee.com VirusScan Online