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
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
