jayam college of engineering and technology (an iso 9001:2000 certified
TRANSCRIPT
JAYAM COLLEGE OF ENGINEERING AND TECHNOLOGY
(An ISO 9001:2000 Certified Institution)
DHARMAPURI – 636 813
COURSE CODE : IT1401 COURSE NAME: COMPONENT
BASED TECHNOLOGY
DEPARTMENT : IT SEMESTER/YEAR : VI1 / IV
ACADEMIC YEAR: 2008 – 2009
UNIT-III
INTRODUCTION
Java and CORBA
Interface definition language
Object request broker
System object model
Portable object adapter
CORBA services
CORBA component model
Containers
Application server
Model driven architecture
1
Java and CORBA - a smooth blend
CORBA, for those who haven't heard of it before, stands for Common Object Request Broker Architecture. This architecture allows clients to invoke methods of objects running on remote servers. The idea is nothing new - many developers will have come across similar systems such as RPC (remote procedure call), or Java's own RMI (remote method invocation).
The difference between these and CORBA is that CORBA is much more interoperable with other platforms - a C++ object running on a Wintel system can communicate with a Java object on a Unix box. Developers don't need to know what language a CORBA service is written in, or even where it is physically located. This makes CORBA systems very versatile - one can change the location of a CORBA object, and then re-register with a name server. Clients that look up the service can then find its new location, and then continue to make requests. Java makes it easy to integrate support for CORBA into applications and applets, thanks to the introduction of Java IDL in JDK1.2
What is CORBA?
CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate.
The OMG
The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers.
CORBA Architecture
CORBA defines an architecture for distributed objects. The basic CORBA paradigm is that of a request for services of a distributed object. Everything else defined by the OMG is in terms of this basic paradigm.
The services that an object provides are given by its interface. Interfaces are defined in OMG's Interface Definition Language (IDL). Distributed objects are identified by object references, which are typed by IDL interfaces.
The figure below graphically depicts a request. A client holds an object reference to a distributed object. The object reference is typed by an interface. In the figure below the object reference is typed by the Rabbit interface. The Object Request Broker, or ORB, delivers the request to the object and returns any results to the client. In the figure, a jump request returns an object reference typed by the AnotherObject interface.
2
Interface Definition Language (IDL)
Developers use the Interface Definition Language (IDL) to describe the interface to a CORBA object. An IDL schema can then be used to generate Java code for the client and server that will use the object. The same IDL schema could be used to generate either a client or server in C++, Ada, or any other language that supports CORBA. You don't write your implementation of a CORBA service in IDL - so you can continue to write in pure Java code if you so wish.
Let's start by taking a look at a sample IDL schema, to give you an idea what I'm talking about. The following schema shows a very simple CORBA service, which allows clients to get and store the name associated with an email address. For the purposes of this example, we won't worry about modifying or deleting an existing user.
// Address book system modulemodule address_book_system{ // Specify interface to our address book interface address_book {
// Unknown user exceptionexception unknown_user {};
// User already exists exceptionexception user_exists {};
// Lookup name from email addressstring name_from_email(in string email)
raises (unknown_user);
// Lookup email from full namestring email_from_name(in string name)
raises (unknown_user);
// Record a new name and emailvoid record_user(in string name, in string email) raises user_exists;
3
};};
From IDL to Java
Converting an IDL schema into Java source code is quite straightforward. Sun provides a free tool, idltojava, that creates the source code for you. This tool is currently distributed separately to JDK 1.2, but is freely available for members of the Java Developer Connection.
idltojava -fno-cpp AddressBook.idl
Based on the name of your IDL schema's module, a package will be generated that contains skeleton source code for your CORBA client and server, as well a second package to cover our two exceptions. The following is a list of the files it creates for us
\address_book_system\ _address_bookStub.java address_book.java address_bookHolder.java address_bookHelper.java address_bookPackage _address_bookImplBase.java
address_bookPackage\ unknown_user.java unknown_userHelper.java unknown_userHolder.java user_exists.java user_existsHelper.java user_existsHolder.java
As you can see, there are a lot of files! Fortunately, we only need three to implement a complete CORBA client and server. The first file is a servant, which serves the requests made by clients. The second is a server, which will accept requests, and the third is a standalone application which will issue requests.
Implementing a CORBA Servant
Under CORBA, a servant is responsible for handling service requests. When we ran the idltojava tool, an abstract class was created that handles most of the hard work for us. All we need to do is create an AddressBookServant class, that implements the _address_bookImplBase. It will contain the code for our three methods described in the IDL schema.
4
package address_book_system;import address_book_system.address_bookPackage.*;
import java.util.Hashtable;import java.util.Enumeration;////// AddressBookServant//// This servant class is responsible for implementing// three methods//// * String name_from_email ( String email );// * String email_from_name ( String name );// * void record_user ( String name, String email ); ////class AddressBookServant extends _address_bookImplBase{ private Hashtable name2email;
public AddressBookServant() {
// Create a new hashtable to store name & emailname2email = new Hashtable();
}
// Get the name of this email user public String name_from_email ( String email ) throws unknown_user {
if (name2email.contains(email)){
// Begin search for that name for (Enumeration e = name2email.keys();
e.hasMoreElements();) {
String name = (String) e.nextElement();String e_mail = (String) name2email.get(name);
// Match on email ?if (email.compareTo(e_mail) == 0){
return name;}
}
5
}
// User not found - throw unknown user exceptionthrow new unknown_user();
}
// Get the email of this person public String email_from_name ( String name ) throws unknown_user {
// If user existsif (name2email.containsKey(name)){
// Return email addressreturn (String) name2email.get(name);
}
// User doesn't existthrow new unknown_user();
}
// Add a new user to the system public void record_user ( String name, String email ) throws user_exists {
// Is the user already listedif (name2email.containsKey( name ) || name2email.contains( email ) ){
// If so, throw exceptionthrow new user_exists();
}
// Add to our hash tablename2email.put (name, email);
}}
The servant class maintains a list of people's email addresses, and stores this information inside a Hashtable. When the CORBA server receives a request, it will call upon the name_from_email, email_from_name, and record_user methods of the servant to fulfill the request.
Writing a CORBA server
6
Writing a CORBA server is pretty straightforward. We need to create an ORB (object-request-broker), and register our servant with it. We'll also notify a nameserver of our ORB, so that CORBA clients can access our address book. Once we've registered, CORBA clients will be able to look for our interface, and send requests through our ORB to the servant object.
package address_book_system;import org.omg.CORBA.*;import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;
////// AddressBookServer//// This server is responsible for creating an object// request broker (ORB), and registering an AddressBookServant// with a naming service////public class AddressBookServer { public static void main(String args[]) {
try{
// Create a new object request brokerORB orb = ORB.init(args, null);
// Create a new address book ...AddressBookServant servant = new AddressBookServant();
// ... and connect it to our orborb.connect(servant);
// Object Request Broker InitialisedSystem.out.println ("Address book ORB initialised");
// Obtain reference for our nameserviceorg.omg.CORBA.Object object = orb.resolve_initial_references("NameService");
// Since we have only an object reference, we must// cast it to a NamingContext. We use a helper// class for this purposeNamingContext namingContext =
7
NamingContextHelper.narrow(object);
// Add a new naming component for our interfaceNameComponent list[] = { new NameComponent("address_book", "") };
// Now notify naming service of our new interfacenamingContext.rebind(list, servant);
// Wait for clientsfor (;;){}
}catch (Exception e){
System.err.println ("ORB Error - " + e);e.printStackTrace(System.out);System.exit(0);
} }}
Writing a CORBA client
Now that we have a finished server, we need to write a client to show that the server works. Our client is very simple. It looks up our AddressBook service through a naming service, and then sends requests in response to commands made by the user. The client also traps exceptions thrown by the AddressBook service, in the event that a user's details doesn't exist or that a duplicate is being inserted into the system.
package address_book_system;import address_book_system.address_bookPackage.*;
import org.omg.CORBA.*;import org.omg.CosNaming.*;import java.io.*;
////// AddressBookClient//// This client demonstrates the AddressBook server and servant.// A menu is presented to the user, allow he or she to add// users, and look up their names & email addresses//
8
//public class AddressBookClient { public static void main(String args[]) throws IOException { try
{ // Create an object request broker ORB orb = ORB.init(args, null);
// Obtain object reference for name service ... org.omg.CORBA.Object object = orb.resolve_initial_references("NameService");
// ... and narrow it to a NameContext NamingContext namingContext = NamingContextHelper.narrow(object);
// Create a name component array NameComponent nc_array[] = { new NameComponent("address_book","") };
// Get an address book object reference ... org.omg.CORBA.Object objectReference = namingContext.resolve(nc_array);
// ... and narrow it to get an address book address_book AddressBook = address_bookHelper.narrow(objectReference);
// DataInputStream for system.in DataInputStream din = new DataInputStream (System.in);
for (;;) { try {
// Print menu System.out.println ("1- Add user"); System.out.println ("2- Look up email"); System.out.println ("3- Look up name"); System.out.println ("4- Exit");
System.out.print ("Command :");
9
// Read a line from user String command = din.readLine();
// Convert to number Integer num = new Integer (command); int choice = num.intValue();
// Variables we'll need for service calls String name; String email;
switch (choice) { case 1:
System.out.print ("Name:");name = din.readLine();System.out.print ("Email:");email = din.readLine();
// Call AddressBook serviceAddressBook.record_user(name,email);break;
case 2:System.out.println ("Name:");name = din.readLine();
// Call AddressBook serviceemail = AddressBook.email_from_name(name);System.out.println ("Email of " + name + " is " + email);break;
case 3:System.out.println ("Email:");email = din.readLine();
// Call AddressBook servicename = AddressBook.name_from_email(email);System.out.println ("Name of " + email + " is " + name);break;
case 4:System.exit(0);
} }
catch (user_exists already_there)
10
{ System.out.println ("User already exists - cannot be added to
address book");}catch (unknown_user bad_user){ System.out.println ("User doesn't exist");}
} }
catch (Exception e){
System.err.println ("CORBA error - " + e);}
}}
Putting it all together
Now that we have a CORBA server and a CORBA client, the next step is to have the client connect to the server. If you've already compiled the source code, then you're ready to begin. Otherwise, download the source code (available as a .ZIP file), and extract it to its own directory.
Next, you need to do the following :
1. Start the nameservice that comes with JDK1.2 2. Start the server 3. Start the client
Start the nameservice that comes with JDK1.2
If your Java installation directory is in the path, you can type the following from your prompt
tnameserv -ORBInitialPort 2000
The port parameter is necessary for Unix users who aren't logged it as root. Windows users can omit the parameter. If you do specify a port parameter, make sure you do so for the client and server as well.
Start the server
11
All of the examples are part of the address_book_system package. Some users have reported problems running the examples. Make sure that the current directory is in the classpath, and then go to the directory where you've compiled the examples, or where you've unzipped them. Next, start the server
java address_book_system.AddressBookServer -ORBInitialPort 2000 -ORBInitialHost myhost
The port parameter is optional (but needed if you've specified a port for your nameservice). You'll also need to specify the hostname if you run the server on a different machine to the nameservice (omit it if running everything locally).
Start the client
You'll need to go to the directory where the examples are stored. Make sure that the nameservice and server are already running, and then start the client
java address_book_system.AddressBookClient -ORBInitialPort 2000 -ORBInitialHost myhost
The port parameter is optional (but needed if you've specified a port for your nameservice). You'll also need to specify the hostname if you run the client on a different machine to the nameservice (omit it if running everything locally).
Running the client
The client is capable of invoking all the methods defined in our IDL. It can record new users, look up an email address, and look up a name. While the demonstration is relatively simple, it does show how easy it is to write clients that interact with services on remote systems. This demo is a standalone application, but you could just as easily write an applet that implemented the same functionality.
1- Add user2- Look up email3- Look up name4- ExitCommand :1Name: David ReillyEmail: [email protected] Add user2- Look up email3- Look up name4- ExitCommand :2Name:
12
David ReillyEmail of David Reilly is [email protected]
Interface Definition Language
The Interface Definition Language (IDL) is a language for specifying operations (procedures or functions), parameters to these operations, and data types. This chapter specifies IDL and the associated Attribute Configuration Source (ACS). It includes:
a description of the notation used in the language specifications a specification of the IDL language a specification of the ACS a series of tables summarising IDL and ACS grammar.
Notation
The syntax of IDL and ACS is described using an extended BNF (Backus-Naur Form) notation. The meaning of the BNF notation is as follows:
Brackets ([ ]) enclose an optional part of the syntax. Ellipsis points (...) indicate that the left clause can be repeated either zero or more
times if it is optional or one or more times if it is required. The vertical bar (|) indicates alternative productions; it is read as "or". Language punctuation that does not conflict with punctuation characters used in
the BNF notation appears in a production in the appropriate position. Language punctuation that does conflict with punctuation characters used in the BNF notation is enclosed in less-than and greater-than symbols; for example, <[>. Note particularly that when ' (single quotation) or " (double quotation) appear in a production, they are a part of the language and must appear in IDL source.
Elements in the grammar that are capitalised are terminals of the grammar. For example, <Identifier> is not further expanded. Also, keywords of the language are terminals of the grammar. For example, the keyword boolean is not further expanded.
IDL Language Specification
The syntax of the IDL language is derived from that of the ISO C programming language. Where a term in this description of the IDL language is not fully defined, the C-language definition of that term is implied. This chapter specifies both language syntax and semantics. As a result, the syntax is presented in pieces. Grammar Synopsis provides a syntax summary, with the productions in the order in which they appear in this chapter.
13
An alphabetical cross-reference to the language syntax is also provided in Alphabetic Listing of Productions .
IDL Lexemes
The following subsections define the lexemes of the IDL language.
Keywords and Reserved Words
The IDL contains keywords, which are listed in IDL and ACS Reserved Words . Some keywords are reserved words, and must not be used as identifiers. Keywords that are not reserved may be used as identifiers, except when used as attributes (that is, within [] (brackets)).
Identifiers
Each object is named with a unique identifier. The maximum length of an identifier is 31 characters.
Some identifiers are used as a base from which the compiler constructs other identifiers. These identifiers have further restrictions on their length. Constructed Identifier Classes lists the classes and maximum lengths of identifiers that are used as bases. The character set for identifiers is the alphabetic characters A to Z and a to z, the digits 0 to 9, and the _ (underbar) character. An identifier must start with an alphabetic character or the _ (underbar) character.
The IDL is a case-sensitive language.
Restrictions on Names
Interface specifications must observe the following restrictions on names:
A field name or parameter name cannot be the same as a type name. Type names, operation names, constant names and enumeration identifiers form a
single name space. An identifier may only have one usage within this name space. A parameter name must be unique within the parameter list of an operation or
function type declaration. An arm name must be unique within a case list. A field name must be unique within a structure field list. Union and structure tag names must be unique within an interface.
IDL Punctuation
The punctuation used in IDL consists of the following characters:
the . (dot)
14
the , (comma) the pair () (parentheses) the pair [] (brackets) the pair {} (braces) the ; (semicolon) the : (colon) the * (asterisk) the ' (single quote) the " (double quote) the = (equal sign).
Alternate Representation of Braces
The { (open brace) and } (close brace) characters are defined as national replacement set characters by ISO and may not be present on all keyboards. Wherever an open brace is specified, the ??< trigraph may be substituted. Wherever a close brace is specified, the ??> trigraph may be substituted. These substitutions are the same as those specified in the ISO C standard.
White Space
White space is a character sequence that can be used to delimit any of the other low-level constructs. The syntax of white space is as follows:
a blank a return a horizontal tab a form feed in column 1 a comment a sequence of one or more white space constructs.
A language keyword, an <Identifier> or a list of <Digit>s must be preceded by a punctuation character or by white space. A language keyword, an <Identifier> or a list of <Digit>s must be followed by a punctuation character or by white space. Any punctuation character may be preceded or followed by white space.
Comments
The /* (slash and asterisk) characters introduce a comment. The contents of a comment are examined only to find the */ (asterisk and slash) that terminate it. Thus, comments do not nest. One or more comments may occur before the first non-comment
15
lexical element of the IDL source, between any two lexical elements of the IDL source, or after the last non-comment lexical element of the IDL source.
Interface Definition Structure
An interface definition written in IDL has the following structure:
<interface> ::= <interface_header> { <interface_body bgcolor="#FFFFFF"> }
Interface Header
The structure of the interface header is as follows:
<interface_header> ::= <[> <interface_attributes> <]> interface <Identifier>
where:
<interface_attributes> ::= <interface_attribute> [ , <interface_attribute> ] ...
<interface_attribute> ::= uuid ( <Uuid_rep> ) | version ( <Integer_literal>[.<Integer_literal>]) | endpoint ( <port_spec> [ , <port_spec> ] ... ) | exceptions ( <excep_name> [ , <excep_name> ] ... )| local| pointer_default ( <ptr_attr> )
<port_spec> ::= <Family_string> : <[> <Port_string> <]> <excep_name> ::= <Identifier>
If an interface defines any operations, exactly one of the uuid attribute or the local attribute must be specified. Whichever is specified must appear exactly once.
It is permissible to have neither the uuid nor the local attribute if the interface defines no operations. The version attribute may occur at most once.
The uuid Attribute
The uuid attribute designates the UUID that is assigned to the interface to identify it uniquely among all interfaces. The uuid attribute is expressed by the uuid keyword followed by a string of characters that gives the literal representation of the UUID.
Universal Unique Identifier .
The version Attribute
16
The version attribute identifies a specific version of a remote interface when multiple versions of the interface exist. Version semantics are specified in Remote Procedure Call Model .
Legal Values for Version Numbers
The major and minor version numbers of an interface must each have a value between 0 and 65,535, inclusive.
Version Number Defaults
The defaulting rules for interface version numbers are as follows:
The interpretation of an interface with only a single (major) version number is that the minor version number is 0.
An interface with no version attribute is given the version number 0.0.
The endpoint Attribute
The endpoint attribute specifies the well-known endpoint(s) on which servers that export the interface will listen. Well-known endpoint values are typically assigned by the central authority that owns the protocol.
A <port_spec> is composed of two strings separated by punctuation as described in the syntax. The <Family_string> identifies the protocol family to be used; the <Port_string> identifies the well-known endpoint designation for that family.
The actual syntax of <Port_string> is family-dependent. Registered values of <Port_string> are given in Endpoint Mapper Well-known Ports .
The exceptions Attribute
The exceptions attribute specifies a set of user-defined exceptions that can be generated by the server implementation of the interface.
The local Attribute
The local attribute provides a means to use the IDL compiler as a header generation language. When the local attribute is specified, the uuid attribute must not be specified.
Stubs are not generated for local interfaces. Checks for data transmissibility are omitted.
The pointer_default Attribute
The pointer_default attribute specifies the default treatment for pointers. If no pointer_default attribute is specified in the interface attributes, and a construct requiring
17
a default pointer class is used, the compiler will issue an error. (See Pointers for more information.)
Interface Body
The structure of the interface body bgcolor="#FFFFFF" is as follows:
<interface_body bgcolor="#FFFFFF"> ::= [ <import> ... ] <interface_component> [ <interface_component> ... ]
where:
<import> ::= import <import_list> ;
<interface_component> ::= <export>| <op_declarator> ;
<export> ::= <type_declarator> ;| <const_declarator> ;| <tagged_declarator> ;
Import Declaration
The syntax of the <import_list> in an import declaration is as follows:
<import_list> ::= <import_name> [ , <import_name> ] ...<import_name> ::= "<Import_string>"
where: <Import_string> gives a system dependent name for an import source.
The IDL [??]import[??] declaration specifies another interface definition whose types and constants are used by the importing interface. It is similar to the [??]include[??] declaration in C. The imported definition must in itself adhere to all specifications in this chapter.
Constant Declaration
The following subsections specify the syntax and semantics of constant declarations.
Syntax
The syntax for a constant declaration is as follows:
<const_declarator> ::= const <const_type_spec> <Identifier> = <const_exp>
18
<const_type_spec> ::= <primitive_integer_type>| char | boolean | void * | char *
<const_exp> ::= <integer_const_exp> | <Identifier> | <string> | <character_constant>| NULL | TRUE | FALSE
<integer_const_exp> ::= <conditional_exp><conditional_exp> ::= <logical_or_exp>
| <logical_or_exp> ? <integer_const_exp> : <conditional_exp><logical_or_exp> ::= <logical_and_exp>
| <logical_or_exp> <||> <logical_and_exp><logical_and_exp> ::= <inclusive_or_exp>
| <logical_and_exp> && <inclusive_or_exp><inclusive_or_exp> ::= <exclusive_or_exp>
| <inclusive_or_exp> <|> <exclusive_or_exp><exclusive_or_exp> ::= <and_exp>
| <exclusive_or_exp> ^ <and_exp><and_exp> ::= <equality_exp>
| <and_exp> & <equality_exp><equality_exp> ::= <relational_exp>
| <equality_exp> == <relational_exp>| <equality_exp> != <relational_exp>
<relational_exp> ::= <shift_exp>| <relational_exp> <<> <shift_exp>| <relational_exp> <>> <shift_exp>| <relational_exp> <<=> <shift_exp>| <relational_exp> <>=> <shift_exp>
<shift_exp> ::= <additive_exp>| <shift_exp> <<<> <additive_exp>| <shift_exp> <>>> <additive_exp>
<additive_exp> ::= <multiplicative_exp>| <additive_exp> + <multiplicative_exp>| <additive_exp> - <multiplicative_exp>
<multiplicative_exp> ::= <unary_exp>| <multiplicative_exp> * <unary_exp>| <multiplicative_exp> / <unary_exp>| <multiplicative_exp> % <unary_exp>
<unary_exp> ::= <primary_exp>| + <primary_exp>
19
| - <primary_exp>| ~ <primary_exp>| ! <primary_exp>
<primary_exp> ::= <Integer_literal>| <Identifier>| '(' <const_exp> ')'
<string> ::= "[<Character>] ... "<character_constant> ::= '<Character>'
Directional Attributes
At least one directional attribute must be specified for each parameter. IDL Directional Attributes gives the meanings of the directional attributes.
Attribute Meaning
in The parameter is passed from the caller to the callee.
out The parameter is passed from the callee to the caller.
Table: IDL Directional Attributes
A parameter with the out attribute must be either an array or an explicitly declared pointer. An explicitly declared pointer is declared by a pointer declarator, rather than by a <declarator> with a named parameter as its type_spec.
Any parameter from which the binding for a call is to be derived must have the in attribute. If an operation has an in handle_t, in customised handle (handle) or in context handle (context_handle), and also contains an in, out context handle, the in, out context handle may be null. If an operation does not have an in handle_t, in customised handle or in context handle, but does contain one or more in, out context handles, at least one of the in, out context handles must be non-null.
Aliasing in Parameter Lists
If two pointer parameters in a parameter list point at the same data item, or at data structures that have some items in common, parameter aliasing is said to occur.
20
Aliasing is supported only for full pointers; both parameters involved in the aliasing must be full pointers. Full pointers are aliases when:
1. They have the same value. 2. They are declared to point to the same type. 3. The size of the pointed-to type, as determined at or before run time, is the same.
The scope of aliasing is a single instance of an RPC call. Aliasing is not preserved across nested RPCs.
Aliasing of reference pointers is not supported and yields unspecified results. Aliasing is not supported for the case where the target of one pointer is a component (for example, a structure field or array element) of another pointer. This yields unspecified results.
Function Pointers
The following sections describe the syntax, semantics and restrictions of function pointers.
Syntax
The syntax for declaration of a function pointer is:
<function_declarator> ::= <direct_declarator> <param_declarators>
Semantics
An instance of a function pointer type allows functions to be referenced indirectly.
Restrictions
Function pointers are permitted only within interfaces declared with the local attribute.
Predefined Types
Predefined types are data types derived from the base types that are intrinsic to the IDL language. The syntax for predefined types is as follows:
<predefined_type_spec> ::= error_status_t | <international_character_type>
<international_character_type> ::= ISO_LATIN_1
21
| ISO_MULTILINGUAL| ISO_UCS
The error_status_t Type
The error_status_t type is used to declare an object in which communications and fault status information can be held. This is the appropriate type for objects with the comm_status or fault_status attributes.
Note: The error_status_t type is transmitted as an IDL unsigned long. However, implementations may choose to unmarshal this type as a local operating system error type instead of unsigned long.
International Character Types
The following types may be used to represent alternative character sets:
ISO_LATIN_1ISO_MULTI_LINGUALISO_UCS
Data of type char is subject to ASCII/EBCDIC conversion when it is transmitted by the RPC mechanism. The predefined international character types are protected from data representation format conversion.
Anonymous Types
An enumeration type is said to be anonymous if it is not a type named through a typedef statement. A structure or union type is said to be anonymous if it does not have a tag and is not named through a typedef statement. The following rules apply to the usage of anonymous types:
A parameter cannot have an anonymous type. A function result cannot have an anonymous type. The target of a pointer cannot have an anonymous type.
The Attribute Configuration Source
22
The Attribute Configuration Source (ACS) is used to specify details of a stub to be generated. ACS is used to create a separate attribute configuration source that accompanies an IDL specification. The ACS specification affects the interface between the application code and the stub; for example, it can specify whether an explicit binding handle parameter is used. The ACS specification also affects the way stub code is generated. The ACS specification does not affect the way the data is transmitted or received during a remote procedure call; this is determined entirely by the IDL specification.
Comments
Comments in ACS conform to the same rules as IDL comments.
Identifiers
Each ACS source is associated with some IDL source. The following associations apply:
The interface name in the ACS source must be the same as the interface name in the interface definition.
Any type names used in the ACS source must have been declared as names of types in the interface definition, except for type names that are <ACS_repr_type>s or a type used in the <ACS_implicit_handle_attr>.
Any operation names used in the ACS source must have been declared as names of operations in the interface definition.
If an identifier occurs as a parameter name within an operation declaration in the ACS source, that identifier must have been used as the name of a parameter within the declaration of the corresponding operation in the interface definition. Not all such parameters need occur in the ACS operation definition.
If a type is declared in a typedef with ACS attributes, those attributes are not inherited by other types declared using the type with ACS attributes.
Note: This is the opposite of the case for IDL type attributes, which are inherited. (See Semantics and Restrictions .)
Syntax
The syntax of an ACS specification is as follows:
<ACS_interface> ::= <ACS_interface_header> { <ACS_interface_body bgcolor="#FFFFFF"> }
23
Include Declaration
The include statement specifies one or more header sources that are are included in generated stub code, for example, via C-preprocessor #include statements. The user must supply the header sources. A C-language definition source (.h file) must always be provided for use when compiling the stubs. If the stubs are being generated for another language, then a definition source for that language must be provided as well. The same ACS source may not work with different target languages.
If the include statements do not fully specify the location of the header sources, the compiler uses implementation-specific searching mechanisms to locate them. Similarly, if the file extension is not specified, then the compiler appends the appropriate file extension for the language of choice.
Include statements are necessary if, in the ACS source, there occur one or more types specified in the represent_as clause's <ACS_named_type> or the implicit_handle or cs_char attribute's <type_spec> that are not types defined in the interface definition (or any imported interfaces). Since the definitions of such types are needed by the generated stub code, the user must supply them in this manner.
Specifying Binding Handles
The means of providing binding information to the RPC run-time system is the binding handle. Binding handles (or simply, handles) may be passed as parameters of the operation or fetched by the generated stub from a static area. A handle passed as an operation parameter is termed an explicit handle. If an explicit handle is used, it is always the first parameter of an operation. Explicit handles may be declared in the IDL source, in which case both the client and server must use the explicit handle. Explicit handles may also be declared in the ACS source, in which case the two sides (client and server) may make the decision to use an explicit handle separately.
When an interface contains one or more operations whose first parameter is not an explicit handle, and which do not have an in or in, out context handle, a means of providing a handle is needed. The implicit_handle and auto_handle attributes provide this capability.
If an interface has an operation requiring an implicit handle, and no ACS source is supplied, or the supplied ACS source does not specify either implicit_handle or auto_handle, then the default auto_handle attribute is applied. The auto_handle attribute is also applied in the event that a operation has an in, out context handle but no other binding handle mechanism.
When the auto_handle attribute is applied, the binding_callout attribute allows the client application using automatic binding to modify the binding handle obtained by the client stub before the remote procedure call is initiated.
24
The explicit_handle Attribute
When used as an interface attribute, the explicit_handle attribute is applied to all operations in the interface. When used as an operation attribute, it is applied to only the specified operation.
The explicit_handle attribute specifies that the operation has an additional first parameter of type handle_t and named IDL_handle, even if one is not explicitly declared in the IDL source. Customised binding handles must be declared in the IDL source. The explicit_handle attribute may occur as an interface attribute only if the implicit_handle attribute and auto_handle attribute do not occur.
The implicit_handle Attribute
The implicit_handle attribute is one of the methods for specifying handles. Under the implicit_handle method, the handle used on calls to operations without a handle in the first parameter position is the data object specified in the implicit_handle attribute.
The implicit_handle attribute must occur at most once in the ACS source. The implicit_handle attribute may occur only if the auto_handle attribute does not occur and the explicit_handle attribute does not occur as an interface attribute.
The <type_spec> specified in the implicit_handle attribute need not be specified in the associated interface definition source. If it is specified, then the definition specified in the IDL source is used; it must be either a type that resolves to the type handle_t or a type with the handle attribute. If it is not a type defined in the interface definition source, then the ACS source must contain an include statement, specifying a definition source that defines the <type_spec>. The type is treated as a customised handle; that is, as if it had the handle attribute applied to it.
The auto_handle Attribute
The auto_handle attribute indicates that any operations needing handles are automatically bound; that is, a client that makes a call on that operation makes no specification as to which server the operation may execute on.
The environment variable RPC_DEFAULT_ENTRY must be set to the name of the namespace entry from which the stub will import bindings to be used when an operation is invoked.
The auto_handle attribute must occur at most once.
The auto_handle attribute may occur only if the implicit_handle attribute does not occur and the explicit_handle attribute does not occur as an interface attribute.
25
The binding_callout Attribute
The binding_callout attribute specifies a routine that the client stub is to call automatically to modify a server binding handle before it initiates a remote procedure call and is intended for use with automatic binding through the auto_handle attribute. Without the binding_callout attribute, the binding handle may not be modified before the client attempts to initiate a call to the selected server. A typical use is to augment automatic binding handles with security context so that authenticated RPC is employed between client and server.
The binding callout routine provided must have a specific routine signature.
The binding_callout attribute must occur at most once.
The binding_callout attribute applies to all operations in the interface.
The represent_as Attribute
The represent_as attribute associates a named local type in the target language (<ACS_repr_type>) with a transfer type (<ACS_named_type>) that is transferred between caller and callee.
There are some restrictions on the types to which the represent_as attribute may be applied. The following types must not have the represent_as attribute:
pipe types types used as the base type in a pipe definition conformant, varying or conformant varying arrays structures whose last member is a conformant array (a conformant structure) pointers or types that contain a pointer.
The code and nocode Attributes
At most, one of the code and nocode attributes may appear in the interface attribute list. If neither is present, the effect is as if code is present. The nocode attribute is only honoured when generating a client stub. Servers must support all defined operations. If code appears in the interface attribute list, stub code is be generated for any operation in the interface that does not appear in the ACS source with nocode in its operation attribute list.
If nocode appears in the interface attribute list, stub code is only generated for those operations in the interface that appear in the ACS source with code in their operation attribute lists. At most, one of code and nocode may appear in an operation attribute list. If both the interface and the operation have a code or nocode attribute, the attribute applied to the operation overrides the attribute applied to the interface.
26
Return Statuses
Two attributes, comm_status and fault_status, are available to provide a status return mechanism for certain error conditions that occur during the execution of remote routines. Portable applications must include an ACS specification that specifies these attributes.
The comm_status Attribute
The comm_status attribute must occur at most once per operation. It may appear as an operation attribute for the operation, or as a parameter attribute for one of the parameters of the operation. If the comm_status attribute appears as an operation attribute, the operation must have been defined to deliver a result of type error_status_t. If the run-time system detects that some communications error (for example, a broken connection or a timeout) has occurred during execution of the operation, the error code is returned as the operation result. If the run-time system does not detect a communications failure, then the operation result has the value returned by the manager routine.
If the comm_status attribute appears as a parameter attribute, the <Identifier> associated with it need not be the <Identifier> of a parameter defined in the IDL. If the comm_status attribute does specify the <Identifier> of a parameter defined in the IDL, then the parameter must be an out parameter of type error_status_t*. In the event that the remote call completes successfully, the parameter has the value assigned by the called procedure.
If the <Identifier> associated with the comm_status attribute is not the <Identifier> of a parameter defined in the IDL, then an extra out parameter of type error_status_t* is created. This follows the last parameter defined in the IDL, unless a parameter with the fault_status attribute is present. If a parameter with the fault_status attribute is present, then the parameters are defined in the order they appear in the ACS. In the case of successful completion of the call, the extra parameter has the value error_status_ok. If a communications error occurs during execution of the operation, the error code is returned in the parameter with the comm_status attribute. For a summary of which errors are reported through the comm_status mechanism when enabled, refer to Reject Status Codes and Parameters .
The fault_status Attribute
The fault_status attribute is similar to the comm_status attribute. However, it deals with certain failures of the remote routine rather than communications errors. The fault_status attribute must occur at most once per operation. It may appear as an operation attribute for the operation, or as a parameter attribute for one of the parameters of the operation. If the fault_status attribute appears as an operation attribute, the operation must have been defined to deliver a result of type error_status_t.
27
If the fault_status attribute appears as a parameter attribute, the <Identifier> associated with it need not be the <Identifier> of a parameter defined in the IDL. If the fault_status attribute does specify the <Identifier> of a parameter defined in the IDL, then the parameter must be an out parameter of type error_status_t*. In the event that the remote call completes successfully, the parameter has the value assigned by the called procedure. If the <Identifier> associated with the fault_status attribute is not the <Identifier> of a parameter defined in the IDL, then an extra out parameter of type error_status_t* is created. This follows the last parameter defined in the IDL unless a parameter with the com_status attribute is present. If a parameter with the com_status attribute is present, then the parameters are defined in the order in which they appear in the ACS. In the case of successful completion of the call, the extra parameter has the value error_status_ok. If a suitable error occurs during execution of the operation, the error code is returned in the parameter with the fault_status attribute.
Interaction of the comm_status and fault_status Attributes
It is possible for one operation to have both the fault_status and the omm_status attributes, either as operation attributes or as parameter attributes. If both attributes are applied as operation attributes, or both attributes are applied to the same parameter, then the operation or parameter has the value error_status_ok if no error occurred. Otherwise, it has the appropriate comm_status or fault_status value. Since the values returned in parameters with the comm_status attribute are disjoint from the values returned in parameters with the fault_status attribute, and it is not possible for a single call to result in two failures, there is no ambiguity in interpreting the returned status value.
If both attributes are specified for an operation, and each attribute refers to an <Identifier> that is not defined in the IDL source, then two extra parameters are defined after the last parameter defined in the IDL source. These parameters are defined in the order in which they appear in the ACS source.
The extern_exceptions Attribute
By default, the IDL compiler declares and initializes in the stub code all exceptions specified by the exceptions interface attribute. The extern_exceptions attribute indicates that the exceptions it specifies are not declared by the stub code but defined and initialized in some other external manner. They may be predefined exceptions that were provided by another interface, or exceptions that are defined and initialized explicitly by the application itself.
If the extern_exceptions attribute appears without parameters, it specifies all IDL-defined exceptions.
The heap Attribute
28
The heap attribute specifies that the server copy of the parameter or parameter of the type so specified will always be allocated in heap memory, rather than on the stack. Any identifier occurring as a parameter name within an operation declaration in the ACS source must also be a parameter name within the corresponding operation declaration in IDL.
The heap attribute is ignored for pipes, context handles, and scalars.
The enable_allocate Attribute
The enable_allocate attribute causes the stub to initialise stub memory management in conditions where it otherwise would not do so. It has no effect if the stub would perform the initialisation for other reasons.
International Character Transfer
Five attributes-cs_char, cs_stag, cs_drtag, cs_rtag and cs_tag_rtn-are available for use in conjunction with the automatic code set conversion routines to provide a mechanism for ensuring character and code set interoperability between clients and servers transferring characters not contained in the Portable Character Set (PCS). (For information on the code set conversion routines see Internationalisation Support Model , Internationalisation Support Operations , and the routines described in RPC API Manual Pages ; for information on the PCS, see Portable Character Set .)
The cs_char Attribute
The cs_char attribute associates a local data type with a data type defined in the IDL source. This permits, during marshalling and umarshalling, the conversion of characters, arrays of characters, and strings of characters between the format in which application code uses them and the format in which they are transmitted over the network. The data is automatically converted between the local data type in the local code set encoding and the byte data type in the network code set encoding. The network code set is the code set encoding that the application code, through the use of the DCE RPC automatic code set conversion routines, has selected to use when transmitting the international characters over the network.
The cs_char attribute does not affect the network contract between client and server. Multiple data items (for example, the characters of an array or string) can be converted with a single stub call to user-written conversion code. The conversion can modify array size and data limit information between what is transmitted over the network and what is used by application code.
.
IDL Grammar Synopsis
29
The following sections give a synopsis of the IDL grammar for quick reference.
Grammar Synopsis
This section provides a synopsis of the IDL productions discussed in Interface Definition Language .
(1) <interface> ::= <interface_header> { <interface_body bgcolor="#FFFFFF"> }(2) <interface_header> ::= <[> <interface_attributes> <]> interface
<Identifier>(3) <interface_attributes> ::= <interface_attribute>
[ , <interface_attribute> ] ...
(4) <interface_attribute> ::= uuid ( <Uuid_rep> )| version ( <Integer_literal>[.<Integer_literal>]) | endpoint ( <port_spec> [ , <port_spec> ] ... ) | exceptions ( <excep_name> [ , <excep_name> ] ... )| local| pointer_default ( <ptr_attr> )
(5) <port_spec> ::= <Family_string> : <[> <Port_string> <]>(5.01) <excep_name> ::= <Identifier>(6) <interface_body bgcolor="#FFFFFF"> ::= [ <import> ... ] <interface_component>
[ <interface_component> ... ](7) <import> ::= import <import_list> ;(8) <interface_component> ::= <export> | <op_declarator> ;(9) <export> ::= <type_declarator> ;
| <const_declarator> ;| <tagged_declarator> ;
(10) <import_list> ::= <import_name> [ , <import_name> ] ...(11) <import_name> ::= "<Import_string>"(12) <const_declarator> ::= const <const_type_spec> <Identifier> = <const_exp>(13) <const_type_spec> ::= <primitive_integer_type>
| char| boolean| void *| char *
(14) <const_exp> ::= <integer_const_exp> | <Identifier> | <string> | <character_constant>| NULL | TRUE | FALSE
(14.01) <integer_const_exp> ::= <conditional_exp>(14.02) <conditional_exp> ::= <logical_or_exp>
| <logical_or_exp> ? <integer_const_exp> : <conditional_exp>(14.03) <logical_or_exp> ::= <logical_and_exp>
30
| <logical_or_exp> <||> <logical_and_exp>(14.04) <logical_and_exp> ::= <inclusive_or_exp>
| <logical_and_exp> && <inclusive_or_exp>(14.05) <inclusive_or_exp> ::= <exclusive_or_exp>
| <inclusive_or_exp> <|> <exclusive_or_exp>(14.06) <exclusive_or_exp> ::= <and_exp>
| <exclusive_or_exp> ^ <and_exp>(14.07) <and_exp> ::= <equality_exp>
| <and_exp> & <equality_exp>(14.08) <equality_exp> ::= <relational_exp>
| <equality_exp> == <relational_exp>| <equality_exp> != <relational_exp>
(14.09) <relational_exp> ::= <shift_exp>| <relational_exp> <<> <shift_exp>| <relational_exp> <>> <shift_exp>| <relational_exp> <<=> <shift_exp>| <relational_exp> <>=> <shift_exp>
(14.10) <shift_exp> ::= <additive_exp>| <shift_exp> <<<> <additive_exp>| <shift_exp> <>>> <additive_exp>
(14.11) <additive_exp> ::= <multiplicative_exp>| <additive_exp> + <multiplicative_exp>| <additive_exp> - <multiplicative_exp>
(14.12) <multiplicative_exp> ::= <unary_exp>| <multiplicative_exp> * <unary_exp>| <multiplicative_exp> / <unary_exp>| <multiplicative_exp> % <unary_exp>
(14.13) <unary_exp> ::= <primary_exp>| + <primary_exp>| - <primary_exp>| ~ <primary_exp>| ! <primary_exp>
(14.14) <primary_exp> ::= <Integer_literal>| <Identifier>| '(' <const_exp> ')'
(15) <string> ::= "[<Character>] ... "(16) <character_constant> ::= '<Character>'(17) <type_declarator> ::= typedef [ <type_attribute_list> ] <type_spec>
<declarators>(18) <type_attribute_list> ::= <[> <type_attribute>
[ , <type_attribute> ] ... <]>(19) <type_spec> ::= <simple_type_spec>
| <constructed_type_spec>(20) <simple_type_spec> ::= <base_type_spec>
| <predefined_type_spec>| <Identifier>
31
(21) <declarators> ::= <declarator> [ , <declarator> ] ...(23) <declarator> ::= <pointer_opt> <direct_declarator>(24) <direct_declarator> ::= <Identifier>
| ( <declarator> ) | <array_declarator> | <function_declarator>
(26) <tagged_declarator> ::= <tagged_struct_declarator> | <tagged_union_declarator>
(27) <base_type_spec> ::= <floating_pt_type> | <integer_type>| <char_type>| <boolean_type>| <byte_type>| <void_type>| <handle_type>
(28) <floating_pt_type> ::= float| double
(29) <integer_type> ::= <primitive_integer_type>| hyper [unsigned] [int]| unsigned hyper [int]
(29.1) <primitive_integer_type> ::= <signed_integer> | <unsigned_integer>
(30) <signed_integer> ::= <integer_size> [ int ](31) <unsigned_integer> ::= <integer_size> unsigned [ int ]
| unsigned <integer_size> [ int ](32) <integer_size> ::= long
| short| small
(33) <char_type> ::= [ unsigned ] char(34) <boolean_type> ::= boolean(35) <byte_type> ::= byte(36) <void_type> ::= void(37) <handle_type> ::= handle_t(38) <constructed_type_spec> ::= <struct_type>
| <union_type> | <enumeration_type> | <tagged_declarator>| <pipe_type>
(39) <tagged_struct_declarator> ::= struct <tag> | <tagged_struct>
(40) <struct_type> ::= struct { <member_list> }(41) <tagged_struct> ::= struct <tag> { <member_list> }(42) <tag> ::= <Identifier>(43) <member_list> ::= <member> [ <member> ] ...(44) <member> ::= <field_declarator> ;(45) <field_declarator> ::= [ <field_attribute_list> ] <type_spec>
32
<declarators>(46) <field_attribute_list> ::= <[> <field_attribute>
[ , <field_attribute> ] ... <]>(47) <tagged_union_declarator> ::= union <tag>
| <tagged_union>(48) <union_type> ::= union <union_switch> { <union_body bgcolor="#FFFFFF"> }
| union { <union_body bgcolor="#FFFFFF"_n_e> }(48.1) <union_switch> ::= switch ( <switch_type_spec> <Identifier> )
[ <union_name> ](49) <switch_type_spec> ::= <primitive_integer_type>
| <char_type>| <boolean_type>| <Identifier>
(50) <tagged_union> ::= union <tag> <union_switch> { <union_body bgcolor="#FFFFFF"> }
| union <tag> { <union_body bgcolor="#FFFFFF"_n_e> }(51) <union_name> ::= <Identifier>(52) <union_body bgcolor="#FFFFFF"> ::= <union_case> [ <union_case> ] ...(52.1) <union_body bgcolor="#FFFFFF"_n_e> ::= <union_case_n_e> [ <union_case_n_e> ] ...(53) <union_case> ::= <union_case_label> [ <union_case_label> ] ...
<union_arm>| <default_case>
(53.1) <union_case_n_e> ::= <union_case_label_n_e> <union_arm>| <default_case_n_e>
(54) <union_case_label> ::= case <const_exp> :(54.1) <union_case_label_n_e> ::= <[> case ( <const_exp>
[ , <const_exp> ] ... ) <]>(55) <default_case> ::= default : <union_arm>(55.1) <default_case_n_e> ::= <[> default <]> <union_arm>(55.2) <union_arm> ::= [ <field_declarator> ] ;(55.3) <union_type_switch_attr> ::= switch_type ( <switch_type_spec> )(55.4) <union_instance_switch_attr> ::= switch_is ( <attr_var> )(57) <enumeration_type> ::= enum { <Identifier> [ , <Identifier> ] ... }(58) <pipe_type> ::= pipe <type_spec>(59) <array_declarator> ::= <direct_declarator> <array_bounds_declarator>(61) <array_bounds_declarator> ::= <[> [ <array_bound> ] <]>
| <[> <array_bounds_pair> <]>(62) <array_bounds_pair> ::= <array_bound> .. <array_bound> (63) <array_bound> ::= *
| <integer_const_exp> | <Identifier>
(64) <type_attribute> ::= transmit_as ( <xmit_type> ) | handle| <usage_attribute>| <union_type_switch_attr>
33
| <ptr_attr>(65) <usage_attribute> ::= string
| context_handle(66) <xmit_type> ::= <simple_type_spec> (67) <field_attribute> ::= first_is ( <attr_var_list> )
| last_is ( <attr_var_list> ) | length_is ( <attr_var_list> ) | min_is ( <attr_var_list> ) | max_is ( <attr_var_list> ) | size_is ( <attr_var_list> ) | <usage_attribute> | <union_instance_switch_attr> | ignore | <ptr_attr>
(68) <attr_var_list> ::= <attr_var> [ , <attr_var> ] ...(69) <attr_var> ::= [ [ * ] <Identifier> ] (70) <pointer_opt> ::= [<pointer>](70.1) <ptr_attr> ::= ref
| unique| ptr
(70.2) <pointer> ::= *... (71) <op_declarator> ::= [ <operation_attributes> ]
<simple_type_spec> <Identifier> <param_declarators>(72) <operation_attributes> ::= <[> <operation_attribute>
[ , <operation_attribute> ] ... <]>(73) <operation_attribute> ::= idempotent
| broadcast | maybe | reflect_deletions| <usage_attribute>| <ptr_attr>
(74) <param_declarators> ::= ( [ <param_declarator> [ , <param_declarator> ] ... ] )| ( void )
(75) <param_declarator> ::= <param_attributes> <type_spec> <declarator>(76) <param_attributes> ::= <[> <param_attribute>
[ , <param_attribute> ] ... <]>(77) <param_attribute> ::= <directional_attribute>
| <field_attribute>(78) <directional_attribute> ::= in
| out (79) <function_declarator> ::= <direct_declarator> <param_declarators>(80) <predefined_type_spec> ::= error_status_t
| <international_character_type>(81) <international_character_type> ::= ISO_LATIN_1
| ISO_MULTI_LINGUAL
34
| ISO_UCS
Alphabetic Listing of Productions
Alphabetic Listing of Productions lists the terminals and non-terminals of the grammar in alphabetic order, with their numbers and the numbers of all productions that use them.
Table: Alphabetic Listing of Productions
Production Name Number Used In
<additive_exp> 14.11 14.10
<and_exp> 14.07 14.06
<array_bound> 63 61 62
<array_bounds_declarator> 61 59
<array_bounds_pair> 62 61
<array_declarator> 59 24
<attr_var> 69 55.4 68
<attr_var_list> 68 67
<base_type_spec> 27 20
<boolean_type> 34 27 49
<byte_type> 35 27
<char_type> 33 27 49
<Character> Terminal 15 16
<character_constant> 16 14
<conditional_exp> 14.02 14.01
<const_declarator> 12 9
<const_exp> 14 12 14.14 54 54.1
<const_type_spec> 13 12
<constructed_type_spec> 38 19
<declarator> 23 21 24 75
<declarators> 21 17 45
<default_case> 55 53
35
<default_case_n_e> 55.1 53.1
<direct_declarator> 24 23 59 79
<directional_attribute> 78 77
<enumeration_type> 57 38
<equality_exp> 14.08 14.07
<excep_name> 5.01 4
<exclusive_or_exp> 14.06 14.05
<export> 9 8
<Family_string> Terminal 5
<field_attribute> 67 46 77
<field_attribute_list> 46 45
<field_declarator> 45 44 55.2
<floating_pt_type> 28 27
<function_declarator> 79 24
<handle_type> 37 27
<Import_string> Terminal 11
<Identifier> Terminal 2 5.01 12 14 14.14 20 24 42 48.1 49 51 57 63 69 71
<import> 7 6
<import_list> 10 7
<import_name> 11 10
<inclusive_or_exp> 14.05 14.04
<integer_const_exp> 14.01 14 14.02 63
<Integer_literal> Terminal 4 14.14
<integer_size> 32 30 31
<integer_type> 29 27
<interface> 1 GOAL
<interface_attribute> 4 3
<interface_attributes> 3 2
<interface_body 6 1
36
bgcolor="#FFFFFF">
<interface_component> 8 6
<interface_header> 2 1
<international_character_type> 81 80
<logical_and_exp> 14.04 14.03
<logical_or_exp> 14.03 14.02
<member> 44 43
<member_list> 43 40 41
<multiplicative_exp> 14.12 14.11
<op_declarator> 71 8
<operation_attribute> 73 72
<operation_attributes> 72 71
<param_attribute> 77 76
<param_attributes> 76 75
<param_declarator> 75 74
<param_declarators> 74 71 79
<pipe_type> 58 38
<pointer> 70.2 70
<pointer_opt> 70 23
<port_spec> 5 4
<Port_string> Terminal 5
<predefined_type_spec> 80 20
<primary_exp> 14.14 14.13
<primitive_integer_type> 29.1 13 29 49
<ptr_attr> 70.1 4 64 67 73
<relational_exp> 14.09 14.08
<shift_exp> 14.10 14.09
<signed_integer> 30 29.1
<simple_type_spec> 20 19 66 71
<string> 15 14
37
<struct_type> 40 38
<switch_type_spec> 49 48.1 55.3
<tag> 42 39 41 47 50
<tagged_declarator> 26 9 38
<tagged_struct> 41 39
<tagged_struct_declarator> 39 26
<tagged_union> 50 47
<tagged_union_declarator> 47 26
<type_attribute> 64 18
<type_attribute_list> 18 17
<type_declarator> 17 9
<type_spec> 19 17 45 58 75
<unary_exp> 14.13 14.12
<union_arm> 55.2 53 53.1 55 55.1
<union_body bgcolor="#FFFFFF"> 52 48 50
<union_body bgcolor="#FFFFFF"_n_e>
52.1 48 50
<union_case> 53 52
<union_case_n_e> 53.1 52.1
<union_case_label> 54 53
<union_case_label_n_e> 54.1 53.1
<union_instance_switch_attr> 55.4 67
<union_name> 51 48.1
<union_switch> 48.1 48 50
<union_type> 48 38
<union_type_switch_attr> 55.3 64
<unsigned_integer> 31 29.1
<usage_attribute> 65 64 67 73
<Uuid_rep> Terminal 4
<void_type> 36 27
38
<xmit_type> 66 64
IDL Constructed Identifiers
Constructed Identifier Classes lists the various classes of identifiers that are used to construct other identifiers. It shows the various strings that are applied to the identifier to build new identifiers. The table also gives the maximum length that a user-supplied identifier is permitted to have in order for the resulting identifier have 31 characters or less. Identifiers of 31 characters or less fall within the ISO C "minimum maximum" requirement for identifiers. This value need not be meaningful for other target languages. The length specified for interface names assumes a single digit major and minor version number. The actual length allowed for interface names is:
(19 -((digits-in-major-version) + (digits-in-minor-version)))
Table: Constructed Identifier Classes
Max
Class of ID Constructed IDs Length
Interface name <interface>_v<major_version>_<minor_version>_c_ifspec 17
<interface>_v<major_version>_<minor_version>_s_ifspec
<interface>_v<major_version>_<minor_version>_epv_t
<interface>_v<major_version>_<minor_version>_c_epv
<interface>_v<major_version>_<minor_version>_s_epv
Type with <type_id>_to_xmit 21
transmit_as <type_id>_from_xmit
attribute <type_id>_free_inst
<type_id>_free_xmit
Type with <type_id>_bind 24
handle <type_id>_unbind
attribute
Type with <type_id>_rundown 23
context_handle
attribute
39
Type with <type_id>_to_local 20
represent_as <type_id>_from_local
attribute <type_id>_free_inst
<type_id>_free_local
IDL and ACS Reserved Words
Reserved words are keywords of the language that must not be used as user identifiers. IDL reserved words are given in the following list:
boolean byte case char
const default double enum
FALSE float handle_t hyper
import int interface long
NULL pipe short small
struct switch TRUE typedef
union unsigned void
The following list gives the IDL keywords that are reserved when in the context of an attribute: that is, between [] (brackets):
broadcast case context_handle endpoint
exceptions first_is handle idempotent
ignore in last_is length_is
local max_is maybe min_is
out ptr pointer_default ref
reflect_deletions size_is string switch_is
switch_type transmit_as unique uuid
version
The following are ACS reserved words: include, interface, typedef.
The following list gives the ACS keywords that are reserved when in the context of an attribute: that is, between [] (brackets):
auto_handle binding_callout code comm_status
cs_char cs_drtag cs_rtag cs_stag
40
cs_tag_rtn enable_allocate extern_exceptions explicit_handle
fault_status heap implicit_handle nocode
represent_as
Object Request Broker
CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network).
CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The
Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user processes for interfacing with the CORBA infrastructure.Some IDL language mappings are "more hostile" than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather "trivial" and makes usage of CORBA very simple in a Java application. The C++ mapping is not "trivial" but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even stranger (since it's not an Object Oriented language) but it does make sense and handles the RPC semantics just fine. (Red Hat Linux delivers with the GNOME UI system, which used to have its IPC built on CORBA, now replaced by DBus)
A "language mapping" requires that the developer ("user" in this case) create some IDL code representing the interfaces to his objects. Typically a CORBA implementation comes with a tool called an IDL compiler. This compiler will convert the user's IDL code into some language-specific generated code. The generated code is then compiled using a traditional compiler to create the linkable-object files required by the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable
41
Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
Objects By Reference
Objects are used in an application by reference. This reference is either acquired through a stringified URI string, NameService lookup (similar to DNS), or passed-in as a method parameter during a call.Object references are lightweight objects matching the interface of the real object (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any) , and exception data are marshaled internally by the ORB according the local language/OS mapping.
Data By Value
The CORBA Interface Definition Language provides the language/OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc) are passed by value. The combination of Objects by reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
Objects by Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV. The code inside the methods of these objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space separated list of URLs from where this code should be downloaded. The OBV can also have the remote methods.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
CORBA Component Model (CCM)
42
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language independent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing 4 component types instead of the 2 that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.
The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction management. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.
External links
Official OMG CORBA Components page Unofficial CORBA Component Model page System Configuration EJCCM: Computational Physics Inc's free Java CCM implementation
Portable interceptors
Portable interceptors are the "hooks", used by CORBA and RMI-IIOP to mediate the most important functions of the CORBA system. The CORBA standard defines the following types of interceptors:
1. IOR interceptors mediate the creation of the new references to the remote objects, presented by the current server.
2. Client interceptors usually mediate the remote method calls on the client (caller) side. If the object Servant (CORBA) exists on the same server where the method is invoked, they also mediate the local calls.
3. Server interceptors mediate the handling of the remote method calls on the server (handler) side.
The interceptors can attach the specific information to the messages being sent and IORs being created. This information can be later read by the corresponding interceptor on the remote side. Interceptors can also throw forwarding exceptions, redirecting request to another target.
General InterORB Protocol (GIOP)
Main article: General Inter-ORB Protocol
43
The GIOP is an abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG.). The GIOP architecture provides several concrete protocols:
1. Internet InterORB Protocol (IIOP) — The Internet Inter-Orb Protocol is an implementation of the GIOP for use over an internet, and provides a mapping between GIOP messages and the TCP/IP layer.
2. SSL InterORB Protocol (SSLIOP) — SSLIOP is IIOP over SSL, providing encryption and authentication.
3. HyperText InterORB Protocol (HTIOP) — HTIOP is IIOP over HTTP, providing transparent proxy bypassing.
4. and many more...
Data Distribution Service (DDS)
The Object Management Group (OMG) has a related standard known as the Data Distribution Service (DDS) standard. DDS is a publish-subscribe data distribution model, in contrast to the CORBA remotely-invoked object model.
The Common Object Request Broker: Architecture and Specification (CORBA 2.3)
Corba Location (CorbaLoc)
Corba Location (CorbaLoc) refers to a stringified object reference for a CORBA object that looks similar to a URL.All CORBA products must support two OMG-defined URLs: "corbaloc:" and "corbaname:". The purpose of these is to provide a human readable/editable way to specify a location where an IOR can be obtained.
An example of corbaloc is shown below:
corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root
A CORBA product may optionally support the "http:", "ftp:" and "file:" formats. The semantics of these is that they provide details of how to download a stringified IOR (or, recursively, download another URL that will eventually provide a stringified IOR). Some ORBs do deliver additional formats which are proprietary for that ORB.
External links
CORBA/IIOP Specification
44
Benefits
CORBA brings to the table many benefits that no other single technology brings in one package. These benefits include language- and OS-independence, freedom from technology-linked implementations, strong data-typing, high level of tunability, and freedom from the details of distributed data transfers.
Language Independence
CORBA at the outset was designed to free engineers from the hang-ups and limitations of considering their designs based on a particular software language. Currently there are many languages supported by various CORBA providers, the most popular are Java and C++. There are also C-only, SmallTalk, Perl, Ada, Ruby, and Python implementations, just to mention a few.
OS Independence
CORBA's design is meant to be OS-independent. CORBA is available in Java (OS-independent), as well as natively for Linux/Unix, Windows, Sun, Mac and others.
Freedom from Technologies
One of the main implicit benefits is that CORBA provides a neutral playing field for engineers to be able to normalize the interfaces between various new and legacy systems. When integrating C/C++, Java, Fortran, Python, and any other language/OS into a single cohesive system design model, CORBA provides the means to level the field and allow disparate teams to develop systems and unit tests that can later be joined together into a whole system. This does not rule out the need for basic system engineering decisions, such as threading, timing, object lifetime, etc. These issues are part of any system regardless of technology. CORBA allows system elements to be normalized into a single cohesive system model.
For example, the design of a Multitier architecture is made simple using Java Servlets in the web server and various e time, C++ legacy code can talk to C/Fortran legacy code and Java database code, and can provide data to a web interface.
Strong Data Typing
CORBA provides flexible data typing, for example an "ANY" datatype. CORBA also enforces tightly coupled datatyping, reducing human errors. In a situation where Name-Value pairs are passed around, it's conceivable that a server provides a number where a string was expected. CORBA Interface Definition Language provides the
45
mechanism to ensure that user-code conforms to method-names, return-, parameter-types, and exceptions.
High Tune-ability
There are many implementations available (e.g. OmniORB (Open source C++ and Python implementation)) that have many options for tuning the threading and connection management features. Not all implementations provide the same features. This is up to the implementor.
Freedom From Data Transfer Details
When handling low-level connection and threading, CORBA provides a high-level of detail in error conditions. This is defined in the CORBA-defined standard exception set and the implementation-specific extended exception set. Through the exceptions, the application can determine if a call failed for reasons such as "Small problem, so try again", "The server is dead" or "The reference doesn't make sense." The general rule is: Not receiving an exception means that the method call completed successfully. This is a very powerful design feature.
Problems and criticism
While CORBA promised to deliver much in the way code was written and software constructed, it was much criticized during its history.[1] Some of its failures were due to the implementations and the process by which CORBA was created as a standard, others reflect problems in the politics and business of implementing a software standard. These problems led to a significant decline in CORBA use and adoption in new projects and areas. The technology is slowly being replaced by Java-centric technologies.[verification
needed][2]
Location transparency
CORBA's notion of location transparency has been criticized; that is, that objects residing in the same address space and accessible with a simple function call are treated the same as objects residing elsewhere (different processes on the same machine, or different machines). This notion is flawed if one requires all local accesses to be as complicated as the most complex remote scenario. However, CORBA does not place a restriction on the complexity of the calls. Many implementations provide for recursive thread/connection semantics. I.e. Obj A calls Obj B, which in turn calls Obj A back, before returning.
Design and process deficiencies
The creation of the CORBA standard is also often cited for its process of design by committee. There was no process to arbitrate between conflicting proposals or to decide on the hierarchy of problems to tackle. Thus the standard was created by taking a
46
union of the features in all proposals with no regard to their coherence.[3] This made the specification very complex, prohibitively expensive to implement entirely and often ambiguous.A design committee composed largely of vendors of the standard implementation, created a disincentive to make a comprehensive standard. This was because standards and interoperability increased competition and eased customers' movement between alternative implementations. This led to much political fighting within the committee, and frequent releases of revisions of the CORBA standard that were impossible to use without proprietary extensions.[1]
Problems with implementations
Through its history, CORBA was plagued by shortcomings of its implementations. Often there were few implementations matching all of the critical elements of the specification,[3] and existing implementations were incomplete or inadequate. As there were no requirements to provide a reference implementation, members were free to propose features which were never tested for usefulness or implementability. Implementations were further hindered by the general tendency of the standard to be verbose, and the common practice of compromising by adopting the sum of all submitted proposals, which often created APIs that were incoherent and difficult to use, even if the individual proposals were perfectly reasonable.[citation needed]Working implementations of CORBA have been very difficult to acquire in the past, but are now much easier to find. The SUN Java SDK comes with CORBA already. Some poorly designed implementations have been found to be complex, slow, incompatible and incomplete. Commercial versions can be very expensive. This changed significantly as commercial-, hobbyist-, and government-funded high quality free implementations became available.
Firewalls
CORBA (more precisely, IIOP) uses raw TCP/IP connections in order to transmit data. However, if the client is behind a very restrictive firewall/transparent proxy server environment that only allows HTTP connections to the outside through port 80, communication may be impossible, unless the proxy server in question allows the HTTP CONNECT method or SOCKS connections as well. At one time, it was difficult even to force implementations to use a single standard port — they tended to pick multiple random ports instead. As of today, current ORBs do have these deficiencies. Due to such difficulties, some users have made increasing use of web services instead of CORBA. These communicate using XML/SOAP via port 80, which is normally left open or filtered through a HTTP proxy inside the organization, for web browsing via HTTP. Recent CORBA implementations, though, support SSL and can be easily configured to work on a single port. Most of the popular open source ORBS, such as TAO and JacORB also support bidirectional GIOP, which gives CORBA the advantage of being able to use callback communication rather than the polling approach characteristic of web service implementations. Also, more CORBA-friendly firewalls are now commercially available.
47
System Object Model (SOM)
1. Basic Concepts
SOM (System Object Model) is a library packaging technology that enableslanguages to share class libraries regardless of the language they werewritten in. This ability to share class libraries between various objectoriented languages solves many interoperability and re-use problems betweenobject oriented and non object oriented languages as well.
Key characteristics of SOM in support of these key commercial requirementsinclude:
- the ability to create portable shrink wrapped binaries
- the ability to create class libraries in one language that can beaccessed and used by other languages
- the ability to subclass from binaries even if they were written ina different language
- the ability to add new methods and relocate existing methods withoutre-compilation of the application
- the ability to insert new classes into the inheritance hierarchy withoutrecompiling the application.
SOM provides an object model distinct from those contained in objectoriented programming languages yet does not interfere with the use of thosemodels in the same application that is using SOM. In addition, SOM canbe used with procedural programming languages thus providing an objectmodel for those languages that do not have one. SOM consists of an Interface Definition Language (with an accompanyingcompiler), a run-time environment with procedure calls, and a set of enablingframeworks. SOM is an IBM technology that is being licensed to other companies inanticipation of extending its benefits to heterogeneous environments. Inaddition, a number of language vendors are working on providing nativeSOM capability for their compilers.
2. Objects
SOM objects are derived from a root object which defines the essentialbehavior common to all SOM objects. Factory methods are used to createSOM objects at run time. These factory methods are invoked on a class object,in the SOM run-time.
2.1 Operations
48
The interface to a SOM object is defined by permitting the specificationof operation signatures which consist of an operation name and the argumentand result types. Operations are performed on methods which implement anobjects behavior.
2.2 requests
Client requests are invoked on objects by specifying the name of anobject and the name of the operation along with parameters to invoke onit. An object can support multiple operations.
2.3 messages
Messages are not explicitly identified in SOM.
2.4 specification of behavioral semantics
SOM defines object behavior by permitting the specification of operationsignatures which consist of an operation name, and the argument and resulttypes. The semantics of the operations on an object are defined by themethods that implement these operations.
2.5 methods
Methods are invoked on SOM objects. Methods can be relocated upwardin the class hierarchy without requiring the client to be re-compiled.SOM supports three different method dispatching mechanisms; offset, nameresolution, and dispatch function resolution.
The "offset resolution" mechanism implies a static schemefor typing objects and is roughly equivalent to the C++ virtual functionconcept. It offers the best performance characteristics for SOM methodresolution at a cost of some loss in flexibility.This form of method resolution supports polymorphism that is based onthe derivation of the object's class. Name resolution supports access to objects whose class is not knownat compile time, and permits polymorphism based on the protocols that anobject supports, rather than its derivation.
The "dispatch function" resolution is a feature of SOM thatpermits method resolution to be based on arbitrary rules known only inthe domain of the receiving object. Dispatch function resolution is a completely dynamic mechanism thatpermits run time type checking, and open-ended forms of polymorphism. A distinguishing feature of SOM is that all 3 forms of method resolutionare complementary and can be intermixed within client programs.
2.6 state
49
The state of SOM objects is accessed through published interfaces toan object. Invoking operations on objects may cause state changes.
2.7 object lifetime
SOM objects are created by invoking a create operation on a factoryobject in the SOM run time. Once created, the object will exist until explicitlydeleted or until the process that created it no longer exists. A SOM objectwould need to make use of a persistence mechanism in order to exist beyondthe life of the process that created it. A persistence mechanism is beyondthe scope of this object model discussion, however, SOM could be and hasbeen used as the basis for building a variety of persistence frameworks.
2.8 behavior/state grouping
SOM uses the classical object model in that a target object must bespecified for each operation.
2.9 communication model
Since SOM is a basic mechanism, its run-time model is one where an operationoccurs on a single thread within a single process. However, SOM code permitsconcurrent execution by multiple threads on systems where SOM supportsthe underlying threads model, therefore, multi-threaded programs can usemutual exclusion mechanisms to serialize updates to SOM objects with confidencethat critical sections in SOM are thread safe. Complex object interactions that need to span process boundaries canbe constructed on SOM using standard inter-process communication acilitiesprovided by the underlying system.
2.10 events
2.11 transition rules
3. Binding
SOM provides support for both early and late binding. These bindingchoices are on a per method bases. See entry under 2.5 methods fora discussion of different method invocation models.
4. Polymorphism
The polymorphism provided by SOM depends on the method dispatching schemeselected. If "offset resolution" is used then a static schemefor typing objects is used and polymorphism is based strictly on classinheritance. If the "name resolution" method dispatching is usedthen methods are located dynamically and polymorphism is based on the actualprotocols that objects honor.
50
5. Encapsulation
Access to the state of SOM objects is through the operations that makeup the objects interface. Invoking operations on SOM objects can have sideeffects. SOM objects do have private data that is not accessible by invokingexternal operations. In addition, it is possible to define class attributeson SOM objects. These attributes are accessed via set and get functionsimplemented for each attribute and are invoked in the same way as methods.
6. Identity, Equality, Copy
When a SOM object is created the SOM run-time returns a pointer to theobject. It is left to higher level abstractions which build on SOM to defineobject identity, equality and copy operations.
7. Types and Classes
The SOM description for "types and classes" is essentiallythe same as that described in the OODBTG Reference Model entry in thissection in that a "type" defines a protocol shared by a groupof objects, called "instances" of the type and a class definesan implementation shard by a group of objects. In SOM, all objects are derived from a SOM root object which definesthe essential behavior common to all SOM objects. In addition, SOM hasa root class for all SOM metaclasses which defines the essential behaviorcommon to all SOM classes. The SOM metaclasses define factory methods thatmanufacture objects of any class for which they are the metaclass.
8. Inheritance and Delegation
A class defines both an interface and an implementation for objects.The interface defines the signature of the methods supported by objectsof the class, and the implementation defines what instance variables implementthe object's state and what procedures implement its methods.
New classes are derived by sub-classing from previously existing classesthrough inheritance and specialization. Subclasses inherit their interfacesand implementations from their parent classes unless they are overridden.SOM supports multiple inheritance. That is, a class may be derived frommultiple parent classes.
9. Noteworthy Objects
SOM has three important objects which exist as part of the run timeenvironment. The first is a root object from which all SOM objects arederived. This root object defines the essential behavior common to allSOM objects.
51
The second object is the root class object which defines the essentialbehavior common to all SOM classes. All SOM classes are expected to havethis class object or some class derived from it as their metaclass. Thisobject carries the methods which serve as factory objects.
The third object is a class manager. It serves as a run time registryfor all SOM class objects that have been created or dynamically loadedby the current process.
9.1 relationships
Not addressed.
9.2. attributes
SOM classes support attributes. An attribute can be thought of as aninstance variable that has accompanying "get" and "set"methods. The get and set methods are invoked the same way as other methods.
9.3 literals
SOM literal types are characters and integers.
9.4 containment
SOM is a basic technology and therefore does not have a notion of oneobject containing another. However, since SOM is a library packaging technologyit supports the construction of SOM objects which can contain other SOMobjects.
9.5 aggregates
Aggregation is used in SOM to represent collections of basic data types.The aggregation types as expressed in C are struct, union and enum.
9.6 other
10. Extensibility
In SOM, all new classes are defined in terms of a previously existingSOM class. New methods can be added and old methods can be overridden.Methods can also be relocated upward in the hierarchy without requiringre-compilation of the application. Source code is not required for sub-classingsince the binaries can be used for this purpose. This sub-classing frombinaries even extends to languages other than the one the binaries werewritten in.
10.1 dynamic
52
SOM is dynamic in that the class binaries can be replaced without havingto re-compiled the application.
10.2 metaclasses/metaobject protocol
In SOM all classes are real objects. SOM supports a class object whichrepresents the metaclass for the creation of all SOM classes. The SOM metaclassdefines the behavior common to all class objects. S ince it inherits fromthe root SOM object it exists at run time and contains the methods formanufacturing object instances. It also has the methods used to dynamicallyobtain information about a class and its methods at run time.
10.3 introspection
See entry under 10.2 Metaclasses/Metaobject Protocol.
11. Object Languages
SOM is designed to work with a variety of programming languages. SOMsupports an interface definition language to define interfaces and data.The IDL is then compiled (pre-compiler) and linked with the application.This does not preclude the use of a languages' object model in the sameapplication.
The use of SOM with a procedural language provides that language withobject oriented capabilities.
12. Semantics of Base Classes (+type constructors)
See entry under 10.2 Metaclasses/Metaobject Protocol.
13. Background and References
[CS92] N. Coskun and R. Sessions, "Class Objects in SOM",IBM Personal Systems Developer (Summer 1992): 67-77.
[SC92] R. Sessions and N. Coskun, "Object-Oriented Programmingin OS/2 2.0", IBM Personal Systems Developer (Winter 1992):107-120.
[OH92] R. Orfali and D. Harkey, Client/Server Programming with OS/22.0, 2nd. ed., Van Nostrand Reinhold, New York, 1992.
SOMobjects Developer Toolkit Publications Version 2.0 - IBM Order No.96F8649
Notes: "SOMobjects" is a registered trademark of IBM.
Page Portable Object Adapter (POA)
53
What is the Portable Object Adapter (POA)?
An object adapter is the mechanism that connects a request using an object reference with the proper code to service that request. The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification. The POA is designed to meet the following goals:
Allow programmers to construct object implementations that are portable between different ORB products.
Provide support for objects with persistent identities. Provide support for transparent activation of objects. Allow a single servant to support multiple object identities simultaneously.
This document presents an introduction to using the POA with the Java 2 Platform, Standard Edition. For a more complete description of the POA, see Chapter 11 of the CORBA 2.3.1 Specification.
Creating and Using the POA
The steps for creating and using a POA will vary according to the specific application being developed. The following steps generally occur during the POA life cycle:
1. Get the root POA 2. Define the POA's policies 3. Create the POA 4. Activate the POAManager 5. Activate the servants , which may include activating the Tie 6. Create the object reference from the POA
Each step is described in more detail in the sections that follow.
Step 1: Get the root POA
The first step is to get the first POA, which is called the rootPOA. The root POA is managed by the ORB and provided to the application using the ORB initialization interface under the initial object name "RootPOA".
An example of code that will get the root POA object and cast it to a POA is:
ORB orb = ORB.init( args, null ); POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));Step 2: Define the POA's Policies
The Portable Object Adapter (POA) is designed to provide an object adapter that can be used with multiple ORB implementations with no rewriting needed to deal with different vendors' implementations.
54
The POA is also intended to allow persistent objects -- at least, from the client's perspective. That is, as far as the client is concerned, these objects are always alive, and maintain data values stored in them, even though physically, the server may have been restarted many times.
The POA allows the object implementer a lot more control over the object's identity, state, storage, and life cycle. You can create a POA without defining any policies and the default values will be used. The root POA has the following policies by default:
Thread Policy: ORB_CTRL_MODEL Lifespan Policy: TRANSIENT Object Id Uniqueness Policy: UNIQUE_ID Id Assignment Policy: SYSTEM_ID Servant Retention Policy: RETAIN Request Processing Policy: USE_ACTIVE_OBJECT_MAP_ONLY Implicit Activation Policy: IMPLICIT_ACTIVATION
The following code snippet shows how policies are set in the RMI-IIOP (with POA) example:
Policy[] tpolicy = new Policy[3]; tpolicy[0] = rootPOA.create_lifespan_policy( LifespanPolicyValue.TRANSIENT ); tpolicy[1] = rootPOA.create_request_processing_policy( RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY ); tpolicy[2] = rootPOA.create_servant_retention_policy( ServantRetentionPolicyValue.RETAIN);
Each policy is discussed briefly in the following topics. For more information on POA policies, refer to Chapter 11, Portable Object Adapter of the CORBA/IIOP 2.3.1 Specification at http://cgi.omg.org/cgi-bin/doc?formal/9 9-10-07
Thread Policy
This policy specifies the threading model used with the created POA. The default is ORB_CTRL_MODEL.
The ThreadPolicyValue can have the following values:
ORB_CTRL_MODEL - The ORB is responsible for assigning requests for an ORB-controlled POA to threads.
SINGLE_THREAD_MODEL - Requests for a single-threaded POA are processed sequentially. (NOTE: This policy is not supported in the ORB shipped with Sun's J2SE v.1.4.1).
Lifespan Policy
55
This policy specifies the lifespan of the objects implemented in the created POA. The default is TRANSIENT.
The LifespanPolicyValue can have the following values:
TRANSIENT - The objects implemented in the POA cannot outlive the POA instance in which they are first created.
PERSISTENT - The objects implemented in the POA can outlive the process in which they are first created.
Object Id Uniqueness Policy
This policy specifies whether the servants activated in the created POA must have unique object identities. The default is UNIQUE_ID.
The IdUniquenessPolicyValue can have the following values:
UNIQUE_ID - Servants activated with that POA support exactly one Object Id. MULTIPLE_ID - A servant activated with that POA may support one or more
Object Ids.
Id Assignment Policy
This policy specifies whether Object Ids in the created POA are generated by the application or by the ORB. The default is SYSTEM_ID.
The IdAssignmentPolicyValue can have the following values:
USER_ID - Objects created with that POA are assigned Object Ids only by the application.
SYSTEM_ID - Objects created with that POA are assigned a unique object id by the POA. If the POA also has the PERSISTENT policy, assigned Object Ids must be unique across all instantiations of the same POA.
Servant Retention Policy
This policy specifies whether the created POA retains active servants in an Active Object Map. The default is RETAIN.
The ServantRetentionPolicyValue can have the following values.
RETAIN - to indicate that the POA will retain active servants in its Active Object Map.
NON_RETAIN - to indicate Servants are not retained by the POA.
Request Processing Policy
56
This policy specifies how requests are processed by the created POA. The default is USE_ACTIVE_OBJECT_MAP_ONLY.
The RequestProcessingPolicyValue can have the following values:
USE_ACTIVE_OBJECT_MAP_ONLY - If the object ID is not found in the Active Object Map, an OBJECT_NOT_EXIST exception is returned to the client. The RETAIN policy is also required.
USE_DEFAULT_SERVANT - If the object ID is not found in the Active Object Map or the NON_RETAIN policy is present, and a default servant has been registered with the POA using the set_servant operation, the request is dispatched to the default servant.
USE_SERVANT_MANAGER - If the object ID is not found in the Active Object Map or the NON_RETAIN policy is present, and a servant manager has been registered with the POA using the set_servant_manager operation, the servant manager is given the opportunity to locate or activate a servant or raise an exception.
Implicit Activation Policy
This policy specifies whether implicit activation of servants is supported in the created POA. The default value is IMPLICIT_ACTIVATION.
The ImplicitActivationPolicyValue can have the following values:
IMPLICIT_ACTIVATION - Indicates implicit activation of servants. This requires SYSTEM_ID and RETAIN policies to be set.
NO_IMPLICIT_ACTIVATION - Indicates no implicit servant activation.
Step 3: Create the POA
Creating a new POA allows the application developer to declare specific policy choices for the new POA and to provide a different adapter activator and servant manager (these are callback objects used by the POA to activate POAs on demand and activate servants). Creating new POAs also allows the application developer to partition the name space of objects, as Object Ids are interpreted relative to a POA. Finally, by creating new POAs, the developer can independently control request processing for multiple sets of objects.
A POA is created as a child of an existing POA using the create_POA operation on the parent POA. To create a new POA, pass in the following information:
Name of the POA. The POA is given a name that must be unique with respect to all other POAs with the same parent. In the following example, the POA is named childPOA.
57
POA Manager. Specify the POA Manager to be associated with the new POA. If, as is shown in the following example, null is passed for this parameter, a new POA Manager will be created. The user can also choose to pass the POA Manager of another POA.
Policy List. Specify the policy list to be associated with the POA to control its behavior. In the following example, a persistent lifespan policy has already been defined for this POA.
The following code snippet shows how the POA is created in the Hello World: Persistent Server example.
// Create a POA by passing the Persistent PolicyPOA persistentPOA = rootPOA.create_POA("childPOA", null, persistentPolicy );
Step 4: Activate the POAManager
Each POA object has an associated POAManager object that controls the processing state of the POAs with which it is associated, such as whether requests to the POA are queued or discarded. The POAManager can also deactivate the POA. A POA Manager may be associated with one or more POA objects.
The POAManager can have the following states:
Holding - In this state, associated POAs will queue incoming requests. Active - In this state, associated POAs will start processing requests. Discarding - In this state, associated POAs will discard incoming requests. Inactive - In this state, associated POAs will reject the requests that have not
begun executing as well as as any new requests.
The POAManagerOperations javadocs contain more information on these states.
POA Managers are not automatically activated when they are created. The following code snippet shows how the POAManager is activated in the Hello World: Persistent Server example. If the POA Manager is not activated in this way, all calls to the Servant will hang because, by default, the POA Manager is in the HOLD state.
// Activate PersistentPOA's POAManager. Without this step, // all calls to Persistent Server will hang because POAManager // will be in the 'HOLD' state. persistentPOA.the_POAManager().activate( );
Step 5: Activate the servants
The following information is quoted from section 11.2.5 of the CORBA Specification.
58
At any point in time, a CORBA object may or may not be associated with an active servant.
If the POA has the RETAIN policy, the servant and its associated Object Id are entered into the Active Object Map of the appropriate POA. This type of activation can be accomplished in one of the following ways.
The server application itself explicitly activates individual objects (via the activate_object or activate_object_with_id operations).
The server application instructs the POA to activate objects on demand byhaving the POA invoke a user-supplied servant manager. The server application registers this servant manager with set_servant_manager.
Under some circumstances (when the IMPLICIT_ACTIVATION policy is also in effect and the language binding allows such an operation), the POA may implicitly activate an object when the server application attempts to obtain a reference for a servant that is not already active (that is, not associated with an Object Id).
If the USE_DEFAULT_SERVANT policy is also in effect, the server application instructs the POA to activate unknown objects by having the POA invoke a single servant no matter what the Object Id is. The server application registers this servant with set_servant. If the POA has the NON_RETAIN policy, for every request, the POA may use either a default servant or a servant manager to locate an active servant. From the POA's point of view, the servant is active only for the duration of that one request. The POA does not enter the servant-object association into the Active Object Map.
When using RMI-IIOP technology, your implementations use delegation (known as the Tie model) to associate your implementation with the interface. When you create an instance of your implementation, you also need to create a Tie object to associate it with a CORBA interface. The following code snippet shows how to activate the Tie, if the POA policy is USE_ACTIVE_OBJECT_MAP_ONLY. This sample code is from the RMI-IIOP with POA example.
_HelloImpl_Tie tie = (_HelloImpl_Tie)Util.getTie( helloImpl );String helloId = "hello";byte[] id = helloId.getBytes();tPOA.activate_object_with_id( id, tie );
The CORBA Specification discusses creating object references (section 11.2.4), activating objects (section 11.2.5), and processing requests (section 11.2.6) in more detail than is done in this document. Please refer to the CORBA 2.3.1 Specification for more information.
Step 6: Create the object reference
59
Object references are created in servers. Once created, they may be exported to clients. Object references encapsulate object identity information and information required by the ORB to identify and locate the server and the POA with which the object is associated. References are created in the following ways:
Explicitly activate a servant and associate it with an object reference.
The following example is from Hello World: Persistent Server. This example uses the servant_to_reference operation to map an activated servant to its corresponding object reference.
// Resolve Root Naming context and bind a name for the// servant.org.omg.CORBA.Object obj = orb.resolve_initial_references( "NameService" );NamingContextExt rootContext = NamingContextExtHelper.narrow( obj );
NameComponent[] nc = rootContext.to_name( "PersistentServerTutorial" );rootContext.rebind( nc, persistentPOA.servant_to_reference( servant ) );
Server application directly creates a reference.
The following example is from the RMI-IIOP with POA example. In this example, the following code directly creates a reference. In doing so, they bring the abstract object into existence, but do not associate it with an active servant.
// Publish the object reference using the same object id// used to activate the Tie object.Context initialNamingContext = new InitialContext();initialNamingContext.rebind("HelloService", tPOA.create_reference_with_id(id, tie._all_interfaces(tPOA,id)[0]) );
Server application causes a servant to implicitly activate itself.
The behavior can occur only if the POA has been created with the IMPLICIT_ACTIVATION policy, which is the default behavior.
Once an reference is created in the server, it can be made available to clients. For more information on creating object references and exporting to clients, please refer to section 11.2.4 of the CORBA 2.3.1 Specification for more information.
Adapter Activators
For an example application that uses Adapter Activators, see Using Adapter Activators.
60
An adapter activator is optional. You would use an adapter activator if POAs need to be created during request processing. If all needed POAs are created when the application is executed, an adapter activator is not required.
An adapter activator supplies a POA with the ability to create child POAs on demand, as a side-effect of receiving a request that names the child POA (or one of its children), or when the find_POA method is called with an activate parameter value of TRUE. The ORB will invoke an operation on an adapter activator when a request is received for a child POA that does not currently exist. The adapter activator can then create the required POA on demand.
A request must be capable of conveying the Object Id of the target object as well as the identification of the POA that created the target object reference. When a client issues a request, the ORB first locates an appropriate server (perhaps starting one if needed) and then it locates the appropriate POA within that server.
If the POA does not exist in the server process, the application has the opportunity to re-create the required POA by using an adapter activator. An adapter activator is a user-implemented object that can be associated with a POA. It is invoked by the ORB when a request is received for a non-existent child POA. The adapter activator has the opportunity to create the required POA. If it does not, the client receives the ADAPTER_NONEXISTENT exception.
Once the ORB has located the appropriate POA, it delivers the request to that POA. The further processing of that request depends both upon the policies associated with that POA as well as the object's current state of activation. For more information on Adapter Activators, please refer to section 11.3.3 of the CORBA 2.3.1 Specification or the AdapterActivatorO perations API documentation. If you are reading this documentation as part of the J2SE documentation bundle, check the Web site at http://java.sun.com/j2se/1.4.1/docs/guide/idl/POA.html#adapteractivator for updates to this topic.
Servant Managers
Servant Managers are optional. You would use a servant manager to allow the POA to activate servants on demand when a request for an inactive object is received. If your server loads all objects when it starts up, you do not need a servant manager.
A servant manager is a callback object that the application developer can associate with a POA. The ORB will invoke operations on servant managers to activate servants on demand, and to deactivate servants. Servant managers are responsible for managing the association of an object reference (as characterized by its Object Id value) with a particular servant, and for determining whether an object reference exists or not. Each servant manager type contains two operations, the first called to find and return a servant and the second to deactivate a servant. The operations differ according to the amount of information usable for their situation.
61
To use servant managers, the USE_SERVANT_MANAGER policy must be set. Once set, the type of servant manager used in a particular situation depends on other policies in the POA. The two types of servant managers are:
ServantActivator
When the POA has the RETAIN policy, it uses servant managers that are ServantActivators.
This type is typically used to activate persistent objects.
o For an example that uses Servant Activators, see Using Servant Activators.
ServantLocator
When the POA has the NON_RETAIN policy, it uses servant managers that are ServantLocators. Because the POA knows that the servant returned by this servant manager will be used only for a single request, it can supply extra information to the servant manager's operations and the servant manager's pair of operations may be able to cooperate to do something different than a ServantActivator. When the POA uses the ServantLocator interface, immediately after performing the operation invocation on the servant returned by preinvoke, the POA will invoke postinvoke on the servant manager, passing the ObjectId value and the Servant value as parameters (among others). This feature may be used to force every request for objects associated with a POA to be mediated by the servant manager.
This type is typically used to activate transient objects.
o For an example that uses Servant Locators see Using Servant Locators.
For more information on Servant Managers, please refer to section 11.3.4 of the CORBA 2.3.1 Specification.
If you are reading this documentation as part of the J2SE documentation bundle, check the Web site at http://java.sun.com/j2se/1.4.1/docs/guide/idl/POA.html#servantmanager for updates to this topic.
POA Q&A
Is POAManager.activate() required for a newly created POA?
POAManager.activate() is required for a newly created POA if a null is passed for the POAManager parameter to POA::createPOA . If null is passed, a new POAManager is created and associated with the created POA. In this case, POAManager.activate() is needed.
62
To control several POAs with the same POAManager, you would:
1. Create a POA or use the rootPOA 2. Obtain the POA's manager via POA::the_POAManager 3. Pass the POAManager to subsequent createPOA calls
There is no implicit relationship between the Root POA's POAManager and other POAs unless explicitly programmed by the programmer as shown above.
CORBA services
OMG is pleased to announce a new format for its formal CORBA services specifications. Previously, the CORBA services were combined into one "binder" and you had the option to view/print the complete set of services or each service as its own discrete chapter.
The new format treats each CORBA service as its own stand-alone document. You have the option to view/print each CORBA service separately. This new format provides a faster and easier method of downloading OMG formal documents. Click on the CORBA service of choice below.
Specification Name: Additional Structuring Mechanisms for the OTS
Description:
Provides a low-level architecture for Workflow Engines, Component Management Middleware, and other systems used to create advanced transaction implementations. Attempts to solved the problem of supporting applications that can be very complex in structure, may take a long time to complete, may contain long periods of inactivity, and have complex relationships with other applications.
Keywords:abort, ACID, automicity, commit, commited, completion, durability, isolation, lock, policy, propagation, rollback, security, synchronization, thread, transaction, workflow
Latest / past specifications:Current version: 1.1 Past version:1.0
Additional documents: IDL
Contact Information:Middleware and
Related Services PTF
Related OMG Specifications: CORBA/IIOP, Transaction Service
63
Related Industry Standards:
Specification Name: Collection Service
Description:Provides a uniform way to create and manipulate the most common collections generically.
Keywords:bag, collection, heap, iterator, key, ordered, sequence, sequential, set, sorted
Latest / past specifications:Current version: 1.0.1 Past version: 1.0
Contact Information:Middleware and
Related Services PTF
Related OMG Specifications: CORBA/IIOPRelated Industry Standards:
Specification Name: Concurrency Service
Description:Mediates concurrent access to an object such that the consistency of the object is not compromised when accessed by concurrently executing computations.
Keywords: concurrent, lock, nested, transaction, unlock
Latest / past specifications:Current version: 1.0 Past versions: n/a
Contact Information:Middleware and
Related Services PTF
Related OMG Specifications: CORBA/IIOP, Transaction ServiceRelated Industry Standards:
CORBA Component Model (CCM)
CORBA Component Model (CCM)
The specification for the CORBA Component Model (CCM) is written to address these and other complexities in the CORBA object model. The CCM is part of the CORBA 3.0 specification, which is due to be released this year. The CCM is a server-side component model for building and deploying CORBA applications.
It is very similar to Enterprise Java Beans (EJB) because it uses accepted design patterns and facilitates their usage, enabling a large amounts of code to be generated. This also allows system services to be implemented by the container provider rather than the application developer. The benefit and need for these types of containers can be observed through the growth of Application Server software.
64
The CCM extends the CORBA object model by defining features and services in a standard environment that enable application developers to implement, manage, configure and deploy components that integrate with commonly used CORBA Services. These server-side services include transactions, security, persistence, and events.
Figure 1. Component model
Component Implementation Definition Language (CIDL)
To support all the above features, the CCM extends the CORBA Interface Definition Language (CIDL) to the point that it "introduces a new declaration language." CIDL, like IDL, relieves developers from having to provide much of the "plumbing" needed to include components within a container. To be exact, CIDL is a superset of the Persistent State Definition Language (PSDL), which itself is a superset of IDL. You should be aware that OMG IDL is morphing. Since CIDL is a language to emphasize the description of components, it has many new keywords. All of these keywords have been added to support the features introduced above. Listing 1 provides an example:
Listing 1. An example
interface VideoPlayer { VideoStream play(); int fastForward(in Speed spd); int rewind(in Speed spd);};
component VCR supports VideoPlayer{ provides AudioStream audioPort; provides VideoStream videoPort;
65
};
component DVD supports VideoPlayer{ provides AudioStream audioPort; provides VideoStream videoPort;
};
Distributed computing, the future and CORBA 3.0
It should be obvious that distributed computing is where software technology is headed. It suits our businesses and our homes. Component manufacturing is utilized in cars, stereos and kitchens. The promised land for distributed computing and software engineering will be an architecture model that will eventually provide many of the services we all need in an easy-to-learn and easy-to-use package. The CCM will provide greater opportunity for off-the-shelf components and commodity development tools, as well as an eventual reduction in time to market. All these should combine to create better long-term value for our software.
Container
Description
A Container is an object that stores other objects (its elements), and that has methods for accessing its elements. In particular, every type that is a model of Container has an associated iterator type that can be used to iterate through the Container's elements.
There is no guarantee that the elements of a Container are stored in any definite order; the order might, in fact, be different upon each iteration through the Container. Nor is there a guarantee that more than one iterator into a Container may be active at any one time. (Specific types of Containers, such as Forward Container, do provide such guarantees.) A Container "owns" its elements: the lifetime of an element stored in a container cannot exceed that of the Container itself.
Refinement of
Assignable
66
Associated types
Value type X::value_type The type of the object stored in a container. The value type must be Assignable, but need not be DefaultConstructible. [2]
Iterator type X::iterator The type of iterator used to iterate through a container's elements. The iterator's value type is expected to be the container's value type. A conversion from the iterator type to the const iterator type must exist. The iterator type must be an input iterator. [3]
Const iterator type
X::const_iterator A type of iterator that may be used to examine, but not to modify, a container's elements. [3] [4]
Reference type
X::reference A type that behaves as a reference to the container's value type. [5]
Const reference type
X::const_reference A type that behaves as a const reference to the container's value type. [5]
Pointer type X::pointer A type that behaves as a pointer to the container's value type. [6]
Distance type
X::difference_type A signed integral type used to represent the distance between two of the container's iterators. This type must be the same as the iterator's distance type. [2]
Size type X::size_type An unsigned integral type that can represent any nonnegative value of the container's distance type. [2]
Notation
X A type that is a model of Container a, b Object of type X T The value type of X
Definitions
The size of a container is the number of elements it contains. The size is a nonnegative number.
The area of a container is the total number of bytes that it occupies. More specifically, it is the sum of the elements' areas plus whatever overhead is associated with the container itself. If a container's value type T is a simple type (as opposed to a container type), then the container's area is bounded above by a constant times the container's size times sizeof(T). That is, if a is a container with a simple value type, then a's area is O(a.size()).
67
A variable sized container is one that provides methods for inserting and/or removing elements; its size may vary during a container's lifetime. A fixed size container is one where the size is constant throughout the container's lifetime. In some fixed-size container types, the size is determined at compile time.
Valid expressions
In addition to the expressions defined in Assignable, EqualityComparable, and LessThanComparable, the following expressions must be valid.
Name Expression Type
requirements Return type
Beginning of range
a.begin() iterator if a is mutable, const_iterator otherwise [4] [7]
End of range a.end() iterator if a is mutable, const_iterator otherwise [4]
Size a.size() size_type
Maximum size a.max_size() size_type
Empty container a.empty() Convertible to bool
Swap a.swap(b) void
Expression semantics
Semantics of an expression is defined only where it differs from, or is not defined in, Assignable, Equality Comparable, or LessThan Comparable
Name Expression Precondition Semantics Postcondition
Copy constructor
X(a) X().size() == a.size(). X() contains a copy of each of a's elements.
Copy constructor
X b(a); b.size() == a.size(). b contains a copy of each of a's elements.
Assignment operator
b = a b.size() == a.size(). b contains a copy of each of a's elements.
Destructor a.~X() Each of a's elements is destroyed, and memory allocated for them (if any) is deallocated.
Beginning of a.begin() Returns an iterator a.begin() is either
68
range pointing to the first element in the container. [7]
dereferenceable or past-the-end. It is past-the-end if and only if a.size() == 0.
End of range a.end() Returns an iterator pointing one past the last element in the container.
a.end() is past-the-end.
Size a.size() Returns the size of the container, that is, its number of elements. [8]
a.size() >= 0 && a.size() <= max_size()
Maximum size
a.max_size() Returns the largest size that this container can ever have. [8]
a.max_size() >= 0 && a.max_size() >= a.size()
Empty container
a.empty() Equivalent to a.size() == 0. (But possibly faster.)
Swap a.swap(b) Equivalent to swap(a,b) [9]
Complexity guarantees
The copy constructor, the assignment operator, and the destructor are linear in the container's size.
begin() and end() are amortized constant time.
size() is linear in the container's size. [10] max_size() and empty() are amortized constant time. If you are testing whether a container is empty, you should always write c.empty() instead of c.size() == 0. The two expressions are equivalent, but the former may be much faster.
swap() is amortized constant time. [9]
Invariants
Valid range For any container a, [a.begin(), a.end()) is a valid range. [11]
Range size a.size() is equal to the distance from a.begin() to a.end().
Completeness An algorithm that iterates through the range [a.begin(), a.end()) will pass
69
through every element of a. [11]
Models
vector
Notes
[1] The fact that the lifetime of elements cannot exceed that of of their container may seem like a severe restriction. In fact, though, it is not. Note that pointers and iterators are objects; like any other objects, they may be stored in a container. The container, in that case, "owns" the pointers themselves, but not the objects that they point to.
[2] This expression must be a typedef, that is, a synonym for a type that already has some other name.
[3] This may either be a typedef for some other type, or else a unique type that is defined as a nested class within the class X.
[4] A container's iterator type and const iterator type may be the same: there is no guarantee that every container must have an associated mutable iterator type. For example, set and hash_set define iterator and const_iterator to be the same type.
[5] It is required that the reference type has the same semantics as an ordinary C++ reference, but it need not actually be an ordinary C++ reference. Some implementations, for example, might provide additional reference types to support non-standard memory models. Note, however, that "smart references" (user-defined reference types that provide additional functionality) are not a viable option. It is impossible for a user-defined type to have the same semantics as C++ references, because the C++ language does not support redefining the member access operator (operator.).
[6] As in the case of references [5], the pointer type must have the same semantics as C++ pointers but need not actually be a C++ pointer. "Smart pointers," however, unlike "smart references", are possible. This is because it is possible for user-defined types to define the dereference operator and the pointer member access operator, operator* and operator->.
[7] The iterator type need only be an input iterator, which provides a very weak set of guarantees; in particular, all algorithms on input iterators must be "single pass". It follows that only a single iterator into a container may be active at any one time. This restriction is removed in Forward Container.
[8] In the case of a fixed-size container, size() == max_size().
[9] For any Assignable type, swap can be defined in terms of assignment. This requires three assignments, each of which, for a container type, is linear in the container's size. In
70
a sense, then, a.swap(b) is redundant. It exists solely for the sake of efficiency: for many containers, such as vector and list, it is possible to implement swap such that its run-time complexity is constant rather than linear. If this is possible for some container type X, then the template specialization swap(X&, X&) can simply be written in terms of X::swap(X&). The implication of this is that X::swap(X&) should only be defined if there exists such a constant-time implementation. Not every container class X need have such a member function, but if the member function exists at all then it is guaranteed to be amortized constant time.
[10] For many containers, such as vector and deque, size is O(1). This satisfies the requirement that it be O(N).
[11] Although [a.begin(), a.end()) must be a valid range, and must include every element in the container, the order in which the elements appear in that range is unspecified. If you iterate through a container twice, it is not guaranteed that the order will be the same both times. This restriction is removed in Forward Container.
Application server
Contents
[hide] 1 Java application servers 2 Microsoft platform 3 Other platforms 4 Advantages of application servers 5 See also
6 External links
Java application servers
Following the success of the Java platform, the term application server sometimes refers to a J2EE or Java EE 5 application server. Among the better known Java Enterprise Edition application servers are WebLogic Server (BEA), JBoss (Red Hat), WebSphere Application Server and WebSphere Application Server Community Edition (IBM), JRun (Adobe), Apache Geronimo (Apache Software Foundation), Oracle OC4J (Oracle Corporation), Sun Java System Application Server (Sun Microsystems), SAP Web Application Server and Glassfish Application Server (based on Sun Java System Application Server).
JOnAS application server was the first open source application server to have achieved official compliance with the Java Enterprise Specification. BEA delivered the first Java EE 5 certified application server followed by Sun Microsystems' reference implementation GlassFish.
71
The Web modules are servlets and JavaServer Pages, and business logic is built into Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss Application server. Tomcat from Apache and JOnAS from ObjectWeb are typical of containers into which these modules can be put.
A Java Server Page (JSP) is a servlet from Java that executes in a Web container—the Java equivalent of CGI scripts. JSPs are a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.
The application servers mentioned above mainly serve Web applications. Some application servers target networks other than the Web: Session Initiation Protocol servers, for instance, target telephony networks.
Microsoft platform
Microsoft's contribution to application servers is the .NET Framework. This technology includes the Windows Communication Foundation, .NET Remoting, Microsoft Message Queuing, ASP.NET, ADO.NET, and Internet Information Services.
Other platforms
Open source application servers are available from other vendors. Examples include Appaserver, Base4 and Zope.Non-Java offerings have no formal interoperability specifications, like the Java Specification Record. As a result, interoperability between non-Java products is poor compared to that of Java EE based products. To address these shortcomings, specifications for enterprise application integration and service-oriented architecture were designed to connect the many different products. These specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture.
Advantages of application servers
Data and code integrity By centralizing business logic on an individual or small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner.
Centralized configuration Changes to the application configuration, such as a move of database server, or system settings, can be done centrally.
Security A central point through which access to data and portions of the application itself can be managed is considered a security benefit, devolving responsibility for
72
authentication away from the potentially insecure client layer without exposing the database layer.
Performance By limiting the network traffic to performance tier traffic, it is perceived that the client-server model improves the performance of large applications in heavy usage environments.
Total Cost of Ownership (TCO) In combination, the benefits above are considered to represent a cost saving to a company when developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm combined with the need for software distribution to distribute client code somewhat negate these benefits.
Transaction Support A transaction is a unit of activity, in which many updates to resources (that can be on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End users can benefit by a system wide standard behaviour and less time to develop (and cost) as the server does a lot of the hard programming. Developers can focus on business logic.
Model-driven architecture
Contents
[hide] 1 MDA approach 2 Related standards 3 The Executable UML approach 4 MDA tools 5 Design methodologies for MDA 6 MDA concerns
o 6.1 Code generation controversy 7 Trademark 8 Conferences 9 See also 10 References 11 Further reading 12 External links
MDA approach
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated specifications[citation needed]. OMG's ADTF (Analysis
73
and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems [2]. Knowledge Discovery Metamodel (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).
One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.Of particular importance to model-driven architecture is the notion of model transformation. A specific standard language for model transformation has been defined by OMG called QVT.
Related standards
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
The Executable UML approach
Main article: Executable UML
Executable UML, often abbreviated to xtUML [3] or xUML [4], is the evolution of the Shlaer-Mellor method[5] to UML, it is a specific approach to implement MDA. Executable UML graphically specifies a deterministic system using a profile of the UML. The models are testable, and can be compiled into a less abstract programming language to target a specific implementation. [5] [6] Executable UML supports MDA through specification of platform-independent models, and the compilation of the platform-independent models into platform-specific models. [7]
MDA tools
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). The OMG documents the overall process in a document called the MDA Guide.Basically, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc.
74
models or metamodels.[8] In the following section "model" is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation.
An MDA tool may be one or more of the following types[citation needed]:
Creation Tool: A tool used to elicit initial models and/or edit derived models. Analysis Tool: A tool used to check models for completeness, inconsistencies, or
error and warning conditions. Also used to calculate metrics for the model. Transformation Tool: A tool used to transform models into other models or into
code and documentation. Composition Tool: A tool used to compose (i.e. to merge according to a given
composition semantics) several source models, preferably conforming to the same metamodel.
Test Tool: A tool used to "test" models as described in Model-based testing. Simulation Tool: A tool used to simulate the execution of a system represented by
a given model. This is related to the subject of model execution. Metadata Management Tool: A tool intended to handle the general relations
between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.
Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc.One of the characteristics of MDA tools is that they mainly take models (e.g. MOF models or metamodels) as input and generate models as output[citation needed]. In some cases however the parameters may be taken outside the MDA space like in model to text or text to model transformation tools.
Implementations of the OMG specifications come from private companies or open source groups. One important source of implementations for OMG specifications is the Eclipse Foundation. Many implementations of OMG modeling standards may be found in the Eclipse Modeling Framework (EMF) or Graphical Modeling Framework (GMF), the Eclipse foundation is also developing other tools of various profiles as GMT. Eclipse's compliance to OMG specifications is often not strict. This is true for example for OMG's EMOF standard, which Eclipse approximates with its ECORE implementation. More
75
examples may be found in the M2M project implementing the QVT standard or in the M2T project implementing the MOF2Text standard.
Power RAD is being developed by Outline Systems Inc. Microsoft is proposing the DSL tools approach which is a similar approach, not based on OMG standards. Another open source project called AndroMDA provides an extensible framework for generating code using virtually any technology/platform (e.g., .NET, Java, etc.) and is meant to be used repeatedly as part of the build process (i.e., instead of just generating starter code once at the beginning of a project).
One should be careful not to confuse the List of MDA Tools and the List of UML tools, the former being much broader. This distinction can be made more general by distinguishing 'variable metamodel tools' and 'fixed metamodel tools'. A UML CASE tool is typically a 'fixed metamodel tool' since it has been hard-wired to work only with a given version of the UML metamodel (e.g. UML 2.1). On the contrary, other tools have internal generic capabilities allowing them to adapt to arbitrary metamodels or to a particular kind of metamodels.
Usually MDA tools focus rudimentary architecture specification, although in some cases the tools are architecture-independent (or platform independent).
Simple examples of architecture specifications include:
Selecting one of a number of supported reference architectures like Java EE or Microsoft .NET,
Specifying the architecture at a finer level including the choice of presentation layer technology, business logic layer technology, persistence technology and persistence mapping technology (e.g. object-relational mapper).
Metadata: information about data.
Design methodologies for MDA
MDA requires that design is done in an architecture and technology neutral way. Design methodologies like URDAD have been specifically formulated to generate a UML-based, technology neutral design in the spirit of the MDA.
MDA concerns
Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the Shlaer-Mellor method during the late 1980s. Indeed a key absent technical standard of the MDA approach (that of an action language syntax for Executable UML) has been bridged by some vendors by adapting the original Shlaer-Mellor Action Language (modified for UML)[citation needed]. However during this period the MDA approach has not gained mainstream industry acceptance; with the Gartner Group still identifying MDA as an "on the rise" technology in its 2006 "Hype Cycle"[9], and
76
Forrester Research declaring MDA to be "D.O.A." in 2006[10]. Potential concerns that have been raised with the OMG MDA approach include:
Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e.g. an action semantic language for xtUML), or are yet to be implemented in a standard manner (e.g. a QVT transformation engine or a PIM with a virtual execution environment).[11][12]
Vendor Lock-in: Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an MDA approach.[citation needed]
Idealistic: MDA is conceived as a forward engineering approach in which models are transformed into implementation artifacts (e.g. executable code, database schema) in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application[13]. This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) are not supported . This constitutes a problem in situations where such post-transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called "pragmatic MDA"[14]. Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers.[15]
OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard[16].
Uncertain Value Proposition: As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation (program) for a particular computing platform (i.e. .NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release .NET platform (or even a Java platform) in a deterministic manner – although significant questions remain as to real-world practicalities during translation (such as user interface implementation). Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an "alternative to programming" should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used (e.g. xtUML) is more abstract (than, say, Java or
77
C#) and exists interwoven with traditional UML artifacts (e.g. class diagrams). Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered.
78
2-MARKS
1. What is CORBA?
2. what is IDL?
3. What are the element of interface header?
4. what are the directional attributes?
5. what is ORB?
6. How to change ORB technology?
7. what are the key charterstics of SOM?
8. what is POA?
9. what are the services provided by object adaptor?
10. what are the components in the CORBA REFERENCE MODEL?
16-MARKS?
1. Explain the details about CORBA architecture and CORBA –OMA?
2. Explain the details about CORBA services?
3. what are the components of CCM architecture and explain ?
79