| Specification Name: |
CORBA/e |
| Description: |
CORBA/e enables the
implementation of middleware products that are open, mature, robust, and
memory efficient (small footprint); offering high performance and
deterministic real-time behavior - key requirements of most DRE systems.
CORBA/e consolidates CORBA as the dominant standard for embedded
middleware for the foreseeable future.
It is further recognized that there are a wide range of
capabilities in today’s embedded systems. A key tenet of CORBA/e is the
support for "Profiling", a process by which specific subsets of
these CORBA specifications can be defined by different end user
communities and then standardized through the OMG. This will allow
different end user communities to choose the appropriate subset of CORBA
features required by any standards that are developed within that working
group/task force and then for the vendors to produce highly optimized
implementations based on the corresponding CORBA/e specification
(Profile). |
| Latest / past specifications: |
|
Current version: 1.0 |
Past versions: n/a |
|
| Related OMG Specifications: |
CORBA/IIOP, Minimum
CORBA |
| OMG Cross Reference: |
CORBA/IIOP Specifications |
| Most recent IPR
and Implementation questionnaire responses: |
|
|
| Specification Name: |
CORBA
Bindings for WSDL (corbabinding) |
| Description: |
This specification
defines a CORBA binding for WSDL to allow CORBA services to be described using WSDL, and to allow native CORBA communication mechanisms to be specified in
WSDL. |
| Latest / past specifications: |
|
Current version: 1.0 |
Past versions: n/a |
|
| Specification Name: |
Data Parallel Processing |
| Description: |
This specification defines the
architecture for data parallel programming in CORBA. The specification
address data parallelism as opposed to other types of parallel processing
that are already possible with distributed systems, namely pipeline
parallelism and functional parallelism. |
| Keywords: |
bridging, collective invocation,
data partitioning, parallel clients, parallel objects, parallel
processing, part objects, singular clients, singular objects |
| Latest / past specifications: |
|
Current version: 1.0 |
Past versions: n/a |
|
| Contact Information: |
|
| Related OMG Specifications: |
CORBA/IIOP, Fault
Tolerance |
| Specification Name: |
GIOP
Compression (ZIOP) |
| Description: |
This specification defines a compression
mechanism for the CORBA GIOP protocol. Such a mechanism provides a way for
servers to publish objects that accept compressed requests and for clients
to make compressed invocations. Pluggable compression algorithms could
additionally be defined by clients. |
| Latest / past specifications: |
|
Current version: 1.0 |
Past versions: n/a |
|
|
| Specification Name: |
Lightweight
CCM (CORBA Component
Model) |
| Description: |
This specification defines a new
conformance point for CCM, which represents a subset of the functionality
of the full CORBA CCM specification. Lightweight CCM components must be
interoperable with “full” CCM components such that a component-based
application can consist of some of each, with the lightweight components
presenting normal CCM interfaces to “full” CCM components, while
having some of the their operations disabled. |
| Keywords: |
CCM, CIDL, CIF, component,
configuration, deployment, DTD, EJB, emitter, events, facet,
homes, identity, implementation framework, interface repository, language
mapping, metamodel, navigation, packaging, port, profile, programming
model, publisher, receptacles, server interfaces, DTD, XML |
| Latest / past specifications: |
|
| Specification Name: |
Lightweight
Load Balancing |
| Description: |
The need for
distributing incoming requests across a set of servers to share incoming
load appears in many application domains, such as web servers, enterprise
information systems, as well as mission and safety critical applications
such as Air Traffic Control Systems. While the high level goal -
distributing load - is common across all the application domains mentioned
above, there are few differences in terms of non-functional requirements,
support for dynamic vs. static features which has made very difficult, so
far, to agree on a standard Load Balancing Service. This specification
fills this specification gap, by (1) standardizing a minimal set of
interfaces for per request, static load balancing, relevant to as many
application domains as possible, and (2) allowing different implementation
strategy, so to make it possible to accommodate the different non
functional requirements which characterize the application domains
aforementioned. |
| Keywords: |
Load Balancing
(LB), Load Balancing Service, Load Balancing Strategy |
| Latest / past specifications: |
|
Current version: 1.0 |
Past versions: n/a |
|
| Related OMG Specifications: |
CORBA/IIOP,
Data Parallel Processing |
| Most recent IPR
and Implementation questionnaire responses: |
|
| Specification Name: |
Lightweight
Logging Service |
| Description: |
This specification is primarily
intended as an efficient, central facility inside an embedded or real-time
environment to accept and manage logging records. These records are
emitted from applications residing in the same environment and stored in a
memory-only storage area owned and managed by the Lightweight Logging
Service. The service was designed to be a mostly compatible subset of the
Telecom Log Service, however, it differs in the way logging records are
written to the log; or looked up and retrieved from the log. This service
has a much wider application than just the software-defined radio domain.
It will find its way into all areas of embedded systems, like machine
control, onboard vehicle systems, etc., but also into ubiquitous computing
devices like pocket computer and electronic organizers. |
| Keywords: |
administrator, consumer, CORBA,
log status, MDA, operational state, PIM, PSM, producer, Software
Communication Architecture (SCA) |
| Latest / past specifications: |
|
Current version: 1.1 |
Past versions: 1.0 |
|
| Contact Information: |
|
| Related OMG Specifications: |
CORBA/IIOP, Telecoms
Log Service |
| Related Industry Standards: |
|
| Specification Name: |
Lightweight
Services |
| Description: |
This specification defines a compatible subset of three
existing CORBA services (Event, Naming and Time) to make these services
suitable for use in resource- constrained systems. These subsets are
intended to be inserted as new chapters in the Services documents that
they produce the subset of. No other changes to the existing documents are
being proposed. |
| OMG Cross Reference: |
CORBA
Services |
| Specification Name: |
Minimum CORBA |
| Description: |
A subset of CORBA designed for
systems with limited resources. |
| Related OMG Specifications: |
CORBA/e |
| Specification Name: |
Model-level
Testing and Debugging |
| Description: |
This
specification defines a platform independent model (PIM) of the interface
to an executing UML model for the purposes of testing and debugging. The
interface provides visibility into the model execution as well as a way to
provide test stimuli and collect test results. The interface assumes that
instrumentation code to support the interface is provided either manually
or through MDA transformations. The PIM contained in this specification is
independent of middleware and implementation language used. |
| OMG Cross Reference: |
Modeling
Specifications |
| Specification Name: |
Online Upgrades |
| Description: |
Online Upgrades facilitates the safe and orderly upgrading of objects in a manner that is portable
across systems and that is interoperable between systems. It is a first step towards
a more general online upgrade capability. The specification aims to provide the
ability to: • Upgrade individual objects, where such upgrades change the
implementation of the object but do not change the external interfaces of the object
• Pause an object, so that it can be upgraded, while allowing the
object the opportunity to reach a safe and quiescent state • Transfer state from an instance of the old implementation of the
object to an instance of the new implementation of the object, with provision for
such state transfers where the representations of the old state and the new state
are different • Resume service using an instance of the new implementation of the
object without risk that messages will be lost, misordered or processed twice
• Allow client objects to continue to use a server object while
remaining unaware that the server has been upgraded, and allow server objects to continue
to serve a middle-tier client object that also acts as a server while remaining
unaware that the client has been upgraded • Address objects in such a way that a client can continue to use its
existing object reference to access a server after it has been upgraded • Rollback an upgrade, prior to the instance of the new
implementation becoming operational, if some part of the upgrade fails • Revert from an instance of the new implementation to an instance of
the old implementation, if operation with the instance of the new
implementation proves to be unsatisfactory • Perform upgrades on small collections of objects by means of
allowing the application to commit and rollback the upgrades explicitly. |
| OMG Cross Reference: |
CORBA/IIOP Specifications |
| Specification Name: |
Real-time
CORBA |
| Description: |
Standard interfaces that meet Real-time requirements by
facilitating the end-to-end predictability of activities in the system
and by providing support for the management of resources. Version 1.2
combines existing support for Static Scheduling with support for Dynamic
Scheduling.
|
| Keywords: |
deterministic behavior, EDC, messaging, predictability,
priority, real-time system, resources, scheduling, static scheduling,
dynamic scheduling, interoperability, portability, resource manager,
thread
|
| Latest / past specifications: |
|
Current version: 1.2 |
Past versions: 1.1 |
|
| Contact Information: |
|
| Related OMG Specifications: |
CORBA/IIOP |
| Related Industry Standards: |
POSIX Real-time Extensions |
| Specification Name: |
UML
Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE) |
| Description: |
This
specification of a UML™ profile adds capabilities to UML for
model-driven development of Real Time and Embedded Systems (RTES). This
extension, called the UML profile for MARTE (in short MARTE), provides
support for specification, design, and verification/validation stages.
This new profile is intended to replace the existing UML Profile for
Schedulability, Performance and Time. |
| OMG Cross Reference: |
UML
Profile Specifications |
| Specification Name: |
UML
Profile for Modeling QoS and Fault Tolerance Characteristics and
Mechanisms |
| Description: |
This specification defines a set of UML
extensions to represent Quality of Service and Fault-Tolerance concepts.
These extensions reduce the problems of UML 2.0 for the description of
Quality of Service and Fault-Tolerance properties, and integrate the
extensions in two basic general frameworks (QoS Modeling Framework, and FT
Modeling Framework). The general framework for the description of QoS
requirements and properties gives the support to describe vocabulary that
is used in high quality technologies (e.g., real-time,
fault-tolerant). |
| OMG Cross Reference: |
UML Profile Specifications |
| Specification Name: |
UML
Profile for Schedulability, Performance and Time |
| Description: |
Specifies a UML profile
that defines standard paradigms of use for modeling of time-,
schedulability-, and performance-related aspects of real-time
systems" that (1.) enable the construction of models that can be used
to make quantitative predictions regarding these characteristics; (2.)
facilitate communication of design intent between developers in a standard
way; and (3.) enable interoperability between various analysis and design
tools. |
| OMG Cross Reference: |
UML
Profile Specifications |
| Specification Name: |
UML
Profile for System on a Chip (SoCP) |
| Description: |
This specification defines a UML 2 profile
for SoC (System on a Chip) design. This profile provides following
representation capabilities : (1.) hierarchical representation of modules
and channels, which are the fundamental elements of SoC; (2.) roles of
modules; and (3.) information transferred between modules using only one
type of diagram. |
| OMG Cross Reference: |
UML
Profile Specifications |
| Specification Name: |
Unreliable
Multicast |
| Description: |
The purpose of MIOP
(Unreliable Multicast Inter-ORB Protocol) is to provide a common mechanism
to deliver GIOP request and fragment messages via multicast. The default
transport specified for MIOP is IP Multicast 1 through UDP/IP 2 which will
provide the ability to perform connectionless multicast. This requires
that IDL operations will have one-way semantics. |
| Keywords: |
delivery, gateway, GIOP,
IOR, IP, MIOP, multicast, packet, QoS, request |
| Latest / past specifications: |
See CORBA 3.1- Part 2:
Current version: 3.1 |
Past versions: n/a |
|
| Related OMG Specifications: |
CORBA/IIOP,
Naming Service |
[ top ]
[ Index
Page ]
Edited by Lana on
04/12/2013
|
|
