[This was posted 3 days ago from another network site, but never appeared, so is
being re-posted]
My company is building a 3-tier architecuture. The business component tier is
built with Java and C++ (through JNI), and the client tier is pure java working
with RMI to support stateless connections to the servers.
I've been wondering this week if I might dramatically cut the cost of the
project by hosting the business component server layer in lisp,
using Franz and Allegrostore. Assuming that works (I'm inquiring with Franz now
for more Allegrostore information), the real question is how to web-enable my
solutions to the business logic servier tier.
One thing which comes to mind is CL-HTTP. I know little about it, and I'm just
looking for ideas. I need relatively fully functional client access to some
solutions, so that they can post files and do all those things which are
typically problematic for browsers. I'm willing to write any html or java code
necessary to enable the browsers. We've learned though that taking java
application code and just expecting it to run in browsers is a very unpleasant
scenario. Perhaps the weakest part of the Java story is browser support for JDK
compliant "100% pure" java applications. The sandbox stuff is ... painful ...
from a solutions standpoint.
That aside, I'm wondering what other options exist for network enabled access to
my servers if they're lisp based. Sure, we can write socket code galore,
but I'm interested in the alternatives such as:
- Corba interfaces brokering lisp servers to all kinds of clients
- RMI interfaces brokering lisp to java clients.
- Other solutions which enable Java access to the workings of a lisp based
server whose model is built on CLOS.
The last point reflects the fact that the object model which is used to serve
the business component logic may need an equivalent schema which is used to
present graphical or other user interfaces in the client layer which serve to
access the model.
So if there's a DOG class on the server, then chances are that there's a DOG
class on the client, which needs to handle remote method invocations and
stateless connections to the server namesake, given some appropriate persistent
key.
In Java, I use persistent object ids, "smart stubs" (our own invention), and RMI
to allow client DOG representations to be automatically generated from server
DOG representations.
What are my options going from lisp (server) to java (client)? Are there any
lisp client alternatives? (Like the rumor that Franz has plugins which allow
lisp to run in browsers? I'll take that with a grain of salt until it's
announced...)
I think these kinds of problems represent a key opportunity for Lisp based
solutions to gain acceptance, if we can solve the problems I've (perhaps poorly)
alluded to above. I'm looking for your help and ideas to see if I might not
actually deliver my solution in lisp. If you have experience with Allegrostore,
I have some questions about the performance of that solution as well.
Dave Tenny
mail to (concatenate 'string "dtenny"
·@truesoft.com") ; anti-spam device
Dave Tenny
············@games.ultranet.com - no spam please
From: Bruce Tobin
Subject: Re: 3-tier architectures in lisp. Looking for ideas.
Date:
Message-ID: <34EE13A6.5F9585EA@infinet.com>
Dave Tenny wrote:
> That aside, I'm wondering what other options [ aside from CL-HTTP and homebrew]
> exist for network enabled access to
> my servers if they're lisp based. Sure, we can write socket code galore,
> but I'm interested in the alternatives such as:
>
> - Corba interfaces brokering lisp servers to all kinds of clients
Check out the ILU project at Xerox PARC. This is a free (mostly) Corba-compliantORB
with mappings for Common Lisp, C, C++, Java, Python and Modula-3.
> - RMI interfaces brokering lisp to java clients.
See above.
> - Other solutions which enable Java access to the workings of a lisp based
> server whose model is built on CLOS.
Check out the Itasca Active ODBMS (built in Allegro CL) at http://www.ibex.ch.
This is probably the closest you'll come to getting everything you want
out-of-the-box. I suspect (but don't know for sure) that it's quite expensive, and
I'm not sure whether the Java interface is ready yet.
From: Nick Levine
Subject: Re: 3-tier architectures in lisp. Looking for ideas.
Date:
Message-ID: <6ck2n3$5808i_002@harlequin.com>
> I've been wondering this week if I might dramatically cut the cost of the
> project by hosting the business component server layer in lisp,
> using Franz and Allegrostore. Assuming that works (I'm inquiring with Franz
now
> for more Allegrostore information), the real question is how to web-enable
my
> solutions to the business logic servier tier.
>
As an alternative, LispWorks has a bundled SQL interface to several relational
databases and we have a layered product for LispWorks, called DataWorks/LS,
that interfaces with Object Store. :-)
> That aside, I'm wondering what other options exist for network enabled
access to
> my servers if they're lisp based. Sure, we can write socket code galore,
> but I'm interested in the alternatives such as:
>
> - Corba interfaces brokering lisp servers to all kinds of clients
> - RMI interfaces brokering lisp to java clients.
> - Other solutions which enable Java access to the workings of a lisp
based
> server whose model is built on CLOS.
>
The Corba solution seems the easiest of three, and allows the lisp servers to
be called from languages without an RMI interface (C++ for example). The Corba
IIOP protocol is a well specified protocol that does not allow all of the
functionality of RMI (passing objects by value for example, though the OMG are
currently in the advanced stages of agreeing on a pass-by-value mechanism for
CORBA to support RMI:
http://www.omg.org/library/schedule/Objects-by-Value_RFP.htm), but will allow
inter-working with a large range of languages. If the classes in the system
are expressible in OMG IDL, then it is fairly straightforward to parse the IDL
and generate the infrastructure to make calls between the languages. However,
this would require an ORB for the server side, and some sort of Corba runtime
(containing things like the marshaling engine) for the client side.
Both Franz and Harlequin are working on CORBA support for Common Lisp.
> The last point reflects the fact that the object model which is used to
serve
> the business component logic may need an equivalent schema which is used to
> present graphical or other user interfaces in the client layer which serve
to
> access the model.
>
> So if there's a DOG class on the server, then chances are that there's a DOG
> class on the client, which needs to handle remote method invocations and
> stateless connections to the server namesake, given some appropriate
persistent
> key.
>
> In Java, I use persistent object ids, "smart stubs" (our own invention), and
RMI
> to allow client DOG representations to be automatically generated from
server
> DOG representations.
>
I'm not quite sure I follow all of the above, but in the Corba world, given a
definition of the class (expressed in IDL), you'd parse the IDL to get
equivalent proxy class definition for your particular programming language.
You'd then use an IOR (an inter-operable object reference, given to you by the
server) which would be represented as an instance of this proxy class, to
identify a target in the server to which calls in the client should be
redirected.
Corba has a notion of metadata (stored in an interface repository), which
would allow a client to browse the class definitions to determine attributes
of the objects in the model; alternatively, you could probably parse a simple
subset of the IDL to generate display methods for the IDL classes [ie use IDL
as an OO schema definition].
> What are my options going from lisp (server) to java (client)? Are there
any
> lisp client alternatives? (Like the rumor that Franz has plugins which
allow
> lisp to run in browsers? I'll take that with a grain of salt until it's
> announced...)
>
Given the presence of a java ORB, the java side can act as a client for the
Lisp world too. This means that java clients can set up callbacks from the
Lisp server back to the java clients.
CORBA support for Franz ACL is currently available in ILU, free for any use
at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.
Bill
--
Bill Janssen <·······@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
·······@parc.xerox.com (Bill Janssen) writes:
> CORBA support for Franz ACL is currently available in ILU, free for any use
> at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.
>
What would it take to make it usable under LispWorks and CMUCL?
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
In article <··············@galvani.parades.rm.cnr.it> Marco Antoniotti <·······@galvani.parades.rm.cnr.it> writes:
·······@parc.xerox.com (Bill Janssen) writes:
> CORBA support for Franz ACL is currently available in ILU, free for any use
> at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.
>
What would it take to make it usable under LispWorks and CMUCL?
Not too much, I think, for LispWorks. We've had patches for both at
various times, and I can make them available to anyone who'd like to
work on it.
Bill
--
Bill Janssen <·······@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html