- Information Sources
- Web Server Architectures
- HTML (and XML) Generation
- Component Interaction: Choose Your Model
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Component Interaction: Choose Your Model
Finally, you should consider how the various components of your web framework are going to interact. Some frameworks, such as Webware and Xitami, include facilities for interaction between their components. You can always use socket programming for such interactions, but this has two potential disadvantages. The first is simply the amount of programming required, and the second is the lack of generality.
If your components need to communicate with others, there are two systems in general use that are designed to facilitate such interactions, and another two newer ones that focus on the use of a combination of XML and HTTP. Because they are all complex, it is only possible to give the briefest of outline to close this chapter.
The Common Object Request Broker Architecture (CORBA)
CORBA is a heterogeneous system for locating and using services in a networked environment. It is an open standard maintained by the Object Management Group (OMG), whose web site (http://www.omg.org) prominently features CORBA. The site also describes UML, the Unified Modeling Language used to describe services, and CWM, the Common Warehouse MetaModel, which describes complex data structures for interchange between structured repositories. These last two topics are not considered here.
You describe a CORBA service interface in the OMG Interface Definition Language (IDL). This allows you to specify the data to be passed between objects in a platform-independent manner. Python CORBA interfaces can parse IDL to allow CORBA-mediated interactions between arbitrary system components using the features of Xerox PARC's ILU project, for which Python provides the reference implementation. For a full description see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html. ILU is a free, CORBA-compliant, object request broker (ORB) that supplies distributed object connectivity to myriad platforms using a variety of programming languages.
The CORBA architecture is designed to allow clients and servers of particular services to locate each other on the Net and interact by means of what CORBA calls transactions. These are simply programmed interactions rather than the database transactions discussed in earlier chapters.
Microsoft's Distributed Common Object Model (DCOM)
Mark Hammond, Greg Stein, and others have interfaced Python to Microsoft's COM, Distributed COM, and ActiveX architectures. This means, among other things, that you can use Python in ASP or as a COM controller (for example, to automatically extract from or insert information into Excel, Access, or any other COM-aware application). Python can even be an Active Scripting host (which means you could embed JScript inside a Python application, if you had a strange sense of humor).
Python support for many Microsoft Foundation Classes (MFC), COM, DCOM, and Active Scripting is integrated into the ActivePython distribution available from http://www.activestate.com. You can also download the win32all extension package separately if you already have Python installed on your Windows computer.
The major disadvantage of DCOM when compared with CORBA is its restriction to Microsoft-supported environments. DCOM is not an open system because Microsoft controls the standards. This might not matter if you work exclusively with Windows anyway. There has been some work to bridge the CORBA and DCOM worlds using IIOP, the Internet Inter-ORB Protocol, but this has not so far led to massive integration between the Microsoft world and everything else.
DCOM has also proved to be difficult to scale to larger systems without explicit use of MTS. Although this is an acceptable overhead for large-scale projects, it appears to require disproportionate effort for small- and medium-sized developments. A good description of DCOM technology, along with many examples of how Python can be integrated into the DCOM environment, is available in Programming Python on Win32 (Mark Hammond and Andy Robinson, O'Reilly).
XML-Based Interactions
Various communication schemes are current that use XML to encode remote requests and responses between system components, the two best known being XML-RPC and SOAP. SOAP is of interest to web developers because it uses HTTP as the request/response transmission protocol and so is available wherever web services can operate. Microsoft has built its BizTalk services around SOAP, carving out an early market share in distributed services. The XML-RPC camp promotes technologies that allow a similar style of interactions, with all data interchanged using XML.
It will be interesting to see whether BizTalk is operated as a closed framework: if third parties do not run BizTalk servers, then even Microsoft may not be able to provide a large enough infrastructure to win out over an open systems protocol. SOAP itself is receiving broad support across the industry, by companies as large as IBM, so its future seems assured independently of BizTalk.
One of the "features" used to promote SOAP and similar techniques is that it uses HTTP, which corporate firewalls already accommodate. What this really means, however, is that any server that can be accessed for web services can also be accessed for remote procedure calls after it becomes SOAP-capable. This would seem to be a somewhat specious argument in favor of SOAP because opening firewalls to other RPC protocols like IIOP would only involve substantially the same risks. Whether the managers of corporate firewalls will want to allow SOAP traffic to continue to pass unhindered after they appreciate its implications remains to be seen.