I definitely agree with you that this is not an easy issue.  It appears, 
however, that you have focused on one approach to RTI to RTI 
interoperability - an over the wire standard.  In my earlier email I 
declined to comment on specific approaches to RTI interoperability and I 
am still reticent to start down this path..... but

I would argue that as you have that an over the wire standard is overly 
restrictive and unnecessarily limits the flexibility of RTI developers.  
It is this very flexibility that will be required to insure that RTIs can 
be developed that will meet the needs of all users.  Some might perform 
well on the range, others over wide area nets, still others may exhibit 
very low latency on local nets, etc..

However, an over the wire standard is is not the only approach to RTI 
interoperability.  For those who are interested I presented a paper at 
the fall conference to the RTI forum evaluating both the need and 
possible approaches to RTI interoperability at a top level (98S-SIW-188, 
entitled "A required RTI gateway standard as a solution to RTI 
interoperability").  As the title suggests I favored an RTI gateway.  The 
rationale for promoting an RTI gateway was two fold:  1)  It didn't 
overly restrict RTI development freedom, and 2)  It seemed to meet what I 
perceived as the main requirements for interoperability.

Still, I would rather not focus on possible solutions at this point until 
consensus is reached on the basic requirements.  The solution selected 
will depend on ones evaluation of the requirements for interoperability 
and we shouldn't as they say "put the cart before the horse."

In my opinion, achievable solutions to RTI interoperability exist and 
need to be considered.  If we don't, the HLA may be a giant step 
backwards in terms of interoperability.  

As to further postings, I know that these discussions can get carried 
away at times, but I believe you raise some excellent points in your 
email that need to be considered in evaluating any attempted solution.  
If you have further comments please do not defer from posting them.  Only 
through a thorough and open discussion of the issues can we hope to 
achieve a solution.


Message from Steve Bachinsky sent 5/4/98 8:19 PM.

>Whew... I feel kind of beat up for initially stating that we may not be
>ready to address RTI interoperability. I am afraid that this is one of
>those discussions that could go on forever. As much as I cringe at sending
>another email on the topic, I would like to clarify my position. I promise
>to stop after this email ;-)
>I believe as much as anyone else that RTI interoperability would be
>beneficial, the problem is that I am not sure that everyone appreciates the
>issues associated with developing a mechanism to ensure interoperability.
>Interoperability would require much more than an "over-the-wire" protocol
>standard, it would unfortunately have to imply implementation details of
>the RTI. This is bad since after four years only one fully functional RTI
>has been built (RTI 1.3 from the MITRE/Lincoln team), so as a community we
>are not in a position to specify how (and under what conditions) a feature
>of an RTI should be implemented.
>Lets look at a brief interoperability example -- ownership transfer. First
>off, the different RTI implementations would need to use the same
>representation for federation unique object ids. Do the RTIs use a
>combination of (unique federation id, unique federate id, and a local
>counter), or does it use a central id server that hands out unique ids? If
>different RTIs need to interoperate they will need to coordinate on id
>generation schemes to guarantee uniqueness. Next, when the local RTI
>component needs to request ownership transfer of a particular attribute how
>does it find out the federate that owns the attribute. Does it broadcast a
>message to everyone asking for the owner, does it communicate with a
>central server that holds a list of attributes and federates, do the RTIs
>broadcast object registration in which case the attribute owners are cached
>The point I would like to make is that there are various implementation
>decisions that can be made in developing an RTI. In order to ensure
>interoperability the RTIs would need to agree on what type of messages need
>to be exchanged between local RTI components, the representation of those
>messages, and how those messages are to be exchanged. Standardizing on the
>how/what/when of RTI-RTI messages will constrict implementation choices,
>(and if you disagree please explore defining a interoperability standard
>for different reliable multicast protocols without impacting performance).
>Attempting to define RTI interoperability standards at this point will
>inhibit the development of RTIs which either attempt to optimize behavior
>based on particular operating conditions, and it may prevent RTI developers
>from exploring different techniques and technologies. Additionally there
>does not appear to be a real need for RTI interoperability at this time, I
>don't understand why it is unreasonable for federation *executions* to use
>a single RTI implementation. Yeah, yeah the software may not be ported to
>all platforms, but this can be solved with a small fraction of the energy
>it would take to implement interoperability.
>The bottom line is that although I recognize the usefulness of RTI
>interoperability I think we are not experienced enough to make concrete
>standardization decisions, I believe that there are more meaningful tasks
>to examine.
>Just my opinion (now I'll unsubscribe :)  Steve


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