I would add to this that the intention of the RTS model library was to provide the minimum protocol-based “API” contract for the runtime service library to implement UML-RT service provision points (frame, timing, log), with the notable exception of messaging services (send, invoke, etc.), which is handled separately through the port implementation.
These are the services that every UML-RT runtime service library implementation must provide (again, in addition to port-based messaging).
Because these are defined as protocols, they should be language-agnostic and applicable for all languages, although the syntax of the way they are called will, of course, depend on the implementation language.
And yes, there is more than just protocols in that library because some of these protocols’ messages would require additional information, but these elements are defined as UML classes and should therefore be translatable to any OO language.
Note that this does not preclude the addition of other runtime service in libraries that specialize (inheritance) or complement (composition) this one. The creation of more specific (e.g., language, platform, etc.) or augmented (additional services, possibly from a UML-RT-based DSML) should be possible, but the base UML-RT language must still be present.
Unfortunately, Zeligsoft currently has issues accessing the Eclipse infrastructure, so I can’t comment on Peter’s picture yet - I’ll do that later today from home, after my morning meetings.
Sincerely,
Charles Rivet
Senior Product Manager, Papyrus-RT product lead