Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Chat

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
Print Button
 
Meet the Author Index Transcripts

Meet the Author:
Eric Freeman, Susanne Hupfer, and Ken Arnold
September 16, 1999

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.

coffeecup


Reader Feedback

Tell us what you think of this transcript.

Duke

Very worth reading Worth reading Not worth reading

If you have other comments or ideas for future sessions, please type them here:


Print Button
[ This page was updated: 21-Sep-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary | Feedback | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.