Zope vs. Microsoft Dev Days 99 - mini-report
Yesterday I attended an all-day Microsoft Windows 2000 ra-ra event called Developer Days 99. It was pretty much what I expected, though there were some useful ideas/concepts that might be applicable to Zope. The track I attended focused on COM/OLE and XML. 1. In Windows 2000, MS has extended the concept of web-server load balancing to include COM object load balancing. You can combine multiple Windows 2000 machines into a COM "pool". When creating a business COM object, the pool manager creates the object on the first available/least loaded system. On the backend, multiple machines are running SQL 7 in a distributed manner. This gives a three tear approach (actually 4 if you count the client). Note that Microsoft encourages developers to encapsulate the business logic of an app into a COM component. This allows the component to be used by WIn32 apps, and by ASP web pages. The web pages only serve to present the data, they don't handle any of the logic: a. multiple web servers load-balanced by the router, each server runs IIS 5 with ASP b. multiple "business logic" COM servers instantiating objects to process requests made by the ASP pages c. multiple back-end SQL servers handling requests from the COM servers. Of course all of these layers could run on one physical machine, but Windows 2000 is supposed to make it easier to split up the processing if you want to. How does this apply to Zope? DC has a commercial product which I think applies to multiple web servers talking to a single ODB3, but I'm not sure exactly how that works. Since DTML methods/documents are not really Objects, I can't see a direct correlation with the "business logic" server aspect. However, the idea of seperating "business logic" from "presentation" sounds good. Presumably Python methods represent "business logic" and dtml methods are the presentation layer. Making it easier to use "external procedures" might be a big win (no flames on PythonMethods vs. External Methods, ok). 2. Tracking Session state for web users. By session, I mean remembering what the user has selected/set as properties between web requests. The example they used was a purchase order application. When adding a line item to a PO, the current PO number was saved as a session variable. Although not specific to Windows 2000, one technique they demonstrated seemed interesting. Variables or properties specific to a given session were packaged up into a COM Stream object (think of it as a pickled dict) and saved to an SQL server. Later requests used a cookie to retrieve the associated session information from the SQL server, unpack it and use the saved properties. Going back to item 1 above, using a back-end SQL database was the only way to save session properties because multiple web servers were handling the web requests. Hence the only common location for all of the servers was the back-end SQL. How does this apply to Zope? Someone could create a package that allows for quick and easy storage of session properties to a backend DB (perhaps using a DB Connection of some kind). Session retrieval could be via cookie, or using the URL insert method mentioned previously on this list. Using an external DB makes it easy to support multiple web servers (if they use the same backend database) for load balancing. A non- transactional ZODB3 would also be useful, but perhaps not available for load-balancing.. There are two ways I can think of to use such a product. <dtml-with>, which is explicit, or implicitely pushing the session dict into the namespace stack. The question of which comes first, REQUEST, or session dict, would be important. Another other issue is how to clean out old session objects from the database using ZCron.. Thoughts? 3. XML and OLE DB ADO 2.5 (apparently only available with Windows 2000 they said) can now export and import XML. They demonstrated using MS's XMLDOM component in conjunction with an ADO recordset (the result of a select). The ADO recordset now has a GetText and PutText function which exports/imports XML. By passing an XSL sheet to the XMLDOM component, the ADO XML output could be massaged for the target client. For example, IE5 clients got pretty much the raw XML, whereas non-XML capable clients got basic HTML. I haven't looked at the Zope XMLDocument, but ADO's built-in support of XML to represent data sets seems compelling. For example, could a ZClass property sheet have a GetXML or PutXML feature? Would that make sense? ZODB knows how to pickle objects and restore them. Seems to me that ZODB might also be able to represent python objects in XML. I'm not sure how this would be useful, but you could imagine creating a python class that consists of just data members, and being able to easily get it as XML. I think the dtml record feature addresses this for HTML.. Without data type information, XML'd python classes will be tough... 4. Finally I saw something interesting for Zope. IIS 5 has two new features. Server.Execute, and Server.Transfer The first, Server.Execute, allows an ASP script to be called "as a subroutine". We have this now with Zope, its very easy.. <dtml-var ...> The second, Server.Transfer, allows an ASP script to pass control to another script on the same server without using a redirect. This one seems interesting and the idea might be applicable to Zope. Basically it performs the same action as RESPONSE.redirect(), but does not send the redirect to the client. This is useful when you want to render a different page after processing a form, for example, but want the rendering of the second page to look like a new request from the user, without forcing the client to actually perform the redirect. This improves the response time for the client. I looked at HTTPResponse, and it looks like redirect() really sends the redirect back to the client. I didn't see an obvious function, like localredirect()... Perhaps using the new RETURN tag would work, but I don't think that starts a new transaction. You could imagine an "add" form that updates a database, then wants to redisplay the master detail page. If the "add" form redirects the client to the master detail page using something like the return tag, if the master detail page generates an exception, the add will be rolled back because its part of the same transaction. Right? I think a function like RESPONSE.localredirect() would be handy. It would accept URLs that only reference the local server. Internally it would complete the current transaction, then "fake up" a new request from the client to the new URL, as if the client had actually requested the new URL. Of course, RESPONSE.redirect() could be made smarter, such that it would automatically do this for local URLs, but perhaps need an option to force a client-side redirect if desired. Thoughts? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
On Thu, 16 Sep 1999, Brad Clements wrote:
4. Finally I saw something interesting for Zope.
IIS 5 has two new features.
Server.Execute, and Server.Transfer
The first, Server.Execute, allows an ASP script to be called "as a subroutine". We have this now with Zope, its very easy.. <dtml-var ...>
The second, Server.Transfer, allows an ASP script to pass control to another script on the same server without using a redirect. Try <dtml-return script> Perhaps using the new RETURN tag would work, but I don't think that starts a new transaction. You could imagine an "add" form that updates a database, then wants to redisplay the master detail page. Well, you can always commit an transaction early.
If the "add" form redirects the client to the master detail page using something like the return tag, if the master detail page generates an exception, the add will be rolled back because its part of the same transaction. Right? Well, perhaps this is right? I mean, if you have a broken web app, perhaps you should not use it in a production environment. Consider that many users will submit the data multiple times. Much fun sorting that out.
Additionally, there is a <dtml-try> construct already here ;)
I think a function like RESPONSE.localredirect() would be handy. It would accept URLs that only reference the local server. Internally it would complete the current transaction, then "fake up" a new request from the client to the new URL, as if the client had actually requested the new URL. Well, to be completely correct, it would have to emulate cookie behaviour of the client. Bad. How should the server know if the cookie will get accepted or rejected?
Thoughts? Well, redirecting locally is well enough supported with ZOPE ;)
Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
On Thu, 16 Sep 1999 14:41:53 -0400, you wrote:
Note that Microsoft encourages developers to encapsulate the business logic of an app into a COM component.
This allows the component to be used by WIn32 apps, and by ASP web pages.
The COM component could also be used by Zope external methods in exactly the same way as from ASP. This approach does have some appeal if those other win32 clients are important to you. Toby Dickenson
participants (4)
-
Andreas Kostyrka -
Brad Clements -
Magnus Heino -
Toby Dickenson