April 8, 1997 Meeting Minutes

Proposed Agenda

• Performance
  • Review work on "outlining".
  • Review progress on finding lost performance.
• Object Adapter
  • Review BOA API presented in CORBA 2.0 specification and discuss TAO ROA API.
  • Discuss possible implementation strategies to maximize portability with existing/future commercial ORBs. (i.e., should the BOA represent CORBA 2.0 API with pure virtuals and TAO ROA inherit from BOA?)
  • Discuss strategy and schedule for integrating de-layered demux into TAO.
• Runtime/ORB Core
  • Review architecture for Reactor-based server runtime for TAO.
  • Review current implementation for Reactor-based server runtime for TAO.
  • Discuss strategies for eliminating nasty scoped globals in current implementation.
  • Discuss a connection model/architecture for clients.
  • Which component--OA or ORB--manages sockets or socket information?

Actual Minutes

Participants

Chris Cleeland, Brian Mendel, Andy Gokhale, Doug Schmidt

What Happened

• Deferred major discussion of ORB Core details until next Tuesday's 1pm code/design review. One thing Chris wanted to discuss today was a strategy for eliminating some of the nasty global state information required to be kept as part of ripping apart the original ORB Core and putting ACE in there.
• Discussed at length how we will attack the whole OA issue.
• Discussed architecture for integrating ACE into CORBA clients.
• Discussed strategies for de-layered demultiplexing.
• Discussed overall implementation schedule.
• Discussed the API between the ORB Core and the Object Adapter.

Resolutions

• Elimination of global state is not a primary goal. The focus of the ORB Core is to clean up the current implementation, get active objects working on the server side and get an implementation going on the client side. These will be the subject of Tuesday's code review.
• The client side will use a cached connection manager, which will hopefully be a derivation of the current ACE_Connector component.
• Brian will do a test prototype of an Object Adapter that allows the application to register CORBA target objects with an ACE_Hash_Map_Manager. Andy's current hard-coded version of an app will form the basis of this.
• Brian and Chris will further discuss the required API between Core and the OA. Of major concern is to maintain a decoupling of demultiplexing and dispatching, i.e., don't make it be one call. Doug recommends that they take a look at the Orbix API, which provides a method called ContinueThreadDispatch that may be useful as an example of how to decouple the demuxing and the dispatching.
• We will (eventually) provide a Basic Object Adapter as specified in CORBA 2.0. More than likely what we will do is have that be a subclass of an abstract class OA from which we can derive more specialized object adapters. The first subclass that we will build is the Real-time Object Adapter (ROA), which will support real-time scheduling and dispatching of client requests onto CORBA target object operations.

Open Issues

• There was some question as to whether or not the existing clients used a select() loop ala Reactor. The issue centered around how to implement cache purging within the client-side cached connection manager. Doug recommends that we use a separate thread in order to accomplish this.

Miscellaneous Notes

• There will likely be a new component, Cache_Connector, introduced to ACE which allows clients to initiate connections. The component will cache these connections, returning Svc_Handlers to existing connections when they are available. For the first cut, this need only support a synchronous connection model. It does not address the issue of tagging information that goes across the connections; individual applications must tackle that. Doug is currently implementing a prototype of the new ACE_Connector_Strategy class that will form the basis for the client-side Cache_Connector. Ideally, this can be supported without much additional effort.
• It appears that the current TCP_OA::handle_message() provides the functionality that our dispatch() method would.
• One of overall goals for TAO is to have an Abstract Factory (link for that, anyone?) which can be queried for information such as the threading policy, dispatch methods, etc.