streams for ccm specification - ulm · streams for ccm specification this omg document...

Streams for CCM Specification

This OMG document (ptc/2005-07-01) replaces the draft adopted specification (ptc/05-06-02). It is an OMG Final Adopted Specification, which has been approved by the OMG board and technical plenaries, and is currently in the finalization phase. Comments on the content of this document are welcomed, and should be directed to [email protected] by December 1, 2005.

You may view the pending issues for this specification from the OMG revision issues web page http://www.omg.org/issues/; however, at the time of this writing there were no pending issues.

The FTF Recommendation and Report for this specification will be published on March 1, 2006. You can find the lastest version of a document from the Catalog of OMG Specificationshttp://www.omg.org/technology/documents/spec_catalog.htm

OMG Final Adopted SpecificationJuly 2005

Date: July 2005
Streams for CCMFinal Adopted Specification

ptc/05-07-01

Copyright © 2005 Fraunhofer FOKUS Copyright © 2005 Mercury Computer Systems, Inc. Copyright © 2005 Object Management Group, Inc.

USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES

The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice.

LICENSES

The company listed above has granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. The copyright holder listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.

Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

GENERAL USE RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

DISCLAIMER OF WARRANTY

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT

LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.

RESTRICTED RIGHTS LEGEND

Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 250 First Avenue, Needham, MA 02494, U.S.A.

TRADEMARKS

The OMG Object Management Group Logo®, CORBA®, CORBA Academy®, The Information Brokerage®, XMI® and IIOP® are registered trademarks of the Object Management Group. OMG™, Object Management Group™, CORBA logos™, OMG Interface Definition Language (IDL)™, The Architecture of Choice for a Changing World™, CORBAservices™, CORBAfacilities™, CORBAmed™, CORBAnet™, Integrate 2002™, Middleware That's Everywhere™, UML™, Unified Modeling Language™, The UML Cube logo™, MOF™, CWM™, The CWM Logo™, Model Driven Architecture™, Model Driven Architecture Logos™, MDA™, OMG Model Driven Architecture™, OMG MDA™ and the XMI Logo™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.

COMPLIANCE

The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials.

Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites.

OMG’s Issue Reporting Procedure

All OMG specifications are subject to continuous review and improvement. As part of this pro-cess we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/technology/agreement.htm).

Table of Contents

1 Scope .....................................................................................................................1

2 Conformance .........................................................................................................1

3 Normative References ...........................................................................................1

4 Terms and Definitions ............................................................................................2

5 Additional Information ............................................................................................35.1 Changes to Adopted OMG Specifications ........................................................... 35.2 How to Read this Specification ........................................................................... 35.3 Acknowledgements ............................................................................................. 3

6 Basic Concepts .....................................................................................................56.1 Stream Types ...................................................................................................... 56.2 Stream Ports ....................................................................................................... 66.3 Stream Transport ................................................................................................ 66.4 Stream Content Transmission ............................................................................. 6

7 Stream Type System ............................................................................................97.1 Basic Stream Types .......................................................................................... 107.2 Constructed Stream Types ............................................................................... 117.3 The Raw Stream Type ...................................................................................... 117.4 Value Stream Types .......................................................................................... 117.5 Compatibility of Source Stream Port and Sink Stream Port .............................. 127.6 IDL Extensions for the Definition of Stream Types ........................................... 12

7.6.1 Usage Examples ................................................................................................... 13 7.6.2 MIME Content Stream Types ................................................................................ 13

8 Component Connectivity....................................................................................... 158.1 Assembly Connections ...................................................................................... 15

8.1.1 Background of CCM assemblies and deployment ................................................ 15 8.1.2 New capabilities defined in this specification for Assembly Connections .............. 16

8.2 Transport Connections ...................................................................................... 17 8.2.1 CORBA ports ........................................................................................................ 17 8.2.2 Stream ports .......................................................................................................... 17 8.2.3 New capabilities defined in this specification for Transport Connections .............. 18

8.3 Information flowing between ports over transport connections ......................... 18 8.3.1 New capabilities defined in this specification for information flow ......................... 19

9 Component Interface Extensions ......................................................................... 219.1 Component IDL for Stream Ports ...................................................................... 219.2 Examples .......................................................................................................... 219.3 Equivalent IDL Mapping .................................................................................... 229.4 The StreamPorts Interface ................................................................................ 22

9.4.1 StreamPorts operations for deployment — none .................................................. 23 9.4.2 StreamPorts operations for clients needing connectivity and navigation .............. 23

Streams for CCM Adopted Specification i

9.4.3 StreamPorts operations for introspection .............................................................. 259.5 The Sink Interface ............................................................................................. 27

9.5.1 Sink object references ........................................................................................... 27 9.5.2 Sink operations for transport negotiation and connection management ............... 28 9.5.3 Sink operations for stream negotiation, demarcation and management ............... 29

9.6 The Source Interface ......................................................................................... 319.7 Consolidated External IDL ................................................................................. 31

10 Component Implementation Framework Extension ...........................................3510.1 Stream port Interactions between component implementation and container 3510.2 Execution Models ............................................................................................ 35

10.2.1 Event-driven Execution Model ........................................................................... 36 10.2.2 Blocking Execution Model .................................................................................. 36 10.2.3 Run-condition Execution Model .......................................................................... 37

10.3 Buffer Management ......................................................................................... 39 10.3.1 Buffer Management with event-driven ports ....................................................... 40 10.3.2 Buffer Management with blocking ports .............................................................. 41 10.3.3 Buffer Management with the Run Condition Execution Model............................. 41

10.4 Stream Management ....................................................................................... 43 10.4.1 Stream boundaries............................................................................................... 44

10.5 IDL summary for local interactions between component and container .......... 44 10.5.1 Context interfaces for component-to-container invocations ................................. 44 10.5.2 Per-port callback interfaces ................................................................................. 45 10.5.3 Per-component callback interfaces ..................................................................... 46

10.6 Consolidated internal IDL ................................................................................. 46

11 Deployment Extensions .....................................................................................4911.1 Extensions to the Component Deployment metadata ..................................... 4911.2 Extensions to the Target Deployment metadata ............................................. 49

12 Metamodel Extensions....................................................................................... 5112.1 The Component Meta Type............................................................................. 51

13 Profiles ............................................................................................................... 5313.1 Stream Profiles ................................................................................................ 5313.2 Transport Profiles ............................................................................................ 54

13.2.1 The TCP profile for CCM streams...................................................................... 54 13.2.2 The SCTP profile for CCM streams .................................................................... 55 13.2.3 The TCP/MPA profile for CCM streams .............................................................. 55 13.2.4 The RTP/UDP profile for CCM streams ............................................................. 55

ii Streams for CCM Adopted Specification

1 Scope

The CORBA Component Model (CCM) reduces the complexity of the development of large distributed applications by defining a component-based programming paradigm where a special runtime construct, the container, manages and controls certain runtime services, like transactions and security. With languages for the specification of both a CORBA component and its desired implementation, it allows for the automatic generation of wrappers and implementation skeletons and hence reduces programming work for the CORBA component implementer.

The CORBA Component Model supports two different styles of communication, synchronous operational communication and asynchronous event communication. There is a broad application area, especially in the audio, video, telecommunications and defense domains, that demands a third communication style, known as continuous data streams. This specification extends the CORBA Component Model with an optional conformance point: native support for the communication of continuous data streams between CORBA components. It extends the meta model of CCM with constructs to model stream-specific ports on a component. Furthermore it develops a type system to be used for the classification of data streams.

Similar to the existing communication types, the communication of stream data will be performed by the container. For that reason, communicating containers need a common understanding about the transport of the data stream. This specification defines so called transport profiles that state rules of communication between containers. These profiles are completely independent of the actual data stream type (content) to be communicated.

To assist the container in the handling of the communication packets of a data stream, stream implementation profiles are defined, which state rules with respect to a certain data stream type for the component implementer. These stream (content) profiles are independent of the transport profiles.

This specification extends the component aspects of the Interface Definition Language and the Component Implementation Definition Language with stream-specific constructs.

2 Conformance

This specification defines optional behavior as a full stream conformance point, and a subset consistent with the Lightweight CCM profile. The same rules used to define the existing Lightweight CCM conformance point are applied to streams, defining a profile of the streams behavior suitable for resource-constrained systems. Implementations, in addition to the conformance points defined by CCM itself, must support all aspects of this specification:

• the CCM stream types,• stream-specific IDL extensions and stream-specific equivalent interfaces,• the CCM_TCP transport profile.

For the lightweight profile, introspection interfaces are disabled and CIDL is removed.

3 Normative References

The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.

CCM for Streams Adopted Specification 1

• CORBA Component Model specification• The Deployment and Configuration of Distributed Component-based Application• The Lightweight Profile of the CCM

4 Terms and Definitions

For the purposes of this specification, the terms and definitions given in the normative reference and the following apply.

Term Definitionbasic stream type The stream type system used in this specification is based on the terms basic

and constructed stream types. Basic stream types are the types that identify a specific concrete stream format. They can be annotated with stream type meta information. The term “basic” is used analogous to its use in IDL. Basic stream types are analogous to content-types in MIME or payload type (scoped by profile) in RTP.

constructed stream type Constructed stream types group basic stream types or other constructed stream type to new stream types. This can be used, for example, to define a stream type „Audio“. The term “constructed” is used analogous to its use in IDL.

value stream type Value stream types define the content of the stream using IDL data definitions.

stream implementation profile A stream implementation profile defines rules with respect to a certain stream type for the implementation logic of a component. These rules are roughly analogous to the RTP profiles used for the Real Time Protocol.

stream type meta information The stream data of a basic stream type can be further described by certain parameters like resolution or bit rate. All these parameters are collectively called stream type meta information. For a given basic stream type, a specific set of parameters of specific types is valid. This information is analogous to the MIME type parameters. Some stream type parameters may be valid to change during the transmission of stream data. Most are only valid to be specified when a stream is established.

stream port A port on a CORBA component that enables the component to communicate using continuous data streams. There are two kinds of stream ports, stream source and stream sink.

stream sink A stream port on a CORBA component that enables the component to receive a continuous data stream.

stream source A stream port on a CORBA component that enables the component to send a continuous data stream.

transport profile A transport profile defines certain rules for the inter-container communication. It selects a transport protocol and a set of rules describing how to use this protocol to communicate data. This includes rules for the connection setup phase between two components. Transport profiles may define a header that precedes each packet in a connection-oriented protocol like TCP. They may also specify metadata.

2 CCM for Streams Adopted Specification

5 Additional Information

5.1 Changes to Adopted OMG SpecificationsThis specification applies changes to the CCM specification in terms of the augmented CCM meta model, the IDL and CIDL grammar, the component implementation framework, and the container programming model.

This specification also discusses relationships between the Audio/Video Streams specification with this specification.

5.2 How to Read this SpecificationThe rest of this document contains the technical content of this specification. As background for this specification, readers are encouraged to first read the CORBA Component Model (http://www.omg.org/technology/documents/formal/components.htm) specification that complements this and the Audio/Video Streams (http://www.omg.org/technology/documents/formal/audio.htm) specification.

Although the chapters are organized in a logical manner and can be read sequentially, this is a reference specification and is intended to be read in a non-sequential manner.

5.3 AcknowledgementsThe following companies submitted and/or supported parts of this specification:

• Fraunhofer Institute Fokus• Humboldt University Berlin• Mercury Computer Systems• Deutsche Telekom/T-Systems

This specification is supported by participants of the COACH project consortium, supported by the IST Program of the European Union.


6 Basic Concepts

The exchange of continuous data (streams) between components of a distributed software application is a requirement especially in the telecommunications and signal processing domains. Continuous data streams are used to transport audio, video data or sensor data efficiently. A technology for distributed applications that allows for the native integration of stream-based communication opens the door for a broad range of new applications that until now in most cases are realized in a non-distributed way.

The CORBA Component Model is the OMG technology for building distributed object applications from pre-fabricated components. It introduces the concept of the container, a runtime construct that helps integrate the components’ business code with a variety of services through the interception of communication between components. The integration of stream-based communication into the CORBA Component Model enables this technology to also serve application domains like distributed audio, video, or sensor/signal processing. There are four applications domains that would certainly benefit from a CORBA Component Model streaming extension:

• audio and video presentations,• audio and video processing,• data acquisition, filtering and storage• sensor data set processing.

6.1 Stream TypesAudio and video data streams transport data that generally cannot be described with description languages like IDL. The actual format of these streams is defined using a bit syntax. In some cases, data streams can transport data that can be described using IDL. Such data streams continuously transport consecutive instances of an IDL data type.

When two components want to communicate, they must agree on the format of the communication. With audio and video data streams there are also implicit semantics connected with each audio or video type. Although PCM audio samples can be described using the CORBA basic data type Long, the implicit semantics of a PCM stream type forbids use of the values as color values for a bitmap - a PCM data stream is always something that can be reproduced using speakers. The set of possible formats that a component can choose from must be standardized. The definition of this set will require some compromise, since on one side there is a strong demand for a very expressive type system with clearly defined types, on the other side there is demand for a type system that allows flexible reuse of components, which sometimes will be prevented by two types that share many common features, but are declared different by the type system.

The solution is to find stream types that are expressive enough for the business logic of a component to decide whether it can process this type or not, and to attach additional information about the stream data as stream type meta information. A stream type defined in such a way could be a PCM stream type with additional meta information like the number of channels, the number of bits per sample and the kind of audio quantization. Stream types that have a concrete representation in some binary format will be called basic stream types. In cases where a component is able to produce or consume many different stream types, the concept of constructed stream types is used. Both these terms are analogous to their use in IDL. A constructed stream type groups other basic or constructed stream types to a new stream type that can be used in the signature of a component. During compatibility tests between components, a constructed stream type is recursively resolved to its constituting set of basic stream types. A constructed stream time is roughly like a “union” type: it expresses a type that, at any one time, may represent any of a set of types.

Value stream types are those whose content is expressed as consecutive instances of some IDL data type.


6.2 Stream PortsCORBA components expose ports through which they can communicate with other components or their environment. For the communication of stream data an additional kind of port is introduced, called a stream port. A stream port can be a source port or a sink port. A source port produces stream data of a stream type. If that stream type is a constructed stream type, it may potentially produce each of the basic stream types that constitute this constructed stream type. A sink port consumes stream data of a stream type. If that stream type is a constructed stream type, it can consume each of the basic stream types that constitute this constructed stream type. There is no bi-directional stream port. If a source port is associated with a constructed stream type, it must announce the actual basic stream type it will produce before streaming the data. This is necessary since in many cases the sink port has no chance to identify the stream data from the received bit signature. This is especially true for formats where the stream data does not hold embedded format information, like in RGB frames streams. There is also a provision for a sink port to express a preference for the stream type it would like to receive, among the previously specified types it is able to receive. The source port may then produce that stream type, or not.

6.3 Stream TransportSetting up and managing transport connections is the task of the container. For a given pair of components, where one of them has a source stream port and the other a compatible sink stream port, the two containers that host these components are responsible for setting up a transport connection to transport the stream data between both components. In some cases this requires a negotiation where the containers agree on the transport mechanism to use. The available transport mechanisms are described by transport profiles. Each transport profile specifies a transport protocol along with a number of parameters about how to utilize this protocol to transport stream data. The negotiation, if required, may be carried out using CORBA communication between the containers. This implies that the transport used to carry CORBA communication between containers (typically set up by ORBs), is assumed to be operational prior to the setup of transport connections for stream ports between components.

Note – These transport profiles are deferred pending work on the CORBA Transport QoS RFP, and thus are not part of this specification.

Each of these transport profiles specifies a certain transport protocol, may define a special header that precedes each packet sent using this profile, and also may define metadata delivered to the sink port. The metadata may or may not actually be conveyed over the transport connection. It may simply be state information about the connection. The optional profile-defined packet headers are not necessarily the portions of data that the business code of a component hands over to the container. A transport profile can allow fragmenting a data portion or combining portions of data into a single packet. A transport profile may require that the data portion received by the business code of the component with the sink stream port is exactly the data portion that was sent by the component with the source port.

6.4 Stream Content TransmissionTransport connections can be reused for the transfer of multiple data streams (i.e., stream data sets). Operations are defined to demarcate the beginning and the end of a data stream on a transport connection. The containers communicate the data stream boundaries to the receiving sink stream port of the component. This concept is especially useful for finite data streams, like file transfers, where a file can be transported multiple times over the same transport connection.


The source port components’ business code provides the portions of data to the container for the purpose of transmitting them to the receiving sink port component. A container is not required to interpret a data stream, and has no stream-type-specific knowledge. Different stream profiles may require different transport attributes, especially whether the exact packet of data provided by the source should be delivered intact to the sink (rather than refragmented), and/or whether dropping any data is allowed.

An example for such a stream is a stream of RGB frames. When a single frame is fragmented and transport as multiple packets over a non-reliable transport connection, some of the packets can be dropped by the network. This results in a scrambled RGB frame, since there is no information inside an RGB frame about the position of data in a frame. For the subsequently received frames this means that the whole stream of RGB frames is now corrupted, since synchronization on the start of a frame is not possible with this type of data. For RGB frame data streams, the implementation profile may forbid providing fragments of a frame to the container. Every data portion provided by the component’s business code would always hold an integral number of RGB frames. With this rule, the container is always able to detect meaningful elements in a data stream without knowing the exact format of the data. Meaningful entities in a data stream must be delivered to the target component completely or not at all. Some aspects of stream implementation profiles may be further affected by metadata associated with the source and sink ports used.

This specification does not preclude stream communication where multiple source ports collectively produce data to be consumed by multiple sink ports. However, transport profiles and stream implementation profiles must specifically enable this.

Support for streaming ports on a component requires additional component IDL constructs, additional operations on the component’s equivalent interface, new external interfaces for stream ports, and local context and callback interfaces for interactions between component and container.

Note that connections are always simplex for stream ports at the component interface level. Multiplexing or multicasting is always the responsibility of the container for stream ports. From a connection point of view, data streams are unidirectional, but from a control perspective, they are bidirectional, to allow sink ports to optionally abort streams being transmitted by source ports.


7 Stream Type System

This chapter describes the stream type system to be used in the CORBA Component Model for stream ports.

Stream-based communication takes place between a source stream port that produces stream data and a sink stream port that consumes stream data. To specify the type of stream data that is exchanged between components using stream-based interaction, a stream type system is needed. The stream type system classifies instances of data streams. A classification of data streams enables a type-safe binding of data stream ports between component instances, similar to the type-safe binding of other CCM port types.

• Basic stream types are defined as concrete data formats for the information content of streams, which are not necessarily defined using IDL, but are encoded some other way. Basic streams are used to transport streams of encoded data, typically audio or video data. The data is consumed and produced by component implementation logic as octet sequences, unless the basic stream type.

• Value stream types, are a subtype of basic streams, which transport consecutive marshalled instances of data types specified in a subset of IDL. If the IDL data type of a value stream is octet, it is indistinguishable from a basic stream that does not have a specified IDL data type, and is not considered a value stream type.

• Constructed stream types are a hierarchical grouping of multiple basic stream types or other constructed types, indicating the ability to produce or consume any of the basic or value types.

• Raw streams are untyped, and intended for applications where the format of the stream does not influence the functionality of a component. Examples for the applicability of this type are a component that encrypts or compresses a data stream or a component that reads from or writes to a file.

Considering today’s multimedia world numerous multimedia formats are in use. Among the most popular formats are:

• compressed formats

• e.g., MPEG1, MPEG2 or MPEG4 for video delivery or MP3 for audio encoding

• uncompressed formats

• e.g., YUV in its many variants or RGB555 and RGB24

Basic stream types are defined with respect to a certain binary format of the stream data. They specify unmistakably the meaning and interpretation of a finite or infinite sequence of bytes. Sometimes this binary format is described using a bit syntax. Other basic stream types are simply streams of bytes with a special semantics. The compatibility of components for the purpose of connecting source stream ports to sink stream ports is validated using the set of basic stream types supported by each stream port. The connection can be established, if and only if the basic stream types supported by the source stream port are a subset of the basic stream types supported by the sink stream port or the sink stream port has the special stream type Raw. These rules can be applied (used to check validity) at the time a CCM assembly deployment descriptor is created (application design time). The intention of this stream type system is to support the type validation of assembly connections at the same time as, and to the same extent as, other CCM port types such as facets and receptacles.

In the multimedia domain with its many different and also related formats, a concept for grouping multimedia formats can enable components to be more flexible and re-usable. Examples are render components that are able to operate on a set of different but related bit streams in a polymorphic way, rendering both MPEG1 and MPEG2 video streams. Constructed stream types group basic and other constructed stream types. As an example, a constructed stream type Audio can be defined that groups a number of basic audio stream types. A source stream port that is associated with a constructed stream type rather than a basic stream type expresses its potential to produce any of the basic stream types that constitute


its constructed stream type. The set of basic stream types that constitute a constructed stream type is determined by recursively resolving each constructed stream type to its grouped basic and constructed stream types until only basic stream types are left. A sink stream port that is associated with a constructed stream type expresses its ability to consume any of the basic stream types that constitute its constructed stream type.

There is one special stream type, which is neither a basic nor a constructed stream type, called Raw. This stream type can be used for all basic data streams, for all situations where the actual format of the data stream does not contribute to the functionality of the component. The Raw data stream type can especially be used on sink stream ports to specify that the behavior of the component does not depend on the concrete data inside the stream. Figure 7.1 illustrates the meta model for the stream types used in this specification.

Figure 7.1 - The Stream Type Meta Model

7.1 Basic Stream TypesThe compatibility of stream types is evaluated by comparing the individual basic stream types that make up a constructed stream type. For that reason, the set of basic stream types must be standardized. Initially, we can define a list of stream types as those already defined in RFC 3555, but in general any IANA-registered MIME media (content) type could be used. The registration procedure for these types includes defining required and optional parameters. To stay within the IDL language type system, we use the namespace Components::Streams::MIME, and define a new namespace for each MIME content type (currently application, audio, image, message, model, multipart, text, video), with the actual basic type defined as Components::Streams::MIME::<content-type>::<content-subtype>. Of course any user-defined basic type or any constructed stream type can use any namespace.

All MIME content types are case insensitive (as in IDL), all registered top level types contain only letters. To express special characters used in some MIME types and subtypes (-, ., +) in the basic stream type names, hyphens are replaced with single underscores, periods are replaced with double underscores, and plus-signs are replaced with triple underscores.

StreamType

ValueStreamType IDLTypeConstructedStreamType

BasicStream Type1.. *

*

RawStreamType

Constrained set -- see text

+grouped

1.. *

*+group


Note: if required, MIME type parameters that impact compatibility may be appended in alphabetical order, but there are character set issues with the parameter values. Such parameters are generally part of a Stream Profile (see Section 13.1, “Stream Profiles,” on page 53).

The raw type is represented by Components::Streams::Raw.

7.2 Constructed Stream TypesThis document does not standardize constructed stream types. They are essentially a modeling concept only and have no direct technological representation. Vendors can specify their own set of constructed stream types. During runtime, any type checks are always done using the basic stream types that constitute a constructed stream type.

7.3 The Raw Stream TypeThe Raw stream type is used whenever the format of a data stream does not matter and the concrete stream type is not a ValueStreamType. It is a direct instance of the meta class StreamType. All other stream types are either instances of the BasicStreamType class or the ConstructedStreamType class.

7.4 Value Stream TypesValue stream types are defined by specifying a constrained IDL data type for the content of the stream. The subset of IDL types that are allowed to be used in the definition of a value stream type are defined recursively. All IDL-defined “basic” types except any can be used, which includes:

• octet• char, wchar• short, long, long long• unsigned short, unsigned long, unsigned long long• float, double, long double• boolean

The IDL-defined “template types” string, wstring, and fixed and the IDL-defined constructed type enum may also be used.

For this brief discussion of value stream types, we will call the above types primitive types. We will call types built from these primitive types, compound types. This is to avoid confusion with IDL terminology.

Compound types are also valid to be used in a value stream type definition. Compound types are built from primitive types or other compound types (e.g., an IDL type constructed from an interface identifier is not valid). The following “compound” types can be used:

• sequence (termed a “template type” in IDL)• array (termed a “complex declarator” in IDL)• struct (termed a “constructed type” in IDL)• union (termed a “constructed type” in IDL)

Typecodes are excluded.


7.5 Compatibility of Source Stream Port and Sink Stream PortA source stream port can only be connected to a sink stream port if the associated stream types of source stream port respective sink stream port are compatible. There are a number of compatibility rules that constrain the compatibility of stream types. The compatibility rules are designed so that a sink stream port can be sure to always understand every potential stream data format that can be produced by the source stream port. If the source stream port is able to produce many different stream data formats (through the use of a constructed stream type), the sink stream port must be able to understand each of the formats, since at design time there is no information about the concrete stream data format that a source stream port will choose at runtime.

All basic stream types are based on data conveyed as octet sequences. Value stream types are based on some basic IDL data types (a defined subset). Raw streams are also based on octet sequences. All constructed stream types can be flattened to a list of its constituent basic and value stream types. The compatibility rules are as follows:

• A sink of type Raw is compatible with any source.

• A source of type Raw is compatible with any sink.

• A sink that is not of type Raw is compatible with sources of type Raw, or with sources all of whose constituent types are supported by the sink.

• A source that is not of type Raw is compatible with sinks of type Raw, or with sinks that support all of its constituent types.

7.6 IDL Extensions for the Definition of Stream TypesStream types are defined using IDL. For this reason, component IDL must be extended with a few constructs and one new keyword that allow the definition of new stream types. The extensions are underlined below:

(2) <definition> ::= <type_dcl> “;” | <const_dcl> “;” | <except_dcl> “;” | <interface> “;” | <module> “;” | <value> “;” | <type_id_dcl> “;” | <type_prefix_dcl> “;” | <event> “;” | <component> “;” | <home_dcl> “;” | <streamtype_dcl> “;”

(139) <streamtype_dcl> ::= (<stream_dcl> | <stream_fwd_dcl>)

(140) <stream_forward_dcl> ::= “streamtype” <identifier> “;”

(141) <stream_dcl> ::= (<basic_stream_dcl>|<constructed_stream_dcl>|<value_stream_dcl)

(142) <basic_stream_dcl> ::= “streamtype” “<>” <identifier> “;”

(143) <constructed_stream_dcl> ::= “streamtype” <identifer> “:” <scoped_name> [“,” <scoped_name>]*

(144) <value_stream_dcl> ::= “streamtype” “<” <scoped_name>“>” <identifier> “;”

A new stream type is introduced by the keyword streamtype (chosen over the better “stream” to avoid legacy collisions). For a forward declaration the name of the stream type simply follows the keyword and is followed by a “;”.


For a definition of basic or value stream types, the keyword is followed by “<” and optionally, for value stream types, by a scoped name that identifies the IDL type to be transported with streams conforming to this stream type. If no IDL type is provided, the stream is considered a basic stream and hence opaque to the IDL type system. After the optional scoped IDL type name, a “>” follows. After this the name of the new basic or value stream type is specified. The definition is closed by a “;”.

A constructed stream type definition has no “<>”, and follows the type identifier by a colon followed by a list of one or more basic type identifiers, similar in syntax to the inheritance specification for interfaces. A constructed stream type must only specify basic or constructed stream types after the stream identifier.

7.6.1 Usage Examples

The following examples demonstrate how to use the new keyword to specify stream types. Predefined basic stream types (e.g., based on MIME types) are defined in the same way as user-defined basic stream types or constructed stream types.

A forward declaration of a stream type can be written as follows:

streamtype MP3; streamtype MyOwnFormatStreamType; streamtype PositionDataStreamType;

The format of a basic stream can not be expressed using IDL, so the binary format of an encoded stream is opaque on the specification level. Basic stream types are specified as follows:

streamtype <> MP3; streamtype <> MyOwnFormatStreamType; streamtype <> RGBVideo;

In contrast to this, a value stream type need to specify an IDL data type that is transported over the data stream. The definition of example value stream types is as follows:

streamtype <long> MyLongStreamType; struct PositionData {

long x; long y; long z;

}; streamtype <PositionData> MyPositionDataStreamType;

Constructed stream types group other basic and constructed stream types. They are used whenever a component is capable of handling multiple related or independent basic stream data formats. Constructed stream types are specified in the following way:

streamtype MyAudioStreamType : PCM, MP3; streamtype MyVideoStreamType : RealVideo, WMV; streamtype MyMultimediaStreamType : MyAudioStreamType, MyVideoStreamType;


7.6.2 MIME Content Stream Types

This is a list of example stream type declarations based on those found in RFC 3555.

module Components { module Streams {

module MIME { module audio {

streamtype <> g722; }; module video {

streamtype <> mpeg4_generic; }; module image {

streamtype <> jpeg; };

}; };

};


8 Component Connectivity

This discussion of component connectivity applies to connectivity among all CCM port types, including facets, receptacles, emitters, publishers, consumers, as well as the stream ports (sink and source) defined in this specification. It is the intention of this specification to maintain as much consistency as possible in the treatment of all port types, while satisfying the specific requirements of stream ports.

There are three aspects of connectivity among CCM components:

1. The CCM assembly connections specify logical interconnections of type-compatible ports of components. This aspect is defined by the assembly designer and expressed in assembly deployment metadata.

2. The transport connection(s) move the actual data. This aspect is created at runtime by the containers. For CORBA ports (facets and receptacles) this is simply ORB transport, like IIOP (GIOP over TCP/IP). For stream ports, other protocols may be used that may or may not be suitable for ORB transport.

3. The information that moves among connected component ports, over transport connections. For CORBA connec-tions, this is the request/response messages between user and provider, emitter and consumer etc. For streaming con-nections, the actual data stream that is flowing from source to sink. Transport connections are typically serially reused for multiple streams (between stream ports) or multiple messages (between CORBA ports).

Each aspect will be discussed, and the extensions required for streams will be indicated. The specific interfaces and operations are defined in later chapters.

8.1 Assembly Connections

8.1.1 Background of CCM assemblies and deployment

As of the recently adopted update to the CCM deployment chapters, CCM deployment metadata is model-based and divided into three categories: component, target, and execution. The component metadata describes interfaces and implementations of components (and their resource requirements). The target metadata defines topology and resources existing in the target environment in which components will execute and communicate. The execution metadata defines a specific mapping (deployment) of how a component-based application will be deployed into the target environment.

Assemblies are found in the component metadata. They are implementations of components in the form of a hierarchical decomposition consisting of an assembly of interconnected lower level components (a.k.a. subcomponents). For example, an “assembly implementation” of a component describes how the component can be implemented using assembled and interconnected smaller components. The other type of implementation is a “monolithic” implementation: a typical compiled code implementation represented by some executable file (dll, exe, etc.). Connections defined in an assembly, among the ports of subcomponents can have their own requirements (QoS, protocols, etc.), which must be satisfied during deployment.

Assembly connections, in general, express that multiple user/output ports (receptacles, sources, emitters, publishers) are being connected to multiple provider/input ports (facets, sinks, consumers). This general case can be thought of as a “bus” with multiple ports putting data on the bus, and multiple ports taking data off the bus. This logical connection is thus like a “signal wire” between chips on a circuit board. Some port types expose the multiplicity to the component implementation (receptacles). Stream ports do not, to maximize reusability.


A “component-based application” is based on running a particular component functionality as an application. Running such an application requires: 1) choosing some implementation of that component to use, 2) choosing which computers (nodes) to host the monolithic (executable) implementation(s), and 3) choosing which communication pathways (busses, networks) to use for intercomponent communication. If the chosen implementation of the top level “application component” is monolithic, running the “component-based application” is simply running one executable file on one computer. If the chosen implementation of the application component is an assembly implementation, then the process involves recursively choosing implementations of each subcomponent, choosing where they will run, and choosing the communication paths for communications among those subcomponents. (Prior to the recently adopted update to the CCM deployment model, there was no such hierarchy, and applications were specifically defined as assemblies, not components).

Making all the choices mentioned above (which implementation?, which nodes?, which paths?) is called “deployment planning.” The result of this activity is the execution metadata, embodied in a deployment descriptor called a “deployment plan.” There is no hierarchy in a deployment plan. It is an explicit set of instantiations of monolithic component implementations on specific nodes, and specific associations assigning connections among component instance ports onto specific communication pathways.

Thus, when a component-based application is run, it is based on a deployment plan that defines how intercomponent communication is to be accomplished and which resources in the target environment should be used. If the deployment plan is not specific about these connections, the intercomponent communication may be negotiated, established, and configured at run time. On the other hand, the deployment plan can precisely define most details about how to create the necessary transport connections (described below).

Run time intercomponent connectivity is established by the deployment system, which first gets object references from containers housing the components with connected provider/input ports (facet, sink, consumer). These references are then passed to the containers housing components with connected user/output ports (receptacle, source, emitter, publisher). This allows the containers to provide the communication path between connected component implementation instances, since the “output” containers (hosting components with output ports) know how to reach the “input” containers (hosting components with input ports), and thus the CCM Assembly Connections are established. The port object references contain information about how communication is actually accomplished. Object references contain transport information (addressing, configuration, QoS) that allow the containers to talk to each other. Establishing the actual transport connections is discussed in Section 8.2, “Transport Connections,” on page 17.

8.1.2 New capabilities defined in this specification for Assembly Connections

Stream connections need additional information in the port references. References to stream sink ports are normal references to CORBA objects created by containers, allowing containers to perform remote control operations on the port objects, which are container objects, not component implementation objects. These objects are used by containers for connection and stream management. In addition to the normal CORBA transport information in these references, the references must also contain transport connection information to carry the stream data to the streaming sink port, which is usually not CORBA transport.

Each of the sink port object reference’s tagged profiles contain extra tagged components to describe the transport connection information for stream communication, in addition to the normal CORBA transport profile information in the profile. The CORBA type of the sink port objects is fixed and does not depend on the type of stream data actually consumed by the port.


To avoid various types of system congestion, the components and containers housing sink ports may need to send control messages (operations) to components and containers housing the connected source ports. Thus a reference to the source port object must be made available to the component/container housing the sink port. This “upstream” reference is not required for other port types, and is only provided when needed. One of the operations on the sink port object gives the source port object reference to the sink container for this upstream control purpose.

The rules for validating the type compatibility of stream ports at design time (when the assembly is defined), are different for stream connections and depend on the stream type system described earlier. The supported stream types are also placed in tagged components of the tagged profiles in the object reference.

8.2 Transport ConnectionsTo enable communication between assembly-connected ports, transport connections are established by the containers, and these connections must respect the QoS requirements expressed by:

• The (static) assembly connection metadata.

• The (static) component port metadata (of the component implementation).

• The stream-start-time dynamic port metadata.

The transport connections generally have the same lifetime as the application, although they may be transparently torn down and re-established as needed by the container/ORB (as defined in the CORBA messaging specification and RTCORBA specification) See http://www.omg.org/technology/documents/formal/corba_iiop.htm for additional information. [Note that these connection binding policies are not yet standardized in the deployment metadata - maybe we should do it in this specification].

For all ports, the container at the user/output side of a connection uses the information in the provider/input reference to select and establish a transport connection for CORBA operations on that reference.

8.2.1 CORBA ports

The transport connection is established by the local ORB in the normal CORBA fashion, possibly with QoS applied as in Real-time CORBA (or the new RFP for transport QoS). Such a transport connection carries CORBA requests and responses when the user port invokes operations on the provider port. The transport connection is usually “re-used” by repeated sending requests and responses for operation invocations. Transport connections can be shared for messages to multiple ports in the same process, or dedicated to specific ports.

8.2.2 Stream ports

For streaming ports, the normal CORBA transport connections are established for the container-supplied stream port objects, and then additional transport connections are established by the containers to convey stream data. The stream transport connection is “re-used” by repeatedly sending streams of data across the connection.

For stream transport connections, the additional sink port stream transport information in the provider/input reference is used to establish the stream connection. The stream source container does this by selecting among transport alternatives offered in the stream sink reference. If deployment metadata fixes the transport profile for a connection, then the reference will indicate this. In some cases an extra operation is performed on the sink port reference by the source port container. This extra operation is performed if any of the following conditions are true:

• If there is a choice of transport to be communicated to the sink port (“I can do any of these, among the ones that you have offered to do”).


• If the transport profile requires that the sink side be informed about additional source side transport parameters prior to connection establishment (“here are the final details necessary for you to make the connection”).

• If the source port container offers out of band upstream capabilities such as abort-stream. (“here is my reference so you can call me back when you need to”).

Conversely, no such operation is required if:

• The sink port only offers one transport

• The sink port needs no extra information for connection establishment (e.g., a typical TCP connection when the server side simply listens on its port and needs no client-side addressing information).

• The source container offers no upstream functionality.

8.2.3 New capabilities defined in this specification for Transport Connections

Containers create objects representing sink and source ports of instantiated components. (Source port objects are standardized, but optional at runtime and thus a quality of implementation).

Transport profiles for stream connections are embedded in the tagged profiles in sink port object references.

Components may express transport requirements and/or preferences in deployment metadata time. See Section 11.1, “Extensions to the Component Deployment metadata,” on page 49.

There is API support for components to modify transport parameters (those that are mutable) while a connection is established.

Source containers may issue an additional CORBA request to the sink container to finalize the stream transport decisions.

Stream profiles may assert transport requirements.

8.3 Information flowing between ports over transport connectionsTransport connections carry information between component ports. For CORBA ports, the information is the request and reply (or event) messages used to implement a sequence of remote operation invocations. For stream ports, the information is a sequence of one or more data streams. The APIs used by component implementations to send and receive information on CORBA ports are well defined in the existing base CCM specification. Stream ports require new local APIs to send and receive data stream information. A stream connection can carry consecutive streams of different stream types as long as the stream data type is supported by the connected ports.

Before a new data stream flows over a stream transport connection, a handshake must take place between containers to establish:

• the new actual basic stream type, and

• associated stream type parameters

• any transport parameter changes (unusual)

This handshake is generally within the scope of a transport connection and is used to delimit the different streams flowing across the transport connection.


New transport types are not negotiated for each stream, although this does not preclude the containers from implementing transport protocols that tear down and setup transport connections for each stream. However, it is possible that some dynamic transport parameters are also changed.

The choices made for each stream are based on information from both sides. The sink side knows what it will do with the stream data, and thus may want to express preferences or requirements upstream (as in the example of a small clipped window displaying a piece of a large image produced upstream). The source side knows when the new stream will start, and what types it can provide.

For each stream that flows across a connection, the source component must describe (to its container) the stream data type and stream type metadata to be used for the stream. The source container then can inform the sink container of this information. The sink container informs the sink component of this fact. After this information is conveyed from source to sink, the data content of the stream flows over the transport connection. In some cases, the sink component wants to express preferences for what stream type, and associated parameters, it wants to receive. It may do this statically, in the sink port object reference, or dynamically, when a new stream is being sent from the source.

When the source component implementation needs to demarcate the end of the stream, it does this by marking the last data in the stream, and the container uses this information to convey end-of-stream either in-band (if the transport connection supports this service adequately) or out-of-band via a CORBA call to the sink port object in the sink container. The sink container receives this indication (either in-band or out-of-band) and informs the sink component implementation in-band. Sink components can also “abort” a stream by informing its container that no further upstream data in the stream is desired or required. Such an indication is then conveyed from sink container to source container, again in-band if possible and out-of-band if not. This eliminates congestion and minimizes the latency for reusing stream connections for new data streams.

The out-of-band CORBA invocations to manage streams can be considered a fall-back to make up for the fact that transports generally to not provide in-band capabilities to do this. In-band capabilities are generally preferable.

8.3.1 New capabilities defined in this specification for information flow

This specification defines how stream data flows and is demarcated, over the transport connections established among stream ports. APIs are defined to be used for component implementations to produce, consume, and demarcate stream data. Containers are responsible transport-specific methods for demarcating and aborting streams, possibly using CORBA requests when the transport protocols do not support in-band demarcation or abort etc.

The set of basic stream types acceptable to the sink port are also included in the sink port object reference. This allows for a port compatibility check without extra remote operations. The supported stream types, and parameters, are ordered by preference. APIs are defined for source components to indicate stream types and for sink components to indicate preferred stream types and parameters (among those it is known to accept). Both source and sink components may abort a stream. Both source and sink components may modify (some) stream parameters and (some) transport parameters at run time.

Interoperability of data between containers is simply for basic streams that are not value streams. Octets are moved, possibly with message boundaries preserved. For value streams, the data between containers (on the wire) is an encapsulation of the sequence of IDL-defined types, encoded with at least version 1.2 CDR.


9 Component Interface Extensions

There are three levels of interfaces for CCM components. The component IDL defines the basic surface features of the component, and the CORBA interfaces they implement or use in interacting with other components. From this definition two other interfaces are generated:

• The external CORBA interfaces visible to non-component clients, other containers, and introspection.

• The local interfaces used by the author of a particular component implementation and used by the container to interact with the component.

This section defines the CCM extensions for the component IDL and the generated external CORBA interfaces. The next section of this specification (10) addresses the implementation interfaces (the Component Implementation Framework).

All new IDL in this section is introduced in the Components::Streams module unless otherwise specified.

9.1 Component IDL for Stream PortsFor specifying components with stream ports, rule 119 of the CCM IDL syntax must be augmented as underlined below:

(119’) <component_export> ::= <provides_dcl> “;” | <uses_dcl> “;” | <emits_dcl> “;” | <publishes_dcl> “;” | <consumes_dcl> “;” | <attr_dcl> “;” | <sink_dcl> “;” | <source_dcl> “;”

Also, two new rules must be added to the IDL syntax:

(144) <source_dcl> ::= “source” <scoped_name> <identifier>

(145) <sink_dcl> ::= “sink” <scoped_name> <identifier>

A stream port on a component is defined by the keyword source or sink, followed by the stream type of the stream port and the name of the stream port in the scope of the component. The stream port definition is terminated by a “;”.

9.2 ExamplesThe new IDL constructs for the specification of stream ports on a component can be used as follows:

component MyComponent {

source Components::Streams::MIME::audio::MP3 mp3_out1; source Components::Streams::MP3 mp3_out2; sink Components::Streams::MP3 mp3_input; sink Components::Streams::PCM pcm_input;

};

This defines a component MyComponent that has a two source stream ports mp3_out1, mp3_out2 of type MP3, and a sink stream port mp3_input of type MP3 and a sink stream port pcm_input of type PCM. These stream ports all are associated with basic stream types.


struct PositionData { long x; long y; long z;


component MyComponent5 {

sink MyPositionDataStreamType pos_data_input; source Components::Streams::RGBVideo video_output;

};

This defines a component MyComponent5 that has a sink stream port pos_data_input of type MyPositionDataStreamType and a source stream port video_output of type RGBVideo. The sink port is associated with a value stream type, while the source port has a basic stream type.

9.3 Equivalent IDL MappingFor non-stream CCM component ports, additional type-specific interfaces are defined by the equivalent IDL mapping of CCM for the component’s equivalent interface. These operations are in fact used rarely, since they are not needed when the application is executed through the generic CCM deployment infrastructure. This specification defines a set of basic stream types and a means by which these stream types can be grouped into new constructed stream types. Because the stream type system is unrelated to CORBA interface types, there is no relationship between stream types and CORBA interfaces hence the CORBA interfaces used to externalize source and sink port functionality are invariant.

With these interfaces being invariant, the only value of the type-specific interfaces over the generic interfaces would be the special operation name that reflects the stream port name for which functionality is being accessed. Since such port-name-specific operations provide only trivial value for an application, no type-specific equivalent IDL mapping for stream ports has been specified. Thus generic operations must be used for all external stream-related control interactions.

This specification does not define external interfaces generated that are specific to the component IDL. Rather, components with stream ports simply inherit another concrete StreamPorts interface.

9.4 The StreamPorts InterfaceThe StreamPorts interface is defined to bundle all stream-related external management operations that are not involved in actually processing streams by the implementation. This interface, analogous to the Navigation and Receptacles interface, is inherited along with the interface CCMObject and thus both the StreamPorts and the CCMObject base interfaces are inherited for all CORBA components with stream ports. StreamPorts is not directly inherited by CCMObject since stream ports is an optional conformance point and thus inheriting StreamPorts by CCMObject would create two versions of CCMObject under the same repository id. This violates the OMA, thus StreamPorts is inherited by the actual equivalent interface at the same level as CCMObject.

The StreamPorts interface supports these usage scenarios:

• Deployment systems, including containers, are required to create/destroy, manage, configure, and interconnect components.

• Non-component CORBA Clients (maybe another component, maybe not) which needs to control or navigate beyond the operational intercomponent interactions.


• Tools for introspection and system monitoring.

9.4.1 StreamPorts operations for deployment — none

The component execution environment is based on: 1) a container (usually existing prior to any loading or instantiation of component implementation code), 2) the functional component implementation code (“business logic”) using local interfaces, and 3) a container-specific and component-specific generated code “wrapper” to bridge between the generic container software and the type-specific component implementation code. Both the business logic and the wrapper are combined in the packaged component (e.g., the dll or exe). The minimum requirement enabling the container to support deployment, is to load, instantiate, and configure the local component implementation (business logic + wrapper), and create the external communication references that other components (or clients) use to operationally communicate with the local (to its container) component implementation. Supporting ad hoc control, navigation, or introspection is not necessary for basic deployment.

Internal operations (executor, callback, context) generated for deployment are described in the Component Implementation section below. There are no external interfaces required for deployment, so there is no StreamPorts operations for deployment since:

• Containers privately can be aware of the internal wrapper interfaces for deployment.

• Stream ports do not export type-specific object references.

External CORBA references for ports are provided to the deployment system by the container. In the case of stream ports (sink or source), they are of fixed type (Sink and Source). The object references for these ports contain not only the standard contents for performing CORBA operations on these objects, but also contents for making the streaming data transport connections. This is done using tagged components. One, TAG_STREAM_CONTENT, carries stream type information of the sink port (e.g., which basic stream types are supported, and any required or preferred parameters to those types). Another, TAG_STREAM_TRANSPORT, carries information about transport connections for stream data. Putting this information inside the IOR allows the deployment system to treat the connectivity of stream ports the same as other CCM port types, leaving the deployment system unaffected by this optional CCM feature. Only containers and component implementations need be aware of stream ports.

So, when a container provides the references to the Sink objects to the deployment system, it embeds stream content and stream transport information in that reference. There is no requirement that the container provide these references to the deployment system in any particular way since the interface between the container and the wrapper is container-specific. The provide_sink and connect_to_sink operations on the StreamPorts interface are defined for consistency with the treatment of CCM facets and receptacles, and to enable the adhoc introspection and connectivity of components with stream ports. They are not necessary for deployment.

9.4.2 StreamPorts operations for clients needing connectivity and navigation

CCM allows for clients to navigate from facet references to the component reference, and the get_component operation should be supported for the generic external stream port interfaces (Sink and Source). Since CCM supports a standardized and externalized method for clients to make connections, there are operations on the StreamPorts interface to do this.

module Components { struct TransportProfile; typedef sequence<TransportProfile> TransportProfileSeq;

}; interface Sink {


}; interface StreamPorts {

exception UnsupportedStreamType { CORBA::RepositoryIdSeq unsupported_stream_types;

}; Sink provide_sink(in FeatureName the_sink)

raises(InvalidName); Cookie connect_to_sink(in FeatureName the_source, in Sink the_sink,

in TransportProfileSeq the_profiles) raises(InvalidName, ExceededConnectionLimit, InvalidConnection,

AlreadyConnected, UnsupportedStreamType, TransportFailed) ; Sink disconnect_from_sink(in FeatureName the_source, in Cookie ck)

raises(InvalidName, InvalidConnection, NoConnection); };

The operations are described below.

provide_sink

A client may navigate from the component interface to the Sink interface of a sink stream port on a component using the provide_sink operation. Sink interfaces are identified by the name of their sink stream port. If there is no sink stream port with the name the_sink, the InvalidName exception is raised.

A component that does not have any sink stream ports (e.g., a basic component) will have no valid the_sink parameter to this operation and thus shall always raise the InvalidName exception.

connect_to_sink

The connect_to_sink operation is used to connect a source stream port of the component to a sink port of a different component. The outcome of a successful call of this operation is an established transport connection between the source and the sink stream port over which stream data can be communicated. This operation may result in invocations of finalize_transport on the Sink interface specified in the_sink. If the operation fails, the stream ports of the components have not been connected and hence no stream data communication is possible.

The parameter the_source specifies the source stream port name for which a connection should be established. The parameter the_sink specifies the Sink interface of the sink stream port that should be connected to this source stream port. The parameter the_profiles provides optional configuration values for the transport connection. The presence of a single transport profile causes the container to use this profile. If there is more than one profile, any one can be used, but the source container should choose the first one among those that it can use, since the profiles are in the order of preference of the sink.

This operation returns a Cookie value that can be used subsequently to disconnect (which results in unbinding the stream ports) the object reference.

If the the_source parameter does not specify a valid name of a source stream port on the component, the InvalidName exception is raised.

If the transport connection cannot support connections to multiple sinks, and one sink is already connected, the AlreadyConnected exception is raised. Note that this does not depend on the implementation, but rather the transport and container.

If the sink stream port specified through the the_sink parameter is not compatible with the source stream port, the InvalidConnection exception is raised.


If the transport or container-defined limit on the number of bindings of this source is exceeded, the ExceededConnectionLimit exception is raised.

If no transport can be set up between the source stream port and the sink stream port, the TransportFailed exception should be raised.

A component that does not have any source stream ports (e.g., a basic component) will have no valid the_source parameter to this operation and thus shall always raise the InvalidName exception.

disconnect_from_sink

The disconnect_from_sink operation disassociates the Sink object reference associated with the Cookie value ck (i.e., the object reference that was bound by the operation that created this Cookie value) from the source stream port and closes any transport connection belonging to the sink stream port identified by the ck parameter.

If the the_source parameter does not specify a valid source stream port name, the InvalidName exception is raised.

If there is no current connection, the NoConnection exception is raised.

If the Cookie value in the ck parameter does not denote an existing connection on the source stream port, the InvalidConnection exception is raised.

A component that does not have any source ports (e.g, a basic component) will have no valid the_source parameter to this operation and thus shall always raise the InvalidName exception.

9.4.3 StreamPorts operations for introspection

To be consistent with the introspection interfaces in CCM for facets and receptacles, the following interfaces are provided, whose functionality is the same as the analogous interfaces for facets and receptacles. Stream ports are always multiplex, from an interface perspective, but possibly simplex at run time (independent of the component implementation). Containers manage multi-way stream connections so the component implementation is not aware of it. For example, the component interface or implementation does not define or care whether a stream source is connected to multiple sinks. These interfaces are disabled in the Lightweight CCM profile.

valuetype SinkDescription : PortDescription { public CORBA::RepositoryIdSeq basic_stream_types; public Sink sink_ref;

}; typedef sequence<SinkDescription> SinkDescriptions; struct SourceConnection {

Sink sink_ref; Cookie ck;

}; typedef sequence<SourceConnection> SourceConnections; valuetype SourceDescription : PortDescription {

public CORBA::RepositoryIdSeq basic_stream_types; public SourceConnections connections;

}; typedef sequence<SourceDescription> SourceDescriptions; interface StreamPorts {

SinkDescriptions get_all_sinks(); SinkDescriptions get_named_sinks(in NameList names)

raises(InvalidName);


SourceConnections get_connections(in FeatureName the_source) raises(InvalidName);

SourceDescriptions get_all_sources(); SourceDescriptions get_named_sources(in NameList names)

raises(InvalidName); };

The operations are described below:

get_all_sinks

The get_all_sinks operation returns a sequence of valuetypes describing the sink stream ports of the component. The sequence shall contain descriptions and references for all of the sink stream ports in the component’s inheritance hierarchy. The order in which these values occur in the sequence is not specified.

A component that does not have any sink stream ports shall return a sequence of length zero.

get_named_sinks

The get_named_sinks operation returns a sequence of valuetypes describing the sink stream ports of a component that are named in the names parameter. If any name in the names parameter is not a valid name for a sink stream port on that component, the operation raises the InvalidName exception. The order in which these values occur in the sequence is not specified.

A component that does not have any sink stream ports (e.g., a basic component) will have no valid names parameter to this operation and thus shall always raise the InvalidName exception.

get_connections

The get_connections operation returns a sequence of SourceConnection values for the source stream port named by the the_source parameter. If the the_source parameter does not specify a valid name of a source stream port, the InvalidName exception is raised.

A component that does not have any source stream port (e.g., a basic component) will have no valid the_source parameter to this operation and thus shall always raise the InvalidName exception.

get_all_sources

The get_all_sources operation returns a sequence of valuetypes describing the source stream ports of a component. The sequence shall contain information about all source stream ports in the component’s inheritance hierarchy. The order in which these values occur in the sequence is not specified.

A component that does not have any source stream ports returns a sequence of length zero.

get_named_sources

The get_named_sources operation returns a sequence of valuetypes describing the source stream ports of a component that are named in the names parameter. If any name in the names parameter is not a valid name for a source stream port on that component, the operation raises the InvalidName exception. The order in which these values occur in the sequence is not specified.

A component that does not have any source stream port (e.g., a basic component) will have no valid names parameter to this operation and thus shall always raise the InvalidName exception.


9.5 The Sink InterfaceEvery sink stream port on a component is represented by an independent CORBA object created by the container, which implements the interface Sink. This interface supports negotiation of a transport profile and setup of a transport connection with respect to an agreed transport profile. It also supports the out-of-band initiation of each data stream flowing over the transport connection. This interface is invariant and does not depend on the actual stream type(s) that the represented sink stream port is associated with.

9.5.1 Sink object references

The deployment system establishes connections between component ports by requesting a port object reference from the container(s) housing the sink port(s) and giving it (them) to the container(s) housing the source port(s). This is the same procedure as is used for any component ports (receptacles, facets, emitters, consumers, etc.). The conveyance of the sink reference to the container of the source port is essentially an initial one-way communication from sink to source, via information embedded in the object reference. The IOR contains two types of tagged components, one for stream type information and one for transport profiles.

module IOP { const ComponentId TAG_STREAM_DATA_TYPES = xx; const ComponentId TAG_STREAM_TRANSPORT_PROFILES = xx;

};

9.5.1.1 Tagged components for stream type information

A Sink IOR may contain a tagged component for each supported basic type, or the single IDL type. The tag is TAG_STREAM_DATA_TYPE, and the value is a CORBA::RepositoryIdSeq. The purpose of these components is to enable type checking at the time of connection. This checking is redundant with the type checking that may be done when connections are created in the assembly metadata. It also provides a set of sink stream data type preferences that can be used by the source component in selecting among several possible stream data types it is able to produce. The order of these stream types represents the order of preference of the sink component. There should only be one such component.

If a sink port container does not provide any of this information, then no connection-time error checking is done. This delays any compatibility checking until the time the first data stream is initiated over the connection, and provides no preferences. If this information is present, the source container should use it to perform compatibility checking at that point.

9.5.1.2 Tagged components for stream transport profiles

A Sink IOR shall contain a tagged component containing all transport profiles supported by the sink container for that port. The order of the profiles indicates a preference. The tag is TAG_STREAM_TRANSPORT_PROFILES and the value is defined by the TransportProfileSeq containing TransportProfile structures as defined below: The TransportProfile type is in the Components module rather than the Components::Streams module due to its possible application to other port types.

module Components { typedef CORBA::OctetSeq TransportParameters; struct TransportProfile {

IOP::ProfileId tag; boolean complete; ConfigValues properties;


TransportParameters parameters; };

};

The tag member indicates the transport protocol, and uses the IOP::ProfileId type already established to indicate CORBA interoperability protocols, such as TAG_INTERNET_IIOP. Some tags may only apply to stream transport. The properties member indicates values of generic properties that are defined to be common across protocols, hopefully in the submission to the recent Transport QoS RFP. The parameters member is an encapsulation of transport-specific parameters in a single efficient data structure.

A transport profile is considered complete if it contains sufficient information for sink (provider) or source (user) side to establish the transport connection with no further out of band communication with the other side. The complete member indicates whether the sink/provider container considers the transport profile complete. If a Sink reference contains one transport profile component, and that transport profile is complete, then the source container can initiate the connection with no further negotiation or communication. It there are multiple transport profiles, or the single transport profile is not complete, then further out-of-band communication is necessary (see below) since the source container must either:

• Inform the sink container which transport profile has been selected for use, and/or

• Inform the sink container of additional transport information to enable it to connect, and/or

• Obtain from the sink container additional transport information to enable the source side to connect.

Note that the completeness of a transport profile typically is dependent on whether resources such as TCP ports are preallocated or not. Resource-conservative containers may avoid any such allocations until it is known whether a transport will in fact be used. A possible transport profile would be TCP with client and server roles reversed (where the sink was required to issue a TCP connect to the user which was listening). In this case the source container would need to indicate the TCP port to the provider. Thus the transport profile produced by the sink container would be incomplete since it did not contain the TCP port of the source container.

9.5.2 Sink operations for transport negotiation and connection management

Containers have transport-specific knowledge (either statically or via plug-ins of some sort). The operations defined here are used when required by different scenarios. They generally provide out-of-band information and indications that do not depend on the underlying stream transport mechanisms. Thus the containers use them when required and indicated for specific transports. A transport will define its properties and parameters, the role of the provider and user in connection establishment, and whether modifications of some parameters or properties are allowed after connections are established.

When the conditions of transport profile information require additional transport negotiation as mentioned above (e.g., when incomplete), the finalize_transport operation is used. It is not necessary or useful if the conditions are not met. If a transport allows modification to its properties or parameters while a connection is established, and such modification information must be communicated out of band, the modify_transport operation is used. Note that, if allowed by the transport, modifications also may occur when new data streams are initiated. These operations are defined by the following IDL:

interface Source; interface Sink {

exception TransportFailed {}; void finalize_transport(in boolean now, inout TransportProfile the_profile,

in Source the_source) raises(TransportFailed);

void modify_transport(in TransportProfile the_profile)


raises(TransportFailed); void release_transport();

};

The finalize_transport operation indicates to the sink container the specific transport profile that will be used (via the tag member). It also provides any required completeness information in the profile to the sink, and retrieves any completeness information from the sink. It also provides a Source stream port reference to enable the sink container to communicate with the source container. See the definition of the Streams::Source interface below. When the operation returns, it does not indicate that the connection has been established, since the sink container may be passive in connection establishment. For a given transport profile, either side may be active or passive. The now argument indicates whether any sink-side connection establishment should be accomplished before the operation returns. Deployment systems will ensure that all connections are established during the finish_launch operation [D&C], and thus would typically provide a FALSE value in the now argument to enable maximum concurrency. If ad hoc connections are made using the connect_to_sink operation, its implementation would need to provide a TRUE value in the now argument.

If the now argument is TRUE, the operation shall raise the TransportFailed exception if connection establishment on the sink side failed.

The modify_transport operation is used when the source container needs to inform the sink container of changes in the operation (properties and parameters) of the transport. Only modified properties are sent. This is only necessary when any allowable modifications require out-of-band communication for the transport profile in use.

The release_transport operation is used to inform the sink port that the transport connection is no longer needed and any associated resources may be released. This is only necessary when an out-of-band indication is required by the transport, or when such an indication might accelerate the recovery of resources. This operation would be used in the context of a disconnect_sink operation or when the deployment system was tearing down the application.

9.5.3 Sink operations for stream negotiation, demarcation and management

While a transport connection is established, multiple data streams may be transmitted from source to sink. Several operations are used to:

• Negotiate the stream data type and its properties and parameters.

• Indicate out of band, to finish a stream.

• Indicate out of band, to start a stream.

• Force a stream to be aborted.

These operations are defined by this IDL:

exception TransportFailed {}; exception NoStream {}; exception DuplicateStream {}; exception AlreadyBound {}; exception UnsupportedStreamType {

CORBA::RepositoryIdSeq unsupported_stream_types; }; typedef CORBA::OctetSeq StreamParameters; struct StreamProfile {

CORBA::RepositoryId repository_id; ConfigValues properties;


StreamParameters parameters; }; enum PreviousAction {

NoAction, FinishStream, AbortStream

}; typedef CORBA::OctetSeq Marker; interface Sink {

void start_stream (in PreviousAction previous, in Marker the_marker, in StreamProfile stream_profile, in TransportProfile transport_profile)

raises (UnsupportedStreamType, DuplicateStream,TransportFailed); void finish_stream(in Marker the_marker)

raises (NoStream); void abort_stream(in Marker the_marker)

raises (NoStream); };

This start_stream operation is called on the sink stream port to announce the start of the transmission of new stream data. The stream_profile argument is used to describe the basic or value stream type that to be produced by the source stream port, along with any parameters. This operation is needed both to explicitly name a stream type for which stream data will be produced and to demarcate the current stream from previous/future streams for the matter of transport connection reuse.

The transport_profile arguments allow the source to modify the transport profile associated with the transport connection.

If this operation is also intended to finish or abort any previous stream, the previous argument should be set to FinishStream or AbortStream, respectively. This avoids the need for an extra intercontainer operation to finish one stream and start another.

If there is already an active stream that has not been finished or aborted, and the previous argument is NoAction, the DuplicateStream exception is raised. If the sink stream port does not support the provided physical stream type, the UnsupportedStreamType exception is raised, with the unsupported_stream_types parameter holding the unsupported stream type. If the transport profile cannot be modified as indicated, the TransportFailed exception is raised.

The finish_stream operation is called on the sink stream port to announce the end of the transmission of stream data of a particular logical stream. When the finish_stream operation is called the current stream is finished. After this call a component can expect to not get any stream data from the container until another call of start_stream. This operation does not affect the connection between the two components. A container with a source stream port can call the start_stream operation to start a new logical stream. If start_stream has not been called and hence there is no active stream, the NoStream exception will be raised.

Every transport must be able to somehow synchronize the data on the transport connection with the finish/abort/start operations to the Sink object. This could be accomplished by tearing down and reestablishing the connection or other mechanism specific to the transport protocol. The marker argument is an opaque value specific to a transport profile which may be used by a container to help in this synchronization. It would normally be used to flush any stale data out of the transport connection.


9.6 The Source InterfaceThere are several situations that require the sink container to communicate with the source container and this Streams::Source interface is implemented by an object created by the source container and provided to the sink container in the finalize_transport operation on the Streams::Sink interface.

The IDL for this interface is:

interface Source {Marker abort_stream(); void modify_transport(in TransportProfile the_profile)

raises(TransportFailed); };

The abort_stream operation is used to inform the source that the sink has no more use for the current stream, and provides the source the possibility to return a synchronization marker (which is used by the containers transport code to synchronize the stream).

The modify_transport operation is used to modify transport properties or parameters while a connection is established (when the transport profile in use allows such modifications).

9.7 Consolidated External IDL

#include <orb.idl>module IOP {

const ComponentId TAG_STREAM_DATA_TYPES = xx; const ComponentId TAG_STREAM_TRANSPORT_PROFILES = xx;

}; module Components {

typedef CORBA::OctetSeq TransportParameters; struct TransportProfile {

IOP::ProfileId tag; boolean complete; ConfigValues properties; TransportParameters parameters;

}; typedef sequence<TransportProfile> TransportProfileSeq;


module Streams { exception TransportFailed {}; exception NoStream {}; exception DuplicateStream {}; exception AlreadyBound {}; exception UnsupportedStreamType {

CORBA::RepositoryIdSeq unsupported_stream_types; }; typedef CORBA::OctetSeq StreamParameters; struct StreamProfile {

CORBA::RepositoryId repository_id; ConfigValues properties; StreamParameters parameters;

}; enum PreviousAction {

NoAction, FinishStream, AbortStream

}; typedef CORBA::OctetSeq Marker; interface Source {

Marker abort_stream(); void modify_transport(in TransportProfile the_profile)

raises(TransportFailed); }; interface Sink {

void finalize_transport(in boolean now, inout TransportProfile the_profile, in Source the_source)

raises(TransportFailed); void modify_transport(in TransportProfile the_profile)

raises(TransportFailed); void release_transport(); void start_stream (in PreviousAction previous, in Marker the_marker,

in StreamProfile stream_profile, in TransportProfile transport_profile)

raises (UnsupportedStreamType, DuplicateStream, TransportFailed); void finish_stream(in Marker the_marker)

raises (NoStream); void abort_stream(in Marker the_marker)

raises (NoStream); }; interface StreamPorts {

Sink provide_sink(in FeatureName the_sink) raises(InvalidName);

Cookie connect_to_sink(in FeatureName the_source, in Sink the_sink, in TransportProfileSeq the_profiles)

raises(InvalidName, ExceededConnectionLimit, InvalidConnection, AlreadyConnected, UnsupportedStreamType, TransportFailed) ;

Sink disconnect_from_sink(in FeatureName the_source, in Cookie ck) raises(InvalidName, InvalidConnection, NoConnection);


// Introspection interfaces valuetype SinkDescription : PortDescription {

public CORBA::RepositoryIdSeq basic_stream_types; public Sink sink_ref;

}; typedef sequence<SinkDescription> SinkDescriptions; struct SourceConnection {

Sink sink_ref; Cookie ck;

}; typedef sequence<SourceConnection> SourceConnections; valuetype SourceDescription : PortDescription {

public CORBA::RepositoryIdSeq basic_stream_types; public SourceConnections connections;

}; typedef sequence<SourceDescription> SourceDescriptions; SinkDescriptions get_all_sinks(); SinkDescriptions get_named_sinks(in NameList names)

raises(InvalidName); SourceConnections get_connections(in FeatureName the_source)

raises(InvalidName); SourceDescriptions get_all_sources(); SourceDescriptions get_named_sources(in NameList names)

raises(InvalidName); };

}; };

};


10 Component Implementation Framework Extension

Stream data is produced at source stream ports of a component. The produced stream data is conveyed to the (local) container using operations on a port-specific part of the context of the component. The container communicates the stream data to the container hosting the component with the connected sink port. This sink container makes the stream data available to the sink stream port of another component using a well-defined port-specific context or callback interface on that component. The interfaces provided by the component to the container (callback), as well as those provided by the container to the component (context) are described in this chapter. All interfaces and types in this specification are placed in the Components::Streams:: module unless otherwise noted. All are local.

10.1 Stream port Interactions between component implementation and containerIn CCM terminology, the container invokes operations on the local component implementation via “callback” interfaces, and the component invokes operations on the local container via the “context” interfaces. In CCM, the component implementation executor inherits from the EnterpriseComponent class, and has some extra operations generated from the component IDL for facets and event sinks. This represents the component’s callback interface. Also in CCM, a specific context interface is generated, based also on the component IDL, which inherits from CCMContext, and has extra methods generated for receptacles and event sources.

For stream ports, the executor’s callback interface also inherits from Components::Streams::StreamComponent, and the context also inherits from Components::Streams::StreamContext. Furthermore, for each stream port, an operation get_<portname>, is added to the generated context interface (similar to the get_<facetname> operations for facets). This operation returns a local per-stream-port context object used by the component to interact with the container about that port. For sink ports, the IDL for this context operation is:

SinkContext get_<portname>();

For source ports:

SourceContext get_<portname>();

Similarly, for each stream port, an operation get_<portname> is added to the callback interface, which returns a local per-stream-port callback object with which the container interacts with the component about that port. For sink ports, the IDL for this operation is:

SinkPort get_<portname>();

For source ports:

SourcePort get_<portname>();

10.2 Execution ModelsThree different execution models are supported for processing streams, to ensure that components can always be written in a natural and clear style for the job they are doing. The component declares, for each port, which model it wants. The models are:

1. The event-driven model where callback operations (new_buffer) are made by the container to the port callback objects, to inform the component of the availability of buffers on ports. For sink ports, the container invokes an oper-ation on the sink port callback object providing a new buffer containing input data. For source ports, the container


invokes an operation on the source port callback object providing a new empty buffer for the component to fill with output data.

2. The blocking model where the component invokes blocking operations (with time-out) on the port context objects to obtain the next buffer (get_buffer). For sink ports, the operation blocks until it returns a buffer filled with new input data. For source ports, the operation blocks until it returns a new empty buffer to fill with output data.

3. The run condition model where the component informs the container under what conditions of buffer availability and the passage of time, should the component run. When the component-declared condition is true, the container calls the run operation on the component’s callback interface, and available buffers are accessible as attributes of the ports’ context interfaces. The run operation is not per port. This model is especially convenient when data from multiple inputs is being combined to produce data for an output.

The component informs the container of the model to use on each port by setting an attribute on the port’s context object. To enable the event-driven model on a port, the component sets the enable_new_buffer attribute to TRUE. To enable the run condition model on any ports, the component calls the create_run_condition and set_run_condition operations on the component’s context object. The blocking model is always enabled, and invoked by the component calling the get_buffer operation on the port.

Buffer management is discussed in detail below.

10.2.1 Event-driven Execution Model

The event-driven execution model is characterized by arriving buffers of stream sink data causing invocations in some container thread on the callback interface for a stream sink port. This is analogous to normal CORBA inbound request dispatching via an object adapter in some thread provided by OA. This model may also be used on source ports, where the callback is providing a buffer to fill. In both cases the buffer is provided to the container via the new_buffer operation the stream port’s callback interface.

When input buffers on a sink port are provided in a callback invocation of new_buffer, the component can simply consume the data and return, as it would with an inbound CORBA oneway request. It may also take ownership of the buffer (using take()) before returning so that it may access the data (without copying) after the new_buffer operation returns. It may also pass the data directly to a source port (using send_buffer) before returning, releasing ownership of the buffer to the source port.

This execution model is also analogous to how normal CCM facet ports are used with oneway operations, or how CCM event sinks work. This model is enabled on a port by setting the enable_new_buffer attribute on the component’s context object to TRUE.

10.2.2 Blocking Execution Model

The blocking execution model supports a typical sequential coding style where the component implementation code specifically waits for a new buffer of input data to consume on a sink port, and/or specifically waits for a new buffer to fill with output data on a source port. In both cases the component obtains the buffer from the container by invoking the get_buffer operation on the port’s context interface. The component may specify a time-out for waiting or not wait at all and use get_buffer operation as a polling operation.

The blocking execution model on a source port may be combined with the event-driven model on a sink port, so that the component calls the blocking get_buffer operation on a source port while executing in a new_buffer operation on a sink port.


10.2.3 Run-condition Execution Model

The “run condition” model provides a more powerful and natural model for stream processing which delegates more scheduling responsibility to the container, and simplifies many typical streaming component implementations. In this model the component implementation declares to the container a predicate indicating the conditions under which the component should run, in order to process (produce and/or consume) stream data. This predicate, the run condition, is a logical expression based on the readiness of sink or source ports, as well as the passage of time. Readiness of a stream port is based on buffer availability: buffers with input data at sink ports, or buffers available to fill at source ports.

When the component’s run operation is called by container, the available buffers are accessible as attributes of the various ports’ context interfaces. The passage of time is either relative to the previous invocation of the run operation, or periodic timing of successive invocations.

When a component’s run condition is TRUE, the container executes the component by invoking the run operation on the component’s callback interface (Streams::StreamComponent::Run):

RunResult run() raises (Components::CCMException);

When, during execution of the run operation, the component completely consumes all the data in an input buffer, or completely produces (fills) the contents of an output buffer, it “advances” the port. Advancing a port means that the current buffer is released (input) or sent (output), and a new buffer is requested asynchronously. More details on buffer management are described below. Note that if the component does not fully process an input buffer or complete the filling of an output buffer, the buffers are guaranteed to persist until the next invocation of run.

The RunResult enumeration is defined as:

enum RunResult {OK, ADVANCE_ALL, NO_MORE

};

The run operation returns OK, when it has done its processing, and expects to be called again when its run condition is TRUE. The run operation returns ADVANCE_ALL when it has done its processing, and wants to advance all stream ports (all buffer on all ports). The run operation returns NO_MORE when it never wants to be called again (equivalent to setting its run condition permanently to FALSE). Any exceptions thrown by the run operation to the container are reported as required by the container and no further run invocations are made.

This model of execution allows for both zero-copy data movement from stream input to stream output, and for conveniently combining multiple stream inputs into one or more outputs. It delegates responsibility for scheduling the execution of the component to the container, based on the component’s needs for data or buffers at its streaming ports, or the passage of time. It is a non-blocking model: the component returns when it can do no work, rather than blocking on some single resource (output buffer availability, input flow control, output flow control) or blocking for time passing. Simple stream processing is simple to implement, since the run operation just takes data from input buffers, places data in output buffers, and returns. More complex implementations using this model are typically written in the style of finite state machines.


10.2.3.1 Run Condition APIs

Component implementations may specify an initial run condition, and, if needed, modify its run condition during execution. Many components do not need any run condition changes during execution and thus the default (all stream ports ready, no time-out) can suffice. When dynamic run conditions for a component are required, there are three operations on the component’s context interface to support this:

enum TimeKind { NoTime, // No time aspect for this run condition SinceLastStart, // At least this much time since last starting run operation SinceLastReturn, // At least this much time since last returning from last run Periodic // Run regularly at this period rate.

}; struct TimeFrequency {

unsigned long integer, fraction; }; struct RunConditionSpec {

TimeKind time_kind; TimeBase::TimeT time_interval; TimeFrequency time_frequency; typedef sequence<NameList> PortSets; PortSets port_sets;

}; native RunCondition; RunCondition create_run_condition(in RunConditionSpec run_condition); RunCondition set_run_condition(in RunCondition the_condition); void remove_run_condition(in RunCondition the_condition);

The create_run_condition operation converts the component-specified run condition specification (RunConditionSpec) into an opaque run-time form used efficiently by the container. The set_run_condition operation informs the container of a new run condition to use for future invocations of the run operation. It returns the previously active run condition. The remove_run_condition destroys what create_run_condition created.

10.2.3.2 Run Condition Specifications

Run conditions are specified by a time interval specification and a list of port set specifications. A run condition is TRUE if the time interval specification is true or any of the port set specifications are true. A time interval specification is TRUE when:

• time_kind is SinceLastStart and at least time_interval has passed since the previous run operation was started.

• time_kind is SinceLastReturn and at least time_interval has passed since the previous run operation returned.

• time_kind is Periodic and time is in different period (of time_frequency) than the previous run operation started.

A port set specification is TRUE when all indicated ports in the set are ready (a buffer is available). Each port set is indicated by the NameList type, containing port names.

The time_interval value is specified as in the Time service, with units of 100ns. The time_frequency is specified as a 64 bit fixed point integer, with 32 bits of fraction (e.g., the fraction is the number of 1/(2^32) units of HZ).


Stream processing code is greatly simplified by this delegation of scheduling to the container, and the container can determine whether a stream processing component is “ready to run based on buffer availability or time” much more efficiently and reliably than the component implementation logic. Synchronization and scheduling are declarative.

10.3 Buffer ManagementThe container (and possibly the underlying transport) manages buffers, while the component simply takes input data (at sink ports) from container-provided input buffers, and places output data (at source ports) into container-provided output buffers. It is possible to modify data in a container-provided input buffer at a sink port, and pass that same buffer as an output buffer to a source port. This leaves the decision as to whether data copies are required up to the container (and/or underlying transport). Transports sometimes have special buffer resources. Thus it is necessary to get all buffers from a per-port context object since different ports may use different transports. If a container has no reason to specialize buffers for specific ports, it can implement a single buffer allocator for all ports.

It is possible for the component to process data that is spread across multiple consecutive input buffers without making copies. It is also possible to request that data in output buffers be preserved after they are enqueued for transmission.

Buffers are always created by the container, and at any time are owned by either the container, a port, or the component. Various operations on the buffer itself, and on port context or port callback objects, implicitly change the ownership of a buffer. Buffers that are not visible to the component are implicitly owned by the container.

Buffers are represented by an abstract base local type defined by this IDL:

abstract interface StreamBuffer { attribute boolean last, has_data; attribute CORBA::OctSeq stream_info, transport_info; void release(); void take();

};

The last attribute indicates that this buffer contains the last data in a stream. The has_data attribute indicates whether the buffer has any valid contents at all. A buffer with has_data of FALSE and last of TRUE is valid, and indicates that no more data is available on the stream. A “pass through” component can simply pass a buffer from a sink port to a source port. The stream_info, and transport_info attributes are dynamic information (per buffer) specific to stream types/profiles and transport types/profiles. This is distinct from the static information contained in the stream port context objects, which is not per buffer. Each stream profile can define both the per-stream metadata as well as the per-buffer metadata. Normally component implementations know nothing about transports, but the transport_info is available for special cases. These octet sequence values may or may not be CORBA encapsulations, depending on the transport or stream profiles.

All the attributes are set by the container when a buffer is given to the container at a sink (input) port. They may all be written, or modified, when a component gives a buffer to a source (output) port. When an empty buffer is made available at an output port (for the component to fill), these attributes are given default values of last == FALSE and has_data == TRUE and the stream_info and transport_info attributes are set to default values based on transport and stream profiles.

The release() operation causes the buffer to be owned by the container and not owned by either a port or the component. The take() operation causes the buffer to be owned by the component, and not by the container or by any port. All other operations that change buffer ownership are operations on port context objects or port callback objects and are described below.


Actual buffers (which inherit from StreamBuffer) use a sequence type generated from the IDL type, or for basic stream types, the octet sequence type. To provide full container control of the storage allocation of buffers, the data attribute of these derived stream buffer types is of type sequence<IDLtype>, but with semantics that disallow any storage management operations that would take storage responsibility from the container (such as the C++ mapping’s release flag being FALSE or the replace function in the C++ sequence mapping). Implementations of this generated sequence type are not required to disallow these operations, but they are undefined when used by component implementation code. Thus for a given IDL type, the derived stream buffer type is:

local interface <IDLType>StreamBuffer : StreamBuffer { typedef sequence<IDLType> DataSeq; readonly attribute DataSeq data;

};

The sequence attributes length, and maximum size, and the buffer pointer accessors such as get_buffer (in C++) act normally, with maximum readonly.

For the stream type defined like this:

struct PositionData { long x; long y; long z;


The generated stream buffer type would be:

local interface PositionDataStreamBuffer : StreamBuffer { typedef sequence<PositionData> DataSeq; readonly attribute DataSeq data;

};

The generated stream buffer type for basic streams is always:

local interface OctetStreamBuffer : StreamBuffer { readonly attribute CORBA::OctetSeq data;

};

When a sink stream type is Raw, and the incoming data is a value stream type, the buffer type will be OctetStreamBuffer, and the contents will be the encapsulation of the IDL sequence type.

10.3.1 Buffer Management with event-driven ports

In this execution model (the normal CCM one), when the container notices the availability of a new buffer for a stream port (sink or source), and the enable_new_buffer attribute on the port’s context object has been set to TRUE, it will invoke the new_buffer operation on the port’s callback interface (SinkCallback). Defined as:

void new_buffer(in StreamBuffer input) raises (Components::CCMException);

When new_buffer is entered, the buffer is owned by the port. When the component implementation returns from this operation, the buffer is implicitly released, and becomes owned by the container. If the port is a sink, the buffer may then be made available for new stream input data. If the port is a source, the buffer is sent as output data upon return.


If the component needs to retain the buffer (and not release or send it), it may issue the take() operation on it, which transfers ownership from the port to the component. In this case nothing happens to the buffer when the new_buffer operation returns. When a buffer is taken by the component in this way, it is not available for further use by the container and this may prevent the container from receiving new input data or providing new output buffers. The component can declare its minimum requirement for retaining ownership of buffers, per port, in its deployment descriptor (See Chapter 11 - “Deployment Extensions” on page 49).

A component executing in the new_buffer operation for a sink port, may pass the input buffer to a source port using the send_buffer operation on the source port’s context interface. This implicitly passes ownership of the buffer to the container, and thus nothing happens to that buffer on return from the new_buffer operation. The send_buffer operation is non-blocking and can be used in any execution model. It is defined by:

void send_buffer(in StreamBuffer output_buffer) raises (NoStream);

The NoStream exception is raised when there is no active stream on the source port. The component is responsible for correctly setting the attributes of the buffer prior to sending it, including the length of the data buffer itself.

10.3.2 Buffer Management with blocking ports

In the blocking execution model, if the component wishes to receive a new input buffer or fill and send an output buffer of stream data, it obtains the buffer by using the get_buffer operation on the port’s context object, defined as:

StreamBuffer get_buffer (in unsigned long minimum_size, in boolean wait) raises (Streams::IllegalBufferSize);

If the wait argument is TRUE, the operation will block until a buffer is available. If it is FALSE, it will return nil if no buffer is available. If the minimum_size can never be satisfied, the IllegalbufferSize exception will be thrown. This operation can wait a fixed amount of time, if the get_buffer_timeout attribute of the ports context object has been set to a non-zero value. This attribute is defined by:

attribute TimeBase::TimeT get_buffer_timeout;

The units of TimeBase::TimeT are in 100ns.

When get_buffer returns a buffer (not nil) the ownership of the buffer passes to the component. The component can then release it back to the container for re-use, using the release operation on the buffer, or send it to an output port using the send_buffer operation. If the buffer was obtained from an output port, it normally would be sent back to that same port. If the buffer came from an input port, it may be sent to an output port if the stream buffer IDL type is compatible.

10.3.3 Buffer Management with the Run Condition Execution Model

In the run condition execution model the container makes buffers available to the component on each port as needed. When the component’s run condition is TRUE, the container invokes the run operation on the component’s callback interface. Inside this operation, each port’s context interface supplies a readonly current_buffer attribute, which if non-nil, signifies a buffer available on that port. For input (sink) ports, it contains input data. For output (source) ports, it can be filled by the component with output data. Thus the typical processing in a run operation is to access the input data in the current_buffers of input ports to create the output data, which is placed in the current_buffer of output ports.


The most common run condition is simply that there is a current buffer available on all stream ports (all ports are ready). Thus such a component needs to do no buffer management, and needs to do no work to coordinate or synchronize the availability of input or output buffers. When the run operation has finished processing the data in the current buffers, it returns. Any port indicated as required to be ready in the run condition, can be assumed to have a current buffer when the run operation is called.

Progress in using buffers (processing all the input data in a buffer, or filling an output buffer) is indicated several ways:

1. A simple return value from the run operation indicates that all current buffers on all the stream ports have been used and are no longer needed. Input buffers can be discarded and recycled for new data, and output buffers can be queued for transmission (and recycled when the data has been sent). This is the ADVANCE_ALL value of the RunResult enumeration. For example, in C++, it would be:

return Components::Streams::ADVANCE_ALL;

2. When all current buffers are not fully processed, the logic in the run operation can indicate that a specific port’s cur-rent buffer is no longer needed by invoking the advance_buffer operation on that port’s context interface:

void advance_buffer();

An example of this usage would be a component searching input data and when it found something, sending it on an output (source) stream. It would always advance the buffers of its inputs, but only advance the buffer of its output port when the search succeeded and the data was placed in the output port’s current buffer.

The return value of the run operation in this case is simply:

return Components::Streams::OK;

which implies no specific additional advancement of buffers on any port.

3. When a component partially processes the input data in a buffer, or partially fills an output buffer, it may simply return OK. It is guaranteed that the same current buffers persist across invocations of the run operation.

4. When a component needs to retain access to multiple input or output buffers on a given port to perform its function it can take ownership of current buffers at its ports to allow further buffers to arrive (input) or be filled (output). In this case it uses the take() operation to take ownership. This allows an additional buffer to become the current buffer at a port, while the component retains access (use of) the previously current buffer. An example of this usage is when a component needs to perform a “sliding window” calculation on its input, which requires two consecutive input buffers be available for the computation. It would otherwise have to make extra copies of input data to retain such a history. When the component logic is finished with a buffer it has taken, it uses release operation on the buffer. In the exam-ple above, if the component needed two buffers at a time, it would typically perform the calculation, take the current buffer (and remember it), and release the previous buffer.

5. If a component needed to provide an input buffer to an output port (“zero copy”), it uses the send_buffer operation on the output port’s context interface. Note that a component written this way would never include the output port in its run condition, since it does not need empty buffers to fill on that port.


In all these above cases, a component can never expect to see more than one current buffer on a port within one invocation of its run operation. While the advance() (on a port context) and take() (on a buffer) operations indicate that a new buffer is desired, it may only be made available on another invocation of the run operation. This execution model may share threads among collocated components, since the run operations are non-blocking.

The context and callback interfaces for each port are summarized in Section 10.5, “IDL summary for local interactions between component and container,” on page 44.

10.4 Stream ManagementStream ports are used to handle a sequence of data streams, possibly of different stream types (when the stream type is a constructed type). During execution, source ports indicate, and sink parts are told, when streams begin or end. Components indicate when they are starting a new stream on a source port by invoking the start operation on a source port’s context interface, and indicate when they are finished by invoking the finish operation (or setting the last attribute in a buffer that is sent). Similarly, containers inform components when streams are starting or finishing on a sink port by invoking the started and finished operations on a sink port’s callback interface.

The start and started operations are similar, and convey both the stream profile, (the type as well as the metadata for that stream type). The start operation may request valid changes in the transport profile. The context operations for source ports are:

void start(in StreamProfile stream_profile, in TransportProfile transport_profile); void finish();

The callback operations for sink ports are:

void started(in StreamProfile stream_profile);i void finished();

For both sink and source ports, a component may indicate to the container that it is no longer interested in a stream by invoking the abort operation on the port’s context interface. In this case the container at the other end of the stream will invoke the aborted operation on the other component’s port’s callback interface. Similarly, if a transport failure causes the transmission of a stream to terminate, the failed operation is invoked by both containers when they recognize this condition. The distinction between aborted and failed is that the former was explicitly caused by the action of a component. The context operation is:

void abort();

The callback operations are:

void aborted(); void failed();

The metadata for a stream is stored at both ends in the stream_profile attribute of the port’s context interface. This attribute is of type StreamProfile. This information is supplied as part of the stream profile argument to the start operation to the context interface of a source port, and it is retained as an attribute in all stream port context interfaces. Its value is valid prior to the invocation of the container’s invocation of the started operation on the sink ports callback interface. By using the attribute, the component is relieved from saving or copying this information. The metadata is defined as an attribute on the port’s callback interface:

readonly attribute StreamProfile stream_profile;


Similarly, there is a transport profile stored as an attribute in the port’s context interface to enable components with transport-specific knowledge to access this information. This situation is unusually, since most components will be written to be agnostic to transports. This attribute is defined similar to the stream information:

readonly attribute TransportProfile transport_profile;

10.4.1 Stream boundaries

Stream boundaries are indicated in two ways, to facilitate the most efficient approach possible for a given stream type or transport type. If the last attribute of a StreamBuffer is set before being sent on a source port (via advance_buffer, or send_buffer) this indicates to the container that the stream is finished. This technique is most efficient when the component can attach this attribute to the last buffer of data. No other operation is required to finish the stream on the source side. Furthermore, if the container can use the transport of the stream itself to signal that the stream is finished, it can avoid a remote CORBA invocation to inform the container on the sink side that the stream is finished. The component may find it more convenient to use the finish operation on the source port’s context object, especially when it determines that a buffer previously sent was in fact the last data in the stream.

It is the container’s responsibility to decide whether the extra inter-container CORBA finished() invocation is required, and ensure that all the stream data is received on the sink side before that side is informed that the stream is finished. The container knows the capabilities of the transport and thus which method is appropriate. Some transports may require a new connection to be established for each stream between connected stream ports, while others may have in-band markers to indicate stream boundaries.

10.5 IDL summary for local interactions between component and containerAll of the following IDL is in the Components::Streams module. The examples are based on a component definition of:

component MyComp { source SourceType1 my_source; sink SinkType1 my_sink;

};

10.5.1 Context interfaces for component-to-container invocations

10.5.1.1 Per-port context interfaces

This is the interface all port context objects, whether sink or source:

abstract interface StreamPortContext { // Transport profile is established once for the component readonly attribute TransportProfile transport_profile;

// Stream profile and operations for each stream readonly attribute StreamProfile stream_profile; void abort();

// Buffer operations for each buffer in a stream attribute boolean enable_new_buffer; // enable new buffer callback attribute TimeBase::TimeT get_buffer_timeout; // timeout for get_buffer readonly attribute StreamBuffer current_buffer; // the current buffer for run condition model


void advance_buffer(); // release current buffer, request another StreamBuffer get_buffer(in unsigned long minimum_size,

in boolean wait) raises (Streams::IllegalBufferSize);

} ;

These are the interfaces for actual sink or source port context objects:

local interface SourceContext : StreamPortContext { void start(in StreamProfile stream_profile, in TransportProfile transport_proflle)

raises (UnsupportedStreamType, DuplicateStream);

void finish() raises (NoStream);

void send_buffer(in StreamBuffer buffer, in boolean release); }; local interface SinkContext : StreamPortContext { };

10.5.1.2 Per-component context interfaces

This is the interface inherited by all the context interfaces for all components with stream ports. It is implemented by the container.

abstract interface StreamContext { RunCondition create_run_condition(in RunConditionSpec run_condition); RunCondition set_run_condition(in RunCondition); void remove_run_condition(in RunCondition);

};

The generated context interface for MyComp would be:

local interface CCM_MyComp_Context : Components::Streams::StreamContext, Components::CCMContext {

Components::Streams::SourceContext get_my_source(); Components::Streams::SinkContext get_my_sink();

};

10.5.2 Per-port callback interfaces

These are the interfaces used by the per-port component-supplied callback objects:

abstract interface StreamPort { void new_buffer(in StreamBuffer the_buffer); // Here is new buffer for port void aborted(); // Other side aborted void failed(); // Transport or other side failed

}; local interface SourcePort : StreamPort { }; local interface SinkPort : StreamPort {


void started(in StreamProfile stream_profile) raises (Components::CCMException);

void finished() raises (Components::CCMException);

};

10.5.3 Per-component callback interfaces

This is the callback interface for each component with stream ports:

abstract interface StreamComponent { RunResult run();

};

The example MyComp component would cause this callback interface to be generated for its executor interface:

local interface CCM_MyComp : Components::Streams::StreamComponent, Components::EnterpriseComponent {

Components::Streams::SourcePort get_my_source(); Components::Streams::SinkPortt get_my_sink(); ...

};

10.6 Consolidated internal IDL

#include <orb.idl> module Components { module Streams {

enum RunResult { OK, ADVANCE_ALL, NO_MORE

}; enum TimeKind {

NoTime, // No time aspect for this run condition SinceLastStart, // At least this much time since last starting run operation SinceLastReturn, // At least this much time since last returning from last run Periodic // Run regularly at this period rate.

}; struct TimeFrequency {

unsigned long integer, fraction; }; struct RunConditionSpec {

TimeKind time_kind; TimeBase::TimeT time_interval; TimeFrequency time_frequency; typedef sequence<NameList> PortSets; PortSets port_sets;

};


native RunCondition; RunCondition create_run_condition(in RunConditionSpec run_condition); RunCondition set_run_condition(in RunCondition the_condition); void remove_run_condition(in RunCondition the_condition); abstract interface StreamBuffer {

attribute boolean last, has_data; attribute CORBA::OctSeq stream_info, transport_info; void release(); void take();

}; abstract interface StreamPortContext {

// Transport profile is established once for the component readonly attribute TransportProfile transport_profile;

// Stream profile and operations for each stream readonly attribute StreamProfile stream_profile; void abort();

// Buffer operations for each buffer in a stream attribute boolean enable_new_buffer; // enable new buffer callback attribute TimeBase::TimeT get_buffer_timeout; // timeout for get_buffer readonly attribute StreamBuffer current_buffer; // current buffer for run condition model void advance_buffer(); // release current buffer, request another StreamBuffer get_buffer(in unsigned long minimum_size,

in boolean wait) raises (Streams::IllegalBufferSize);

} ; local interface SourceContext : StreamPortContext {

void start(in StreamProfile stream_profile, in TransportProfile transport_proflle) raises (UnsupportedStreamType,

DuplicateStream); void finish()

raises (NoStream); void send_buffer(in StreamBuffer buffer, in boolean release);

}; local interface SinkContext : StreamPortContext { }; abstract interface StreamContext {

RunCondition create_run_condition(in RunConditionSpec run_condition); RunCondition set_run_condition(in RunCondition); void remove_run_condition(in RunCondition);

}; abstract interface StreamPort {

void new_buffer(in StreamBuffer the_buffer); // Here is new buffer for port void aborted(); // Other side aborted void failed(); // Transport or other side failed

}; local interface SourcePort : StreamPort { }; local interface SinkPort : StreamPort {

void started(in StreamProfile stream_profile)


raises (Components::CCMException); void finished()

raises (Components::CCMException); }; abstract interface StreamComponent {

RunResult run(); };

}; };


11 Deployment Extensions

The deployment of components with stream ports would be done in the context of the recently finalized Deployment and Configuration specification, in particular the PSM for CCM in that specification.

11.1 Extensions to the Component Deployment metadataThe ComponentPortDescription class, associated with the ComponentInterfaceDescription contains an attribute of CCMComponentPortKind, which indicates port types. This specification adds two new types to that enumeration: Sink and Source. The ComponentPortDescription already contains an attribute for supported interface types, and thus can already express the various stream types a sink or source port may support.

While the current deployment descriptors for connections between components can express deployment requirements that must be satisfied by the interconnects between nodes in the target domain (such as various networks), there is no place to attach deployment requirements for a port of a monolithic implementation. Stream ports may have such requirements, such as transport requirements (QoS), buffering requirements, specific transport profile selections, specific transport configurations. This specification adds a simple new class, ImplementationPort, which has a port name attribute, and these associations:

• deployConnectionRequirement : Requirement[*] Requirements of the port to be satisfied as connection requirements.

• deployNodeRequirement : Requirement[*] Requirements of the port to be satisfied by the node, separate from the component implementation requirements of the node because they are requirements that must be satisfied by the node for the interconnect attachment chosen (e.g. a transport protocol required by the node’s attachment to the chosen interconnect).

• execParam : Property[*] Node (container) -specific parameters to be provided to the node

There is a composition relationship (called “port”) from the MonolithicImplementationDescription class and zero or more ImplementationPort classes. The deployment requirements for each port are processed by the deployment planner in the normal fashion.

11.2 Extensions to the Target Deployment metadataTo enable proper deployment planning of transport characteristics that are specific to each attachment of a node to an interconnect (e.g., NIC properties), there must be a way to express resources that are specific to the attachment of a node to an interconnect (e.g., NICs). This can be done by introducing a class, Attachment, to represent the current association between node and interconnects and between bridges and interconnects. Such a class would have one composition relationship, to one or more Resources. It would essentially be a “port” class for the nodes and bridges in the target model, but avoids the collision with that name (and refactoring the entire model would not be worth the trouble).

This allows the deployment planner to do capacity and transport protocol validation on all attachments to an interconnect. Connection requirements and the per-port connection requirements can be checked against attachment resources, and the per-port node requirements can also be checked against these attachment resources.


12 Metamodel Extensions

12.1 The Component Meta TypeCORBA components expose their functionality using ports. For the stream-based communication a new type of port is introduced, the stream port. There are two different kinds of stream ports: source stream ports produce stream data of a given stream type and sink stream ports consume stream data of a given stream type. A component can have an arbitrary number of stream ports. Each stream port is identified by a name that is unique in the scope of the component. Stream ports are uni-directional.

Two new meta classes are introduced to represent the stream port concepts. A SinkDef represents a sink stream port where a SourceDef represents a source stream port. In addition to that a generalization is introduced. This is the meta class StreamPortDef. This meta class is used to make an association to a stream type and to summarize properties which are valid for both source and sink stream port.

Figure 12.1 - Extensions to the Component Meta Type

A stream port is associated with exactly one stream type. That could be a basic stream type, where the stream port supports exactly one stream data format, a constructed stream type, where the stream port supports a set of possibly related stream data formats or the distinguished stream type Raw.

The new meta class StreamTypeDef is introduced to represent a stream type. The stream type may be of kind basic, constructed, value or raw.

A stream type of kind value is associated with an IDL type, indicating that the stream content is a sequence of this type.

Contained(from BaseIDL)

StreamPortDefStreamPortTypeDef

1

+type

1

SinkDef

ComponentDef(from ComponentIDL)

*+sink *

/ sinks

SourceDef

*+source *

/source


A stream type of kind constructed is associated with a set of basic, constructed or value stream types.

Figure 12.2 - Extensions to the Component Meta Type

StreamTypeDefKind<<enumeration>>

BASIC_STREAMCONSTRUCTED_STREAMVALUE_STREAMRAW_STREAM

IDLType(from BaseIDL)

If k ind == V ALUE_STREAM

StreamTypeDefkind : StreamTypeDefKind

0..1+baseIDL0..1

*

+groupedTypes

*

Multiplicity must be > 0 ifkind == CONSTRUCTED_STREAM, 0 otherwise. None of the groupedTypes may be of kind RAW_STREAM

Contained(from BaseIDL)

identifierrepos itoryIdversion/ absoluteNam e


13 Profiles

13.1 Stream ProfilesStream profiles define information beyond what is in a stream type declaration. This information is generally for two different purposes:

• Metadata associated with the stream data that is generally used and needed by the component implementation logic to configure and parameterize the handling of the stream data.

• Metadata associated with the stream type that express handling and transport requirements that may be used and needed by containers handling the stream.

A stream profile structure is defined in Section 9.5.3, “Sink operations for stream negotiation, demarcation and management,” on page 29, as follows:

typedef CORBA::OctetSeq StreamParameters; struct StreamProfile {

CORBA::RepositoryId repository_id; ConfigValues properties; StreamParameters parameters;

};

The properties member is intended to hold generic properties that may apply to different types, and understood by software does not specifically understand the stream data format. This is where profile information is expressed that is intended to configure and parameterize generic handling of the stream, generally by containers and deployment systems.

The parameters member is intended to express information in a stream-specific form, which would be understood by implementation code that understood the content of the stream data. It is an octet sequence to give the stream profile specifier the freedom to use some native stream-specific format, or use a CORBA encapsulation of a data structure defined in IDL to express the stream-specific metadata.

In addition to specifying values of generic stream properties, and the stream-specific parameters, the stream profile specifier also defined another structure: the metadata associated with each stream buffer. A profile can define this orthogonal metadata that will be produced and consumed by component implementation logic.

Perhaps the most important generic parameter specifies whether the contents of the sequence in an output buffer must be preserved in tact when delivered to a connected component as an input buffer. This property, “PreserveMessages,” whose type is boolean, and whose default value is FALSE, indicates that the transport must convey the exact content delivered to a source port, intact, to a sink port. Since the basic data in all buffers is a sequence of some IDL type, the default behavior allows containers and transports to simply preserve whole instances of the underlying IDL data type, and thus to fragment, and arbitrarily reassemble (in order) any number of the underlying elements.

Similarly, the property, AllMessages, whose type is boolean and whose default value is TRUE, indicates that transports of this stream type must not drop any messages at all. Stream types that can be processed in the face of some dropped messages, can set this property to FALSE.

[It is expected that a more complete vocabulary for transport requirements will emerge from the Transport QoS for CORBA RFP submission].

This specification does not define any stream types beyond the implied definition of the MIME content types described in


Section 7.6.2, “MIME Content Stream Types,” on page 14, using the default values for PreserveMessages and AllMessages. Some MIME types have specific required and optional parameters which are implicitly defined as the StreamParameters structure for that MIME content type and subtype.

13.2 Transport ProfilesTransport profiles define information about transport connections and how containers implement and handle them. This information is generally for two different purposes:

• Metadata associated with the establishment and negotiation of transport connections.

• Metadata associated with the state of a transport and parameters that can be adjusted while a connection is established.

• How markers are implemented (if at all) to provide in-band delimiting of streams.

A transport profile structure is defined in Section 9.5.3, “Sink operations for stream negotiation, demarcation and management,” on page 29, as follows

typedef CORBA::OctetSeq TranportParameters; struct TransportProfile {

IOP::ProfileId tag; boolean complete; ConfigValues properties; TransportParameters parameters;

};

13.2.1 The TCP profile for CCM streams

This specification defines a single transport profile (TCP), which every compliant implementation of this specification must support. The transport parameters are defined to be an encapsulation of the following structure, whose content is defined in the RT CORBA specification and in the IIOP profile:

IOP::Version iiop_version; string host; unsigned short port; unsigned long send_buffer_size; unsigned long recv_buffer_size; boolean keep_alive; boolean dont_route; boolean no_delay;

The profile tag is from IIOP, TAG_INTERNET_IOP.

There is no transport_info (per buffer) information defined for this profile.

This profile does not support the preservation of message boundaries (the PreserveMessages property, but does provide reliable delivery of all messages, hence it supports the AllMessages property.

Markers are the TCP byte number from the beginning of the connection, using 4 octets, wrapping at 2^32, TCP network endian.


13.2.2 The SCTP profile for CCM streams

This profile is not defined here, but it is noted that SCTP can provide the PreserveMessages property and the AllMessages property..

13.2.3 The TCP/MPA profile for CCM streams

The profile is not defined here, but it is noted that this protocol combination can provide the PreserveMessages property and the AllMessages property. MPA is not yet an IETF RFC.

13.2.4 The RTP/UDP profile for CCM streams

The profile is not defined here, but it is noted that this protocol combination (e.g. RTP over UDP) can provide the PreserveMessages property, but not the AllMessages property. The per-buffer transport metadata might include timestamp information, payload and marker information.
