Explore topic-wise InterviewSolutions in .

YES, it is POSSIBLE. However, you need to write a custom ant task, get the PATH, and add/modify it, and put it in USE. What I am doing is that I DEFINE a path reference lib.classpath, then add/modify the lib.classpath use my own task.

Yes, it is possible. However, you need to write a custom ant task, get the path, and add/modify it, and put it in use. What I am doing is that I define a path reference lib.classpath, then add/modify the lib.classpath use my own task.

OVERRIDE ant Input task.
Response EVERY USER input with a backspace. Not the best, but it WORKS.

Override ant Input task.
Response every user input with a backspace. Not the best, but it works.

Here is a working one!

<xslt style="${xslfile}" in="${INFILE}" out="${outfile}" &GT;
<classpath>
<FILESET DIR="${xml.home}/bin" 
INCLUDES="*.jar" />
</classpath>
</xslt>

Here is a working one!

<xslt style="${xslfile}" in="${infile}" out="${outfile}" >
<classpath>
<fileset dir="${xml.home}/bin" 
includes="*.jar" />
</classpath>
</xslt>

pass it as compilerarg nested &LT;compilerarg&GT; to specify.

<compilerarg VALUE="-Xlint"/>
<!-- or -->
<compilerarg value="-Xlint:unchecked"/>

pass it as compilerarg nested <compilerarg> to specify.

<compilerarg value="-Xlint"/>
<!-- or -->
<compilerarg value="-Xlint:unchecked"/>

The followings are what I'm doing.

1. Don't define java.home by yourself. Ant USES an internal one derived from your ENVIRONMENT var JAVA_HOME. It is immutable.
2. I do the followings:
* In my build.properties (READ first)
jdk13.bin=${tools.home}/jdk1.3.1_13/bin
jdk14.bin=${tools.home}/j2sdk1.4.2_08/bin/
* In my MASTER properties file (read last), set default javac.location=${jdk13.bin}
* In my prj.properties, if I NEED to use 1.4
javac.location=${jdk14.bin}
* in my javac task
executable="${javac.location}/javac.exe"

The followings are what I'm doing.

1. Don't define java.home by yourself. Ant uses an internal one derived from your environment var JAVA_HOME. It is immutable.
2. I do the followings:
* In my build.properties (read first)
jdk13.bin=${tools.home}/jdk1.3.1_13/bin
jdk14.bin=${tools.home}/j2sdk1.4.2_08/bin/
* In my master properties file (read last), set default javac.location=${jdk13.bin}
* In my prj.properties, if I need to use 1.4
javac.location=${jdk14.bin}
* in my javac task
executable="${javac.location}/javac.exe"

If files are in the DIRECTORY:

<INCLUDE name="a,B,C"/>

If files are in the directory or subdirectories:

<include name="**/a,**/b,**/c"/>

If you want all files WITHOUT extension are in the directory or subdirectories:

<exclude name="**/*.*"/> 

If files are in the directory:

<include name="a,b,c"/>

If files are in the directory or subdirectories:

<include name="**/a,**/b,**/c"/>

If you want all files without extension are in the directory or subdirectories:

<exclude name="**/*.*"/> 

Easy!
WRITING Your Own Task How-To from ANT.
In your own $ANT_HOME/docs/manual DIRECTORY, there also is tutorial-writing-tasks-src.zip
Use them! Use taskdef to DEFINE it in your script, define it before using it.

Easy!
Writing Your Own Task How-To from ant.
In your own $ANT_HOME/docs/manual directory, there also is tutorial-writing-tasks-src.zip
Use them! Use taskdef to define it in your script, define it before using it.

No, you don't need to unarchive them first.

* You don't need to UNZIP the files from archive to PUT into your destination jar/ear/war files.
* You can use zipfileset in your jar/war/ear task to extract files from old archive to different directory in your new archive.
* You also can use zipfileset in your jar/war/ear task to SEND files from local directory to different directory in your new archive. 

See the follow example:

&LT;jar destfile="${dest}/my.jar">
<zipfileset src="old_archive.zip" includes="**/*.properties" prefix="dir_in_new_archive/prop"/>
<zipfileset dir="curr_dir/abc" prefix="new_dir_in_archive/xyz"/>
</jar>

No, you don't need to unarchive them first.

* You don't need to unzip the files from archive to put into your destination jar/ear/war files.
* You can use zipfileset in your jar/war/ear task to extract files from old archive to different directory in your new archive.
* You also can use zipfileset in your jar/war/ear task to send files from local directory to different directory in your new archive. 

See the follow example:

<jar destfile="${dest}/my.jar">
<zipfileset src="old_archive.zip" includes="**/*.properties" prefix="dir_in_new_archive/prop"/>
<zipfileset dir="curr_dir/abc" prefix="new_dir_in_archive/xyz"/>
</jar>

You don't NEED to use Runtime etc. ANT have exec task. The class name is org.apache .tools.ant. taskdefs. ExecTask. You can create the task by USING the CODE in your CUSTOMIZED ant Task.
ExecTask compile = (ExecTask)project.createTask("exec");

You don't need to use Runtime etc. Ant have exec task. The class name is org.apache .tools.ant. taskdefs. ExecTask. You can create the task by using the code in your customized ant Task.
ExecTask compile = (ExecTask)project.createTask("exec");

Here is an example.

&LT;COPY todir="${to.DIR}" >
<fileset dir="${from.dir}" >
<exclude NAME="dirname1" />
<exclude name="dirname2" />
<exclude name="abc/whatever/dirname3" />
<exclude name="**/dirname4" />
</fileset>
</copy>

Here is an example.

<copy todir="${to.dir}" >
<fileset dir="${from.dir}" >
<exclude name="dirname1" />
<exclude name="dirname2" />
<exclude name="abc/whatever/dirname3" />
<exclude name="**/dirname4" />
</fileset>
</copy>

Many ways
* Do an echo on where you have doubt. You will FIND out what is the PROBLEM easily. Just like the old c printf() or Java System.println()
* Use project.log("MSG") in your javascript or CUSTOM ant task
* Run Ant with -verbose, or EVEN -debug, to get more information on what it is doing, and where. However, you might be tired with that pretty soon, since it give you too much information.

Many ways
* Do an echo on where you have doubt. You will find out what is the problem easily. Just like the old c printf() or Java System.println()
* Use project.log("msg") in your javascript or custom ant task
* Run Ant with -verbose, or even -debug, to get more information on what it is doing, and where. However, you might be tired with that pretty soon, since it give you too much information.

Use exec ant task.
Don't FORGET ant is pure Java. That is why ant is so useful, powerful and versatile. If you want ant RECEIVE unix command and RESULT, you must think Unix. So does in MS-Windows. Ant just HELPS you to automate the process.

Use exec ant task.
Don't forget ant is pure Java. That is why ant is so useful, powerful and versatile. If you want ant receive unix command and result, you must think Unix. So does in MS-Windows. Ant just helps you to automate the process.

Download apache ant src version. USE ant JAVADOCS COMMAND to see GENERATED JAVADOC for ant in build/docs directory.

Download apache ant src version. Use ant javadocs command to see generated javadoc for ant in build/docs directory.

Yes, you can.
This is very similar to the call of Java class toString() method and actually it is calling the toString() method inside ant. For example

&LT;FILESET id="fs1" dir="t1" includes="**/*.java"/>
<property NAME="f1.contents" refid="fs1"/>
<ECHO>f1.contents=${f1.contents}</echo>

Yes, you can.
This is very similar to the call of Java class toString() method and actually it is calling the toString() method inside ant. For example

<fileset id="fs1" dir="t1" includes="**/*.java"/>
<property name="f1.contents" refid="fs1"/>
<echo>f1.contents=${f1.contents}</echo>

See here.
You NEED to ESCAPE the string to "D:\\\\Code\\\\include" or use "D:/Code/include" instead!

BELIEVE me or not? Forward slash works on windows in all ant or java code. It also works in windows environment VARIABLES. It does not work in cmd (DOS) window before XP. It also works in XP dos window now!

See here.
You need to escape the string to "D:\\\\Code\\\\include" or use "D:/Code/include" instead!

Believe me or not? Forward slash works on windows in all ant or java code. It also works in windows environment variables. It does not work in cmd (dos) window before XP. It also works in XP dos window now!

USE ANT-contrib <for> <foreach> tasks
General to SAY, use <for> is BETTER than use <foreach> since for each is actually open another ant property space, use more MEMORY too.

Use ant-contrib <for> <foreach> tasks
General to say, use <for> is better than use <foreach> since for each is actually open another ant property space, use more memory too.

ANT sets properties by order, when something is set, the later same properties cannot OVERWRITE the previous ones. This is opposite to your Java SETTERS.

This give us a good leverage of preset all properties in one place, and overwrite only the needed. Give you an example here. You need password for a TASK, but don't want to share it with your team members, or not the developers outside your team.

Store your password in your ${user.home}/prj.properties
pswd=yourrealpassword
In your include directory master prj.properties
pswd=password
In your build-common.xml read properties files in this order

1. The commandline will prevail, if you use it: ant -Dpswd=newpassword
2. ${user.home}/prj.properties (personal)
3. yourprojectdir/prj.properties (project team wise)
4. your_master_include_directory/prj.properties (universal) 

<cvsnttask password="${pswd} ... />

Problem solved!

Ant sets properties by order, when something is set, the later same properties cannot overwrite the previous ones. This is opposite to your Java setters.

This give us a good leverage of preset all properties in one place, and overwrite only the needed. Give you an example here. You need password for a task, but don't want to share it with your team members, or not the developers outside your team.

Store your password in your ${user.home}/prj.properties
pswd=yourrealpassword
In your include directory master prj.properties
pswd=password
In your build-common.xml read properties files in this order

1. The commandline will prevail, if you use it: ant -Dpswd=newpassword
2. ${user.home}/prj.properties (personal)
3. yourprojectdir/prj.properties (project team wise)
4. your_master_include_directory/prj.properties (universal) 

<cvsnttask password="${pswd} ... />

Problem solved!

Here is some snippet of CODE

<path id="build.classpath"&GT;
<fileset dir="${build.lib}" includes="**/*.JAR"/> 
<fileset dir="${build.classes}" /> 
</path>

<TARGET....>
<javac ....>
<classpath refid="build.classpath" />
</java>
</target>

<target....>
<java ....>
<classpath refid="build.classpath" />
</java>
</target>

Here is some snippet of code

<path id="build.classpath">
<fileset dir="${build.lib}" includes="**/*.jar"/> 
<fileset dir="${build.classes}" /> 
</path>

<target....>
<javac ....>
<classpath refid="build.classpath" />
</java>
</target>

<target....>
<java ....>
<classpath refid="build.classpath" />
</java>
</target>

Simple.
* Download the most recent version of ant from Apache; unzip it some where on your machine.
* Install j2sdk 1.4 or above.
* Set JAVA_HOME and ANT_HOME to the directory your installed them respectively.
* Put %JAVA_HOME%/BIN;%ANT_HOME%/bin on your PATH. Use ${JAVA_HOME}/bin:${ANT_HOME}/bin on UNIX. Yes, you can use forward slash on windows.
* WRITE a "Hello world" build.xml

&LT;project name="hello" default="say.hello" basedir="." >
<property name="hello.msg" value="Hello, World!" />
<TARGET name="say.hello" >
<echo>${hello.msg}</echo>
</target>
</project>

* Type ant in the directory your build.xml located.
* You are ready to go!!!! 

Simple.
* Download the most recent version of ant from Apache; unzip it some where on your machine.
* Install j2sdk 1.4 or above.
* Set JAVA_HOME and ANT_HOME to the directory your installed them respectively.
* Put %JAVA_HOME%/bin;%ANT_HOME%/bin on your Path. Use ${JAVA_HOME}/bin:${ANT_HOME}/bin on UNIX. Yes, you can use forward slash on windows.
* Write a "Hello world" build.xml

<project name="hello" default="say.hello" basedir="." >
<property name="hello.msg" value="Hello, World!" />
<target name="say.hello" >
<echo>${hello.msg}</echo>
</target>
</project>

* Type ant in the directory your build.xml located.
* You are ready to go!!!! 

There is a shortcut.

If you download a small jakarta project, such as Log4J, which is built by ant. It is a GOOD and simple EXAMPLE for you to learn ant. Actually, you HIT two birds with one stone.

Ant is easy!

The hard part is how to make a very COMPLICATED diversified system work very simple and elegant. Knowledge about ant is not enough, you NEED an elegant and simple design, you need great naming convention, you need to optimize the code reusability and flexibility, you need a least maintenance system...

Then it is not easy now .

There is a shortcut.

If you download a small jakarta project, such as Log4J, which is built by ant. It is a good and simple example for you to learn ant. Actually, you hit two birds with one stone.

Ant is easy!

The hard part is how to make a very complicated diversified system work very simple and elegant. Knowledge about ant is not enough, you need an elegant and simple design, you need great naming convention, you need to optimize the code reusability and flexibility, you need a least maintenance system...

Then it is not easy now .

Java Bean as is a plain java class with member variables and getter setter methods. Java Beans are defined under JAVABEANS specification as Java-Based software component model which includes the features like introspection, customization, events, properties and persistence.

Enterprise JavaBeans or EJBs for short are Java-based software components that comply with Java's EJB specification. EJBs are delpoyed on the EJB container and executes in the EJB container. EJB is not that simple, it is used for building distributed APPLICATIONS. Examples of EJB are SESSION Bean, Entity Bean and Message Driven Bean. EJB is used for server side programming WHEREAS java bean is a client side. Bean is only DEVELOPMENT but the EJB is developed and then deploy on EJB Container.

Java Bean as is a plain java class with member variables and getter setter methods. Java Beans are defined under JavaBeans specification as Java-Based software component model which includes the features like introspection, customization, events, properties and persistence.

Enterprise JavaBeans or EJBs for short are Java-based software components that comply with Java's EJB specification. EJBs are delpoyed on the EJB container and executes in the EJB container. EJB is not that simple, it is used for building distributed applications. Examples of EJB are Session Bean, Entity Bean and Message Driven Bean. EJB is used for server side programming whereas java bean is a client side. Bean is only development but the EJB is developed and then deploy on EJB Container.

JTA STANDS for Java Transaction API and JTS stands for Java Transaction Service. JTA provides a standard interface which allows the developers to demarcate transactions in a manner that is independent of the transaction manager implementation. The J2EE SDK uses the JTA transaction manager to implement the transaction. The code developed by developers does not calls the JTS methods directly, but only INVOKES the JTA methods. Then JTA internally invokes the JTS ROUTINES. JTA is a HIGH level transaction interface used by the application code to control the transaction.

JTA stands for Java Transaction API and JTS stands for Java Transaction Service. JTA provides a standard interface which allows the developers to demarcate transactions in a manner that is independent of the transaction manager implementation. The J2EE SDK uses the JTA transaction manager to implement the transaction. The code developed by developers does not calls the JTS methods directly, but only invokes the JTA methods. Then JTA internally invokes the JTS routines. JTA is a high level transaction interface used by the application code to control the transaction.

J2EE CLIENTS are the software that access the services components INSTALLED on the J2EE CONTAINER. Following are the J2EE clients:
a) Applets
b) Java-WEB Start clients
c) Wireless clients
d) Web applications.

J2EE clients are the software that access the services components installed on the J2EE container. Following are the J2EE clients:
a) Applets
b) Java-Web Start clients
c) Wireless clients
d) Web applications.

The J2EE platform consists of multi-tiered DISTRIBUTED application model. J2EE applications allows the developers to design and IMPLEMENT the business logic into components according to business requirement. J2EE architecture allows the development of multi-tired applications and the developed applications can be INSTALLED on different machines depending on the tier in the multi-tiered J2EE environment . The J2EE application parts are:

a) Client-tier components run on the client machine.
b) Web-tier components run on the J2EE server.
C) Business-tier components run on the J2EE server and the
d) ENTERPRISE information system (EIS)-tier software runs on the EIS servers.

The J2EE platform consists of multi-tiered distributed application model. J2EE applications allows the developers to design and implement the business logic into components according to business requirement. J2EE architecture allows the development of multi-tired applications and the developed applications can be installed on different machines depending on the tier in the multi-tiered J2EE environment . The J2EE application parts are:

a) Client-tier components run on the client machine.
b) Web-tier components run on the J2EE server.
c) Business-tier components run on the J2EE server and the
d) Enterprise information system (EIS)-tier software runs on the EIS servers.

Session Bean: Session is one of the EJBs and it represents a single client inside the Application Server. STATELESS session is easy to develop and its EFFICIENT. As compare to entity beans session beans require few server resources.

A session bean is similar to an interactive session and is not shared; it can have only one client, in the same way that an interactive session can have only one user. A session bean is not persistent and it is DESTROYED once the session terminates.

Entity Bean: An entity bean represents persistent global data from the DATABASE. Entity beans data are stored into database.

Session Bean: Session is one of the EJBs and it represents a single client inside the Application Server. Stateless session is easy to develop and its efficient. As compare to entity beans session beans require few server resources.

A session bean is similar to an interactive session and is not shared; it can have only one client, in the same way that an interactive session can have only one user. A session bean is not persistent and it is destroyed once the session terminates.

Entity Bean: An entity bean represents persistent global data from the database. Entity beans data are stored into database.

These files are simply zipped file using java jar tool. These files are created for different PURPOSES. Here is the DESCRIPTION of these files:

.jar files: These files are with the .jar extenstion. The .jar files contains the libraries, resources and accessories files like property files.

.war files: These files are with the .war extension. The war file contains the web application that can be deployed on the any servlet/JSP container. The .war file contains jsp, HTML, javascript and other files for necessary for the DEVELOPMENT of web applications.

.ear files: The .ear file contains the EJB modules of the application.

These files are simply zipped file using java jar tool. These files are created for different purposes. Here is the description of these files:

.jar files: These files are with the .jar extenstion. The .jar files contains the libraries, resources and accessories files like property files.

.war files: These files are with the .war extension. The war file contains the web application that can be deployed on the any servlet/jsp container. The .war file contains jsp, html, javascript and other files for necessary for the development of web applications.

.ear files: The .ear file contains the EJB modules of the application.

A web MODULE MAY contain:
a) JSP FILES
b) Java CLASSES
c) gif and html files and
d) web component deployment descriptors.

A web module may contain:
a) JSP files
b) Java classes
c) gif and html files and
d) web component deployment descriptors.

No.

No.

If the variable is PRIMITIVE DATATYPE then it is PASSED by copy.
If the variable is an object then it is passed by reference.

If the variable is primitive datatype then it is passed by copy.
If the variable is an object then it is passed by reference.

AUTOMATIC VARIABLE have to be INITIALIZED EXPLICITLY.

Automatic variable have to be initialized explicitly.

The STATIC VARIABLES are INITIALIZED when the CLASS is loadedNon static variables are initialized just before the constructor is CALLED.

The static variables are initialized when the class is loadedNon static variables are initialized just before the constructor is called.

class variable is a static variable and does not belong to instance of class but rather shared across all the instances member variable BELONGS to a particular instance of class and can be called from any METHOD of the class AUTOMATIC or local variable is CREATED on entry to a method and has only method scope.

class variable is a static variable and does not belong to instance of class but rather shared across all the instances member variable belongs to a particular instance of class and can be called from any method of the class automatic or local variable is created on entry to a method and has only method scope.

So that it can be INVOKED WITHOUT CREATING an INSTANCE of that CLASS.

So that it can be invoked without creating an instance of that class.

False.

False.

DECIMAL, octal and HEXADECIMAL, hence EXAMPLE it can be 28, 034 and 0x1c respectively.

decimal, octal and hexadecimal, hence example it can be 28, 034 and 0x1c respectively.

CHAR type is integral but UNSIGNED. It range is 0 to 2^7-1.

char type is integral but unsigned. It range is 0 to 2^7-1.

All EXCEPT CHAR and BOOLEAN.

All except char and Boolean.

It only TAKES VALUES TRUE and FALSE.

It only takes values true and false.

A source file can contain UNLIMITED number of non-public CLASS DEFINITIONS.

A source file can contain unlimited number of non-public class definitions.

The CORBA specification defines two mechanisms for implementations of a CORBA Object to service its operation invocations. One is the static mechanism and the other is dynamic. The static mechanism requires that the implementation support the specific methods as required by statically KNOWN IDL INTERFACES. Implementations can do this through either a delegated or derived approach (i.e. inheritance or delegation/TIE). If the dynamic approach is taken, the implementation of the Object deals with the REQUEST generically and in a sense, has one "do-it" method for dealing with all requests. The implementatin must INFORCE type safety as apposed to RELYING on an IDL compiler or Language compiler to do it. DSI is much more complicated for a developer then relying on the IDL compiler to generate static request dispatching code.

The CORBA specification defines two mechanisms for implementations of a CORBA Object to service its operation invocations. One is the static mechanism and the other is dynamic. The static mechanism requires that the implementation support the specific methods as required by statically known IDL interfaces. Implementations can do this through either a delegated or derived approach (i.e. inheritance or delegation/TIE). If the dynamic approach is taken, the implementation of the Object deals with the request generically and in a sense, has one "do-it" method for dealing with all requests. The implementatin must inforce type safety as apposed to relying on an IDL compiler or Language compiler to do it. DSI is much more complicated for a developer then relying on the IDL compiler to generate static request dispatching code.

DII ALSO provides a DEFERRED synchronous invocation. This feature is not part of CORBA 2.0's SII. Deferred synchronous invocations are submitted without having to WAIT for a response. This is similiar to a one-way operation except a return values and out parameters are possible, but must be polled for. CORBA 3.0 will support this type of invocation for both STATIC and dynamic modes via the Asynchronous Messaging SERVICE.

DII also provides a deferred synchronous invocation. This feature is not part of CORBA 2.0's SII. Deferred synchronous invocations are submitted without having to wait for a response. This is similiar to a one-way operation except a return values and out parameters are possible, but must be polled for. CORBA 3.0 will support this type of invocation for both static and dynamic modes via the Asynchronous Messaging Service.

Implementations of the CORBA specification (i.e. a CORBA ORB) support SII in the following way. The ORB will PROVIDE an IDL compiler which is specific to that particular ORB PRODUCT. When a developer compiles their IDL with the ORB vendor's IDL compiler, stubs and SKELETONS are created. These stubs and skeletons are static. This is because they do not change. If changes are made to the IDL, the stubs and skeletons must be regenerated by running the IDL compiler again. The IDL compiler generates a stub and skeleton based on the STRUCTURE of the appropriate IDL interfaces. The stubs and skeletons are statically generated at IDL compilation TIME. These stubs are then either imported or included into the application which needs access to the CORBA Objects. The stubs and skeletons will have been generated to either directly or indirectly utilize IIOP to communicate. In many cases, the IDL compiler, will generate stubs to utilize Dynamic Invocation Interface to interact with the skeletons. The IDL compiler may also generate skeletons which utilize Dynamic Skeleton Interface to interact with the stubs.

Implementations of the CORBA specification (i.e. a CORBA ORB) support SII in the following way. The ORB will provide an IDL compiler which is specific to that particular ORB product. When a developer compiles their IDL with the ORB vendor's IDL compiler, stubs and skeletons are created. These stubs and skeletons are static. This is because they do not change. If changes are made to the IDL, the stubs and skeletons must be regenerated by running the IDL compiler again. The IDL compiler generates a stub and skeleton based on the structure of the appropriate IDL interfaces. The stubs and skeletons are statically generated at IDL compilation time. These stubs are then either imported or included into the application which needs access to the CORBA Objects. The stubs and skeletons will have been generated to either directly or indirectly utilize IIOP to communicate. In many cases, the IDL compiler, will generate stubs to utilize Dynamic Invocation Interface to interact with the skeletons. The IDL compiler may also generate skeletons which utilize Dynamic Skeleton Interface to interact with the stubs.

Generally speaking, SII is the easiest mechanism which can be used to INVOKE operations on a CORBA object. All applications which use SII could be IMPLEMENTED with DII. Not all applications which use DII can be implemented with SII. If an application can be developed with SII then it probably should be. This is because DEVELOPING code with SII requires less code and is much more straight forward. The language compiler can be used to validate types and optimize code. There are certain conditions which make DII a better alternative.

Generally speaking, SII is the easiest mechanism which can be used to invoke operations on a CORBA object. All applications which use SII could be implemented with DII. Not all applications which use DII can be implemented with SII. If an application can be developed with SII then it probably should be. This is because developing code with SII requires less code and is much more straight forward. The language compiler can be used to validate types and optimize code. There are certain conditions which make DII a better alternative.

The CORBA specification defines two MECHANISMS for invoking operations on a CORBA Object. Functionaly, the two mechanisms provide the same capabilities. They allow basically the IDL defined operations on the CORBA object to be invoked, allow program variables to be passed to the operation as inbound parameters, and allow return VALUES or out parameters to be passed from the server to the client. The first mechanism is known as the Static Invocation Interface (SII), the other is known as DYNAMIC Invocation Interface . Developers of client applications which USE SII must know the name of the operation, and all parameters/return TYPES prior to program compilation. The actual operation names and parameters/return values are in effect hard coded into the application source code.

The CORBA specification defines two mechanisms for invoking operations on a CORBA Object. Functionaly, the two mechanisms provide the same capabilities. They allow basically the IDL defined operations on the CORBA object to be invoked, allow program variables to be passed to the operation as inbound parameters, and allow return values or out parameters to be passed from the server to the client. The first mechanism is known as the Static Invocation Interface (SII), the other is known as Dynamic Invocation Interface . Developers of client applications which use SII must know the name of the operation, and all parameters/return types prior to program compilation. The actual operation names and parameters/return values are in effect hard coded into the application source code.

CORBA IDL is used to describe application and system INTERFACES in a MANNER that is independent of PROGRAMMING language and computer platform. A language mapping is a standard to convert the IDL to a particular programming language, like C, C++ or JAVA.

CORBA IDL is used to describe application and system interfaces in a manner that is independent of programming language and computer platform. A language mapping is a standard to convert the IDL to a particular programming language, like C, C++ or Java.

Object references allow applications to issue distributed requests. How does an application ACQUIRE an object reference? CORBA provides a number of ways for this to occur. They basically fall into two categories, mechanisms to obtain initial object references and mechanisms to obtain subsequent object references.

CORBA provides two standard ways to obtain an initial object reference:

ORB::resolve_initial_references(string): CORBA defines a VENDOR specific MECHANISM for obtaining an initial set of object references. While CORBA defines the interface for the mechanism, internals required to drive the functionality are not STANDARDIZED. CORBA specifies that an application can obtain an object reference by calling resolve_initial_references(), but vendor specific configurations files, command line arguments, of environmental variable might be required for the call to succeed. Object references obtained in this way can most likely be implemented only within the same vendors ORB. ORB::string_to_object(string):

CORBA provides a vendor independent mechanism for obtaining an object reference. The string_to_object() operation returns an object reference directly from a particular string. The object reference is actually an interoperable object reference and thus can be implemented within an ORB supporting IIOP. Strings are basically encoded identifiers and are not human readable. The string can be hard coded into an application, stored and retrieved from a file, or obtained through some other IPC mechanism. Strings are initially created by calling object_to_string() on an actual object reference. Once an application obtains an object reference, it can obtain subsequent objects by calling any remote operations on the original object reference that happen to return a CORBA object. CORBA refers to an object capable of returning an object reference as a factory. CORBA defines two services that are basically mechanisms by which subsequent object references can be obtained. These are listed below: CORBA NameService CORBA TraderService .

Object references allow applications to issue distributed requests. How does an application acquire an object reference? CORBA provides a number of ways for this to occur. They basically fall into two categories, mechanisms to obtain initial object references and mechanisms to obtain subsequent object references.

CORBA provides two standard ways to obtain an initial object reference:

ORB::resolve_initial_references(string): CORBA defines a vendor specific mechanism for obtaining an initial set of object references. While CORBA defines the interface for the mechanism, internals required to drive the functionality are not standardized. CORBA specifies that an application can obtain an object reference by calling resolve_initial_references(), but vendor specific configurations files, command line arguments, of environmental variable might be required for the call to succeed. Object references obtained in this way can most likely be implemented only within the same vendors ORB. ORB::string_to_object(string):

CORBA provides a vendor independent mechanism for obtaining an object reference. The string_to_object() operation returns an object reference directly from a particular string. The object reference is actually an interoperable object reference and thus can be implemented within an ORB supporting IIOP. Strings are basically encoded identifiers and are not human readable. The string can be hard coded into an application, stored and retrieved from a file, or obtained through some other IPC mechanism. Strings are initially created by calling object_to_string() on an actual object reference. Once an application obtains an object reference, it can obtain subsequent objects by calling any remote operations on the original object reference that happen to return a CORBA object. CORBA refers to an object capable of returning an object reference as a factory. CORBA defines two services that are basically mechanisms by which subsequent object references can be obtained. These are listed below: CORBA NameService CORBA TraderService .

The aggregation of two objects is a very common OO design concept. Aggregation is also known as has-a and contains. Since IDL doesn't support "public data," a programmer that is using an IDL interface cannot tell whether an aggregation is actually implemented using aggregation or by some other technique. In other words, IDL is a specification language that separates interface from implementation. In particular, IDL does not support implementation constructs such as aggregation. However logical aggregation is supported by IDL: IDL lets you specify an operation that returns another interface, and this second interface could REPRESENT an object that is logically contained within the FIRST object. Whether it's actually implemented using aggregation or not is an implementation issue, not a specification issue, and the implementer can do it EITHER way without requiring any changes to the IDL interface. Note that DCOM directly supports aggregation since DCOM combines implementation issues with specification issues. The COM<->CORBA interworking specification actually maps aggregation to and from inheritance (CORBA IDL supports inheritance directly, and DCOM supports aggregation directly).

The aggregation of two objects is a very common OO design concept. Aggregation is also known as has-a and contains. Since IDL doesn't support "public data," a programmer that is using an IDL interface cannot tell whether an aggregation is actually implemented using aggregation or by some other technique. In other words, IDL is a specification language that separates interface from implementation. In particular, IDL does not support implementation constructs such as aggregation. However logical aggregation is supported by IDL: IDL lets you specify an operation that returns another interface, and this second interface could represent an object that is logically contained within the first object. Whether it's actually implemented using aggregation or not is an implementation issue, not a specification issue, and the implementer can do it either way without requiring any changes to the IDL interface. Note that DCOM directly supports aggregation since DCOM combines implementation issues with specification issues. The COM<->CORBA interworking specification actually maps aggregation to and from inheritance (CORBA IDL supports inheritance directly, and DCOM supports aggregation directly).

IDL stands for Interface DEFINITION Language. Its PURPOSE is to define the capabilities of a distributed service along with a common set of data types for interacting with those distributed services. IDL meets a number of objectives:

• Language Independence:
• Distributed service specification:
• Definition of COMPLEX data types:
• HARDWARE Independence.

IDL stands for Interface Definition Language. Its purpose is to define the capabilities of a distributed service along with a common set of data types for interacting with those distributed services. IDL meets a number of objectives:

• Language Independence:
• Distributed service specification:
• Definition of complex data types:
• Hardware Independence.

Keep in mind the CORBA is primarily a specification for accessing remote OBJECTS. There is support for location TRANSPARENCY and the case where CORBA objects can be accessed LOCALLY, but there is a bias in the specification for remote objects. There is a need, however, to describe local objects, such as the ORB itself in the local process. In keeping with CORBA, the description of this local object is done in IDL, so that the description is programming language independent. To distinguish the use of IDL to describe a POTENTIALLY remote object (the normal use of IDL), and the use of IDL to describe an exclusively local object, the concept of a Pseudo Object was introduced. Pseudo objects use Pseudo IDL (also called PIDL) to describe their interfaces. PIDL is indentical to IDL, except the intention is that the object of a PIDL interface is not associated with an Object Reference for the PURPOSES of remote access.

Keep in mind the CORBA is primarily a specification for accessing remote objects. There is support for location transparency and the case where CORBA objects can be accessed locally, but there is a bias in the specification for remote objects. There is a need, however, to describe local objects, such as the ORB itself in the local process. In keeping with CORBA, the description of this local object is done in IDL, so that the description is programming language independent. To distinguish the use of IDL to describe a potentially remote object (the normal use of IDL), and the use of IDL to describe an exclusively local object, the concept of a Pseudo Object was introduced. Pseudo objects use Pseudo IDL (also called PIDL) to describe their interfaces. PIDL is indentical to IDL, except the intention is that the object of a PIDL interface is not associated with an Object Reference for the purposes of remote access.

CORBA PSEUDO OBJECTS are not real CORBA objects. A CORBA OBJECT has an Object Reference, and can be accessed REMOTELY. Pseudo objects do not have Object References and cannot be accessed remotely.

CORBA Pseudo Objects are not real CORBA objects. A CORBA Object has an Object Reference, and can be accessed remotely. Pseudo objects do not have Object References and cannot be accessed remotely.