See All Titles |
![]() ![]() Distributing Objects with PythonThere are some other packages that enable you to talk to other programs on platforms without COM support. As for the object distribution models, Python has many projects currently being developed. The Inter-Language Unification system (ILU) is a free and stable multi-language object interface system. The Object Request Broker is the mechanism that lets objects transparently make requests to—and receive from—other objects located locally or remotely. The ORB component is also commonly referred to as CORBA, which stands for Common Object Request Broker Architecture. omniORBpy is an almost complete implementation of the current Python CORBA mapping. Fnorb is an Object Request Broker (ORB) that is compliant with the CORBA 2.0 specification from the Object Management Group (OMG). Fnorb implements a single language mapping from OMG IDL to Python. This implementation is excellent for those who want to learn CORBA. Another project worth mentioning is the ORBit-python project, which a binding for ORBit, the CORBA orb used by GNOME and some other projects. DCOM is the COM technology that distributes objects between different machines on the network. It defines a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. The Object Management Facility (OMF) is an object-oriented middleware environment for the process automation area. Even though it doesn't contain any Python code, it is heavily tested using Python scripts. The object model used by OMF is similar to other distributed object systems, such as OMG's CORBA and Xerox's ILU. OMF is implemented in C++, with APIs for other languages, including Python. It is said that the Python API was primarily created for writing test programs, but it has since been used to write various tools for application development and runtime management. Hector is a distributed object system developed at the University of Queensland, Australia. It is written almost entirely in Python. Hector attempts to provide application objects with a consistent environment, regardless of their physical location, through a series of transparencies. Inter-Language Unification (ILU)The Inter-Language Unification system (ILU) is a free and stable multi-language object interface system, whose interfaces hide implementation distinctions between different languages, address spaces, and operating system types. ILU can be used to build multilingual, object-oriented class libraries with well-specified, language-independent interfaces. It can also be used to implement distributed systems and to define and document interfaces between the modules of nondistributed programs. ILU interfaces can be specified in either the OMG's CORBA Interface Definition Language (OMG IDL) or ILU's Interface Specification Language (ISL). ILU is primarily about interfaces between modules of program structure. Each module encapsulates the part of a program that has high adhesion internally and low connection to other parts of the program. The main goal of ILU is to create object-oriented interfaces that can communicate with those modules. ILU does all the translating and communicating necessary to use all kinds of modules in a single program. Its mechanism optimizes calls across module interfaces to involve only what it is necessary for the calling and called modules to interact. The notion of a module should not be confused with the independent concept of a program instance, which is translated as a combination of code and data running in one memory image, such as the UNIX processes. ILU standardizes many of the issues involved in providing proper inter-module independence, such as memory management and error detection and recovery strategies. ILU also includes an implementation of the Object Management Group's CORBA Internet Inter-Orb Protocol (IIOP), and can be used to write CORBA services or clients, as well. ILU provides a standard notation to write its interfaces—ISL, which stands for Interface Specification Language. ISL is a declarative language, which can be processed by computer programs that enables you to define exceptions, constants, object and non-object types. Next, you have a sample of what ISL looks like: INTERFACE CalcMachine; EXCEPTION DivideByZero; TYPE Calculator = OBJECT METHODS SetValue (v : REAL), GetValue () : REAL, Divide (v : REAL) RAISES DivideByZero END END; ILU provides a program, islscan, which can be used to check the syntax of an ISL specification, parse the specification, and summarize it to standard output. After you've defined an interface, you then need to supply an implementation of your module, which can be done in any language supported by ILU. The program python-stubber is used to read an ISL file, and generate all the Python code that is required to support the ISL interface. One of the files generated is 'Interface.py', which contains the definitions of all the Python types for that interface: % python-stubber CalcMachine.isl client stubs for interface "CalcMachine" to CalcMachine.py … server stubs for interface " CalcMachine " to CalcMachine__skel.py … % To provide an implementation of your interface, subclass the generated Python class for the Calculator class: # CalculatorImpl.py import CalcMachine, CalcMachine__skel class Calculator (CalcMachine__skel.Calculator): def __init__ (self): self.value = 0.0 def SetValue (self, value): self.value = value def GetValue (self): return self.value def Divide (self, value): try: self.value = self.value / value except ZeroDivisionError: raise CalcMachine.DivideByZero Each instance of a CalculatorImpl.Calculator object inherits from CalcMachine__skel.Calculator, which in turn inherits from CalcMachine.Calculator. Each has an instance variable called value, which maintains a running total of the accumulator for that instance. We can create an instance of a CalcMachine.Calculator object by simply calling CalculatorImpl.Calculator(). A very simple program to demonstrate the use of the CalcMachine module is listed next. To run this program, you have to type the command python divide.py <NUMBER_TO_DIVIDE>. # File: divide.py import CalcMachine, CalculatorImpl, sys, string def main (argv): calc = CalculatorImpl.Calculator() if not calc: error("Error creating the calculator") calc.SetValue (10.0) divisor = string.atof(argv[1]) calc.Divide(divisor) print "the division result is", calc.GetValue() sys.exit(0) main(sys.argv) This program would be compiled and run as follows: % python divide.py 5.0 the division result is 2.0 % ILU also supports the use of the interface definition language OMG IDL, defined by the Object Management Group (OMG) for its Common Object Request Broker Architecture (CORBA). That kind of support allows more programmers to easily use ILU because OMG's IDL uses a syntax similar to C++. However, because CORBA doesn't implement some of the concepts found in ILU, programmers can't implement all types of ILU interface using OMG IDL. ILU is available for free at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html Using ILU with Python: A Tutorial ftp://parcftp.parc.xerox.com/pub/ilu/misc/tutpython.html CORBA Binding and ImplementationThe Object Request Broker (ORB) is the mechanism that lets objects transparently make requests to—and receive from—other objects located locally or remotely. The ORB is the middleware that establishes the client/server relationship between objects. Using an ORB, a client object can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. The client is not aware of the mechanisms used to communicate with, activate, or store the server objects. The ORB serves as the foundation for building distributed object applications. Note that CORBA can short circuit requests to objects in the same address space, as ILU and COM can, if the implementation supports this. The ORB component, or CORBA, is a set of specifications defining the ways software objects should work together in a distributed environment. The organization that drives the specifications, the Object Management Group (OMG), has hundreds of members representing a major portion of the software industry. The members work together to propose, review, and finally adopt a set of specifications to enable software objects to be developed independently and yet work together in a harmonic fashion. The fundamental piece of CORBA is the ORB, or Object Request Broker. The ORB can be viewed like a channel carrying objects between the clients (those that consume the objects) and the servers (those that produce the objects). The consumers are provided with object interfaces, which are defined using a language called the Interface Definition Language. The detailed implementation of the objects by the producers is totally shielded from the consumers. The ORB is usually just a library that the program links to that marshals object requests. The promised benefits of making the software objects from different vendors publicly known made those vendors highly endorse OMG's specifications. At the most basic level, CORBA is a standard for distributed objects. CORBA enables an application to request that an operation be performed by a distributed object and that the results of the operation be returned to the application making the request. The application communicates with the distributed object performing the operation. This is basic client/server functionality, in which a client issues a request to a server, and the server responds to the client. Data can pass from the client to the server and is associated with a particular operation on a particular object. Data is then returned to the client in the form of a response. Note that just like COM/DCOM, CORBA can be used to access objects that are local to the process, machine, or non-local. DCOM is a Microsoft-specific distribution solution, whereas CORBA products are available from more than 20 different vendors, and they support Microsoft and non-Microsoft operating systems. CORBA is an excellent mechanism to bridge between Microsoft desktops and UNIX servers. There is no explicit need to choose between DCOM and CORBA. Distributed applications can be developed using both CORBA and DCOM. For example, a client application might be developed to access a set of OLE automation objects, and OLE automation objects might in turn access CORBA Objects running on a non-Microsoft platform such a UNIX. The OMG has defined a COM/CORBA interworking specification that standardizes this sort of bridging. Note
Python can be used to create wrappers between COM and CORBA systems. CORBA is more mature than DCOM; it has existed since 1990, and commercial implementations have been available since 1992. DCOM wasn't available in beta form until 1996. Also, a large number of different companies have developed CORBA ORBs. This level of competition increases the robustness of CORBA solutions on the whole. It also ensures compatibility—a vendor's CORBA ORB is of much greater value if it can talk to a competitor's ORBs. One of the advantages of DCOM over CORBA is the fact that DCOM is well suited to front-end application development. If entire distributed application runs under Microsoft platforms, DCOM might be a good choice. DCOM can also be used with CORBA. Of course, using DCOM will lock you into Win32 in the future, which might not be a good thing even if you are using Win32 at the moment. The CORBA distributed object system is becoming an important standard in developing industrial-strength client/server and Web applications. It is also used as an IPC layer between a number of components in both the Gnome and KDE desktop environments for UNIX. In the current development phase of the CORBA binding for Python, the OMG board of directors has adopted the specification, and the finalization task force has completed its report. After approval, this report will become an available specification. omniORBpy is an almost complete implementation of the current Python/CORBA mapping. It is currently in beta, but is very stable. More information about the omniOrbpy interface, which is provided by omniORB, can be found at http://www.uk.research.att.com/omniORB/omniORB.html Other interesting links for you include
FnorbFnorb is written in Python and its framework supports only Python. The implementation provided by this object-model helps you to learn more about CORBA systems. Fnorb is an object request broker (ORB) compliant with the CORBA 2.0 specification from the Object Management Group (OMG). Fnorb implements a single language mapping from OMG IDL to Python. Because of the interpreted and interactive nature of Python, and the simplicity of the mapping (as compared to mappings with C++ and Java), Fnorb is ideally suited as a tool for the rapid prototyping, testing, and scripting of CORBA systems and architectures. The pair Python/Fnorb is ideal for prototyping complex CORBA architectures, for using as a scripting tool, and for building test harnesses for all your CORBA development projects. The combination of Python and Fnorb provides the existing CORBA community with a much needed tool for rapid prototyping and scripting, and gives those new to CORBA a great way to learn the fundamental concepts without being swamped by the intricacies of a "heavyweight" language mapping. Like ILU from Xerox PARC, Fnorb gives the Python programmer access to the wonderful world of CORBA. It supports all CORBA 2.0 data types (including Any's) and provides a full implementation of IIOP. Unlike ILU, Fnorb is Python and CORBA/IDL-specific, which makes it simple, lightweight, and easy to install and use. Using Fnorb, you no longer have to use other languages to write CORBA clients and servers—you can use Python now. This makes Fnorb ideal for prototyping complex CORBA architectures, for use as a scripting tool, and for building test harnesses for all your CORBA development projects. The Python language mapping used by Fnorb is based on a specification document being prepared by members of the DO-SIG (Distributed Objects - Special Interest Group). One goal of Fnorb is to enable the Python community to experiment with the mapping before attempting to set it in stone via the OMG standardization process. Fnorb is being developed at the CRC for Distributed Systems Technology based at the University of Queensland in Brisbane, Australia. Fnorb is released under a free for non-commercial use license. Another license must be acquired to use it commercially.
DCOMDCOM is Microsoft's way of distributing objects between different machines on the network. DCOM, or Distributed Common Object Model, defines the specifications that an object must obey to interoperate with other objects using Microsoft distributing architecture. The core of DCOM is the Common Object Model, defined and refined from the earlier Object Link and Embedding implementation. Started naively as a way to enable documents to be embedded or linked into another document, OLE has completely reinvented itself. The Common Object Model (COM) lays the foundation for objects to gain knowledge about, and to make use of, each other; thus they can engage in so-called component-based computing. DCOM extends the capability to include the constituent objects on other machines connected through the network. The Distributed Common Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. Previously called Network OLE, DCOM is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the (COM). DCOM enables objects to be remote from their caller, and it handles all marshalling across machines and necessary security. Configuration tools enable an administrator to configure objects so that neither the object nor the caller needs any changes. The following Microsoft article takes you to the download page of the DCOM configuration tool (dcomcnfg.exe), which was not included on the Windows 98 2nd Edition CD: http://support.microsoft.com/support/kb/articles/Q253/3/11.ASP Sometimes, code changes can be used to explicitly control the source of objects. OMFObject Management Facility (OMF) is an object-oriented middleware environment for the process automation area. It is used as the middleware foundation for several ABB [the ABB Industrial Systems AB (Sweden)] control system applications. Although it doesn't contain any Python code, it is heavily tested using Python scripts. OMF includes the all-important features of an object request broker. A type definition language defines the interface and provides mappings to multiple programming languages. Objects can be distributed transparently on heterogeneous platforms. Furthermore, services for naming, type management, messaging, and persistence are available. OMF contains features particularly for real-time distributed control, such as high-speed communication, asynchronous messaging, message prioritization, and support for different bus protocols. OMF is a distributed object system specifically designed for the process control industry. The object model is similar to other distributed object systems, such as OMG's CORBA and Xerox's ILU. What makes OMF different from these is its interaction model. The OMF interaction model specifies that, after finding a set of objects, OMF has to select what methods to call (for each object) and what attributes to get or set. It also has to choose when to perform the operation (at request, at event, periodically). After all this is done, OMF sends a single request for all objects. OMF is implemented in C++, with APIs for other languages, including Python. Created for writing test programs, Python API has since then been used to write various tools (testing tools, development tools, and maintenance tools) to aid in application development and runtime management. The OMF API for Python is implemented in two layers: The lower layer is written using a slightly modified version of Jack Jensen's modulator tool, whereas the higher layer is completely written in Python. On top of this API there are a few utility classes, such as the OMF agent, in which the agent lets the user treat OMF objects as local Python objects with attributes and methods, as follows: from OMFagent import Agent # Connect to an object in the network ai = Agent('AI1.1') # Get the Analog Input's value # This will actually result in an RPC value = ai.VALUE The Agent code is surprisingly small, but results in a drastically higher abstraction layer than the bare OMF API. This is a rather simple class because of Python's dynamic typing.
HectorHector is a distributed object system written almost entirely in Python, taking advantage of the language's many features. This specification provides a communication transparency layer enabling negotiation of communication protocol qualities, comprehensive support services for application objects, and novel interaction architecture. Its framework sits above other distributed environments, providing open negotiation and interoperability of communication protocols, high level description of component services and their requirements, a rich set of support services for objects and an interaction framework which enables the description of workflow-like interactions between autonomous objects. Hector attempts to provide application objects with a consistent environment, regardless of their physical location, through a series of transparencies. Designed with the goal of supporting a dynamic, global system of distributed objects, it embraces diversity through extensibility. Specifically, it supports the following features while maintaining transparent usage of object services:
Hector is structured as four layered components representing decreasing levels of abstraction. These layers are the Object, Language, Encapsulation (or Kernel), and Communication layers. The initial language layer supports Python. Python Language Binding is available by default because the visible kernel classes are actually written in Python, making the wrapper classes very simple.
|
© 2002, O'Reilly & Associates, Inc. |