river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 15:36:22 GMT
----- Original Message ----

> From: Greg Trasuk <trasukg@stratuscom.com>
> To: river-dev@incubator.apache.org
> Sent: Wednesday, September 3, 2008 2:03:06 AM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
> 
> 
> 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:
> 

Sure, I'm just talking about the generalities along the lines of:
*) Jini provides services accessible from multiple clients, and so does JEE.
*) Jini provides, while not something designed for long term persistence, JavaSpaces, and
JEE provides EJB persistence which can be used as short or long term storage.
*) JEE provides the capability to define workers. Sure, you don't have multiple end points,
but you do have multiple services running in multiple JVMs in the back ground. This being
similar, possibly, to Jini services running in multiple JVMs. The main point I was trying
to figure out here is how those can cluster like JEE servers in the back ground, and what
is the big difference. This was one of the questions I had.
*) JEE provides services for turning EJB stateless beans methods into web services, and similarly
Jini does this albeit in a different manner and now as XML based services.

But, I definitely see your point on it being a better comparison to WS-*. Thought it also
seems like there is more to Jini than that through JavaSpaces and interface or service download
which seems more like JEE. Seems like it is similar to both technologies in some ways and
different in many others.

> - 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.
> 

Thanks I'll check out much of the information.

> > 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.
> 

Managled that a bit. I'm just referencing the fact that you can use JEE inside your Jini methods
or services and the other way Jini from inside JEE, and they compliment each other in that
manner. Then more clearly: Jini services are discoverable where as JEE isn't, so is that the
real beauty of Jini compared to JEE. Obviously to get the same support of EJB without EJB
in a Jini service one would need to use some other type of persistence framework anyways;
I get JavaSpaces isn't equal to EJB persistence.

> >  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.
> 

Sure, and I guess in that regard the Jini services could be end points for JEE to have a better
overall design. That is one of the things I was trying to nail down.

> > 
> > 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).
> 

Cool.

> >  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).
> 

Yes, thanks to you, Gregg, and Sean for enlightening me more on its best feature actually
being loosely coupled communication.

> > 
> > 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.
> 

Yes, distributed versus clustered has many differences. I was trying to verbalize and understand
the differences between Jini and JEE myself as part of the question. Sean mentioned JMS and
Jini. EJB message beans are a good comparison. Too, I was trying to figure out if and if so
how Jini would use clustering along with its distributable and discoverable features. The
one thing about clustering is you have an end point which manages the distribution, and that
is where the static nature of an EE server connection come into play, and I assume that is
what the smart proxy would do for Jini. It would manage things the same as the different EE
services manage clustering on behalf of the Jini services using the proxy per requests. I
have read some on proxies in the specifications, but haven't really dug there. Are Jini proxies
a single end point or at least a distributed end point which collectively manages all the
calls so they may be limited or threaded to
 support high throughput just as EE servers do? I don't guess it really matters, proxy interfaces,
I assume, can do what ever they need to do in the back ground including communicating with
some kind of a central management application.

> > 
> > 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.
> 

Sure, see my last reply to Gregg where I tried to clear up some of what I'm saying. I'm not
really talking about specifics in the spaces server as much as just letting the client end
be described and be more flexible. I can understand the point on how the server manages what
it receives.

> > 
> > 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.
> 

I see. Maybe some type of a body could be formed within the group if enough users and contributors
are pulled in. Maybe we need more evangelism, demos, and applications which may be pointed
which are built on River. Some good documentation on how to redo certain applications or types
of applications using Jini might be helpful. More of this will probably arise when more companies
are building software which they are funding their resources atop Jini. Is jini.org to be
replaced with the River web site? It seems a good single entry point would be good for the
general Jini technology, or to at least pull those resources in line with each other to have
the same look and feel, and one of them be the goto place for all Jini. 

It seems the web pages haven't been edited in a while, and if that isn't the case, then maybe
the dates of last edit need to be changed or just removed from the web site. On the NB web
site we have tools where different groups can submit news very easily which makes the site
dynamic and easy to keep different up to date information on the web site. That is good when
people come to check out the site. Maybe everyone building on Jini now could commit a little,
minor, time to adding some news every now and then. Maybe have a section pulling feeds together
from different peoples blogs on Jini as well. Anyways, just some ideas there.

Thanks for all the info,

Wade

Mime
View raw message