Corba Scripting Language

vroomhuhΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

53 εμφανίσεις

Corba Scripting Language
1
Humboldt-Universität | CNRI
Corba Scripting Language
OMG RFP Submission
Humboldt-Universität zu Berlin
Corporation for National Research Initiatives
OMG Document orbos/97-11-20
Nov 4, 1997
Corba Scripting Language
2
Humboldt-Universität | CNRI
Copyright Humboldt-Universität zu Berlin, 1997.
Copyright Corporation for National Research Initiatives, 1997.
The companies listed above hereby grant to the Object Management Group and Object Management
Group members, permission to copy this document for the purpose of evaluating the technology contained
herein during the CORBA Scripting Language submission evaluation process. Distribution to anyone not a
member of the Object Management Group or for any purpose other than technology evaluation is
prohibited.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE
COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. The companies listed above shall not be liable for errors
contained herein or for incidental or consequential damages in connection with the furnishing, performance
or use of this material. The information contained in this document is subject to change without notice.
This document contains information which is protected by copyright. All Rights Reserved. Except as
otherwise provided herein, no part of this work may be reproduced or used in any form or by any means 
graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and
retrieval systems  without the permission of the companies listed above. All copies of this document must
include the copyright and other information contained on this page.
This document could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated into new editions of the document if any
are published. The companies listed above may make improvements and/or changes in the product(s)
and/or the program(s) described in this document at any time.
RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions
set forth in subdivision (c)(1)(ii) of the Rights in Technical Data and Computer Software Clause at DFARS
252.227-7013.
Macintosh is a trademark of Apple, Inc.
Unix is a trademark of The Open Group.
Windows is a trademark of Microsoft, Inc.
Corba Scripting Language
3
Humboldt-Universität | CNRI
Contents
1 INTRODUCTION.....................................................................................................................................................4
1.1 S
UBMISSION
C
ONTACT
P
OINTS
..............................................................................................................................4
1.2 O
VERVIEW OVER THE
S
UBMISSION AND
D
ESIGN
R
ATIONALE
................................................................................4
1.3 P
ROOF OF
C
ONCEPT
...............................................................................................................................................4
2 RESPONSE TO RFP REQUIREMENTS...............................................................................................................5
2.1 S
CRIPTING
L
ANGUAGE
E
LEMENTS
.........................................................................................................................5
2.2 R
EQUIREMENTS FOR
P
ROGRAMMING
M
ODEL
........................................................................................................6
2.3 O
PTIONAL
R
EQUIREMENTS
....................................................................................................................................6
3 THE PYTHON PROGRAMMING LANGUAGE..................................................................................................7
3.1 O
BJECT
-O
RIENTED
P
ROGRAMMING
U
SING
P
YTHON
..............................................................................................7
3.2 O
BJECT
-O
RIENTED
S
CRIPTING
...............................................................................................................................8
3.3 E
XTENSIBILITY
......................................................................................................................................................9
4 PYTHON AS A CORBA IMPLEMENTATION LANGUAGE............................................................................9
4.1 M
APPING FOR
IDL
TYPES
......................................................................................................................................9
4.2 M
APPING FOR
M
ODULES AND
S
COPED
N
AMES
....................................................................................................10
4.3 CORBA O
BJECTS
...............................................................................................................................................10
4.4 C
LIENTS AND
S
ERVERS
........................................................................................................................................10
5 SCRIPTING IN THE CONTEXT OF CORBA COMPONENTS......................................................................11
5.1 P
YTHON
S
UPPORT FOR
W
IN
32
AND
COM...........................................................................................................11
5.2 M
ULTIPLE
I
NTERFACES
........................................................................................................................................11
5.3 A
CCESS TO
C
OMPONENT
P
ROPERTIES
.................................................................................................................12
5.4 M
ECHANISMS FOR
S
ERIALIZATION
.......................................................................................................................12
5.5 R
ECEPTION OF
C
OMPONENT
E
VENTS
...................................................................................................................12
5.6 I
NTERWORKING WITH
J
AVA
.................................................................................................................................12
6 COMPLIANCE.......................................................................................................................................................13
6.1 C
HANGES TO
E
XISTING
OMG S
PECIFICATIONS
....................................................................................................13
6.2 P
ROPOSED
C
OMPLIANCE
P
OINTS
.........................................................................................................................13
Corba Scripting Language
4
Humboldt-Universität | CNRI
1 Introduction
1.1 Submission Contact Points
All questions about the submission should be directed to:
Martin v. Löwis
Humboldt-Universität zu Berlin
Institut für Informatik
Axel-Springer-Str. 54a
10117 Berlin
phone: +49 30 20181321
fax: +49 30 20181234
email: loewis@informatik.hu-berlin.de
Guido van Rossum
Corporation for National Research Initiatives
1895 Preston White Drive
Reston, Virginia 20191
phone: +1 703-620-8990
email: guido@cnri.reston.va.us
1.2 Overview over the Submission and Design Rationale
This submission proposes to use Python as the CORBA Scripting Language. Python is an object oriented
language which is usually executed in an interpreter. Add-on packages support the interaction of Python
programs and CORBA clients and servers. Python is actively being used in the industry. Rather than
defining a new scripting language, CORBA Scripting should be built on top of the existing Python language.
This proposal is structured as follows:
·

Introduction into Python
·

Overview over the existing CORBA/Python solutions
·

Discussion of issues specific to CORBA Components
Since the technology being discussed is already in use, a wide variety of documentation is available.
Rather than duplication this documentation, the reader is referred to the original sources.
1.3 Proof of Concept
The technology proposed in this document has been available for several years now. It has been applied in
various industrial projects. In particular, the following software packages are available on commercially
reasonable terms:
·

An implementation of the Python programming language is available from the Python Web Server,
www.python.org. This implementation supports various platforms, including various Unix platforms,
Microsoft Windows, and the Apple Macintosh systems.
·

An implementation of the Object Request Broker and the mapping from OMG IDL to Python is included
in the ILU system of Xerox PARC. ILU is available from <URL:ftp://ftp.parc.xerox.com/ilu>. This
package supports multiple transport protocols, including IIOP, as well as multiple implementation
Corba Scripting Language
5
Humboldt-Universität | CNRI
languages, including C and Python. It has been ported to various systems as well, including Unix
systems and Microsoft Windows.
·

Another implementation of the CORBA/Core concepts for Python is the Fnorb package of DSTC,
available from <URL:http://www.dstc.edu.au/Fnorb>.
2 Response to RFP Requirements
The following is a list of the requirements from the Corba Scripting Language RFP (OMG orbos/97-06-13),
specifying how this submission is responsive to the RFP.
2.1 Scripting Language Elements
·

Responses shall clearly define the concept of object-oriented scripting.
Object-oriented scripting is defined based on an object-oriented scripting language in this proposal. Object-
oriented scripting manifests in the ability to use OOP concepts (classes, inheritance, polymorphism,
encapsulation, late binding) in the scripts. A scripting language, as described in the RFP, is mainly
characterized by short turn-around times during development due to interpretation. Since Python provides
all these concepts, it is well suited as an object-oriented scripting language.
·

Responses shall describe the relationship between scripts and the CORBA proposed component model. In
particular, responses shall describe how scripts interact with and control the proposed components.
Since there is no adopted component model at the time of this submission, it is only possible to reason
based on the RFP for that component model. CORBA components will interact using IDL interfaces. This
proposal presents technology to let scripts operate as clients to implementations of IDL interfaces. Thus,
Python scripts will interact with the CORBA components in a straight forward manner. The distinction
between local script objects and components implemented in some other language is almost invisible to
the script programmer.
·

Responses shall describe how scripts can invoke operations on CORBA objects.
This proposal presents Python as a full CORBA implementation language. Python scripts can invoke
operations using the approaches presented in the CORBA Object model: an operation can be invoked
either on a stub object, or the dynamic invocation interface. In addition, the dynamic nature of Python
allows the invocation of operations on stub objects even if the operation name and signature was not
known during the development.
·

Responses shall specify interfaces and mechanisms for controlling component-events, and for installing arbitrary
component-event handlers (listeners) for specific component-events generated by the proposed components. The
language shall be aligned with the proposed CORBA component event mechanism. The relationship between the
proposed CORBA component model's event mechanism and the scripting language shall be clearly defined.
The CORBA event mechanism is based on IDL interfaces. The consumer needs either to invoke operation
(pull model) or to implement operations (push model) in order to receive events. Since the proposed
technology supports arbitrary IDL interfaces, it is aligned with the CORBA event service. In addition,
Python's reflective features allow to dynamically investigate whether a certain object implements a handler
for a certain event. In turn, scripts only need to deal with the events they require for the task that they
execute.
·

Responses shall specify how the scripting language exposes and manages proposed component properties.
Corba Scripting Language
6
Humboldt-Universität | CNRI
Since component properties are accessible using standard IDL interfaces, a script could access the
properties using these very interfaces. Depending on the interfaces, such a property access might be
inconvenient. The dynamic nature of Python allows a simpler property access, exposing them as attributes
of the component. The Python base class for components then needs to implement a
__getattr__
function, transforming the attribute access to a property access using the component's interface.
2.2

Requirements for Programming Model
·

The response shall support both run-time and design-time needs. Responses shall describe how the scripting
language can be used to configure and assemble proposed CORBA components.
Even though the run-time and design-time needs vary from application to application, experience shows
that there are common problems when using scripting languages. At run time, a common need is the
portability of the scripts. Python addresses this problem by supplying the same set of libraries for common
programming problems on a variety of platforms. At design time, the focus often is on maintainability of
scripts. The small number of syntactic constructs make Python easy to learn and simplifies maintainance
of existing scripts.
Python offers different approaches to configuration and assembly of components. The
pickle
externalization mechanism allows to store configuration information with minimal development efforts.
Packaging and distribution of scripts can use either source code or byte code; in both cases, the Python
code will run on the target system without needing extensive compilation or installation procedures.
Assembly of components and scripts into a single file is supported using the
freeze
mechanism.
·

The scripting language shall be designed to be used in a visual runtime environment (i.e. desktop, browser, etc.)
as well as a non-visual runtime environment (i.e. middle tier application server).
The Python interpreter in itself does not require a visual environment; it is distributed non-graphically for
most systems. Special libraries enhance the integration into WWW servers.
Various approaches are available for a visual environment. Rather than introducing a new cross-platform
windowing toolkit, Python integrates windowing libraries which are available on the various platforms.
Currently, four different approaches are available, depending on the application area:
1.

For cross-platform applications, Python integrates Ousterhout's toolkit Tk, which supports X11,
Microsoft Windows, and the Macintosh.
2.

For Microsoft Windows only, an integration with the Microsoft Foundation Classes is available. This
exposes features of the visual environment that are usually not found in cross-platform libraries.
3.

For execution in WWW browsers, plug-ins for different browsers allow the execution of Python code
inside the browser.
4.

In a recent project, another implementation of the Python programming language on top of the Java
Virtual Machine has been developed. This allows the execution of Python code inside any browser that
supports the JVM. In particular, that Python implementation gives access to the Java Abstract
Windowing Toolkit
Corba Scripting Language
7
Humboldt-Universität | CNRI
2.3

Optional Requirements
·

Proposals may also support the use of the scripting language as an implementation language for CORBA objects.
This document proposes Python as a full implementation language for CORBA, including server-side
mappings.
3 The Python Programming Language
This section gives an overview of Python. More detailed descriptions are available from the Python Web
Server, and in the following books:
Internet Programming With Python
By Aaron Watters, Guido van Rossum, and James Ahlstrom
MIS Press/Henry Holt publishers
ISBN: 1-55851-484-8
First published October, 1996
Programming Python
By Mark Lutz
O'Reilly & Associates
ISBN: 1-56592-197-6
First published October, 1996
Das Python-Buch
By Martin von Löwis and Nils Fischbeck
Addison-Wesley-Longman, 1997
ISBN: 3-8273-1110-1
3.1 Object-Oriented Programming Using Python
Python supports different programming styles, although the focus is on object-oriented programming. The
core concept for OOP here is the class. A class definition in Python contains a name, the list of base
classes (allowing multiple inheritance), and the body of the class. The body can contain both data
attributes (class variables) and methods. In the example below, a class with two methods is defined.
class Person:
def __init__(self,name,age):
self.name=name
self.age=age
def has_birthday(self):
self.age=self.age+1
Block structure in Python is indicated as indentation, allowing for better readability. For a method, the
object on which the method is invoked is not implicit (as in C++), but explicit as the first argument - usually
called
self
. Attribute access is done using a dot (.) between the object and the attribute. Methods that are
invoked implicitly by the interpreter as indicated using a underscore convention. For example, the
__init__
method is invoked when a new instance is created, i.e. it is the constructor. A new instance of
the class can then be created using a functional notation:
Corba Scripting Language
8
Humboldt-Universität | CNRI
john = Person("John", 42)
john.has_birthday()
Python is not a statically typed language: there are no type declarations for the method parameters, nor
are the attributes of an instance declared. Instead, the presence of an attribute is checked at the time the
attribute is accessed.
This dynamics is the basis for both polymorphism and late binding. Attributes are bound at the latest
possible time: when they are accessed. Late binding is not only restricted to methods, it applies for all
attributes. Polymorphism is an immediate result of the late binding: If a method expects an instance of a
certain class, an instance of a derived class can be passed at run-time. When the attribute is accessed, the
interpreter checks the instance itself, then the class, then the base classes. Furthermore, polymorphism is
not restricted to the inheritance relationship. Suppose L is a list of objects with a retail price tag. The total of
all the items in the list can then be computed as
sum=0
for item in L:
sum=sum+L.price()
The code works regardless of the inheritance relationships between the items. Instead, each item must
support a price method with should return a numerical value. This allows the implementation of generic
algorithm without requiring templates or type casts as in C++ or Java.
Since there is no static typing, errors in the program are detected at run time. Rather than aborting the
program, the interpreter raises exceptions. The exception mechanism in Python works similar to the one of
C++. In addition to exceptions raised by the interpreter, user defined exceptions are supported as well.
3.2 Object-Oriented Scripting
The main goal of script programming is to develop small programs in a short time. In order to do so, the
scripting language must support complex functionality built-in, and the turn-around times during
development must be short.
Python comes with a standard library that supports various application areas. For text manipulation,
functions ranging from regular expressions up to SGML parsers are available. For internet programming,
the core functionality is in the socket support, with application protocols such as ftp and http built on top.
Operating system functionality and file access is exposed in a platform-independent way.
In addition to the library, scripts often make heavy use of advanced data structures. Python supports three
built-in data structures for common application problems: tuples, lists and dictionaries. Tuples and lists are
integer-indexed arrays and support concatenation and slicing; arrays are indexed with arbitrary objects. In
the example above, the list L could have been constructed as
#assuming that Butter, Milk and Meat are classes with appropriate constructors
L = [ Butter(10.3), Milk(amount=4) ]
L.append(Meat(type='pork', amount=8))
In order to structure the library and the application, Python uses a module concept similar to the one of
Modula-2. A module is a source code unit stored in a single file. Using the import statement, other modules
can load the module, and then access the classes, functions, and other attributes defined in the module.
Modules prove as a good approach to code reuse.
Corba Scripting Language
9
Humboldt-Universität | CNRI
This Python interpreter first translates the script into a platform-independent byte code, and stores this
byte-code into a file for future use. The byte code is then executed. This approach reduces the time
between development cycles, because expensive compilation steps to machine code are avoided. Storing
the byte code in a file is just for efficiency; the program will work whether the byte code is available on disk
or not.
Having the source code parser available at all times gives an additional advantage: It is possible to execute
source code that was created at run-time, e.g. entered by a user or downloaded from a remote location.
This is different from languages like Java, which require the compilation to byte code prior to the execution.
A customizable mechanism known as restricted execution allows to establish flexible security in the
context of untrusted code.
3.3 Extensibility
Python supports both extensions to the library as well as embedding the interpreter into another
application. Extension modules are machine code files, usually obtained from compiling C code. Using
extension modules, it is possible to access libraries written in other languages. Embedding is the process
of enhancing an existing application with a Python interpreter. This is usually done to allow the user of the
application to enhance it by providing Python code. Embedding the Python interpreter increases the total
program size by about 300KB, depending on the number of module made available to the application.
Closely related to the combination of Python code and compiled code like C is the issue of packaging.
Usually, a Python installation consumes one file per module, thus reducing the amount of I/O performed at
application startup. If this is undesirable, a mechanism called freezing allows the integration of all those
files into one. This is done by copying the relevant byte code into the resulting program image. Any mix of
frozen and external modules is possible.
4 Python as a CORBA Implementation Language
The technology presented in this document allows to define the interaction between components and
CORBA scripts in two steps:
1.

Define a mapping between IDL and Python. In ODP terminology, this is the computational view.
2.

Define the interworking of Python scripts and CORBA components for a specific environment, with
issues such as repository access, user interface, operating system specifics, etc. This deals with issues
in the engineering and technology views. Traditionally, not all of those issues are subject to
standardization.
Using this two-steps approach, Python can be used for CORBA applications in general, instead of
restricting applicability to CORBA scripting.
Since there is no OMG adopted mapping from IDL to Python at the time of this submission, the current
state of the mappings as available in implementations today is presented. From a technical point of view,
formalizing such a mapping is straight-forward, but out-of-scope of this contribution.
4.1 Mapping for IDL types
Most IDL types have straight-forward mappings for Python. The numeric IDL types are mapped to the
equivalent numeric types of Python; for the IDL fixed template type, a class is provided. The character and
string types are mapped to Python strings. Boolean is mapped to 0 and 1.
Corba Scripting Language
10
Humboldt-Universität | CNRI
Struct types are mapped to a Python class, with the fields being attributes. Unions are mapped to pairs of
discriminator and value. Both arrays and sequences are mapped to Python sequences (lists and tuples).
Constants are available as attributes of the scope where they are defined.
4.2 Mapping for Modules and Scoped Names
IDL modules are naturally mapped to Python modules, where only certain cases of module re-opening
need special consideration.
Since Python supports nested classes, scoping can be made available in a straight-forward manner. For
example, the IDL name foo::bar::baz could be mapped as foo.bar.baz. In the specific case of nested
modules, writing the entire scope every time is inconvenient. Instead, Python's support for packages
should be used. Given the IDL
module foo{
module bar{
struct baz{ int i;string s;};
};
};
the Python programmer could create instances of the structure in any of the following ways:
import foo.bar
structure = foo.bar.baz(42,"answer")
from foo import bar
structure = bar.baz(42,"answer")
from foo.bar import baz
structure = baz(42,"answer")
This approach gives a flexible scoping while still avoiding name conflicts.
4.3 CORBA Objects
Object references are implemented as instances of Python classes, both for stub objects as well as for
implementation objects. Operations defined in an interface are invoked as normal methods in Python.
Exceptions definitions in IDL are mapped to classes in Python. On the implementation side, an exception is
raised by producing an instance of the class in a raise statement. This instance holds the parameters of
the exception. The client can catch exception in the except clauses, and inspect the exception parameters
in the handler block.
Since attribute declarations in IDL are only a short-cut for set and get operations, Python programs access
attributes using these operations.
4.4 Clients and Servers
Both clients and servers access the ORB interfaces using the CORBA module provided by the CORBA
implementation. For the client, little additional code is necessary to invoke operations on an arbitrary
interface. The mapping for the Dynamic Invocation Interface is currently being studied. Obviously, Python
does not require that much machinery for the DII as required in C++, since there is no need for static
typing. Instead, a client can just pass the actual parameters to the PIDL operation
create_request
.
Corba Scripting Language
11
Humboldt-Universität | CNRI
For the server-side mapping, all of the approaches found in other languages are possible for Python as
well (inheritance, delegation). The CORBA implementations that currently support Python prefer an
inheritance mechanism, where the implementation class inherits from a class defined by the IDL compiler,
implementing the operations defined for the interface. Since Python supports multiple inheritance, it is
possible to inherit both from the generated base class and from a user-defined base class. Similar to the
DII, the DSI is much simpler to use in a dynamically typed language such as Python compared to the
statically typed languages.
5 Scripting in the Context of CORBA Components
Since the CORBA component standard is not yet defined, reasoning on this standard is based on the RFP
(orbos/96-06-12). Only issues relevant to the scripting are discussed. In addition, other information relevant
for using Python as a CORBA scripting language is presented here. Because the CORBA Component
Imperatives (orbos/97-05-25) specifically addresses OLE controls and VisualBasic, an overview over the
current interworking of Python and COM/OLE is given.
5.1 Python Support for Win32 and COM
The component object model (COM) is the core model for various technologies available on Microsoft
Windows, including OLE, ActiveX Controls, and ActiveScripting. PythonWin, a port of Python to the
Microsoft Windows, exposes most of this functionality to Python scripts and applications, wrapping it in a
style familiar to the Python programmer. On different levels of the architecture, different wrapping
approaches are provided:
·

Pure COM interfaces are exposed to Python as classes, similar to the way they are exposed to C++
programmer. Since COM is defined as a binary interface, C++ glue code is provided.
·

Object Linking and Embedding (OLE) is rarely used directly. Instead, applications use some framework,
such as MFC. PythonWin includes an MFC wrapper, exposing the OLE capabilities to Python
programs.
·

ActiveX is defined as supporting both the static (binary) interface, as well as the dynamic interface
IDispatch. While originally intended to support VisualBasic, IDispatch works quite well with Python. It
can be used in Python either dynamically or statically, in which case a type library is required. Thus,
Python can be used to integrate ActiveX controls.
·

ActiveScripting is an interface allowing the integration of arbitrary scripting engines into a scripting host.
Various vendors provides scripting hosts, such as the Microsoft Internet Explorer. Since PythonWin
supports ActiveScripting, Python scripts can be executed in any scripting host.
5.2 Multiple Interfaces
CORBA components are expected to support multiple interfaces. Although it is not clear at the moment
how multiple interfaces are introduced in the CORBA, different proposals are available. As presented later
above, Python on Microsoft Windows supports the Component Object Model (COM), which also has the
concept of multiple interfaces per object. In order to navigate between interfaces, a QueryInterface
operation is provided. This operation, as well as the well-known interfaces, are exposed to the Python
programmer. As a result, it is possible to navigate between COM interfaces in the same way as it was
intended for C++. It is expected that Python can adapt to other navigation mechanisms as well.
Corba Scripting Language
12
Humboldt-Universität | CNRI
5.3 Access to Component Properties
Component properties are defined using the Component Description Facility. As a result, the description of
the properties is available both during development in the description, as well as at run-time in a repository.
Python programs can use either source to expose properties in a way convenient to the programmer. At
development time, compilers can be used to translate the description to Python code. At run time, the
repository can be queried to obtain a list of descriptions. A simple wrapper can be used to hide the access
from the developer, using the
__getattr__
and
__setattr__
methods which override the attribute
access.
5.4 Mechanisms for Serialization
Depending on the application, different approaches to serialization and externalization might be necessary.
Python provides a language-dependent mechanism called
pickle
. Using this technology, a graph of
objects referencing each other is written to a serial representation. In general, there is no need for the
application programmer to concern with the details of this representation: the algorithm will store all
attributes based on the reflective nature of Python (i.e. the availability of type and signature information at
run-time).
In some cases, the external state is defined differently, e.g. by means of invoking operations on interfaces
rather than accessing the attributes. In this case, the Python object can define a special method which then
is invoked to retrieve the external state.
In addition, the state is not necessarily written to a file in some applications. The pickling environment also
allows to specify different destinations for the external state. The combination of these options allows for a
flexible externalization of the component state.
5.5 Reception of Component Events
Although the specific details for component events are not yet defined, it is a safe assumption that they
follow the architectures of the CORBA Event Service, the emerging CORBA Messaging Service, or the
ActiveX event mechanism. That is, events are either propagated by means of an interface in the event
consumer, or can be pulled out of an interface of the event source. Since the first approach is more
convenient for the script programmer, it is most likely that component event consumers expose an
interface.
Python offers different approaches for handling events that appear at such an interface. By implementing
the operations of that interface, an application can detect all events and process them appropriately.
Alternatively, an event consumer could define methods for just those events it is interested in. The
reflective nature of Python allows the development of a base class for event consumers that detects which
events a derived class needs to receive. It can then dispatch the events to these methods appropriately.
Similar to properties, events will be described using the Component Description Facility. Again, such a
description can be used either at compile time or at run time, e.g. for registering the desired events with the
component.
5.6 Interworking with Java
The Components RFP specifies that the component model should follow the JavaBeans architecture. The
goal apparently is to allow component scripts to run in a 100% pure Java environment.
Corba Scripting Language
13
Humboldt-Universität | CNRI
Even though it is not the purpose of this proposal to investigate the usage of Java in a CORBA Scripting
environment, it should be pointed out that the 100% Java goal is not contradictory to using Python for
CORBA Scripting.
There is currently a proof-of-concept implementation of the Python Language being developed which runs
on top of the Java Virtual Machine, see <URL:http://www.python.org/jpython/>. This approach compiles
Python source code to Java byte code, and executes it using an appropriate run-time library, which is also
written in Java. As a result, this Python implementation supports 100% pure Java environments as well.
6 Compliance
6.1 Changes to Existing OMG Specifications
There are no changes to adopted OMG Specifications. It is anticipated that a future CORBA Component
Draft needs additional alignment with the specification presented here.
6.2 Proposed Compliance Points
Implementations of the CORBA Scripting Language must comply with the specification of the Python
Scripting Language as defined in the Python Reference Manual <URL: http://www.python.org/
doc/ref/ref.book.html> and the Python Library Reference <URL: http://www.python.org/doc/lib/lib.html>.
In addition, the IDL to Python mapping as defined in <URL:http://www.informatik.hu-berlin.de/~loewis/
python/pymap.doc> or a future OMG specification must be implemented.