Authors: Eric Freeman, Susanne Hupfer, and Ken Arnold
Moderator: Edward Ort (MDR-edort)
This is a moderated forum.
MDR-edort: Welcome to "Meet the Author".
Our guests today are Eric Freeman, Susanne Hupfer, and Ken Arnold,
authors of JavaSpaces Principles, Patterns, and Practice. They'll
answer your questions about the book as well as questions about the
technology. We're scheduled to begin at the top of the hour.
MDR-edort: Eric Freeman and Susanne Hupfer have joined
the chat. So we'll be able to begin soon. Welcome to others who have also
joined the session. You can start submitting your questions to the queue.
MDR-edort: There's a question in the queue (but I'm not
sure it's a JavaSpaces question). Here it is...
Bhalchandra: What is so definitive about java
patterns? That is, there are C++ pattern books as well.
Eric Freeman: They are definitive only in that they
apply to common sets of problems that occur in distributed computing
with respect to JavaSpaces there are patterns for many things, these
happen to be space-based patterns.
moises: In what context do you all envision
JavaSpaces being used as it applies to core business processes in
Corporate America?
Susanne Hupfer: Not quite sure what you are referring
to as "core business processes", but JavaSpaces (or other space-based
distributing computing tools like it) have the potential to change the way
corporate America approaches its compute-intensive problems. In particular,
some Wall Street financial institutions have begun using this approach to
dist. computing for their large computations.
Eric Freeman: Really a question for Ken, who is, ah,
supposed to be here. ;)
moises: Do you envision the desktop being apart
of distributed processing (optimizing potential)
Eric Freeman: Sure, why not? It follows the current path to
very thin clients and large distributed backends.
Bhalchandra: What is the concept behind JavaSpaces?
Susanne Hupfer: In a nutshell, the idea is that you have a
persistent, network-accessible, shared "exchange area" for objects...
and
processes participating in a distributed computation will put objects into
the space, or read objects that are in the space, or remove them from the
space.
The space is the medium whereby communication happens.
Eric Freeman: This is actually not a new idea. Its origins are
in
David Gelernter's Linda work at Yale in the early 80s.
SteveP: Susanne, you mentioned that some Wall Street
use this approach, are they using JavaSpaces or just the approach?
Eric Freeman: This work basically showed that using the
persistent space with a very small number of operations you could basically
implement about every sychronization and communication primitive possible and
in very simple ways.
Susanne Hupfer: SteveP: I can't speak to whether they are
actively using JavaSpaces, but I do know that companies have been using a
space-based approach to large computations for years (the Linda language, which
is space-based, has been used on Wall Street for at least 10+ years)
SteveP: When will nested transactions be supported?
Eric Freeman: SteveP: Jini already supports this.
EdO: Susanne and Eric: Can you expand on the
interrelationship of JavaSpaces Technology and Jini?
Eric Freeman: sure. JIni technology gives you what
Sun calls the "network dialtone". it basically provides
you with a method of looking up and discovering JIni services. JavaSpaces
is a Jini service and provides essentially a "coordination
environment" that Jini participants can use to coordinate their
activities.
SteveP: Really, the Jini spec AND the
mahalo implementation?
Eric Freeman: SteveP, good question. Definitely in the
spec, Ken would have to comment on the implementation.
moises: How do you envision security being applied,
That is, code is downloaded for execution? Will policies be enough?
Eric Freeman: As I understand it, security is being added
and from what I've heard this is being done in the RMI layers.
SteveP: We are currently using JavaSpaces as part
of a content feed EDI architecture.
Susanne Hupfer: (moises: Perhaps if Ken arrives, he can
address the security issue... )
Eric Freeman: Yea, he isn't there.
Jorgie: I have been developing application on
Oracle RDBMS for 10 years. After Java was introduced, I have always looked
for an development environment like provided by Oracle. I build Order Entry
and Accounting Applications. First, I saw Enterprise Java Beans Specs, then
Jini and now JavaSpaces. I have also worked on ODI's PSE Pro Java Database.
I see a lot of similarities between JavaSpaces and how relational databases
behave and PSE Pro works. Question => Do you see JavaSpaces as an environment
to develop distributed Order Entry Applications? Accounting applications?
Some how working with a PSE Pro Database?
Eric Freeman: Well, the persistent version of JavaSpaces is
implemented on top of PSE interestingly enough. I think it all comes down to
whether this domain of problems can be handled with JavaSpaces more minimal
form of object matching (rather than full blown SQL). There are a number of
people now interested in providing something like an Oracle backend for
JavaSpaces.
SteveP: When is the next release of JavaSpaces
scheduled for and what enhancements will it contain? Will JavaSpaces releases
always be linked to Jini releases?
EdO: I'm sorry that Ken Arnold is not here. He can answer
questions about the JavaSpaces releases. However you can submit questions
to the Sun Spaces team. Send your questions
to javaspaces-comments@java.sun.com.
Eric Freeman: Yea, definitely a question for the JavaSpaces
implementation team.
Jorgie: Oracle backend? What? Who?
Eric Freeman: At this point just some discussion in the Jini
mailing list, sorry didn't mean to get you over excited. ;)
SteveP: Anyone else working on an implementation of
the spec?
Eric Freeman: There is also talk of a very minimal JavaSpace,
one that doesn't require all the Jini machinery below it. Steve, I encourage
you
to join us on the Jini-list to discuss it.
Eric Freeman: Hi, Ken, I believe there were some earlier
questions for you to address.
EdO: Ken, welcome aboard.
Ken Arnold: Sorry to be late. Shall I start by answering
Steve's question? We are expecting to release a 1.0.1 release that fixes
some known bugs by the end of the year. We don't have a date for the next
(1.1) release. What are you looking to see in it?
EdO: Ken, on that score, is there a way for folks to submit
feature requests for later releases?
Ken Arnold: There is the direct feedback line,
javaspaces-comments@east.sun.com, and there is also the javaspaces-users
list, which we watch.
SteveP: Nested trans, but obviously that is Jini,
not spaces.
Ken Arnold: It would require spaces support, too. Nested
transactions are not invisible for participants. Yes, that is an important
feature we're looking at adding, depending on demand. Many people want it,
including us.
SteveP: I'd like a utility that shows me everything
in the space without having to take it all out and put it back in (for bagged
stuff in the space)
Ken Arnold: Have you looked at the AdminIterator? At the
JavaSpaces API level this is a programming model question, which Eric or
Susanne probably have a good handle on.
EdO: Eric or Susanne, would you like to comment on that?
Susanne Hupfer: I think this is getting back to the famous
"how do I program without an iterator" question... I think people
will start to think in terms of programming "distributed data
structures" in the space, like building structures that you keep track of
(for example, programmatically you might keep track of the length of an array
in the space)
Ken Arnold: I think there *is* an administrative need for
monitoring the space sometimes, which is why we put an iterator in the
administrative interface. But usually you can design your algorithm so that
a running algorithm doesn't need to see the contents of the space.
EdO: Briefly, can you pit JavaSpaces technology against RMI
and message sending technologies. When is one better than the other?
Ken Arnold: RMI is a point-to-point messaging system.
It is a request to do something now. The JavaSpaces design is much more
uncoupled.
It lets me say "I need this done -- when you have a chance, please do
it."
SteveP: We have stuff in our Javaspaces stored
as queues, stacks, and bags. Ken is correct, we periodically need to montior
it all.
Ken Arnold: Obviously there are times when you want something
done right now -- asynchronous programming is not the solution to all problems.
But a lot of things get too tightly coupled when using an RMI-based solution
because the requestor and the executor have to be talking directly to the
other.
Susanne Hupfer: Along those lines, also lets you say :
anyone who gets a chance, please do it - in other words, sometimes you don't
care who does something, where, or when - and JavaSpaces is great at
expressing that kind of loose coupling.
Ken Arnold: SteveP, I agree, but the question is does your
algorithm need to know this, or is it something you need when debugging or
monitoring the algorithm -- that is, outside the algorithm itself.
Eric Freeman: By uncoupling sender and receiver you can write
applications that are a lot more robust in the (sometimes nasty) distributed
environment. As Ken said, that can be difficult with message passing or remote
method invocation approaches. Steve, in the Linda days we used something called
a "TupleScope" is that what you are looking for, or something more
programmatic? TupleScope allows you to see "entries", look at their
values, delete them, etc.
EdO: We've got a nice set of participants, but no questions
currently in the queue. Here's the time to get your question about JavaSpaces
answered.
EdO: Ken. Earlier the question was asked how is JavaSpaces
being applied today in "real world" applications? Can you respond?
Eric Freeman: Back to the iterator, I think Ken's point is
that the admin interface is good for building things like tuplescopes, but it
is often best to design JavaSpaces applications such that they make use of
their own space-based data structures to track entries.
Eric Freeman: Ken as the designer of JS may want to say more,
but this really goes to the core of the design of JavaSpaces and some of the
scalability issues that arise.
Ken Arnold: Yes, Solaris 2.8 is shipping using JavaSpaces
internally for system administration. Also, there is BizTone that is
using it inside to transfer information between their components. Several
other products are in the works, most using it in this kind of internal way.
Bhalchandra: Can you put some light on, compare
it with dist computing tech like Tuxedo?
Eric Freeman: JavaSpaces claim is to simplify distributed
design by giving processes a "shared memory" of sorts to communicate
through. There is no point-to-point communication, it is all done through the
space. (Bhalchandra) tell us about Tuxedo (middleware for databases?), hard
to compare against something I don't know
Moises: Do you know of other vendors that are using
Spaces with EJB?
Eric Freeman: To continue with Bhalchandra, this shared
memory gives you lots of advantages over traditional ways or building network
apps
Eric Freeman: I don't know of such a combination (JS + EJB)
per se. For example, BizTone in its ERP system using JavaSpaces, and such a
product could quite reasonable use EJBeans in its implementation. Did you have
something specific in mind, Moises?
Susanne Hupfer: I think this is getting back to the famous
"how do I program without an iterator" question... I think people
will start to think in terms of programming "distributed data
structures" in the space like building structures that you keep track of
(for instance, programmatically you might keep track of the length of an array
in the space)
SteveP: For the most part, I'd say it lies outside of
the algorithm. we create a workflow of content in various states that flows in
and out of a Javaspace. We periodically have to stop the handlers and, from an
administrative standpoint, we need to arrange the elements in the space at some
point in time. Taking out and putting back in fires notifications which we
have setup to do other things.
Bhalchandra: Do I need to implement concept of
"Load Balancing Fault Tolerance" if I am using this?
Susanne Hupfer: Balchandra, you can write algorithms that
basically give you load balancing 'for free' - that is, you can write task
entries into a space, and 'worker processes' can take those out of the
space and compute them as they wish - faster processors pick up more tasks,
while slower ones pick up and compute less
Eric Freeman: On fault tolerance, JavaSpaces makes use of
Jini's transaction so that one or more operations over one or more spaces can
be wrapped into an atomic unit. Either they all happen or not. In this way you
can keep the internal state of your entries consistent even in the presence of
paritial failure.
SteveP: Load balancing is an excellent point.
JavaSpaces *enables* load balancing... Fault tolerance is spoken to vis-a-vis
leasing and transations.
Bhalchandra: Eric, Tuxedo is middleware for
distribute transaction processing
Ken Arnold: Yes, SteveP, exactly. Each tool does its
job, and the sum of the parts is powerful.
EdO: We're coming to the end of the hour, but there are still
some good questions on the queue. So we'll go overtime -- let's say 10 minutes
after the hour.
SteveP: Does tuplescope work on outrigger?
Eric Freeman: Steve, tuplescope was part of the Yale
Linda project back in the 80s, sounds great for outrigger, Ken? ;)
Ken Arnold: Yeah, sure, sounds great. Glad you
volunteered, Eric.-)
Moises: While I can see the need for the
admin to monitor a space, seems the overhead would be costly.
Eric Freeman: I'm on it now. ;)
Eric Freeman: Yes, you are effectively taking a
snapshot of a dynamic space.
Susanne Hupfer: Tuplescope worked as a sort of
'debug mode' -- that is it wasn't monitoring all the time, but usually only
when you were debugging a dist. algorithm.
Ken Arnold: It certainly could *get* expensive if it was
done too often on a large space. Clearly one would have to be judicious.
Moises: I see the potential of all cpu that are
idle. I see the potential of the servers. I want to use them both. I see
a web client performing processing, extracting from and providing for the
space.
Susanne Hupfer: It sounds like you are describing something
like the SETI project, using idle workstations and interacting with a space?
Ken Arnold: Yes, a web client could feed requests into the
space for a bank of servers. Someone could sell access to the idle cycles on
a bank of servers through such a web client. If you enter your credit card
and your entries, we'll give you the answers.
Eric Freeman: There goes my million dollar idea. ;)
Moises: The question becomes, what should the
app be that will allow me to learn? Thank you!
Ken Arnold: You could start with the GenericWorker example
that comes with the outrigger distribution. It is a basic implementation of
this idea.
Scott Jorgensen: Does Sun intend to continue to use
PSE with JavaSpace?
Eric Freeman: Moises, Chapter 11 in the book is just want you
want, shows how to do a compute server.
Ken Arnold: We have no particular plans to rewrite outrigger
to replace PSE. It works well for what we want it to do. We have thought
about other implementations, including an RDB-based one, but that would be
another thing.
EdO: Maybe a good way to conclude the session is to ask
all three of you what your "vision" is for JavaSpaces? How/where do
you see its full potential being expolited? Also, Ken, what's the best way
for people to submit questions about JavaSpaces?
Ken Arnold: Let me answer that one first. The best thing to
do is to use the javaspaces-users@java.sun.com alias. You can subscribe to it
by sending 'subscribe javaspaces-users' to listserv@java.sun.com. That's where
the people most interested in JavaSpaces hang out.
Eric Freeman: JavaSpaces deserves to become a widely used API,
Moore's law can't last forever and the natural way to build systems is going
to be as distributed apps. Creating distributed apps that are loosely coupled
really gives you the qualities you want to build robust systems and JavaSpaces
is a great way to do that.
Susanne Hupfer: I'd like to see it become 'the' way that
people start to think about writing distributed programs. Distributed
programs are going to be a necessary part of every programmer's repertoire
in our increasingly networked world, and I happen to think that JavaSpaces
is a 'relatively' easy and very powerful way to approach building dist.
programs. The tuple space model should be something that every CS undergrad
learns - it is easy enough.
Ken Arnold: I think people will see new ways to use existing
resources, and think more about how to use a galaxy of computers to get things
done. Currently people are very focused on fixed networks or single machines.
We've got to loosen that up, and I think JavaSpaces is a great tool to do that.
Eric Freeman: I'll also note that there is a fair amount of
cross talk about JavaSpaces in jini-users@java.sun.com, so sign up for that
too.
EdO: Well it looks like time (and overtime) is up. Thanks to
our guests and our other participants for an excellent session.
Reader Feedback
Tell us what you think of this transcript.