Scott Binegar
Tom Donaldson
Rob Douglas
Niall Gaffney
Sandy Grosvenor
Karla Peterson
Frank Tanner
Rob wrote a high-level design of how the architecture should communicate and share data.
Rob will formalize the UML for data sharing and the architecture based off of the discussions at the meeting.
Rob will create a high-level design for using plug-ins.
Sandy will provide the general design of SEA’s apply/reset concept.
Tom will prototype CORBA’s use with firewalls to see what options and problems exist.
CORBA is costly to implement. When appropriate and where possible, a simpler communication mechanism will be used.
There were two primary discussions at this week’s meeting. The first was regarding Rob’s high-level concept of how various tools could interoperate within the APT architecture.
Rob created an UML design diagram of how tools may be positioned within the APT architecture. The design is available by following this link. See that document for current detailed information.
The other primary discussion was on various ways to implement data sharing. Under the current architectural plan, all of the data content (A.K.A. the data-pool) would be shared among tools. This lends itself to very easy interoperability among tools. However, this also presents a problem with when to update data. This is especially a problem when retrieving data asynchronously from legacy systems or databases where the data may not be available for several seconds or several minutes.
SEA currently handles some of this functionality via an “apply/reset” mechanism. This allows the user to queue up several requests and then apply them later.
Rob suggested a “blackboard” updating paradigm. This would have an event queue or some sort and allow various tools to take items off of the blackboard to process when necessary.
Various questions were also brought up regarding the architecture’s design. While there are no answers to these questions yet, they will be discussed at future meetings.
· What kind of cashing should APT do?
· When should data updates occur? Should they be synchronous or asynchronous or is it tool dependent?
o Who should be in charge of data updates? Should the user ask to “apply” changes or should the program control this?
· How should plug-ins work? Should we provide a base tool that can be overridden with specific tool implementations? Should we provide an interface definition that defines a “tool” that can simply be plugged in to the APT architecture?