river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 06:03:06 GMT

Hi Wade:

I know there have been several responses so far, but I wanted to go back
to your original question.  Discussion is interspersed below.  I'm not
sure if the formatting comes out well as an email, so I may redo my
comments as a blog entry later on.

Cheers,

Greg Trasuk.

On Fri, 2008-08-29 at 20:31, Wade Chandler wrote:
> All,
> 
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE, what
exactly would the decision maker be? 

I don't think this is the correct comparison.

JEE's primary use case is connecting web applications to an application
backend consisting of business logic and persistence, with the potential
for load balancing over multiple instances of the web container and
application container.  As such, JEE includes elements of remote method
invocation, transaction coordination and object-relational mapping, but
assumes a fairly static configuration and fairly tight coupling of the
web, application, and database components.  "Distributed" components are
generally assumed to be in the same datacenter connected by highly
reliable networks.  Having said that, the vast majority of deployments
end up with the web, business logic, and persistence components running
in the same application server, often with the database on the same
physical node.  This type of configuration hardly justifies any
distribution logic at all; hence the rise of Spring and similar
lightweight component-integration frameworks.

Jini is an enabling technology for service oriented architecture.  As
such, it is more appropriate to compare Jini to the WS-*/WSDL/SOAP/UDDI
universe.  In that light, some Jini's differentiations are as follows:

- Jini makes the assumption that a client of a Jini service is resident
in a Java Virtual Machine.  As such, it dispenses with the need to
define an interface definition language (e.g. WSDL), type system (e.g.
XML formatted according to an XML Schema) and remote procedure call
mechanism (e.g. SOAP over http) that has to try to support multiple
implementation environments.  We can define service interfaces as plain
old Java interfaces (and usually have only partial success, hence
WS-I).  Also, we can mostly avoid  Oddly enough, I frequently find
organizations implementing SOA using the WS-* stack but planning to use
Java for the entire implementation.
	- Note that I said the _client_ is resident in a JVM.  The service
doesn't need to be in Java, as we'll see later.

- Jini is designed explicitly around the Eight Fallacies of Distributed
Computing put forward by Deutsch
(http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing) and is
informed by the insights contained in "A Note on Distributed Computing"
by Kendall, Waldo, Wollrath, and Wyant
(http://research.sun.com/techrep/1994/abstract-29.html).  In particular,
it does a far better job of dealing with network unreliability (through
the leasing mechanism) and supporting security and distributed
administration than WS-*.  Also, because it doesn't impose the verbosity
of XML, it fares much better against the bandwidth and transport cost
fallacies.

- Given that clients of Jini services are in a Java environment, Jini
embraces the concepts of serialized objects and dynamically loaded
mobile code, and deals with most of the difficult aspects of that
embrace (identity issues, proxy verification, proxy trust issues, etc). 
Mobile code allows Jini to present some interesting possibilities:
	- Jini clients do not need to know anything about the communications
protocol used to communicate with the service.  (See Waldo, Jim, "The
End of Protocols",
http://java.sun.com/developer/technicalArticles/jini/protocols.html). 
Having said that, Jini/JERI provides a rich and secure Java Remote
Methods Invocation protocol, which we use more often than not.
	- What we normally think of as "remote objects" can actually be objects
that move between virtual machine, and have their code executed in the
virtual machine that is calling them.  This enables the concept of smart
proxies (see Dan Creswell's blog at
http://www.jroller.com/dancres/entry/stub_proxy_and_smart_proxy).  Many
people don't realize it, but the objects we pass as listeners to events
can also be smart proxies.  You might want to think about that one for a
while...
	- Since all that matters for a client to use a service is that we can
create an appropriate proxy for the service in Java, the services
themselves don't need to be implemented in Java or use any Java-based
communications protocol.  You could register a "Jini Service" that is
actually a proxy for a SOAP-based object or some other wire-level
protocol.  The Surrogate specification expands on this concept and
provides a simple way for connected devices to provide an appropriate
service.
	- It is trivial for a client to set itself up to receive asynchronous
callbacks or remote events from a service.  This is distinctly
non-trivial (tending towards impossible, but I don't like sweeping
generalizations) under the WS-* regime.  As such, Jini is much more
appropriate to GUI clients and event-driven system than WS-*.

- Multicast discovery completely removes the dependence on any physical
location information encoded in a service description (as in WSDL), and
any single point of failure issues (as with UDDI).  It is trivial, even
encouraged, to have multiple service registrars on the network. 
Services automatically register with multiple registrars, and clients
can easily find and query multiple registrars.

- Jini philosophy and technology (e.g. Leases and Transactions)
encourage us to deal with the complicated failure mechanisms present in
distributed systems.  As a result, Jini SOA's are far less fragile than
WS-*-based SOA's, and far easier to manage.  In particular, migrating a
service from one box to another is pretty much trivial, and doesn't
require any administration on the client side.  Not much code on the
client side either (as opposed to doing a UDDI lookup).

There are other differentiating factors as well, but those are the
biggies off the top of my head.

> I know you can use JEE inside Jini services, and thus they are complimenting each other
in this regard, 
> and then Jini services can be discoverable, but is that the real beauty of Jini versus
EE?
Are you suggesting that JEE makes Jini services discoverable?  It's the
other way around.

>  I guess I'm having a hard time reconciling why I should want to really dig into Jini
more versus just continuing to use EE. 
Well, arguably, most "JEE" applications would be much better off using a
Spring container inside the web server, but we'll assume you actually
want the application to be physically distributed over multiple nodes. 
In that case, choice is really between a JEE-style cluster or a
service-oriented architecture.  If your goals require SOA, then you
should be using Jini.

> 
> I can have remote code with EE, and I can have it clustered and running on multiple backends.

> Such a thing would only be done in Jini, per my understanding, by having a Jini front
end where the code which the service 
> still executes in an EE environment using stateless or stateful beans.
No, you'd just have multiple service instances, perhaps with a smart
proxy that "load-balances" between the service instances.  Alternately,
JavaSpaces can be used to implement a nice "perfect" load-balancing
algorithm (the multiple-master-multiple-worker pattern).

>  Too, JavaSpaces seem cool from the sense of remote memory, but I'm having a hard time
reconciling why JavaSpaces are any better
>  than EJBs except for the fact that I don't really have server storage coding for the
backing JavaSpaces tuples, 
> though for any type of application to survive shutdowns and crashes data would need to
be stored in some type of a permanent 
> data store such as a database. Using a database would make sense anyways, so it seems
tuples/entries are better suited to 
> temporary distributed memory, but again, maybe wrong here and needing clarity.
One of the problems with a simple yet powerful concept like tuple-spaces
is that there are a lot of possibilities.  Different people see it
different ways, but I've always treated JavaSpaces as a loosely-coupled
communications mechanism.  I particularly like Ken Arnolds "Remote
Procedure Call to Nowhere in Particular" model (see
http://www.artima.com/intv/swayP.html).

> 
> I know this is a Jini dev list, but I'm trying to reconcile these things to make sure
I want to commit resources here as I am 
> really interested in the automatic discovery of services and pluggability, and I'm very
interested in distributed services, 
> where service calls are distributed and clustered the server/service side so that multiple
instances of a service handle different 
> requests in the backend for a given front end, if this is possible with Jini services
as part of the Jini specification. This would 
> basically be clustered services.
I apologize; I'm having difficulty verbalizing the exact differences,
but distributed services and clustered services seem like different
concepts to me.  Could you perhaps expand on what aspects of
"clustering" are important in this discussion?  Fail-over is a natural
part of the Jini Way.  Load balancing is not intrinisic to the Jini Way,
but is easily implemented using smart proxies or JavaSpaces.

> 
> Something bothering me about JavaSpaces entries is they force public fields/variables.
To me they should operate off the same 
> assumptions JavaBeans and serialization operate. EJBs work this way as well. Truly those
things should be compatible thus true 
> encapsulation can take place. I haven't figured out why entries differ from the other
specifications.
Ken Arnold also explains this design decision in the Artima article
(http://www.artima.com/intv/swayP.html).  Along with his points on the
contract of an Entry field, there is a huge practical advantage to this
decision: The Space implementation never has to load the class that
derives from Entry.  The entry and all its fields can be marshalled on
the "write()"-ing client and unmarshalled on the "take()"-ing client,
and the actual Space can do all its communications and template matching
using the MarshalledObject instances.  This method has huge performance,
reliability, and maintainability advantages over having the Space load
the Entry class.

Probably the simplest thing is just to say that tuples aren't meant to
be encapsulated.  But, remember that the public fields can contain
domain objects that will be marshalled and unmarshalled as appropriate,
and those domain objects can be as encapsulated as you like - you simply
set the fields that hold domain objects to null when you create the
entry that defines the "search template".  The public fields are there
to provide the matching.  It's similar to storing a business object as a
BLOB in a database table;  you would still want to extract the
appropriate fields to select on.  You don't really need to copy the data
from a business object to the entry, unless that data is part of the
matching criteria.

> 
> Too, do I have the wrong idea about the River incubator? I was thinking it was to be
the new place for work on Jini and JavaSpaces to 
> progress forward, but I don't see documentation on the specifications, nor other information
on the web site directly related to that 
> type environment for progress. What is the overall goal here? The first sentence in the
web site states "a project furthering the
>  development and advancement of Jini technology". Is that the goal, and if so what does
that actually mean? I notice links on the
>  site to Jini lists/forums on java.sun.com, but I guess my understanding is that Jini
and all related technologies, maybe even 
> JSRs, are to start and end here now. What is the real story?
River is Jini.  While some of us would like to keep the technology
specifications conceptually separate from the implementation (i.e as
Servlet/JSP is to Tomcat), there is no separate entity that manages the
specifications.  Which is a shame IMO, because the original Jini
Community Process was very well thought-out.  Alas, when the call came
to put money on the table to support an ongoing Jini Community separate
from River, everyone seemed to have forgotten their wallets in their
other trousers.

> 
> Just a side note. I had the privilege of mentoring a NetBeans project to create easy
to use functionality to get people started 
> using JavaSpaces, tuples, and entries. It seems a good start to a larger Jini environment.
This was part of some work the NB Dream 
> Team did for the NetBeans Innovators Grant program. You can see the project from Magdalena
Dukielska at:
> http://code.google.com/p/javaspaces-netbeans/
> 
> Thanks for any and all information,
> 
> Wade
> 
>  ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream
Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


Mime
View raw message