[Mono-list] J2EE/.NET/WDNA De-mystified

[A Rafael D Teixeira]

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 
API/Implementation.

>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) 
environment.

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 
future demands".

Sorry for the long message...

Cheers,

Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker




_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963