by
Frank Pitt >> Tue, 4 Apr 2000 3:09:16 GMT
Jade currently has no built-in support for either, though support for CORBA is "on the wish list".
On the contrary, JADE currently does provide 'built-in' support for COM; furthermore, COM support has been extended in each major JADE release.
OK, I apologize, what I said was wrong , JADE does have "built-in" support for exposing functionality via COM. And yes, you can use the "Exposure Wizard" to generate DLL's to expose stuff to COM.
However, I didn't really say what I meant either.
What I was trying to get at is that JADE doesn't just serve COM objects on demand,
you have to explicitly use this Exposure Wizard, and you need to generate a DLL.
I'll admit I'm being really unfair here, as Microsoft still haven't understood COM properly themselves yet, and AFAIK also haven't produced a COM server that works without using DLLs, so expecting JADE to do it is a bit of an ask, though I believe there are some Enterprise Servers that can serve CORBA objects as COM and vice versa, even from non-Microsoft platforms.
( Completely off topic, but the COM specification is not tied to Microsoft platforms, and doesn't really require it's objects to be provided as a DLL or EXE, they merely have to match the binary standard for COM objects. The DLL or EXE is merely the "package" that the Microsoft "COM server" ( it's operating system) uses to persist the COM objects between uses and load them when required.
Perhaps one day they'll do it right ! )
The curent major problem with JADE talking to JADE or serving JADE objects to anything else for that matter, is the fact that they don't use GUIDs (Globally Unique IDentifiers), only _system_ unique identifiers.
I don't agree that this is a major problem at all and JADE *does* in fact use GUIDs for interacting with COM.
Well, it has to, doesn't it ?
The point though is that the GUID is not used internally in the JADE database.
BTW I should probably have used the more generic term, UUID, rather than the Microsoft-specific GUID, so will do so from now on.
Are you advocating that all JADE database objects are identified by a GUID? If so, I strongly disagree. Within a JADE system, objects are identified by a system unique object-identifier or OID and that is all that is required to access objects within a JADE system. When you need to identify a JADE object outside of a JADE system, all that is required is a suitable qualifier or mapping that ensures 'inter-system' uniqueness. The mapping is only required when you need to reference an object externally, not before.
True, but in any serious distributed system you will then have to _maintain_ that mapping. This means a lot of additional work for all developers which can be avoided if the underlying object database uses UUIDs internally.
The point is that you are using a unique identifier anyway, so why _not_ use a UUID ?
It's not like storage is a huge issue here, and it's only 16 bytes anyway.
For efficiency within a single server system, you could use just part of the UUID if you thought it was that much of an issue, as in your analogy below.
A simple
analogy is telephone numbers; when making a local call, within a city, you don't need to provide the area or country codes.
This is a poor analogy to support your argument as telephone numbers _are_ globally unique if you _do_ include area or country codes, which exist anyway, whether you use them or not. i.e: while you may never use 064 when phoning a number in New Zealand, it is still part of that number, and you _could_ use it internally if you wanted to.
(BTW, some of Vodafones callback numbers uses 064 even when calling within New Zealand, just in case the owner of the phone happens to be overseas at the time, so even here there is a case where using the complete "UUID" makes sense )
Following your analogy, JADE does not provide the area or country codes at all, so when you _do_ want to talk non-locally, you are in trouble.
Further to this, a fine-grain database object is not the typical granularity for distributed objects and is not a requirement for communicating between systems using either of the major standards COM or CORBA.
Actually, for any serious _object_ database work such fine granularity is essential.
Why do you think JADE implements a unique system OID ?
The reason you won't see it in most big CORBA/COM implementations is that they aren't using object databases. When working against a legacy system such as a relational database, it is usually not efficient to try and provide UUID's for the existing data, or to map every data-item to an object instance.
It may not be a _requirement_ for communicating with COM & CORBA, but if you don't do this then you're forcing developers to continually re-implement a meaningful UUID on top of one that already exists and would be adequate for the purpose if it was a UUID rather than just a system UID.
COM uses GUIDs to
identify object types (or classes) and interfaces not object instances.
While I admit that this the main thrust of Microsoft's current implementation of COM,
the COM specification is designed to fully support data object instances as well.
Even the ones you mention actually identify instances. The CLSID identifies an instance of the Class class (to use the JADE equivalent, can't remember the COM name), and the IID identifies an instance of the Interface class.
In COM, object instances are identified using "Monikers".
<snip>
This is incorrect. A "Moniker" is Microsoft's implementation of the concept of a URI, or Universal Resource Indicator. Monikers are designed to provide a means of _locating_ an object instance.
In other words, they are equivalent to a CORBA object reference :
On the other hand, CORBA uses 'Object References', a transient, opaque <snipped discussion of CORBA object references>
The CORBA equivalent of a UUID is _not_ the object reference but the PID or Persistant IDentifier.
I think the fact that JADE uses the OID as both identifier and as the value placed in an object reference is confusing you here. There is a fundamental difference between the concepts of _locating_ an object, and _identifying_ an object.
A CORBA object reference is equivalent to a COM Moniker, which in turn is equivalent to a JADE object reference. All three allow the user to locate an object.
But a CORBA PID is equivalent to COM GUID, which is equivalent to a JADE OID, and these allow one to _identify_ an individual object
It just so happens that in JADE the _value_ stored in a JADE object reference is the same as the _value_ of a JADE object's OID, because due to the way the JOM works, the identity of an object is also always enough to also locate the object.
Until that's fixed, any communication is going to have to be overly complicated, basically allowing only the sharing of data values, not real objects.
Before we talk about fixing a problem, the problem needs to be defined. What problem are you attempting to solve?
The problem of connecting multiple JADE systems that Eric originally brought up.
This is the sort of basic functionality problem that really causes JADE to lose ground to existing standards-based solutions.
WHY!
Basically, while I fully agree that many systems, and definitely most NZ systems can be run quite happily on a single server, many DP types get very antsy when told they can only have a single server on a JADE system. Especially for high availability or high security systems, rules often state that any such system _must_ have at least dual servers, and they must be in different cities.
While one can argue whether this is really neccessary, the fact remains that some people with purchasing clout believe it is. I'll admit I'm inclined to agree with them, especially if your servers are located in earthquake prone locations !
Fixing this problem would also make allowing multiple servers and implementing replication a heck of a lot easier.
Please explain why you think this is so!
OK.
I contend that the major difficulty in allowing replication between servers, and even of allowing multiple servers on a JADE System at all, is that JADE only has single server scope when it comes to allocation of unique identifiers
Let's specify an example in detail.
Assume I have a Customer class defined in JADE.
Assume that this exact same Customer class is used in two separate JADE systems using the same schema, system A & system B.
Now,
I want an individual Customer object created in System A to be used from System B.
It should be possible to identify the object in System A and update that object from System B without having to "re-create" the customer object in System B, and update it back to System A with no persistent affect (other than perhaps some secondary transaction logs) on System B. All that should be required is that System B understand the same schema as System A.
And it should be possible to do this merely by connecting to the JOM on System A and requesting the Customer object containing a particular UUID, in exactly the same way as you do internally to System B with an OID.
In fact, in a predefined (as opposed to an ad-hoc) network, the user should request the object from System Bs JOM, which, when it finds it doesn't exist locally, should then query SystemA's JOM automatically (depending on the number of servers, and the topology of the network the algorithm for this remote query may have to be different)
This sort of stuff is not hard, I was involved in writing this sort of code for a mobile radio network. There, the objects (the mobile radios) could change server of their own accord, and without informing the system, and we still had to find them !
But it requires that the objects be uniquely identifiable across all servers.
With JADE as it is, any attempt to migrate objects of the same class between servers (or systems) requires implementation-dependant creation of a UUID on top of the system UID, and if you want to use the object between two systems in the future it requires you to continue managing and maintaining the relationship between the two system UIDs, which is not something you want to write more than once.
With a UUID, none of this would be neccessary, an object with the same UUID would be the same object, no matter where it currently was, and no matter how many copies we might have.
This _could_ be solved by having JADE automatically maintain such a relationship between the systems, but that would be a lot of addittional overhead for something that could be more simply implemented by just using a UUID in the first place.
Obviously, there are replication issues with holding instances with the same UUID on multiple servers, but these are solvable using such concepts as master-slave copies, it's merely a matter of choosing which update strategy would be most generally appropriate, or even allowing the developer to chose the update strategy depending on the likely mobility of the object.
If I am wrong about all this, and you can easily have multiple live servers with replication on a JADE system, or equivalently, easily migrate objects backwards and forwards between systems, in some other way, then I'd really like to learn how, as I will have been giving people the wrong information, which I don't like doing.
Frankie