Within the Software Communications Architecture (SCA) the Common Architecture Request Broker Architecture (CORBA) is used as the message passing technique for the distributed processing environment. CORBA is a cross-platform framework that is used to standardize client/server operations when using distributed processing. Distributed processing is a fundamental aspect of the system architecture and CORBA is a widely used “Middleware” service for providing distributed processing. The SCA Operating Environment (OE) shall include middleware that, at a minimum, provides the services and capabilities of minimumCORBA as specified by the Object Management Group (OMG).
CORBA Naming Service
The SCA OE shall provide an implementation of a CORBA Naming Service which implements the CosNaming module NamingContext interface operations: bind, bind_new_context, unbind, destroy, and resolve as defined in the OMG Interoperable Naming Service Specification using the IDL found in Appendix A of that reference.
CORBA Log Service
An SCA compliant implementation may include a log service. If a log service is implemented, the log service shall conform to the OMG Lightweight Log Service Specification.
CORBA Event Service
The SCA OE shall provide an implementation of the CORBA Event Service. The Event Service shall implement the PushConsumer and PushSupplier interfaces of the CosEventComm module as described in OMG Event Service Specification using the IDL found in that specification. The CosEventComm CORBA Module is used by consumers for receiving events and by producers for generating events. A component (e.g., Resource, DomainManager, etc.) that consumes events shall implement the CosEventComm PushConsumer interface. A component (e.g., Resource, Device, DomainManager, etc.) that produces events shall implement the CosEventComm PushSupplier interface and use the CosEventComm PushConsumer interface for generating the events. A producer component shall not forward or raise any exceptions when the connection to a CosEventComm PushConsumer is a nil or invalid reference. The CORBA Event Service has the capability to create event channels. An event channel allows multiple suppliers to communicate with multiple consumers asynchronously. An event channel is both a consumer and a producer of events. For example, event channels may be standard CORBA objects and communicate with those channels is accomplished using standard CORBA requests. The OE shall provide two standard event channels: Incoming Domain Management and Outgoing Domain Management. The Incoming Domain Management Channel name shall be "IDM_Channel". The Outgoing Domain Management Channel name shall be "ODM_Channel". The Incoming Domain Management event channel is used by components within the domain to generate events (e.g., Device state change event) that are consumed by domain management functions (e.g., ApplicationFactory, Application, DomainManager, etc.). The Outgoing Domain Management Channel is used by domain clients (e.g., HCI) to receive events (e.g., additions or removals from the domain) generated from domain management functions (e.g., ApplicationFactory, Application, DomainManager, etc.). Besides these two standard event channels, the OE allows other event channels to be set up by application developers.
PrismTech has extensive experience in CORBA technologies (PrismTech has been a member of the OMG since 1993 actively contributing to the development of CORBA standards) and the SCA. PrismTech's Spectra CDB (Common Data Bus) provides COTS CORBA products ideally suited to the Size Weight and Power (SWaP) requirements of the SCA and includes: Spectra ORB (C++ and C for GPP and DSP), Spectra Lightweight Services (Lightweight Event Service, Lightweight Naming Service, Lightweight Log Service) and Spectra ICO (IP CORE ORB for FPGAs). PrismTech can also provide a broad range of CORBA and SCA Professional Services including Consultancy, Training and Workshops.
Please Contact PrismTech for further information about our SCA CORBA Middleware and Services.