At 1:27 PM -0400 5/1/98, Steve Bachinsky wrote:
>I don't believe that this is as bad as you make it out to be. The Object
>Management Group which has been responsible for successfully developing
>distributed computing standards under the CORBA environment initially used
>the same approach. The interfaces and functionality between the
>applications and the ORB software were standardized, but ORBs from
>different vendors were not interoperable. Once they gained experience with
>different ORB implementations, they went through a process to standardize
>on the elements that would make different ORBs interoperate.
>They only issue is that until RTI interoperability issues are resolved
>*instances* of federation executions will need to use the same RTI (or RTIs
>that are interoperable). These same federates will be able to easily switch
>between vendor A and vendor B (provided that RTI A and RTI B are compliant
>with the Interface Specification) between executions.

   A couple of perspectives here.  RTI 1.3 is an experiment, RTI 2.0
is intended for production use.  They have very different requirements,
so compatibility is probably not a reasonable expectation.

   The RTI is not like the ORB.  CORBA services operate in domains
like enterprise computing where software architecture is only vaguely
related to hardware architecture.  In some simulation domains the
hardware architecture provides substantial design drive into the
software community.  That is why only a few simulation activities
have taken advantage of CORBA's features, in fact it is the reason
that the HLA does not embrace CORBA as it once did.

   To provide acceptable cost/performance in these simulation
domains, an RTI must be implemented to exploit the underlying
hardware architecture.  As a result, RTI A and RTI B will most
likely not run on the same hardware.  A federate being ported
from RTI A to RTI B is probably also being ported from NT to
Unix.  These are not zero-cost operations.  If we assume that
they will be free, we will be wrong.

   All this is well and good, unless you want to make a federation
with an RTI-A federate and an RTI-B federate.  You have to change
compilers, network OS, and a bunch of other (non-HLA) stuff.  This
will cost real money.  Don't you wish RTI-A could talk to RTI-B??

   Moreover, I am terribly concerned that in order to get a model
to run you must design your FOM to exploit the implementation
details of your RTI.  If this is true, and evidence is at best
anecdotal, then two RTI-A federates might not be able to run
together if their FOM-approach is too different.  This would lead
down a slippery slope indeed.  Models can now inter operate but
they no longer do what you want them to do.

   There are many serious issues here, and much work to be done
before we solve them.  I don't know if we can task a group to
fix any of them, we are relying on the RTI&C PRP to surface them.
I believe we must put groups on the ones that the PRP thinks we
can solve.  I didn't understand the outbrief point to say that
a solution is in sight.  I read it as a simple "red flag" that
told us that when a solution was spotted we would need to move
to embrace it.  I understand a group tasked to embrace and tell
the world about a solution.  I'm not sure I understand a group
tasked to point out the dangers of a problem without being able
to solve it.  Individual papers seem to do as good a job of that,
as far as I'm concerned.

/Randy Saunders
Raytheon Systems Company
(248) 619-8321
[log in to unmask]

To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: