JADE to JADE communication

[ConvertFromOldNGs]

by Frank Pitt >> Thu, 6 Apr 2000 3:49:01 GMT

Why does this that mean "a lot of additional work for developers"; the system would maintain the mapping transparently?

There would be a requirement for _whoever_ was implementing the mapping to do a lot more work than they would otherwise have to

Though yes, I would hope that the "system" would handle it automatically.

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.

Storage is an issue, but not the only one. The additional overhead added to each object is not the main concern; of greater concern would be the increase from 6 to 16 bytes in every object-reference, which would impose a significant impact on object collections in storage and performance.

True.

This is probably the best objection to incorporating UUIDs I've seen so far.
Personally, I'd dismiss the disk storage issue, storage is cheap and plentiful and anyone who quibbles over another gigabyte of storage is wasting time and money, but the in-memory requirements for a large collection would be a serious issue.

Still, for a non-external key collection, you're still looking at being able to store
a million object collection inside 20-25Mb. Ten million in 250Mb, just throw a 4Gb Compaq server at it. Compared to the JADE licensing cost, that's nothing right ?
<grin>

Let's assume that this is still a problem, perhaps we may be forced to use a non-standard UUID. Ruins our standardization, but at least makes it simple to move betwen JADE systems. Or perhaps there is another UUID standard out there for embedded systems (who really have memory issuses) that we could use ?

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.

And applying the principle that only objects that need to be accessed externally require some form of UUID, a single-server system is just a special case were no objects are accessed externally.

True.
Though my question would be how can you be sure it will remain a single-server system ?

If it didn't take much more than setting a flag and doing a reorg to share an object, then this wouldn't be such a problem ( though even reorgs can be a problem based on what I've heard ) but otherwise it would make sense to build it in from the start, just in case it has to go multi-server later.
<snip>

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.

If the chosen approach to identifying JADE objects externally is to add a system qualifier, then the telephone analogy matches quite nicely. In the absence of the capability under discussion viz. JADE-to-JADE communications, country and area code equivalents would be redundant.

Yes, _IF_ it did so. But it doesn't right now, does it ?

I've explained in another post why this sort of mix up of location and identity is a bad idea.

<snip>

Hands up, how many JADE developers are re-implementing UUIDs continually?

I doubt you'll get many hands considering how difficult it is to connect JADE objects to anything right now, and that most JADE installations I've heard of seem to be built on top of relational or older legacy systems, so they won't be interested in exporting objects, just data.

How many times have you done this Frank?

Myself, I've never done it, because I've always built systems that worked internally using either UUID or some other guaranteed unique ID.

But I was involved in a project where we had to try and maintain a relationship with an external system that had no idea of UUIDs. It was basically impossible to ensure data integrity across the link, because the system on the other end did not have any form of reliable unique identification, so we effectively ended up replicating the whole external system inside our system, and tried to ensure our "model" of the external system remained reasonably up to date.

In case you're wondering, I've never done a commercial JADE system, the areas where I've worked would probably have, until recently, thought of JADE as "toy" and not ever seriously considered using it. Now it runs on AIX, they might look at it, but would be immediately put off by the lack of support for multiple servers.

Prior to the introduction of "Live Backup" (was that 5.0 or 4.0?) that would also have caused them to laugh JADE out of the shop.

Don't get me wrong, I like the ease with which you can build things in JADE, but in terms of scalability and reliability JADE is about where Microsoft was with it's first versions of MTS & SQLServer. Microsoft have made good, they are now serious contenders in some areas. JADE has aways to go to be able to mix it with the big boys, but the kid's got spunk, see ? One day he'll be a contender...

The big benefit JADE has is it's pure object model, and _that's_ why I think it's worth investing effort in.

<snip>

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.

AH HA!, now you have actually admitted that system B only needs to use a UUID when accessing a customer object in system A, while using an OID to access a customer internally. This is perfectly true, but it is counter to all your arguments so far.

No it isn't. I was never arguing that it _needed_ the UUID internally, merely that using it internally meant that you didn't have to change your identification scheme when you went multi-server, among other benefits.

Another aspect of this scenario that you haven't mentioned, is that before they first connect, system B knows nothing about system A's objects; Prior to the first communication, system B has no knowledge of the identities of objects created by system A. In order to import an object reference (or references) from sysA, sysB must invoke some sort of service in A, and only at this time is it strictly necessary to establish an external-to-internal name mapping, which incidentally could possess one of several lifetimes (from session to lifetime of referenced object).

All true, but if you had a UUID you wouldn't need this mapping, and the "service" on A that returns the object would be exactly the same as the one that people "inside" server A would use.

BTW, again you're confusing object references with UUIDs. It's valid to have an object reference that has session lifetime, it isn't valid to have an object identifier that only has session lifetime unless it identifies a transient object.

Such a name mapping could also be implicit, if unique system identifiers were allocated to each co-operating JADE system.

I've discussed why mixing location with identity is a bad idea, and mentioned what I consider better solutions for locating objects, in another post..

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)

There are a number of ways to address this requirement, again without resorting to assigning UUIDs to all objects before-hand.

I agree, I just believe that these other ways are not as beneficial

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 !

Of course its not hard, but you have only addressed one part of a larger problem in isolation. What about larger issues of synchronising the commit of a global transaction involving multi-site updates.

That really has nothing to do with the subject.
That is up to your transaction management system, not your means of identifying objects. Though having a unique identifier for an object will probably make this easier too !.<grin>

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.

Who are you referring to in the above statement?

Anyone doing such work. Right now, this needs to be done should you wish to serve objects from JADE to elsewhere or between JADE systems.

That's not the only way to move _data_ between systems of course.

I would not be impressed if "the" JADE solution (if there ever is one*) required the developer to implement such a mapping individually for every system.

*BTW, this statement is not intended as negative. It could be a valid business decision for JADE to decide they will _never_ support multiple server systems. It would, IMO, limit their potential markets, and probably annoy a number of current customers, but it is a valid decision. The system works fines as it is for single servers, if it ain't broke don't fix it, that sort of thing.

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.

Now, where have I heard that before? Globally assigning UUIDs for all objects is *A* solution; it is not the only solution and futher it only addresses part of the problem.

Exactly. The thing is, it solves _part_ of a _lot_ of problems.

Obviously it's not a complete solution, but I'd contend it's certainly a good candidate for a step in the right direction.

Not that I'd advise anyone to accept my word for it, go out and look at other solutions,
if they work better for your circumstances, then fine. I happen to have found that in the areas I've been working they make things a lot easier, but that's just me.

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.

It could also be a lot lower overhead than just using UUIDs in the first place. Can you supply analytical evidence to the contrary, bearing in mind that you would need to consider all of a number of alternatives to your "UUID for every object" approach.

No, I can't provide analytical evidence. I seriously doubt that anyone other than a dedicated mathematician could do so. Have you ever tried to properly understand a statistical analysis of even something as simple as ethernet ? I know at one stage I have, from a paper in Bell Systems Journal, and I couldn't follow it, so I took it to my professor at the time, and he couldn't follow it either, so we took it it ot the head of the Maths department, and he said he wasn't sure, but he thought there was something wrong with the algebra, which made us all feel much better.

Based on my work on analysing frame relay and other network protocols, one would also need some serious computer power to do so as well. We regularly killed big SPARC stations when running this sort of analysis.

Oh, BTW, one doesn't have to rule out _every_ other approach, only ones that are being seriously considered.

However, I can report on a system that used UUIDs and achieved quite acceptable performance, and I have done so in another post..

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.

There are many issues to be addressed with replication, in the most flexible forms of replication conflict resolution when merging updates is a far more complex problem than simply identifying an object in a "family" of replicas.

Which is why a good replication design completely avoids the problem of merging updates by not allowing it to happen! <grin>

Yes, I agree, if you use batch replication or allow more than one user to update an object at a time, then you have those problems. Me, I'd avoid those solutions if at all possible.

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.

This final statement is perhaps the most disturbing.

Why do you find it disturbing ?
Do you really think that customers won't notice the difficulties ?

I get the feeling from your statement that you feel I should be trying to hide JADE's inadequacies. I'm sorry, but I'm not in marketing, I'm in education.

I understand that you currently work for Software Education Associates Ltd., who deliver JADE courses to current and prospective JADE users. Are we to understand that you are currently advising people that due to certain alleged design flaws, JADE will have difficulty in delivering the capabilities under discussion?

Well, personally I consider it a design flaw anyway, whether we're going multi-server/system or not.

The difficulties people have told me about when moving objects between design-time and run-time or between systems have convinced me of that. Implementing even a non-standard UUID concept would solve a number of problems even in single server.

As people seem to continually bring this up as a problem( those who have had some JADE experience prior to coming on the course) I feel it is neccessary to point out the cause, and how to try and avoid the problem.

However, if there is not some support for some form of UUID then multi-server/system is definitely compromised.

You, in your posts, have really only argued over how best to fix the flaw. The flaw is the lack of a UUID, whether it is fixed by only creating UUIDs for exported objects, by using UIIDs all the time, or some other means.

Actually, for the sort of people who are interested in this sort of thing, most of the time I don't advise them of it, they figure it out for themselves, I just get to confirm it.

Usually it goes like this, the student will say (maybe not as concisely as this ) "So if the OID is only server scoped, what happens when we add another server ?"

So I have to say "Well, basically, you can't" and then people get this incredulous look...

Some people haven't realized they can't have multiple servers up to this point, they've just asumed that, like other development systems, this is all handled by the system administrator. A dBA once laughed at this point and said to me words to the effect of "Do they seriously expect this to compete with Oracle ?". Actually he wasn't as nice about it as that, I think it involved a comparison with MS Access as well.

I can emphasize the fact that it's still a distributed system, because the clients can execute code too, as much as I like, people don't really believe it if you can't have multiple servers.

Frankie

[ConvertFromOldNGs]

by Krull >> Tue, 4 Apr 2000 21:02:20 GMT

Some more thought on this:

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

How does this algorithm scale to say 1000 servers? With this approach you would need to make the request to every server until you lcoated the object.

(depending on the number of servers, and the topology of the network the algorithm for this remote query may have to be different)

Exactly, but you seem to have to avoided this wider issue using a simple two server scenario. Elsewhere you pointed out "there is a fundamental difference between the concepts of _locating_ an object, and _identifying_ an object". That is correct, but isn't a naming scheme that not only indentifies an object but also helps to locate the object more useful than a scheme that simply identifies the object?

A classical UUID provides no useful information that could be used to locate the object and using the UUID to address a particular object directly anywhere in a network the way you would address a mobile phone for example does not scale individual fine-grain database objects. Without suggesting that this is the correct approach for JADE, the alternative of assigning an immutable and unique identifer to each JADE system co-operating in a distributed system and then using this <system identifier> + <internal OID> to externally identify the object has the added advantage that the <system identifier> also provides a direct mapping to the 'birth-place', or the system that first created the object. In your two server example extended to 1000 servers, system B given once it has obtained (and optionally persisted) the correct 'object reference' for an external JADE object can use the identifier itself to directly identify the 'primary' or birth-place server for the object by simply dialling out the <system ID>. Locating this primary server, wherever it happens to be at the time in the network requires a single lookup up of system ID to logical server, which in turn provides the required server connection parameters (assuming a connection is even required).

Now, object migration (or mobility) allows that certain objects may roam around from their original birth-place and object replication allows for replicas to exist in multiple locations. Any form of identification scheme has to address the addditional complexities these introduce with respect to locating an object.

[ConvertFromOldNGs]

by Frank Pitt >> Thu, 6 Apr 2000 3:48:57 GMT

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

How does this algorithm scale to say 1000 servers? With this approach you would need to make the request to every server until you lcoated the object.

Actually, this is _not_ an algoritm, and it's not even pretending to be.

This is a description of a requirement, the algorithm could be hierarchial or broadcast or combinations of the above, or you could use a seperate directory to identify current location(s) of the object.

This, by the way, is the normal way of handling location (see below), not building the location into the identity. Even relational databases use this sort of approach, they use indexes (a form of directory) to find objects which are uniquely identified by keys

(depending on the number of servers, and the topology of the network the algorithm for this remote query may have to be different)

Exactly, but you seem to have to avoided this wider issue using a simple two server scenario.

Nope, I was merely describing the problem, and a preferred requirement, not the solution.

Elsewhere you pointed out "there is a fundamental difference between the concepts of _locating_ an object, and _identifying_ an object". That is correct, but isn't a naming scheme that not only indentifies an object but also helps to locate the object more useful than a scheme that simply identifies the object?

No.
This confuses two totally seperate issues, identity and location, and causes the sort of misunderstanding we have already had in this discussion.

A classical UUID provides no useful information that could be used to locate the object

It's not supposed to. It is an _identifier_ not a _locator_

and using the UUID to address a particular object directly anywhere in a network the way you would address a mobile phone for example does not scale individual fine-grain database objects.

Are you therefore suggesting that JADE does not scale well ?
<grin>

I agree, BTW, but as I said location and identity are two separate issues and should be handled separately.

One of the main reasons you want to seperate these two issues is that in many situations, you don't care about the identity of an object, you just want to find an object of that type. For instance, consider a pool of servers, you don't care which server you
connect to, as long as you get _a _ server. In this case you only need the location of a server, you don't need to know which one it is.

This allows you to get services from a location, without knowing the identity of the service provider, nicely decoupling user and provider.

In other cases you want the object that is _in_ a particular location, regardless of what it is, say whichever customer is at a particular address. Later, when you want to refer to that _particular_ customer again you would need to identify that object, as they may no longer be at that address.

When you have a UUID, it is not up to you or the UUID to discover the location of that object, you should be asking your ORB or JOM equivalent to do this for you.

How the ORB does it should be irrelevant to the user.

But seeing as we are discussing it, the best sort of solution here is to take a leaf from the RDBMS world and use a directory that maintains this knowledge.

If you don't want a seperate directory, your ORBs need to maintain this information
in an internal directory. The classic hierarchial sort of algorithm here is :

Do I have the location of this object ?
If so, get object and return it, otherwise ask my children (if I have any) if they have it.
If they do, get the location, store it's last known location, get the object & return it.
Otherwise ask my parent... etc.

The benefit is that the single server system is no more complicated than it is now.

The performance of such a system can be such that on a nine-node hierarchical directed network, spread over an area the size of New Zealand, an item can be located anywhere in the network in under 250 msec. And in the case I'm thinking of, 95% of that 250msec is being used for data transmission across the wire ! If we had had 2Mbps connections between nodes (not uncommon these days), that time could be reduced dramatically

Without suggesting that this is the correct approach for JADE, the alternative of assigning an
immutable and unique identifer to each JADE system co-operating in a distributed system and then using this <system identifier> + <internal OID> to externally identify the object has the added advantage that the <system identifier> also provides a direct mapping to the 'birth-place', or the system that first created the object.

Using this algorthim one can't guarantee that the ID is unique.

It may be possible for this to guarantee that it is unique within JADE systems, as long as you had some way of ensuring the <system identifier> was unique in all JADE servers ( might be possible using license numbers or something, but it would have to be enforced internally, not reliant on system configuration )

But you cannot guarantee that an object ID will be unique externally to your system, making it no good for communication to CORBA or COM clients.

In your two server example extended to
1000 servers, system B given once it has obtained (and optionally persisted) the correct 'object reference' for an external JADE object can use the identifier itself to directly identify the 'primary' or birth-place server for the object by simply dialling out the <system ID>. Locating this primary server, wherever it happens to be at the time in the network requires a single lookup up of system ID to logical server, which in turn provides the required server connection parameters (assuming a connection is even required).

I agree, it's a nice solution for this limited setup (limited to only JADE servers or servers that you control the object ID generation on).

However even this has problems, such as what happens if an object is migrated ?

In this system, because <internal-id> is only unique inside a single server, when the object migrates, it will likely have to be assigned a new <internal-id> as well as a new
<system-id> thus invalidating _all_ existing references to that object.

Of course, if you are not allowing migration, no problem.

Also, this does not save any storage, as all references to objects must maintain _both_ a reference to <internal-id> & <system-id>, as you don't know when any particular object will be remote.

Unless, of course, you force the programmer to use code differently for "possibly remote" objects, which to me would be a great backward step.

BTW, I'm aware that programmers often have to do this sort of thing with CORBA, that doen't mean programmers _should_ have to do this sort of thing. I'm looking for JADE to maintain it's ease of use when adding functionality.
As another aside, "1000 server" systems are uncommon, so designing for them is not usually worth it (the 90% rule). Server communication and object migration will normally use up a tiny fraction of the overall capability of the system, no matter how inefficient your design.

Scalability usually needs to address increasing the number of users or the amount of data in the system. It is much more common for there to be a requirement to talk between a small number of servers, say under 20, running _different_ (i.e non-JADE) systems, which is why I harp on this UUID thing, as it makes this much easier if all the systems generate UUIDs following a standard format.

Frankie

[ConvertFromOldNGs]

by krull >> Tue, 4 Apr 2000 11:06:25 GMT

Frank Pitt

made some initial comments on the topic

[.. snipped ..]

and then went on to make the following allegations about JADE:

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.

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.

This is the sort of basic functionality problem that really causes JADE to lose ground to existing standards-based solutions.

Fixing this problem would also make allowing multiple servers and implementing replication a heck of a lot easier.

These are strongly worded 'allegations' that solicit some form of defence.
The statements made above, essentially assert there is a fundamental design flaw in JADE that will make certain features not only difficult to implement but also impossible; in particular the statement "basically allowing only the sharing of data values, not real objects", in context claims that JADE will *not* be able to share real objects because it does not use a 'globally unique identifier' to identify objects.

Clearly, all of the features under question JADE-to-JADE communications, multiple server and replication support, present a number of technical issues that must be addressed as part of the overall solution. Frank Pitt's claim is that at least one alleged issue must actually be addressed before-hand.

It is not difficult to refute the above allegations, simply by citing examples of existing systems that have added the above 'distribution capabilities' without first satisfying a prerequisite that thay already use globall unique identifiers to identify object. An OODBMs example is O2. In O2, object-identifiers were implemented as the physical disk address of an object, to avoid the overhead of a logical-to-physical OID mapping (internally). O2 now provides an external permanent logical identifer (using a BTree to map external identifier to internal OID) that can be used outside of the database to uniquely identify an object. The point is that this type of mapping is straightforward to add, when required, without affecting the structure of internal OIDs and furthermore the mapping need only exist for those objects that are deemed to be accessible outside of the 'system'.

Frank also brought up replication, claiming that solving the alleged problem [non use of GUIDs in JADE] , makes "implementing replication a heck of a lot easier". Again, use of GUIDs is only a partial solution to replication thereby diminishing the argument. Depending on the types of replication supported, objects are likely to require several other attributes apart of a globally unique name. Extending Frank's claim that JADE objects ought to really be using GUIDs so that they can be accessed externally to replication: objects should also allocate space for all the attributes required to support replication, in preparation for when replication is officially supported.

There are several approaches to solving the problem of inter-system uniqueness of object-identifiers without the need to use unique identifiers internally [as claimed] . In a homogenous JADE-to-JADE environment a simple solution would be to allocate a 'globally unique' (or JADE unique) identifer for a JADE system, then externally a JADE object could be identifed by its system qualifier + internal OID (as per the telephone the telephone analogy presented by Wanda). Another alternative is to simply provide a persistent mapping from external 'UUID' to internal OID; such a mapping would only need to be created for objects that are required to be accessed outside the system. This provides a useful optimisation for internal 'object-references', which may be used many times within a JADE system, whereas only one instance of the mapping need exist for a subset of objects within the system.

[ConvertFromOldNGs]

by Frank Pitt >> Thu, 6 Apr 2000 3:48:51 GMT

These are strongly worded 'allegations' that solicit some form of defence.

Well, given that in general you seem to agree with the allegations, your "defence" doesn't seem to be going too well. <grin>

The statements made above, essentially assert there is a fundamental design flaw in JADE that will make certain features not only difficult to implement but also impossible;

It _is_ impossible to implement a distributed object system without _some_ form of unique ID for unique objects, something which you have not so far disputed, and something which JADE itself provides.

That requirememt is maintained when other systems or servers become part of the system.

I agree, it is possible to implement such as system without storing that UUID as part of the object it refers to, but it assumes that not all your objects need to be mobile, as otherwise accepting the overhead of such a system would be silly.

in particular the statement "basically allowing only
the sharing of data values, not real objects", in context claims that JADE will *not* be able to share real objects because it does not use a 'globally unique identifier' to identify objects.

I take it you agree with this particular statement seeing as all your proposed implementations also use a globally unique identifier ?

<snip>

It is not difficult to refute the above allegations, simply by citing examples of existing systems that have added the above 'distribution capabilities' without first satisfying a prerequisite that thay already use globall unique identifiers to identify object. An OODBMs example is O2. In O2, object-identifiers were implemented as the physical disk address of an object, to avoid the overhead of a logical-to-physical OID mapping (internally).

Interesting, the version of O2 that I used back in 1990 or thereabouts made use of pointers to a virtual memory space, and did not directly refer to a physical disk address. The mapping to disk was carried out by the virtual memory system, recovery of objects was via virtual memory pointer.

O2 now provides an external permanent logical identifer (using a BTree to map external identifier to internal OID) that can be used outside of the database to uniquely identify an object. The point is that this type of mapping is straightforward to add, when required, without affecting the structure of internal OIDs and furthermore the mapping need only exist for those objects that are deemed to be accessible outside of the 'system'.

Does't anyone else find this sort of concept a bit of a kludge ?

Do programmers have to deal with external references differently than internal ones ?
If so, I'd say this solution has failed. It's not a distributed system, it's merely a system that allows access to remote objects

And contrary to your suggestion, you have not refuted my claim.
The O2 example above, and all of your suggestions _still_ implement a UUID, they just don't store the UUID with the object or use it inside a single server. My primary claim was that a UUID was required, and to me at least , the simplest solution is to assign that UUID to each object.

You have basically agreed with the first (conceptual) part of my claim, and we're now arguing implementation details.

Frank also brought up replication, claiming that solving the alleged problem [non use of GUIDs in JADE] , makes "implementing replication a heck of a lot easier". Again, use of GUIDs is only a partial solution to replication thereby diminishing the argument.

How does it diminish the argument ?
I still contend that having a UUID makes replication easier.

Depending on the types of replication supported, objects are likely to require several other attributes apart of a globally unique name.

Agreed, this is likely, though it is possible to implement without additional attributes,
such solutions are only appropriate for small systems with not many mobile objects

Extending Frank's claim that JADE objects ought to
really be using GUIDs so that they can be accessed externally to replication: objects should also allocate space for all the attributes required to support replication, in preparation for when replication is officially supported.

And the problem with this is ?

While I agree that if one still has no idea how to support replication, then it's pointless just reserving random memory, but if one has a solid plan for it, it would make sense to build in the underlying infrastructure as soon as possible.

There are several approaches to solving the problem of inter-system uniqueness of object-identifiers without the need to use unique identifiers internally [as claimed] .

Not as claimed. As set up as a straw man by you.

In a homogenous JADE-to-JADE environment a simple solution would be to allocate a 'globally unique' (or JADE unique) identifer for a JADE system, then externally a JADE object could be identifed by its system qualifier + internal OID (as per the telephone the telephone analogy presented by Wanda).

The problem with this solution is that you would not be able to uniquely identify an individual object independant of it's location. In other words, it's _location_ would be bound in as part of it's _identity_.

To continue the phone analogy, while this may be appropriate for fixed landline phones, it is not really appropriate for mobile phones, which need to be identifiable independant of location. The current "solution" to this problem in the phone world is still a kludge as mobile phones have been allocated their own "space" in the fixed landline model, one that does not correspond to real world space.

While this works (and would work for mobile objects too, say inside all JADE systems ),_Global_ roaming ( which would be sharing objects to non-JADE systems ) is even more of a kludge, requiring explicit set up by the involved telcos, and sometimes changing the hardware on the phone !

Although you can implement such a system, and it will work, and may even provide better performance on small or largely fixed systems, it is basically a kludge, and it gets harder to deal with as systems become larger with more interconnects, requiring more and more communication between providers to arrange it.

In general, confusing location and identity is a bad thing.

Another alternative is to simply provide a persistent mapping from external 'UUID' to internal OID; such a mapping would only need to be created for objects that are required to be accessed outside the system. This provides a useful optimisation for internal 'object-references', which may be used many times within a JADE system, whereas only one instance of the mapping need exist for a subset of objects within the system.

This is definitely possible, my argument was merely that this is harder to implement than using a UUID for all objects. Especially if you are also trying to carry out replication.

Again, such an implementation would need to be transparent to the developer, otherwise it is no longer a distributed system, but just a way to access remote objects.

Frankie.

[ConvertFromOldNGs]

by Iain S. Kerr >> Tue, 30 May 2000 7:49:44 GMT

There seems to be a lot of interest and lively discussion on this subject. Would it be possible for three or four of the experts on this area to get together over a period and put a White Paper together that covered the main issues involved and looked at a few solution scenarios and then put those to the Jade Plant to see if they could come up with some time frames etc for implementation of this rather important subject.

[ConvertFromOldNGs]

by Krull >> Tue, 30 May 2000 21:32:18 GMT

Iain,

Are you primarily interested in JADE to JADE communications or the wider aspects of object distribution. If you want to discuss this in an open forum or even in a white paper please start with the business requirements rather than stating how to solve the problem. The discussion that arose from some negative statements of the form "The curent major problem with JADE talking to JADE ...." and "until that's fixed...", which hinted at a design flaw in JADE. Allthough the discussions may have been "lively", they were not particularly constructive. The follow up arguments from me in particular were aimed *solely* at debunking the negative claims made by Frank Pitt, which as worded in his original post are false; we ended up with a slanging match rather than a discussion on how the problem (subject of thread) might be addressed in JADE.

[ConvertFromOldNGs]

by Robert Barr >> Thu, 8 Jun 2000 0:54:04 GMT

... start with the business requirements ...

Okay then, here's a business requirement for JADE to JADE communication (which incidentally, doesn't appear to suit Frank's distributed object identification or addressing solution). Variations on the following generalised requirement have come up on at least 6 JADE applications I can think of.

Take two JADE systems - JADE system A is the authentic source of some data. I want a copy of this data in JADE System B. In some cases, new instances are also sometimes created in JS-B, and these need to be updated in JS-A (the authentic data source). Sometimes, the requirement has been for a synchronous communications mode (real time), sometimes async. Assume that the availability of the remote system cannot be guaranteed. Here's a list of development tasks - assistance from JADE appreciated.

1. Establish, secure and manage the physical connection
2. Asynchronous - build a message queue function that guarantees
delivery sometime, within configurable limits.
3. Synchronous - build an exception handling layer for real-time transaction processing.
4. Hand-build messages consisting of selected attributes of the objects and (selected) child and peer objects). I tend to use delimited text messages as a compromise between performance and readability for diagnistics.
5. Messages sometimes include versioning and sequence numbers for duplicate recognition. (I've used a couple of techniques to help guarantee inter-system transaction commit, but never found a solution thats bulletproof).
6. Manage changes to the static (class) definitions and related message definitions in the two systems.

Hope this helps.

... rather than stating how to solve the problem. ...

You ask this of techies? Dream on

Some of CORBA's work on object metadata description and interface packaging may be relevant/of interest, especially in light of the
success of IIOP (bridges for MS-COM and EJB are proliferating). Of course, borrowing from this model may also offer ORB interoperablity benefits.


Cheers,
Rob