Is Python fit for multi-tired apps?
Eike Kock
I've spent the last weeks studying Enterprise Java Beans (EJB) and J2EE. It
takes a lot of time and code to achieve very little. Features beeing
wonderful in theory just don't address complex scenarios in reality (e.g.
CMP). The incomplete specification leads to vendor specific solutions -
using them leads to vendor lock-in. Design patterns help avoid problems of
the spec (e.g. entity bean performance issues) but leaves you with apps that
can't really be called object orientated.
Disappointed with J2EE I looked for possible alternatives and found Python.
What a cool language! I did'nt expect to find a .Net or J2EE like framework
but found typical multi-tired app functionality like object distribution
mechanisms (Pyro, CORBA ORBs).
Is Python fit for multi-tired apps?
Is a pure Python framework a valid option?
Are there any larger implementations using a pure Python framework?
Thanks,
Eike
Laurent Szyster
>
> I've spent the last weeks studying Enterprise Java Beans (EJB) and
> J2EE. It takes a lot of time and code to achieve very little.
> Features beeing wonderful in theory just don't address complex
> scenarios in reality (e.g. CMP). The incomplete specification leads
> to vendor specific solutions - using them leads to vendor lock-in.
> Design patterns help avoid problems of the spec (e.g. entity bean
> performance issues) but leaves you with apps that can't really be
> called object orientated.
I've had the same experience. What's even worse is that Java
application servers require huge ressources.
> Disappointed with J2EE I looked for possible alternatives and found
> Python. What a cool language! I did'nt expect to find a .Net or J2EE
> like framework but found typical multi-tired app functionality like
> object distribution mechanisms (Pyro, CORBA ORBs).
>
> Is Python fit for multi-tired apps?
yes.
> Is a pure Python framework a valid option?
yes.
> Are there any larger implementations using a pure Python framework?
yes. Zope is a Python CMF to build web sites. Then , there's Webware
for entreprise application server.
Laurent Szyster
Andrew Kuchling
> Is Python fit for multi-tired apps?
> Is a pure Python framework a valid option?
> Are there any larger implementations using a pure Python framework?
I recently announced an article describing a pure Python system
(http://www.amk.ca/python/writing/mx-architecture/), though I wouldn't
call the system or database large, as such things go.
The pieces for assembling Python-based business applications are all
there -- ZODB, relational database support, Web application servers --
but they're not packaged or documented together. It would make an
interesting project for someone.
--amk
bru...@tbye.com
On Tue, 18 Sep 2001, Eike Kock wrote:
> Is Python fit for multi-tired apps?
Yes, especially as an alternative to Java! The resource requirements for a
good Java-based tier can be staggering, and in my experience Java
middleware scales poorly.
A company I'm working with is doing a large portion of their multi-tiered
app in Python and so far it's going wonderfully well. One thing I really
like is that in Python it's trivial to do custom IPC (i.e. - your own
private protocol) for communicating between different machines, but
there's also modules to support just about every industry standard
mechanism as well.
> Is a pure Python framework a valid option?
Also yes, although how you'd approach this depends heavily on your
specific requirements. For performance the general consenus is that you
can protoype in Python and then rewrite some components in a lower-level
language if needed, but in many, many cases you'll find that you never
need to do that. For example, your database machine will spend most of its
time in the database itself, so the language you use to access the
database is largely irrelevent, as far as speed goes. As another example,
we made an HTTP proxy server that we assumed we'd later rewrite in C.
After a little performance tuning we're maintaining throughput of several
hundred Mbps, so it doesn't look like we'll need to rewrite it.
Also, if for some reason you can't use 100% Python, that's no
reason to rule out using Python elsewhere. Python is a really nice "glue"
language. For example, in this same company I'm working with they have
some legacy Java servlets that they don't want to abandon yet. One of the
libraries I was working on had a client and server half, both in Python,
and the Java servlets needed to communicate with the server. Rather than
writing a Java version of the client side, I just used Jython to package
up the Python version of the client into a jar file. Now the Java
programmers are using the Python code without even realizing it. Elsewhere
we have Python code calling legacy shell and Perl scripts as well. It's
all stuff that we could easily do in Python but since it's already
written, and it already works, and because it's so easy to call them from
Python anyway, we just went ahead and used them as is.
-Dave
Graham Dumpleton
>
> Disappointed with J2EE I looked for possible alternatives and found Python.
> What a cool language! I did'nt expect to find a .Net or J2EE like framework
> but found typical multi-tired app functionality like object distribution
> mechanisms (Pyro, CORBA ORBs).
You might also look at OSE. OSE is actually C++ at its core but with a Python
interface. OSE contains a distributed messaging system with request/reply and
publish/subscribe interfaces exposed by the Python API. It also includes a
distributed service registry allowing you to know what other service components
exist in the system etc. Because C++ is used in the core, you can combine
services written in either Python or C++ into the one distributed application
or even the same process. In some respects, the features of OSE as exposed
through the Python API can be likened to a simpler distributed Java bean
framework. As to interaction with the system, there is a HTTP servlet framework
and interfaces for RPC over HTTP protocols such as XML-RPC and SOAP.
OSE can be found at "http://ose.sourceforge.net". The documentation for the
Python interfaces is more up to date than that for the C++ components, so if
you look through that it will give you the best idea of what the system can do.
Aahz Maruch
I dunno. You'd have to ask Firestone about that.
[In case anyone is missing the joke, it's "multi-tiered".]
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
We must not let the evil of a few trample the freedoms of the many.
Steven Shaw
As I understand it, OSE cannot be used with proprietary applications.
Probably something that needs mentioning up front when you are
promoting it.
Eike Kock
I looked at Zope, Webware, OSE, MEMS, ... . Webware looks interesting but
still has some way to go. Dispite of all the drawbacks I stated earlier I'm
going for J2EE now. Not coding it directly though but using a program
written in Python to generate the code (coding EJBs with all the suggested
design patterns by hand is not really an option).
Python is a wonderful language. What I miss is a framework for building
scaleable enterprise systems (multi-tiered, transparent object distribution,
transaction monitoring, clustering, ...). If we could build such a system
and make it easy to understand and use, I'm sure Python would be "king of
the hill" (see thread "Why isn't Python king of the hill?" in
comp.lang.python).
Eike
François Pinard
> [...] scaleable enterprise systems (multi-tiered [...]
Hi. Would someone be kind enough for presenting to me what `tiered' means?
I never read that word, before the recent threads about it. What is it?
--
François Pinard http://www.iro.umontreal.ca/~pinard
Steve Holden
client/server. Typically the client was the desktop machine, which handled
the GUI and usually most of the process logic and some of the application
logic. The client would communicate across the network to a server, which
would handle the remainder of the application logic and all the data
management tasks.
Conceptually, applications therefore have four components:
Presentation (user interface) logic
Process logic
Application logic ("business rules")
Data Management
Nowadays the logic can be distributed between more than two machines, so you
might see the GUI running on the desktop along with the process logic, the
business rules being enforced by a "middle tier" server, and the data
management handled by an enterprise RDBMS. This is the "classic" three-tier
structure.
Another three-tier example is when a browser (presentation layer) is used to
drive a web server (process logic, application logic) which transacts
against an RDBMS (data management).
The advantage of these architectures is that you can centralise or
distribute the business rules as you see fit, but that you don't have to do
what traditional C/S applications did, which was to include business rule
handling on the desktop. This became a maintenance nightmare for large
organizations with hundreds or thousands of desktops: when the business
rules changed, new client software had to be rolled out to all the desktops.
regards
Steve
--
http://www.holdenweb.com/
"François Pinard" <pin...@iro.umontreal.ca> wrote in message
news:mailman.1001606015...@python.org...
Ian Parker
Holden <sho...@holdenweb.com> writes
...
>
>The advantage of these architectures is that you can centralise or
>distribute the business rules as you see fit, but that you don't have to do
>what traditional C/S applications did, which was to include business rule
>handling on the desktop. This became a maintenance nightmare for large
>organizations with hundreds or thousands of desktops: when the business
>rules changed, new client software had to be rolled out to all the desktops.
>
>regards
> Steve
>--
>http://www.holdenweb.com/
>
A maintenance nightmare indeed. Almost makes you wish for the return of
the mainframe doesn't it.
One of our trading systems is comprised of 50 servers (plus the user's
workstations). It's arguably 4-tier: desktop, application servers,
data distribution servers and exchange line handlers. Hard to manage,
hard to debug, and with all those pesky network delays to slow things
down.
--
Ian Parker
Graham Dumpleton
> gra...@dscpl.com.au (Graham Dumpleton) wrote in message news:<dc6f5c99.01091...@posting.google.com>...
> > Python interfaces is more up to date than that for the C++ components, so if
> > you look through that it will give you the best idea of what the system can do.
>
> As I understand it, OSE cannot be used with proprietary applications.
> Probably something that needs mentioning up front when you are
> promoting it.
What you say isn't strictly true. OSE uses the Q Public License (QPL), an
Open Source license, which if you read it properly can be used in proprietary
applications provided that you aren't distributing that application in which
case you would need to provide your source code for free.
Thus, you can quite happily develop in house applications for a company no
problems. In the majority of cases companies never want to distribute their
applications anyway, so use of the QPL is therefore not a problem. On the web
site there is a reasonably in depth discussion of the licensing issues
surrounding the use of OSE in a commercial environment. Utimately though,
you still need to read the license to understand it.
Further, an alternate license agreement can also be purchased which is alluded
to on the site with an email address for details given. More precise details
of the latter are being prepared for inclusion on another site. At the moment
it isn't seen that such information should be on SourceForge.
In other words, if you want to build an application and make a profit from it,
but expect not have to pay for anything you use, then you will be dissappointed.
If however you are an Open Source proponent you should not have a problem since
the QPL is an approved Open Source license, it just doesn't give you absolute
carte blanche like some other Open Source licenses.
Would you be happier if OSE were instead released under the GPL, which in
some respects is even worse for business in respect of building proprietary
applications. And no I don't in general support Microsoft's views with regard
to Open Source, but I am sure I am likely to get flamed for this comment
anyway.
Graham Dumpleton
> > Python interfaces is more up to date than that for the C++ components, so if
> > you look through that it will give you the best idea of what the system can do.
>
> As I understand it, OSE cannot be used with proprietary applications.
> Probably something that needs mentioning up front when you are
> promoting it.
I have pushed onto the web site updated versions of some material which
I had ready as part of a bigger release which is pending, which highlights
a little better the options you have with respect to developing proprietary
software. The fact still remains though, that the QPL is no different than
the GPL in respect of restricting your ablity to develop proprietary software
in as much as that both require you to make your source code available for
free if your application is distributed. I don't however see calls being made
for every person who releases a package under the GPL to fore warn people
that you will not be able to develop closed source proprietary applications.
Thus I find a call to add such a warning strange at best.
I actually go to a fair bit of effort on the web site to describe the
implications of the QPL being applied to OSE. This is because in the past
OSE was available under a different license which didn't qualify as an
Open Source license. As OSE has a fair number of corporate users it was
thus important to indicate what the differences were so they knew if they
could still use it without getting a separate license. To my knowledge,
there are few if any other Open Source package which have been released with
any sort of description of the implications to developers of proprietary
applications of using the software. One can speculate that since these
issues aren't discussed that many companies don't bother investigating it
and thus go and use the software anyway, in violation of any license
agreement. Thus perhaps I should drop any discussion of the issues and I
might at least get more users adopting the software even if the way they
use the software isn't legal. :-)
Anyway, I was damned when the software wasn't released as Open Source
and now I am damned because it is. One can't win. :-(
Markus Schaber
Graham Dumpleton <gra...@dscpl.com.au> schrub:
> steve...@users.sourceforge.net (Steven Shaw) wrote in message
> news:<503ca784.01092...@posting.google.com>...
>> gra...@dscpl.com.au (Graham Dumpleton) wrote in message
>> news:<dc6f5c99.01091...@posting.google.com>...
>> > OSE can be found at "http://ose.sourceforge.net". The documentation
>> > for the Python interfaces is more up to date than that for the C++
>> > components, so if you look through that it will give you the best
>> > idea of what the system can do.
>>
>> As I understand it, OSE cannot be used with proprietary applications.
>> Probably something that needs mentioning up front when you are
>> promoting it.
>
> What you say isn't strictly true. OSE uses the Q Public License (QPL),
> an Open Source license, which if you read it properly can be used in
> proprietary applications provided that you aren't distributing that
> application in which case you would need to provide your source code
> for free.
The same applies to the GPL, as far as I remember.
You have to provide the source code to those people who get the binary.
So for in-house use or willing customers, nobody else gets the source.
Whenever a community wants to have something "for internal use" only,
nobody can force them to give GPL'ed products to the outer world, thus
making it "practically" closed source.
There's only one advantage to commercial licenses: Every user also gets
the right to access the source, and so is independent of the vendor
whenever the vendor decides not to support the product any more. (But
even this is limited to three years according to 3) b) in GPL 2)
Note: This should _not_ be an argument to make you use the GPL, simply
a description of a fact that lots of Open Source fanatics don't know
(or ignore).
markus
--
"The strength of the Constitution lies entirely in the determination of
each citizen to defend it. Only if every single citizen feels duty
bound to do his share in this defense are the constitutional rights
secure." -- Albert Einstein