Get documents about "Realtime PSIG - Orlando
Document Sample
Realtime PSIG – Orlando
June 7 - 10, 1998
>>Highlights:
• 60+ people
• Final submission for Minimum CORBA presented in ORBOS
– endorsed by RT PSIG and Embedded WG
• RT CORBA 1.0 Evaluation group provided feedback to submitters
• Vendor presentations on Realtime UML & High Performance CORBA
• Working on RFPs for
– Open Nested Transactions
– Enhanced Time Service
– UML Extensions for Realtime
• High Performance WG had first meeting with Parallel Processing Vendors
• Another successful tutorial on “Fundamentals of Realtime”
• DOD Realtime Defense Information Infrastructure /Common Operations Environment Briefing
>> Detailed Meeting Minutes:
>>Goals & Agenda
Dock Allen opened the meeting by reviewing the Mission, RT PSIG interfaces with other OMG groups,
RT PSIG goals, points of contact, and roadmap/schedule of RFPs
- Orlando Meeting Goals:
- complete the evaluation of Minimum CORBA
- Move towards adoption
- Continue evaluation of Realtime CORBA
- Move RFPs forward - initial ORBOS presentations?
- Enhanced Time Service
- Open Extended Transaction Service
- Complete background work, and begin drafting new RFPs
- Realtime UML extensions
- High Performance CORBA?
- Agenda
- Sunday
- Enhanced Time Service - led by Dock
- Open Transaction Service RFP - led by Malik
- R/T roadmap group - deferred to 5:00 Monday- Judy, Dock, Peter, Doug Jensen
- R/T CORBA evaluation group - led by Steve Uzekaj
- Preliminary Min CORBA Eval- led by Roger Barnett
- Monday
- Minimum CORBA final submission - joint with ORBOS
- and Min-CORBA -eval discussion
- Vote on Revision date for RT CORBA 1.0
- Parallel Sessions
- High Perf CORBA
- RT A&D
- Min CORBA eval (if needed)
- Realtime Tutorial - Doug Locke
- Tuesday
- Embedded Systems Working Group
- Wednesday
- Joint meeting with Security SIG
- inputs on FT & min. CORBA
- interceptors
- security for embedded systems
- DOD Realtime DII/COE Briefing;
- Reports, briefings, votes
- Benchmarking SIG report (Steve Tockey)
- HP CORBA WG report
- Time Service RFP report and possible vote
- Extended Transaction Service RFP report and possible vote
- P&P changes report/ interceptors report - Gene Jarboe
- Roadmap Discussion
- Wrap--up Planning
- No meetings in Orlando for Fault Tolerance, Dynamic Scheduling, Realtime Protocols
-Gene Jarboe reported on proposed process changes
Different levels of participations - up to Contributing
Concern that non-contributing members could do really good work and it could get nixed by AB or Exec
Board. Gene will report on Wednesday afternoon
- Minutes from Manchester meeting were approved by white ballot.
>> RT Mailing lists
To get on an OMG mailing list, send email to request@omg.org. Ask to be added to the
mailing list of your choice. The current Realtime related mailing lists are:
- realtime@omg.org - General Mailing to entire Realtime PSIG
- dynamic@omg.org - Dynamic Scheduling
- ftrfp@omg.org - Fault Tolerance
- rtad@omg.org - Analysis and Design
- rthp@omg.org - High Performance
- real-eval@omg.org - Evaluation of responses to Realtime CORBA 1.0 RFP
- min-eval@omg.org - Evaluation of responses to Minimum CORBA RFP
- embedded@omg.org - Embedded Systems Working Group
- benchmark@omg.org - Benchmarking PSIG
We will set up new mailing lists for Realtime Extensions to OTS rtots@omg.org
and for Realtime Time Service rttime@omg.org
Judy will email this list to realtime@omg.org
>>> Extended Object Transaction Service - led by Malik Saheb of INRIA
- Malik Saheb made a presentation on the Extended Object Transaction Service RFP based
on Realtime TINA work and ACTS work. He will put the presentation on the server.
- Summary
- The RFP seeks the following interfaces and mechanisms allowing
- the Terminator to commit nested transaction with oopen semantics
- to compensate effects of committed open nested transaction
- to identify a resource which triggered the rollback
- to notify existence of inconsistency replies during the closed nested
transaction commitment
- to identify the nested transaction level to rollback (to avoid recursive rollbacks)
- to notify the application that the second commitment has started
- General Discussion: Current RFP shows an interesting "Telecom" use case, but
the RFP needs to be written in generic "computer science terms" asking for:
- non-ACID transacations
- application specific semantics for "commit" and "abort"
- It's common practice today for long-lived transactions to not lock all the
resources for the duration of the transaction
- Application is not a General Purpose Transaction Monitor system = application knows
that at certain points in the transaction process it's safe to release certain resources
- Want to propose a general purpose soln in the CORBA context where Telecom can solve
problem for connection management and Transportation can solve the seat assignment problem
in a general manner. so CORBA can import application specific info and solve the problem
- Rollback Propagation Discussion-
-In an application specific environment, may know that you can live with a partial failure,
and may not want to rollback in every case.
- this optimization reflects a specific policy about the semantics of rollback. In another application
application specifics for commit and abort and
rollback may not want to use those semantics for "rollback"
Doug J. - We agree on the problem. The soln isn't to put in this optimization to fix the problem.
The soln is to do something that enables application-specific optimizations. This
is one optimization technique.
Alternatives: Let's fix the current closed model which is broken or
Let's change models
-Discussion: Doug J. proposes to do more to OTS than this. Would like interfaces
in OTS to change the semantics of ORBS.
Our vision for "openness" (extending OTS to be Open) needs to be that the ACID
properties should NOT be bundled. APIs should be able to select among ACID properties
Want Application specific semantics for commit, abort, concurrency control.
- We may start with first steps toward this
- Have to be able to suck into the realtime system as much application specific knowledge
as possible and still do high performance things based on that knowledge vs "Generic"
approaches. Need to dynamically shift balance between ignorance and awareness of application
to get performance.
Want a very agressive long-term vision - with specific steps
Need to put these changes in a context, so that AB sees a continuum of extensions to
OTS, or else the next change will be resisted.
Doug suggests moving a copy of the "Conclusion" to the beginning of the presentations,
so that at beginning people can see what proposed changes are being made to OTS,
We want to do these things. Let's show you why and here are some examples.
Jorge Rodriguez- Not clear what the relationship to realtime is. Better to show how
this relates to a long term plan for improvements.
- Action Items- Doug Jensen and Malik will work on writing a "roadmap" for the Realtime Extensions neede to the
OTS and to position the work on this RFP as step 1 of this work - to be included
as part of the presentation to be made to ORBOS on Thursday morning. (status update on
the RFP work - not a vote!!)
- Doug led a discussion on the "roadmap" needs for realtime OTS.
RTSIG wants
- Two types of changes to OTS
- Make it more "Open" - Define a framework for Non-ACID transactions
- Could ID multiple domain specific solutions and move toward the general case OR
- Take a technology specific path and define 1st weakening of ACID, then
2nd weakening
- "Realtime"
- Fixed Priority
- Dynamic Scheduling
- How do we interleave incrementally the "more general" with the more "realtime"
changes. Need a sensible plan for this. Not good to do all of "more open"
followed by all of realtime
- Is there a "no-brainer?
- End of the path is an OTS that has application specific choices for application
wrt ACID
- Could work with other domains for use cases, but that could take forever.
- Possibly
- Go with Telecom domain RFP
- Followed by Fixed Priority Telecom Domain Specific RFP
- Concurrently can work on a Defense domain RFP
- ...
>>RT CORBA Evaluation Session
- Mailing list is real-eval@omg.org. To get on this mailing list, send email to
request@omg.org
- Main goal is to post user scenarios of realtime CORBA to this group
- Other goal is to identify issues with the initial Realtime submissions
so submitters can see what the issues are.
- If you want exposure to the full realtime group, also must post it to realtime@omg.org.
Suggest that we send scenarios to both groups
- RT CORBA Eval Use case from HRT Avionics/Legacy Avionics
- Scenario
- Homogeneous processors in a distributed environment
- Part of system uses Rate-based processing - RMA like, highly deterministic with Legacy I/O + Modern I/O
- Rate based drives the system design- even though some things are dynamic
- "Passive" objects + events
- Minimal # of threads, avoid locking'
- Closed system over VME
- uses "minimal" set of TCP/IP pieces
- Model devices as objects. All objects that have registered for an event get them
at specific times. Very little asynchronous.
- A set of threads run at rate 1 on one communication channel and another set of threads
run at rate 2 over another comunication channel. Threads are executing at a
particular rate and you want to maintain the priority over distributed processors
- Critical needs:
- Priority inheritance across nodes - no inversion
- Priority management (all threads)
(e.g., If you have a thread that serves a function for the ORB it has to be set into the
priority structure just like any other threads. It's not OK to have all ORB
threads higher or lower priority - must be fitted to the system)
- static memory allocation
- minimal locking
- predictable timing
- Important needs
- pluggable transport
-have 1553 and other non-standard I/O systems
-don't need own ORB interaction protocol - just need to be able to use specific
transport.
- monitoring interfaces
- discover execution times
- run app thru dry run and determine event dependencies and execution times
- simple, minimal configurations
-Steve talked about a Multi-ORB environment with AWACs. Not using multi-ORBS on
different processors. Some use IIOP. Others don't. Building own inter-ORB managing
layer. If ORB needs to talk to another ORB that doesn't use IIOP, use sockets and hide
that from the application. Mission-based. Not avionics time critical. Each application
manages time differently. Some use ADA services. Others use C++ libraries for scheduling.
- C2 also needs
- Priority inheritance/no inversion
- priority management
- PLUS
- no memory leaks
- Heap is OK @ startup
- to provide fault tolerance - need FT transport protocols
- granularity of Fault tolerance
- today use a group paradigm
- Julien Maissonave noted that it's very likely we won't find pluggable protocols in
Realtime- because AB wants it to be a separate Core RFP. Interceptors are another
separate Core issue that needs to be addressed in ORBOS
- QoS discussion:
- Use Case from Alcatel was discussed. Zoely posted it to real-eval.
It was a good scenario. It could be improved by explaining why the application needed
multiple endpoints.
- Steve raised the issue that people should comment on scenarios as they are shared, so
that submitters can see the range of user needs and judge importance of the issues that
are raised. If submitters
don't get any use cases, they can't address the important issues. Scenarios could
also reveal conflicting requirements.
- Julien noted that the critical needs from his scenario are for
- Multiple protocols (e.g. to communicate over shared memory or over a serial line)
+ some apps need Pluggable transport
- Multiple Endpoints
- Design that let's users make decisions
- Target application on embedded system like GSM telephone needs
- reduce priority inversion
need a number of ports so you can have different priorities, but can't have
one port per priority level. Need only a few priorities that are critical to RT
- Need user flexibility in how they assign ports to priority level.
- In some cases a dispatching thread is OK.
- In others, need ports reserved for specific priorities.
- one way of solving the problem is mapping thread priority to port priority
- options
- receive a message over a port, look at a priority and then dispatch based
on priority
- one port per priority level
- combo
- Priority Inheritance Discussion: If you can look forward to dynamic scheduling, will not always have dynamic
priority
version of priority-inheritance. May have to do some rethinking later.
There is a risk that submissions for this may not be consistent with later approaches
for dynamic scheduling. Both are specific cases of a more general point of view.
When we get to dynamic scheduling RFP, we will need to adjust our thinking.
- Patterns- Anyone who is interested in writing patterns for any of these should
contact Judy McGoogan at jmcgoogan@lucent.com
>>Minimum CORBA Evaluation
- Roger summarized queries/issues he's received on the Minimum CORBA revised submission.
- Some have been partially answered
- Michi Henning "isa" issue
- reply what happens at API implementation and IIOP may not be the same
- ambiguous re C++ mapping. Do you need to take out corresponding things in language
mappings
- type codes in Min. CORBA - John Biggert may not be convinced it's OK to use name
instead of ID. Repository IDs are becoming THE identifier, wheras name is potentially
unreliable.
- removal of POA manager - if you take it out, how do you prevent premature invocation
of ops before they get initialized. Answer- it's an application problem
John Bigger suggested you may want a single POA manager.
- Consolidated IDL left in methods that use types that you took out
- Could you consider restoring option of "used default servant option"
- Root POAs and implicit activation. Only allow "no implicit application" in Min
CORBA - while default in CORBA is "implicit application" - Dave Stringer/Biggert
- Chris Smith - Can we/Should we get the messaging interface in the submission? If
messaging gets through, submitters could raise it as an issue and put it in between
now and Helsinki.
- Clarification on Multiple Inheritance. Will generated code be smaller if I don't
use it?
- Typos sent directly to submitters
- Was there discussion on excluding type ANY
- One initial submission excluded it. There's a worry about losing interoperability
and portability. "Any" not required was felt to be too big a step. It was felt
that putting that in would make it difficult to get it through. People could
still allow a particular customer to omit ANYs (probably a compiler flag), but
it wasn't included in the spec.
- Zoely, what next? What's position of RT group? Proposed RFP. Now it belongs to ORBOS.
At this point, it's up to the voting list. As far as we know there are no major issues
to block it.
>>Joint Meeting With Security SIG -
- Bill Woods reviewed the FT RFP. FT is generally built on redundancy
- Multicast key management is the immediate security issue. You need to secure in
a multicast environment. That might
-Multicasting is more an issue with asynchronous messaging than with fault tolerance
- Is there an issue with security keys on multiple redundant services
- To have FT be transparent to the client, there will be a one-to-many connection
enviroment
- Goal - if someone has a FT w/redundancy reqmt and a Sec reqmt, there will not be
any conflicts in meeting those reqmts
- Redundant on-line systems pretending to be one system have to authenticate identically
to receive the same requests and have to coordinate state maintenance
- Does security detract from realtime?
- treat a security protocol as your starting point and then build in your performance
constraints
- What does a peer protocol do when a key expires, and how does that interfere with
schedules
Summmary from Bob Blakeley - IBM/SecSIG
- Multiple things (e.g., devices) sharing an identity
- how does keying work?
- how does auditing work?
- how is polidy kept in synch?
- Performance concerns
- security overhead in protocols
predictability, throughput, latency
- re-keying latency due to key expiration (how does this interact with scheduling?)
- What is requirement?
- what environments characterize realtime market?
- what threats are common?
- What security issues are associated with recovery?
- In life threatening situations (home-alive mode on an aircraft), it's a good idea
to turn off security. Security is meant to cover the normal state of events.
In these situations, things happen that the security designer didn't expect.
-When an engineer has constraint to use CORBA OTS products, and has FT and Security
needs, we want to be sure that using FT CORBA doesn't preclude using CORBA Security
Facilities or vice/versa.
- Does Security have any issues with Minimum CORBA?
- If there are hooks for security in CORBA core, then they would be in Min CORBA
- Min CORBA does not include COS
- Security Service could be used with Min CORBA
- Min CORBA over a secure protocol
- If predictability is an issue, CORBA with Security services will have different
predictability characteristics than without. Security might make it totally
unpredictable
- Concern of extending Min CORBA across an enterprise
-Security issues with CORBA for embedded systems
- may not have security within the system - but at the boundary between the embedded
system and outside systems. Secure interoperability in bridging between the two
is important.
- Idea of pre-keying the embedded system (using something simpler than Kerberos)
could address this
- Cell phones are a good example of problems in this area
- Nintindo game cartridges are an example of this done well
- use mech of authenticating the cartridge to the unit that will use the cartridge
to make it difficult to copy a cartridge
- Does Security add so much overhead that an embedded environment can't afford it?
- What it adds to the processing is not as important as what it adds to the protocol.
- May be able to get a bigger processor/ hard to add faster wires
- Have to experiment with real apps
- System that may not need security initially could raise problems
- better to
--Interceptors
- Interceptors are no longer being addressed by the Security SIG directly.
- The initial proposals for Security interceptors failed.
- There is a proposal in the Sun, et.al, response to the Realtime CORBA 1.0 RFP
that addresses interceptors, and a number of issues have been raised around this.
- interceptors might be nice to have, but it may not make sense to standardize
things that are not well understood
- There is published IDL for interceptors in the security spec.
- There is a draft RFP that will be addressed in ORBOS on Portable Interceptors
written by Dan Frantz of BEA.
>>>Realtime DII/COE Briefing
- by John Maurer of Mitre
- The Air Force Command and Control System
has evolved from multiple "stovepipe" systems to an integrated environment
- Vision is a globally connected information infrastucture with interconnected systems
- For this to be long-lived, component architectures make sense
- DOD is building a Defense Information Infrastructure (DII) with multiple layers
of internet-style connections that are physically separate from commercial
internets
- The Common Operating Environment (COE) consists of:
- the kernel (present on every DII compliant workstation)
- xwindows, motif, dns, newsprint, + proprietary SW for exec mgt and security
- Sun/Solaris, HP/UX, Windows NT are the only three certified platforms
- there are no RTOSs certified. Maybe Lynx
- Future PowerPC is likely to be certified (in pairs with OSs)
- Common support Applications that emphasize interoperaility via common view of data
- Infrastructure Services that emphasize movement of data thru the network (including
CORBA, DCE, and DCOM)
- Other - Developer's toolkit
- DISA's realtime DII COE Vision
- 97: DII/COE 3.0
- 97: CORBA....
- DII COE Realtime TWG Vision
- TWG Chartered by DISA DII COE to
- define what capabilities are needed by the DII COE in order to support realtime apps
- consult on rt issues
- Foster/inspire a DII COE config with support for RT
- Performs predictably with respect to time at useful levels of performance
- Maintain strict compliance with DII COE standards and APIs
- extensions only when necessary/ individually negotiated with DISA
- What is realtime
- deadlines and timelines imposed by constraints
- Hard RT - dedlines must be satisfied, processing timelines must be deterministic,
value of computation is nil after deadline expires
- Soft RT - deadlines tight but not absolute; value diminishes after deadline
- Characterizing Real-time Systems
- Categories: nonRT, SoftRT, HardRT, Embedded RT (boundaries are qualitative and do not overlap
- Responsive to deadlines dictated by external processes
N/N; S/Y, H/Y, E/Y
- consequence of not satisfying deterministic scheduling
N/nuisance; S/degraded QoS; H/mission failure; E/mission failure
- mission critical reliability/continuity of operations
N/N; S/Y, H/Y, E/Y
- unique/exotic requirements and constraints
N/N; S/N; H/N; E/Y
-Appears whole COE needs to change to accomodate RT
-Approach to this includes steps to select, integrate, benchmark, simulate, and publish guidelines
while also validating thru appropriate prototypes
- Where does CORBA fit?
- Given: CORBA is being explicitly included in DII COEversion 3.4
- CORBA is a key enabling technology for DII/COE
- RT CORBA is
RT kernel, RT CORBA product are two keys that he wants to have in a RT DII COE by 3/00
- web site is password protected: Send email to johnm@mitre.org for an individual login/password.
- vendors who want info on product certification for the RT DII COE can send email
to johnm@mitre.org. He has open meetings on this topic. Contact him for more info.
>>Report from the Benchmarking SIG
- Steve Tockey is soliciting and consolidating rerquirements of the CORBA community for
Benchmarking
- Vote on Benchmark RFI will be tomorrow in ORBOS. Latest version is bench/98-05-02.
- Questions cover: goals; types of measurements; methods for measuring; availaabale technology;
approaches to libraries for algorithms, procedures, apps; and potential problems.
- Steve encouraged responses to the RFI from individuals and companies - both formal
and informal via email.
>> Statistics SIG Report
Christopher Nelson, Dimension EDI, presented info on the Statistics Group
- Discused the statistical exchange process: data collected, statistics compiled,
classified, disseminated, brokered and used
- Lots of work going on in electronic dissemination
- Orgs involved include National Statistics Institutes of the 15 EU countries, US Bureau of Census,
+ Australia and Canada
+ Intl orgs like Eurostat, OECD, IMF, World Bank and UN Statistics
- He discussed the conceptual structure for capturing/recording statistical info and wants
to work on object representations for it. + techniques for accessing it.
- Hamish Blair discussed uses in Telecom
- They are issuing an RFI this week. The mailing list is statistics@omg.org
>> High Performance Working Group Report
Draft Mission Statement - rev 2
The goals of the RTHP WG are to identify areas of possible standardization activities and
define standards for supporting those CORBA applications which:
- are willing to specify more detailed control or hints to achieve higher performance
than that which is possible or expected by internal ORB optimization alone (distinct
from issues of determinism or measurement and instrumentation) --- e.g., smart
proxies, multi-threading, and exposed caching
- exploit aggregated processing by using multiple processors to accelerate a single
task. Such application areas are sometimes referred to as a "cluster" or "parallel"
computing. Signal processing is an important domain of such applications. ---
e.g., collective operations, distributed synchronization and data distribution
-Discussion: HP working group might also take on roles of defining areas where the
RTCORBA architecture itself might need to be modified
- Might take on role of reviewing RFPs and/or submissions for H/P issues -e.g., like
Security does
- Don't exclude changes/ extensions to OMA to improve performance
- Identify what things in current interfaces inhibit H/P - possibly via an RFI
- Identify use cases, success stories, and hints for how to write H/P CORBA systems
- Identify how to componentize CORBA so an application can pick and choose the pieces
needed to build their realtime systems with a specific set of user requirements
>> RTA&D Working Group Report
- Johannes Ernst
- Beginning to id components
- 8-9 Presentations / mostly vendors - details of UML
- need to present user needs for UML
- users who are willing to work on that list should contact Dock. John Maurer will get
someone from Mitre to work on it. Core input would be helpful by June. Judy asked
to find someone from Telcoms
- Small group will take input from presentations and consolidate around themes that
could turn into RFPS
- e.g., modeling of resources
- In Helsinki, will have set of topic areas and invite users to comment on them
- In Seattle, expect to review written draft of first of a series of RFPs
- Presentations will be on RTAD website - subset of RT subsite.
>> Time Services RFP report
Bruce Douglass presented the work of a small group on Clocks:
- Time Types
- absolute, mission, simulation
- Rollover should never be visible for a clock (may be visible for timers)
- Persistence is an application issue
- Synchronization - RFP should ask for precise semantics (offset?, slew?, fastest?)
-RFP definitions that should be revised:
- skew= offset not d0/dt
- drift= d skew/dt
- d drift/dt not interesting
- "Friendly time" (wall clock) should be derived from absolute
- RFP definision should be revised - microseconds should be a long
- Duration
Discussion:
- Should consult Simulation SIG. They are putting out an RFC on the "high level architecture
for simulation - including time.
- RT PSIG Agreed to eliminate "simulation" time from this RFP to make it less complex
- Next steps: Doug (and hopefully Esther) will work towards having an RFP to review for Helsinki.
Folks interested in being an author or reviewer should send email to bpd@ilogix.com
>> Open Nested Transaction Service
- Malik reported on progress on the CORBA ONTS RFP
- Problem statement:
- Immediate release of resources on which concurrent access are required
- Requirements:
- The "Open Nested transaction (ONT) model"
- the ONT commitment is equivalent to a flat transaction commitment
- compensating mechanisms are needed to undo effects of a committed ONT
- Full exploitation of the immediate abort propagation down-tree and up-tree
- The identification of the nested transactin level to rollback (avoid recursive rollbacks)
- Notify the application of a recovery phase
- Resolve ambiguities on the current OTS specification
- Identification of the resource which triggers a rollback event
- Inconsistency of replies duering the closed nested transaction commitment
-Malik and Doug Jensen are working on an RFP for the next meeting.
- Dock is looking for people who have specific application needs in this area to share
them. Send email to rtots@omg.org
>>>Realtime Roadmap
Dock shared the realtime roadmap - listing dependencies on work we are contemplating, but
without specific ordering or dates
-Dock will send this roadmap (in Excel) to the group.
- It includes tracks for work on embedded systems, realtime, fault tolerance, time service,
transaction service, high performance, realtime analysis & design, and protocols
Judy noted that these represent the well-known "dimensions" of Realtime and agreed to
create a "star" diagram illustrating these dimensions
- Need for services & changes to other CORBA CORE
- Dock listed the CORBA Services and asked which are used in realtime CORBA
and asked which should be reused in RT and which need to be modified
- Naming x?
- Time xx
- Events xx
....?
-Persistence x?
- Transaction xx
- FTOL x?
- Concurrency ??
- Property ?
- Query ?
- TMN Interaction ?
- Streams x?
- Collection x
- Externalization x
- Will ask Embedded systems group to fill out table at their next meeting.
- Should also distinguish between - Must have vs might use
- Change means: Simplify: optimize; more predictability
>>>schedule
Dock shared the schedule.
>>>Wrapup
- Met most of meeting goals
- completed evaluation of Minimum CORBA
- SIG voted to endorse the revised submission for Minimum CORBA (subject to
minor revisions).
- HELSINKI Plans
- Agenda items for Helsinki
- Adopt Minimum CORBA- Mon AM / joint w/ORBOS
- Q&A sesion on FT for potential submitters - 2 hours; 5-7 Monday
- ORBOS approval of Open Nested Transactions RFP - 2 hours SIG / 1 hour ORBOS
- ORBOS approval of Time Service RFP - 2 hours SIG/ 1 hour ORBOS
- RTAD Users Forum - 4 hours - Not Sunday
- RTAD Category Review - 4 hours
- High Performance RFI/White Paper - 4 hours
- Analysis of Services for RT/ Embedded Services and RT - 1 hour SIG
- Meeting with MetaObject group - 1.5 hours - not Sunday
- briefing RFP for Mgt of Event Networks /see - 1 hour - not Sunday
Mike Greenberg
- protocols draft RFP(s)? 4 hours
- Embedded Systems WG
- Someone to monitor Interceptors RFP
Plan to start at 10 AM on Sunday
Work Sun, Mon, Wed.
Related docs
