Discussions

News: Sun Dreams of Jini Again

  1. Sun Dreams of Jini Again (74 messages)

    A lot of developers thought Jini was cool, but it felt like Sun didn't quite known what to do with it.
    It was pointed towards networked devices, but may it take off now in the world of the business applications?
    The Jini Community just released its first standard for building Jini-based systems, which hopes to make the software easier to work with.

    Jini has also now thought of as a possible good match for Web Services.

    "The Jini Starter Kit 2.0 is expected to include a new security model that will allow servers and devices running Jini to decide whether code
    downloaded from elsewhere in a network is trust-worthy.
    Also expected is a new implementation of Java RMI (Remote Method Invocation),
    called Jini Extensible Remote Invocation (JERI),
    which should help Jini programs to better interoperate with other, non-Jini applications, according to sources familiar with Sun's plans.

    Starter Kit 2.0 is also expected to include new utility classes, new versions of Jini's discovery protocols, and a new service runner framework, the sources said."

    Sun tries again with Jini:
    http://news.com.com/2100-1012_3-1000911.html

    Sun dreams of Jini 2.0:
    http://www.infoworld.com/article/03/05/09/HNjini2_1.html

    Article: Jini Starter Kit 2.0 tightens Jini's security framework
    http://www.javaworld.com/javaworld/jw-05-2003/jw-0509-jiniology.html

    What do you think the future is for Jini? Will it be a small niche player, or get into the big time?

    Threaded Messages (74)

  2. javalobby[ Go to top ]

    There's a bit of discussion on this topic going on JavaLobby too ....

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  3. Tired of arrogance[ Go to top ]

    <cameron>
     There's a bit of discussion on this topic going on JavaLobby too ....
    </cameron>

    And after reading it, you realize that the arrogance problem is indeed pervasive in our field. Jini advocates have an attitude that turns me off immediately every single time I try to get interested in this technology (every six months or so).

    "J2EE is a pathetic toy", "JINI is the future", blah blah blah.

    Until these guys drop the attitude and try to understand while J2EE succeeds (hint: it solves a real problem) and why JINI is unknown in the industry (hint: go talk to customers and ask them what they need instead of designing your software in closed rooms and carpetted corridors), JINI is the future and always will be.

    Try some humility, it's good for the soul.

    --
    Cedric
    http://beust.com/weblog
  4. hehehe[ Go to top ]

    "J2EE is a pathetic toy", "JINI is the future", blah blah blah.


    Haha.. That sounds like me. Yeah, guess I did have a little tude a while back about all of that. Ah well. Didn't mean to offend anyone, I was just attacking all of the J2EE guys without being very open minded and open to discussion. Oh well..I leave it to better talkers now. ;)

    jesse
  5. Old times[ Go to top ]

    Hey Jesse,

    I remember that whole topic flamed with you against the world.
    Actually I have to thank you since at the time I was working on a J2EE time tracking app and I then decided to use JINI in my next project.

    Well it all turned out to work fine. The J2EE app has been running with only one feature-upgrade/bug-fix release since January 2002. It's been 6 months now that I introduced JINI in the project I am in now, and it has been great. Why JINI? Well they asked for a couple of fast backend fault tolerant components, one being a master/slave data repository and one being a provisioning system.
    We have been able to exploit its features to the fullest. JINI forced us to have a true object oriented approach to software since we started thinking about services and interfaces. JINI forces you not to hack and keep things clear.

    In the development phase we had just one pc running reggie (i.e. the service repository locator) and everyone was writing code and testing it as if it was any other java code. Most developers didn't even notice that we were using JINI, since each JINI service came in a nice jar file containing a class acting as the client for that service (i.e. doing the lookup and discovery for them).

    Using JINI we accomplished things that with J2EE would have been much harder to do. We were able to have services talk via CORBA (both as clients and servers), talk to Swing UI's (for the demo), talk to Tomcat (for the remote customer care application), to Apache-Axis (to enable integration with backend systems that didn't want to use CORBA), and to implement a custom defined protocol via sockets (CORBA was too slow for this one) between a JINI service and a particular C application.

    The beauty of JINI is that it sits around Java letting you do everything you can do with Java. In J2EE, the application server takes over, rewriting your code and deciding how to run it (what if you NEED a separate thread to do something?) which is good in many cases, but not all cases.

    The best thing was being able to tell customers that this architecture had linear scalability by design, its built in.

    Marco Bonechi

    P.S. by the way I wonder at those guys trying to sell J2EE to customers, shouldn't you sell features and only then find them the best technological solution?
  6. New times[ Go to top ]

    Well, I´d find it very amusing, if this Jini things takes off so well as to almost replace this J2EE thing. Not because of J2EE itself, but because of Microsoft! M$ created .Net to fight against J2EE in the Enterprise, copying much of its concepts, then all of a sudden, a new technology emerges, also based on Java, and suddenly M$ falls way behind again! Would be funny to see that happening... :)

    All this just shows that Java is a very flexible and capable platform, despite what M$ may say.

    Not that I am against M$. I just don't like their awful tatics based on lies and FUD.
  7. Hi,
    Jini is not meant to replace J2EE. In fact these 2 technologies target for different type of applications.
    J2EE target for centralized based applications and Jini target for distributed systems. So in many cases these are complimentary technologies.
    Any case, GigaSpaces (that is the first JavaSpaces commercial implementation) provides on top of JavaSpaces a platform that both J2EE applications and Jini applications can benefit from.

    For Jini applications there is no point to clarify the benefit – it is obvious.

    For J2EE applications that do not need high level of performance without high number of concurrent users and do not need to communicate with external non J2EE application – J2EE can offer decent tools.

    But if you need to build complex J2EE application that need very fast way to cache its objects, allow these to be shared with other applications, persist them using classic Object 2 relational mapping to any RDBMS and have high level of reliability and availability (using build-in replication, fail-over and load balancing) – I suggest you to take a look on GigaSpaces technology.
    Our tests shows that we are 10X times faster than CMP using our JCA so we are in-fact the fastest technology to persist Java objects to RDBMS for distributed applications.
    See our booth at JavaOne for live demonstration using Webshpere 5.0 + GigaSpaces 3.0 + ORACLE 8i.

    So why JavaSpaces is not popular as J2EE?
    This is simply question of market mood, time, community knowledge and education!

    Best Regards,
    Shay
    ----------------------------------------------------
    Shay Hassidim
    Product Manager, GigaSpaces Technologies
    <GigaSpaces - Be Local Sync Global
  8. Old times[ Go to top ]

    Thanks for sharing your Jini experience with us.

    We have been waiting for proof of concept for a long time and your experience is just what we have been waiting for.
  9. Tired of arrogance[ Go to top ]

    <cameron>

    > There's a bit of discussion on this topic going on JavaLobby too ....
    > </cameron>
    >
    > And after reading it, you realize that the arrogance problem is indeed
    > pervasive in our field. Jini advocates have an attitude that turns me off
    > immediately every single time I try to get interested in this technology
    > (every six months or so).
    >
    > "J2EE is a pathetic toy", "JINI is the future", blah blah blah.

    Which is too bad because in many places Jini and J2EE peacefully co-exist.
    In general Jini and J2EE complement each other.
  10. 80/20 Rule at work here[ Go to top ]

    80 percent of the work can be done with 20 percent of the infastructure (i.e. J2EE).

    The remaining 20% of work (i.e. the truly hard stuff) requires serious technology (i.e. JINI).

    In short, there's a bigger market for J2EE even though its not as capable as JINI.
  11. Tired of arrogance[ Go to top ]

    I think that throughout the past two years or so both communities have made some progress.
    J2EE community are becoming more open minded in understanding that J2EE doesn’t fit it all and vendors such as Macromedia/JRUN (in the past) and GigaSpaces <www.gigaspaces.com> (present) understood the value of combining the two technologies.
    In the upcoming JavaOne event were going to present our new JavaSpaces JCA adaptor that shows how this integration complement each other to improve the performance of J2EE applications and enable Real-Time integration with external J2EE and none J2EE applications.
    Any way this is our contribution of making the two technologies work together to achieve the best of the two worlds.
    It would be very interesting to see the feedbacks that we will get on this integration.

    --------------------------------------------------------------------------
    Nati Shalom
    CTO GigaSpaces Technologies
    Email: natis at gigaspaces dot com
    Website: www.gigaspaces.com
    GigaSpaces - Be Local Sync Global
    See you in JavaOne Booth #1536
    ---------------------------------------------------------------------------
  12. Arrogance from J2EE[ Go to top ]

    Cedric it seems your claims are from lack of investigation and intuition not knowledge. Maybe your lack of drive promotes this behavior, as you seem to stumble into Jini every 6 months or so, as you have iterated, but you never get anywhere. This might be because you enter this arena with an accompanying prejudice attitude. You are not trying to learn Jini and use its robustness in J2EE. Instead you are too busy finding ways to discount Jini as a formidable technology. Aren't we all playing for the same team? It seems your vendetta is personal and strayed you from the real goal of software development.

    Cheers,

    Don
  13. <cedric>
    Enough criticizing, please show us solutions.
    JINI is unknown in the industry (hint: go talk to customers and ask them what they need instead of designing your software in closed rooms and carpetted corridors)
    </cedric>

    Its funny how you keep requesting to see some sort of proof, to make you believe that Jini is anything close to J2EE. To me it sounds like you are incapable of browsing through the Jini spec and realizing that it’s a robust technology. Perhaps you have become closed minded in software evolution, and chose to plant your flag over J2EE. Personally I don’t need to peek into the industry to conclude the effectiveness of any technology--that would be nothing more than an appeal to popularity, especially in world that’s driven by commercialism. Jini is an open standard with available source code to existing implementations, don’t be shy take a look you might see something you like, you don’t need anyone to show you anything, find out for your self, and if you cant see the strengths of the technology than all I can say is have fun in your non-carpeted obscure basement playing with your wizards and static three tier models.

    BTW, In my book JINI and J2EE are fine technologies that reflect the power of “JAVA” nothing more nothing less. And if you must know I am a “JAVA” advocate, not JINI or J2EE…
  14. Sun Dreams of Jini Again[ Go to top ]

    This is great news; I personally think the Jini / JavaSpaces model is going to play a big part over the coming years. The main problem I’ve seen up until now while trying to promote JavaSpaces solutions has been in the technology leap required when migrating from existing 2 or 3 tier applications. From a technical point of view the solution seem obvious but I’ve found it a hard "sell" to management.
    At C24 we have recently married our Integration Objects with JavaSpaces, in fact it was Intamission who did the work using "Autevo". With this black-box solution we got virtually linear performance per processor. Intamission now have something useful to put in their Spaces and we get a high performance solution for our more demanding financial services clients.
    With Sun behind this again I think we’re going to see a lot more of Jini.
  15. Sun Dreams of Jini Again[ Go to top ]

    Also, look at www.openwings.org
  16. Sun Dreams of Jini Again[ Go to top ]

    Hi,

    I like J2EE a lot, but since the day I was introduced to JINI, I haven't been able to take my eyes off of it. JavaSpaces are excellent for facilitating systems such as workflow management, parallel processing, and distributed {shared memory, message queue, caching}. JavaSpaces allow you to cleanly decouple the service(s) that publish the 'work' and the other(s) which handle the work.

    Check out:
    JPower.org just annonced JPower 1.0 Beta, a full featured JavaSpace implementation available for download.
  17. Sun Dreams of Jini Again[ Go to top ]

    What I don't understand, and which reinforces my impression that Jini advocates don't seem to know much about J2EE, is that Jini offers features that are *not* in J2EE's scope: automatic discovery of services, replication, etc...

    All these services are supplied either by proprietary extensions to J2EE or by third-party tools.

    When I hear these guys (and by the way, the person I was quoting is someone called Serge Bureau) say that "J2EE is a pathetic toy", I am tempted to ask them to show me how I can develop Web applications or database mappings in Java using Jini.

    <sigh>

    --
    Cedric
    http://beust.com/weblog
  18. Sun Dreams of Jini Again[ Go to top ]

    <cedric>
    What I don't understand, and which reinforces my impression that Jini advocates don't seem to know much about J2EE, is that Jini offers features that are *not* in J2EE's scope: automatic discovery of services, replication, etc...
    </cedric>

    I think, you have a very good point Cedric. J2EE and JINI are for different needs that is why they can co-exist. J2EE's scope is not discovery, leasing and stuff but bullet-proof system's scope is. They can make use of one another. i can have Jini services that uses J2EE entity beans for data access and J2EE Server empowered by Jini. A good example would be
    Clustering J2EE with Jini

    -talip
    jpower.org
  19. Sun Dreams of Jini Again[ Go to top ]

    <
    As I stated earlier, J2EE is a static network oriented technology. In J2EE, it is assumed that the topology does not often change, the bandwith is high, there are few system administrators etc. In such an environment, J2EE does a good job.

    The issue arises when the above assumption is not in place, and Jini is then probably is the answer. For example, consider dynamic resource allocation in a grid of computers in order to dynamically balance the load on the system. Would you imagine how difficult this is to achieve with J2EE? Even setting up clustering in a pretty static environment is not a simple job. You are right about replication, but have you considered the cost of replication e.g. based on multicasting in terms of network traffic?

    Regarding dynamic discovery, J2EE is based on preconfigured deployment files and service registration in a JNDI cataloge. Having said that, there is no feature for an object to lookup(query) another object based on e.g. a template.
  20. clustering & grid[ Go to top ]

    Nader: For example, consider dynamic resource allocation in a grid of computers in order to dynamically balance the load on the system. Would you imagine how difficult this is to achieve with J2EE?

    For end user load, use a load-balancer. In fact, for back-end load, e.g. web services, use a stateless load-balancer with a random or round-robin algorithm backed by a rack of Linux/Tomcat servers.

    Nader: Even setting up clustering in a pretty static environment is not a simple job.

    Try Coherence. Typically, no cluster configuration is needed at all, regardless of how static or dynamic the environment. Dynamic allocation of a new node is as simple as starting the JVM process.

    Nader: You are right about replication, but have you considered the cost of replication e.g. based on multicasting in terms of network traffic?

    If you are doing actual replication to all the nodes in the cluster or grid, then multicasting is probably the most efficient approach. Except for a cluster of 2 machines, perhaps. If you need to replicate data in a cluster, then you should definitely look at Coherence ... it's as easy as one line of code to do that.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  21. Enterprise Jini[ Go to top ]

    There is a framework in Jini for writing distributed database services that is almost a direct take on the Enterprise Java Bean, its the DJB Project (http://djb.jini.org).
    It is a lot different to the standard Enterprise Bean as it requires the clients to control the transaction lifecycle for each interaction with the Service. This means clients can cluster services and service operations under a single Distributed Transaction (It can be a Javaspace or any other transaction clompliant service). So in effect, it gives clients automatic bean clustering with any transaction compliant service. It also come with a State Bean Framework so you can write printer services etc... It is a Jini alternative to Enterprise Beans.

    Eg
    Interacting with a remote DJB Service

    <code>

    Transaction txn = TransactionManager.createTransaction(Lease);

    // cluster operation
    CustomerHome customerHome = CustomerService.exclusiveLock(txn, locktimeout);
    OrderHome orderHome = OrderService.exclusiveLock(txn, locktimeout);

    Customer cust = customerHome.create(...);
    Order order = orderHome.create(...).

    cust.setValue(...);
    order.setValue(...);

    cust.store();
    order.store();

    txn.commit();

    </code>
  22. Enterprise Jini[ Go to top ]

    Although it seems that Jini has plenty of difficulty with internal marketing within Sun (perhaps because it COULD compete with J2EE) and has many fewer engineers working on the technology than on J2EE, Jini does provide an enterprise platform and alternative to EJB's, as you point out. Jini still has a good shot at being at least a grass roots winner in business software because it just might provide the best bang for the buck in enterprise software development. There are still plenty of companies out there who like to run stable and lean systems, with few dollars.

    There is also a very significant number of "seasoned" professionals who want the current hammers, nails, and boards and are accustomed to using primarily a language, a means of persisting data to disk (relational database or otherwise) and a VM in which to deploy their software. Many such seasoned professionals gag when they see the layers, code generators, clicky-clicky IDE's, and the complexity in such solutions as J2EE. Take a look at the J2EE Pet Store source code through the eyes of a COBOL or Pick developer, for example.

    With Jini, you "just" need Java, an editor, a scripting/build/launch approach, and various Java libraries (free, even) and you can likely use whatever database you are comfortable with and start coding. There is still plenty to learn, of course, but as Jini grows in popularity, it will take less and less to become productive using it (knock on wood). The Jini approach to distributed computing (all client-server computing is distributed, afterall) is so much more elegant than the "align the planets" client-server approach.

    Without Jini, Java would be just another language with which to write traditional brute-force client-server software. With Jini (and RMI), Java is transformed into a language that seems to comprehend what it means that the network is the computer. So, I'm definitely becoming a fan of Jini for enterprise software, but contact me in three months and I can let you know what kind of success, or lack thereof, I have had.

    --dawn

    Dawn M. Wolthuis
    www.tincat-group.com
  23. Enterprise Jini[ Go to top ]

    <dawn>
    Jini does provide an enterprise platform and alternative to EJB's, as you point out.
    </dawn>

    Okay, you're going to have to provide more information...

    It's the kind of statement I keep hearing from the Jini advocates but I have yet to see some concrete evidence.

    I am not interested in what Jini *could* do. If you go there, potentially anything can be an alternative to J2EE. So please, tell me what Jini currently *does* that could be seen as alternatives to the functionalities J2EE provides.

    Anything out there I could put my hands on that would give me, say, EJB/JDBC-like functionalities?

    Enough criticizing, please show us solutions.

    --
    Cedric
    http://beust.com/weblog
  24. Right..[ Go to top ]

    <cedric>
    Anything out there I could put my hands on that would give me, say, EJB/JDBC-like functionalities?
    </cedric>

    You are right of course, all talk and no walk right? Yes, this has been the persistent problem with most people trying to explain the benefits of JINI. (Including myself..) As far as I have gathered, it seems that most shops tend to roll out their own ~J2EE-like~ application servers built around JINI/JavaSpaces/etc..(including myself) This makes it harder for the general populous to get started using Jini as a viable alternative/companion to J2EE. This is the largest flaw I think that the current JINI community should remedy. There are of course solutions like this out there, as previous posters have pointed out like:

    Autevo - http://www.intamission.com/products/default.asp?PageID=25
    RIO - http://rio.jini.org/overview.html
    Enterprise in general - http://enterprise.jini.org/
    gigaspaces - www.gigaspaces.com

    I haven't used any of these technologies personally(besides gigaspaces), but I'm sure that someone else can speak on their behalf. (My personal opinion, without doing too much research is that autevo has the most promise). This is really all that people talk about when they question the J2EE-like functionality right? You just want an appserver. I still think the jini.org site or something else should do more to promote a particular suite of apps so that more people can get their head around the concept.

    The other problem is of course that while J2EE and JINI are ~sort of~ similar, they really solve different problems. It's sort of like asking "how do I drive my car with JINI?". The problem is of course that you cannot, but you can fly an airplane. It's just different. I don't know if any of this makes sense, but if you really are curious about how all of this works/comparable to J2EE I would try downloading one of the apps linked above and check it out.

    jesse
  25. <cedric>
    Anything out there I could put my hands on that would give me, say, EJB/JDBC-like functionalities?
     
    Enough criticizing, please show us solutions.
    </cedric>

    Although I can't give it to you ( although I am hoping my employer will let me open it back up again as a Jini project), Athena allows you to completely separate the datasource from the client, it uses it's own Connection and resultset interfaces, it has type validation(both Classtype and Regular expressions), type transformation, compound (structure) types, and arrays. For specifics the most features are enabled for Oracle including Oracle Objects, and Stored procedure definitions. It will also build the SQL (or a commarea for CICS) at the server, not requiring the caller to know anything about it, it has connection pooling, resultset caching, resultset chunking (large resultsets chunked into smaller pieces that the client can start going through quicker), nested resultsets, multiple server commands (i.e. one invocation from the client could have multiple invocations made against the server). It's API is extendable so that if you desire you can have an encrypted resultset (whether it is a CICS VSAM, SQL, Berkeley DB backend is irrelevant) without the client knowing, i.e. the proxy handles the decryption for you, so quite probably _nearly_ everything JDBC/JCA gives you.


    Here's a little story....when I first started with Jini, hell, I had to roll up my sleeves and get on with it, none of this "show me the solutions"-Jerry-Maguire-stuff.....just because you can't go to a vendor website and download WebLogic Jini 8 does not mean that Jini advocates are spouting bs for the hell of it....there's a lot of people out there who put a lot of time and effort into using Jini, and for me it has worked wonders, it is definitely a very understated technology.

    Jini is a technology, not a platform like J2EE (which is a collection of technologies), yes you can build a J2EE container using Jini, however you can't build Jini using J2EE

    As for alternatives to what J2EE provides.....EJB => the DJB project and the RIO projects

    Calum
  26. Best Fact so far...[ Go to top ]

    <Calum>
    yes you can build a J2EE container using Jini, however you can't build Jini using J2EE.
    </Calum>

    That's the best "FACT", thus far on this discusion...
  27. Enterprise Jini[ Go to top ]

    <cedric>
    Anything out there I could put my hands on that would give me, say, EJB/JDBC-like functionalities?
    </cedric>

    hmm. how would Morpheus of The Matrix respond to this?

    ....
    maybe you are asking the wrong question !!

    you have got to seek for yourself. i would advise you to read the articles on
    artima.com(articles are as good as your weblogs) and then go check out jpower.org.

    i can only show you the door, you gotta work through it.
    ....


    sorry guys 'the matrix reloaded' massed up the way i respond things.

    -talip
  28. Enterprise Jini[ Go to top ]

    <cedric>
    Posted By: Cedric Beust on May 17, 2003 @ 01:18 PM

    <dawn>
    Jini does provide an enterprise platform and alternative to EJB's, as you point out.
    </dawn>

    Okay, you're going to have to provide more information...

    It's the kind of statement I keep hearing from the Jini advocates but I have yet to see some concrete evidence.
    </cedric>

    Jini does not DO the same thing that an EJB container does -- it provides an alternative strategy for developing information systems. It isn't itself a solution -- it is an approach to writing software that needs to run on more than one computer (and most database software requires at least GUI client and db server nodes).

    I think the best thing to do to illustrate it would be to develop a Jini Pet Store to show the difference between Jini and J2EE software development and once I have SOMETHING developed (I'm not there yet), perhaps I can turn some attention to that.

    There is not one way to handle data in Jini -- the way to handle it in Jini is the way to handle it in Java sans servlet and EJB containers. JDBC is just JDBC in Jini -- no built-in wrappers for connection pooling, for example, so you write them. Basically the strategy is that you write code in a way that it will run on distributed platforms with the right code running on a client node, on a middle tier, and/or on a database server. Instead of appearing as different components that run in different places, using Java RMI makes it so that when you need to run a method on an object that is on another node, you run it - no need to package up data in xml, wrap it up in soap, and transmit it so that it can be unwrapped and parsed and used.

    There are no containers (yet) to manage (except with various Jini projects that are working on such), so the functionality of such containers either needs to get built in or not, depending on the application.

    Which features of J2EE would you be concerned about losing if you used Jini instead?

    --dawn

    Dawn M. Wolthuis
    www.tincat-group.com
  29. J2EE Scope?[ Go to top ]

    What I don't understand, and which reinforces my impression that Jini advocates don't seem to know much about J2EE, is that Jini offers features that are *not* in J2EE's scope: automatic discovery of services, replication, etc...

    >
    > All these services are supplied either by proprietary extensions to J2EE or by third-party tools.

    I'm a Jini advocate, and I've built distributed transaction systems in it, I know quite a lot about J2EE as well, I don't believe that J2EE is a one-system-fits-all solution, and I am glad to say that many J2EE developers are realising that. Also I don't believe that Jini is the "be all and end all" either, but for me it has proven a better solution to our problems than using our J2EE system, that we subsequently scrapped.

    However your quote indeed defines why Jini is different from J2EE - from the outset Jini was developed with self-healing, fault-tolerance, replication capabilities in mind, not as extensions....in many cases clustering/replicating a J2EE server is an expensive option because of these proprietary extensions or third party tools

    Yes I agree that Jini offers things that aren't in J2EE's scope, otherwise why would anybody use it? However, it does offer solutions to more low-level problems that crop up when J2EE is in a single server deployment. Surely as developments become greater and the need to consolidate applications within a single environment/development team, J2EE should have these things within it's scope

    Our infrastructure is distributed across 4 servers for production, 4 for user acceptance and 4 for development, from a purely economic point of view, for us to continue with J2EE and mitigate risks by replicating our environments, would have meant a substantial cost.......and yes we did look at JBoss.

    Database Mappings in Jini - my infrastructure handles that, oh and it talks to a OS/390 Mainframe running CICS as well, and can handle all that within one single distributed transaction, it completely hides all the complexity of SQL from the user or the CICS Commarea, support stored procedures, SQL Structs, arrays, etc.

    As far as web applications go (and I haven't looked into this area in a great deal with Jini, so please forgive anything I miss) but wouldn't that be no different from calling a servlet that looks up Jini service...as I recall I wrote one that displayed all the current states of the services in the lookup services and presented that in HTML when a developer logged into our portal.

    Also the serviceui (http://serviceui.jini.org) project allows the capability of a service to store it's UI in it's downloadable code, this UI could be Swing, AWT or HTML - so I do think it's possible.

    Hope this helps/clarifies/whatever

    Calum
  30. Let us assert that the Sun's Jini marketing team did not do a good job in the beginning. Jini was sold as a technology for devices. It was rather what Web Services would turn out to be. Besides being a good technology, J2EE team had a better marketing, and it thus became the mainstream.

    From a technical point of view, J2EE relies on the traditional multitier application architecture, but it does its job well. J2EE is based on a static network topology, but Jini is based on dynamic networks. Jini has the concept of dynamic resource lookup and leasing which is lacking in J2EE.

    Web Services and Jini have two different answers to two different questions. While Web Services integrates different application by exchanging text objects(XML), Jini uses binary objects to integrate. Again, I find Jini's leasing concept quite interesting while lacking in Web Services.

    From a network point of view, the missing element in Jini would be the "mobility". Jini objects cannot be migrated from one machine to another, as it would be required for example in a grid. Mobile agents would be a better alternative to Jini in this regard.

    When it comes to the "self-healing", Jini's leasing mechanism could be used. But Jini lacks intelligence and autonomy elements. In this regard, intelligent agents would be a better alternative.

    I would really like to see Jini to take off and become the mainstream. However, another option would be to see Jini solve other technologies' problems. For example, I would very much like to see Jini complement Grid Computing technology.
  31. "> I would really like to see Jini to take off and become the mainstream. However, another option would be to see Jini solve other technologies' problems. For example, I would very much like to see Jini complement Grid Computing technology."

    Grid or parallel processing is a very good example that shows how JINI/JavaSpaces are a complementary technology to J2EE.
    Complex tasks processing can be done in a very limited way with J2EE.
    Adding JavaSpaces as a Light GRID engine add the ability to utilize other network resources such as CPU / Memory/ Threads in a way that could dramatically improve the scalability and performance of existing J2EE applications.

    Another examples would be to use JavaSpaces as high performance alternative to Entity Beans. (We hope to release benchmark on for this scenario soon) Or as a Shared Memory BUS for Real Time Integration, Distributed Caching etc. We'll i could probably come up with more examples but i hope you got my point.

    --------------------------------------------------------------------------
    Nati Shalom
    CTO GigaSpaces Technologies
    Email: natis at gigaspaces dot com
    Website: www.gigaspaces.com
    GigaSpaces - Be Local Sync Global
    See you in JavaOne Booth #1536
    ---------------------------------------------------------------------------
  32. "Grid or parallel processing is a very good example that shows how JINI/JavaSpaces are a complementary technology to J2EE.
    Complex tasks processing can be done in a very limited way with J2EE.
    Adding JavaSpaces as a Light GRID engine add the ability to utilize other network resources such as CPU / Memory/ Threads in a way that could dramatically improve the scalability and performance of existing J2EE applications. "

    My understanding was that JavaSpaces/Tspaces are repositories used to share objects between different applications/objects. Would it be possible to share CPU / Threads using JavaSpaces/Tspaces?
  33. My understanding was that JavaSpaces/Tspaces are repositories used to share objects between different applications/objects. Would it be possible to share CPU / Threads using JavaSpaces/Tspaces?


    AFAIK, sharing CPU threads using JavaSpaces is done indirectly. If the objects that are pushed (written) into a JavaSpace are defining the 'works' to be done, then CPU threads (doesn't matter on which machine type are) that run the 'worker' services are used to do the work. I don't think you can write a CPU thread into a JavaSpace and share it but you can write job instructions (works) into JavaSpace so that they can be taken out of space by available CPU threads to be processed.

    i would like to know how else it could be done.

    -talip
    jpower.org
  34. My understanding was that JavaSpaces/Tspaces are repositories used to share objects between different applications/objects. Would it be possible to share CPU / Threads using JavaSpaces/Tspaces?


    One of the common patterns for performing parallel processing is known as the Master Worker pattern.
    There are many examples that illustrate how a space technology can be used to perform parallel processing tasks using JavaSpaces.

    I had recently written cluster pattern paper that talks specifically about this.
    The direct link is http://www.gigaspaces.com/P2PClusterPatterns5.htm ( see the bottom of this page)

    The general idea is that JavaSpaces is used a coordination center. The Master application takes a complex task breaks into small set of jobs, writes those jobs into the space. Generic workers are registered to the space by calling the take(..) method. Each worker represent a processing unit. Each job is taken by a single worker. Upon completion workers writes back the results. The results are picked up by the master in parallel.

    For further information i would recommend the following articles:
    1. “Building Distributed Computing Application” with JavaSpaces http://www.onjava.com/pub/a/onjava/2003/03/19/java_spaces.html

    2. "Make your compute server robust and scalable with Jini and JavaSpaces" written by "Susanne Hupfer".
    http://www.javaworld.com/javaworld/jw-06-2000/jw-0623-jiniology.html

    I hope that this helps

    Nati S.
    GigaSpaces Technologies
    www.gigaspaces.com
  35. |
    |The general idea is that JavaSpaces is used a coordination center. The Master
    |application takes a complex task breaks into small set of jobs, writes those
    |jobs into the space. Generic workers are registered to the space by calling the
    |take(..) method. Each worker represent a processing unit. Each job is taken by a
    |single worker. Upon completion workers writes back the results. The results are
    |picked up by the master in parallel.
    |

    Sounds a lot like using a JMS Queue and MDB's...

    What would be the difference in this case?

    -Nick
  36. Sounds a lot like using a JMS Queue and MDB's...

    >
    > What would be the difference in this case?
    >
    > -Nick

    can you lease a job entry for a certain time, can you tell JMS to keep a job for 10 minutes in the queue and if it is not taken by then, destroy it? can you post a job to one JMS server and then get the result of the job from another JMS server in case of a crash write after job completes? can you locate a JMS server dynamicly?

    yes JMS is really good. It is good to use for some application. i wrote an application that uses JMS about a year ago; i didn't know JavaSpaces back then. i would not use JMS to do it now.

    -talip
    JPower @ jpower.org
    free JavaSpace implementation.
  37. |
    |can you lease a job entry for a certain time, can you tell JMS to keep a job for
    |10 minutes in the queue and if it is not taken by then, destroy it?
    |

    Message expiry? Message.setJMSExpiration(long expiration)

    |
    |can you post a job to one JMS server and then get the result of the job from
    |another JMS server in case of a crash write after job completes?|

    This kind of failover is quite difficult to achieve (transactionally) without some kind of shared storage... but all enterprise messaging servers provide connection failover. And some provide destination failover with a shared storage mechanism. Typically these kinds of "did the transaction commit or not" questions have to be solved by a human or some custom code.

    |
    |can you locate a JMS server dynamicly?
    |

    Not sure why this is that interesting..
    Its possible - though I dont know of any JMS implementations that do this in their connection stubs. Possibly Weblogic's JMS impl does it - but I am not sure you dont have to re-fetch the connection factory from JNDI...

    -Nick
  38. <nick>
    Message expiry? Message.setJMSExpiration(long expiration)
    </nick>

    Sure you can set the expiration time of a message, but unlike Jini's leasing mechanism, you can’t renew that expiration. There’s no Lease manager in any JMS implementation that handles lease renewals. What good is a lease if it can’t be renewed?

    <nick>
    This kind of fail over is quite difficult to achieve (transactionally) without some kind of shared storage...
    </nick>

    Not in Jini, replication can happen directly from one JavaSpace to the other. Setting a central shared storage is not a constraint but an option. All replication between JavaSpaces can be transactional, thus fail over, load balancing, and replication are features that any good JavaSpace implementation supports.
    BTW, no human needed in this scenario :)

    <nick>
    Not sure why this is that interesting..
    It’s possible - though I don’t know of any JMS implementations that do this in their connection stubs. Possibly Weblogic's JMS impl does it - but I am not sure you dont have to re-fetch the connection factory from JNDI...
    </nick>
     
    Discovering a JavaSpace system dynamically “IS” interesting... This introduces "extensibility" and "scalability" to your infrastructure. Using JNDI as a means to get a connection is fine, but what happens when you have your JMS and JDBC connections registered in a JNDI server, and the JNDI server crashes, or the JNDI server needs to be moved to a new machine? There goes your infrastructure, now your forced to recode or restart services in order to find the new JNDI server. In Jini, servers or services are found dynamically, in the JNDI scenario, a service interested in a JMS connection, would discover where the JNDI server lives with out any prior knowledge of its location. If any changes took place on the JNDI server, or the JNDI server was moved to a new machine, it would not affect the services that use JNDI, since they discover its location at runtime. You mentioned connection pooling in WebSphere, well what good is a pool of connections if they all point to JNDI server that has been moved or has crashed?

    Cheers,
    Abel Perez
  39. |
    | you can?t renew that expiration
    |

    Not sure what you are wanting to achieve. You want to throw away the job on expiry - or you want to try again somewhere else?
    Transaction timeout handles the "try again". Expiry handles the "throw away".

    |
    |Not in Jini, replication can happen directly from one JavaSpace to the other
    |

    Obviously this can be similarly achieved by any messaging system. The difficulty however, is to ensure only-once consumption and consumption order. The topology and corresponding scalability depends entirely on the work you want to distribute - and whether you care about multiple consumptions and whether you care about out-of-order consumption. Shared storage is hardly a "constraint" on JMS implementations - but it happens to be reasonably common (because it works best for most scenarios)

    OK, I agree that being able to change server configuration at runtime is very nice. Its just that most production environments I know of take an application down to perform any kind of change (even if the clustering, etc, whatever could cope with it)

    |
    |well what good is a pool of connections if they all point to JNDI server that
    |has crashed
    |

    Well, you cluster your JNDI so that doesnt become a problem ;-)

    -Nick
  40. <nick>
    Obviously this can be similarly achieved by any messaging system.
    </nick>

    Since we are comparing and contrasting between JavaSpaces and JMS, it’s my understanding that JMS uses point-to-point message Queues and pub/sub Topics to distribute its messages. Each message is addressed to a specific queue or topic, and receiving clients extract messages from the queue(s) established to hold their messages, or receive their messages from a specific topic. Each message is delivered "once and only once," Queues retain all messages sent to them until the messages are consumed or until the messages expire, and topics distribute their messages to anyone of the topic consumers online. Personally I think this is fine, but to static for some environments, this means clients have to be aware of a certain queues or topics in the Messaging server, you can argue that placing the queue/topic in a JNDI server makes this approach a little more dynamic but I don’t think so. Just like registered connections, registering queues/topics in JNDI is a point of failure. Also the queue approach delivers messages once per any client, or to a set of consumers online, in JavaSpaces you have the option to read or take the message, you need not know anything about any queues or topics, you can find any message/entry based on a template that describes the message, the message can be read multiple times, thus messages can be read only and found dynamically. In JMS you are also constrained to six different message types, whereas in JavaSpaces an entry can be or do anything it wants, i.e., not sure if this can be extended in JMS, anyhow...

    <nick>
    Shared storage is hardly a "constraint" on JMS implementations - but it happens to be reasonably common (because it works best for most scenarios)
    </nick>

    Yeah it’s common because it’s the only way in JMS, without any third party tools.

    <nick>
    OK, I agree that being able to change server configuration at runtime is very nice. Its just that most production environments I know of take an application down to perform any kind of change (even if the clustering, etc, whatever could cope with it)
    </nick>

    I agree, most shops take this approach which is why I pointed out Jini’s capability to avoid taking down and restarting any services, hence "Self Healing."

    <nick>
    Well, you cluster your JNDI so that doesnt become a problem ;-)
    </nick>

    Sure this works, but now your talking about JNDI server capabilities not JMS. And clustering JNDI servers means more administrative work and licencing fee's :)

    Don’t get me wrong Nick, I like JMS, I am just trying to make the point that a JavaSpaces can do anything JMS can plus some, and if JMS is so accepted in the J2EE community, then so should JavaSpaces, after all its all "Java."

    Cheers,
    Abel Perez
  41. Java is on a roll[ Go to top ]

    You know a technology is good when allies start picking on concepts that are based on the same framework, Java. Might be a bit different if it were a .Net and Java conversation, arguing about similar technologies, we are all on a good thing!
  42. Yes, thanks to all those that pointed out - its obviously ObjectMessage you have to extend.

    However, ObjectMessage isnt the only option for the Command Pattern-type distribution we are talking about (though its arguably the only kind where the worker doesnt need to know too much). This could easily be just data (like a SOAP message or like a script) in any of the other jms message formats. The advantage being that most JMS providers are readily accessible from non-Java clients - which is what Andreas was pointing out. I dont know of any JavaSpaces implementations that support non-Java clients without using JNI.

    But getting back to the thrust of the conversation - I am not trying to prove that JMS is better than Java Spaces. I was just trying to get to the bottom of why it was thought by some that JavaSpaces was a better fit for this kind of problem. It seems to me like they are quite similar.

    The one thing I do understand is that the JavaSpaces query mechanism is somewhat more flexible than a queue. Queues are geared towards the ultimate consumption of a message by just one consumer. JavaSpaces are more like a distributed "cache" which can be leveraged as kind of global message repository. In some respect, this behaviour can be approximated by having just one single queue and using Message Selectors to perform queries - using a QueueBrowser in order to leave the messages in the queue. But I feel this is getting away from what Messaging should be used for. (Its quite possible others disagree).

    Getting back though, to the points you were making regarding messaging, JNDI and failover:
    I feel that I am not getting my point across;
    If you have a "clustered" JNDI (purely to avoid single-point of failure) and from that JNDI tree you get your Queue and QueueConnection objects, then if your JMS implementation has any decent clustering, these objects are virtual. Neither the sending code or receiving code really knows where these physically exist. These objects can then perform load balancing & failover (of the messaging provider! - the application gets its laod balancing and failover naturally from the behaviour of the queue) - while hiding this from the application code.
    So in this sense your system has the same kind of tolerance of failure of the messaging provider (or failure of the worker) as it does with a JavaSpaces soln.

    Having said that, the tricky thing for messaging providers is to provide failover between different instances of a Queue destination at the same time as providing guarantees of only-once consumption. You could essentially perform a 2PC-like transaction between the two destinations - but this would obviously murder performance for some applications. You would be sending multiple messages back and forth for each single message you want to send and consume. (And even then, even a 2PC wouldnt be enough to guarantee absolute coherance across all instances all of he time - esp in failure conditions)

    A JavaSpace, BTW, has the same issues to deal with. Cameron's caching product has the same issues to deal with. This is a common issue when trying to maintain coherance over a fallible medium - ie a network. The solution is to make some assumptions about whether you care or not that two spaces/queues/caches are out of synch for a very brief period of time. (Dont forget that we are taking things out as well as putting them in)

    So in the end I dont understand what you mean by "Yeah it?s common because it?s the only way in JMS, without any third party tools" because this isnt the case.
    As it happens, most messaging solutions use a third party as the transaction arbitrator/coordination point - either a shared filesystem or a database.
    Remember that once the Messaging system is "fail-proof" your workers and masters enjoy the natural clustering semantics of a Queue.


    |I agree, most shops take this approach which is why I pointed out Jini?s
    |capability to avoid taking down and restarting any services, hence "Self
    |Healing."

    I know. I admit that the only messaging systems that have this capability are multicast-based systems like RV (which then have all sorts of problems with transactional aspects of the queueing behaviour). I dont know of any messaging systems that have jini-like discovery built in.

    But... like I said, even if they did, most production teams like to shutdown a system anyway for any kind of maintenance work (except, obviously, in systems where this isnt entertainable).

    The one key aspect where I see that JavaSpaces/Jini has the edge here is when you are talking about HUGE deployments. An example would be harnessing the cpu cycles from the 1000s of desktop PC's that spend the night running screen savers. Here, the admin overhead is a significant aspect of the technical feasibility - and where the self-discovery features come into their own.

    |
    |And clustering JNDI servers means more administrative work and licencing fee's
    |

    Well, its debatable - just an appserver with a decent JMS implementation can provide all of this functionality (clustered destinations, clustered JNDI etc).

    -Nick
  43. |

    > |The general idea is that JavaSpaces is used a coordination center. The Master
    > |application takes a complex task breaks into small set of jobs, writes those
    > |jobs into the space. Generic workers are registered to the space by calling the
    > |take(..) method. Each worker represent a processing unit. Each job is taken by a
    > |single worker. Upon completion workers writes back the results. The results are
    > |picked up by the master in parallel.
    > |
    >
    > Sounds a lot like using a JMS Queue and MDB's...
    >
    > What would be the difference in this case?
    >
    > -Nick


    Nick,

    I forgot to mention the best JavaSpace feature. 'undeclared, undefined, message type' messaging. here is a messaging use case to make it clear.

    * you started up a JavaSpace implementation, say JPower. out of box without deploying anything, not even configuring it. plain download and startup.
    * then you defined a message type name 'com.yourcompany.mypackage.EmailJob'.
    note that this message class is only on the message sender side. class doesn't exist on the JPower server. JPower doesn't know anything about this message type. message type object could be as complex as you can imagine.
    * then your message sender client application creates an instance of that message type and writes (sends, serializes in some form) that message object to JPower. even though JPower doesn't know anything about this message type, it accepts it and persists it even notifies the parties who are interesting in receiving it.
    * then another message reciever application asks JPower about messages with type 'com.yourcompany.mypackage.EmailJob', JPower returns the message to it.


    Only message sender and receiver knows about the message type, Message Queue Server (JPower, JavaSpace implementation, in our case) doesn't know about it.

    I would be interested to know if you could do this in JMS..

    -talip
    JPower @ jpower.org
    free JavaSpace implementation
  44. jcache[ Go to top ]

    Not to take away from JavaSpaces, but you can certainly do it in JCache, which supports distributed caches. For example, using the Coherence distributed cache, which provides transactions, load-balancing and failover without data loss.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  45. |
    |I would be interested to know if you could do this in JMS..
    |

    Of course you can. (que??)

    The only constraint is that your custom object has to extend javax.jms.Message ...

    -Nick
  46. Dealing with POJO's[ Go to top ]

    <nick>
    The only constraint is that your custom object has to extend javax.jms.Message ...
     </nick>

    Then, of course, the answer is that you cannot. The only constraint he's talking about is extending Object.
  47. Only message sender and receiver knows about the message type, Message Queue Server (JPower, JavaSpace implementation, in our case) doesn't know about it.

    I would be interested to know if you could do this in JMS..


    The corresponding JMS message type for such an application is javax.jms.ObjectMessage. You can transfer any Serializable with it. I'm sure there isn't any JMS provider which depends on the object class.

    Anyway, your points are meaningless. It is not that difficult to create a messaging system on base of a proprietary API (like Jini) which is better than JMS. That's not the point. The point is that JMS is a standard in messaging and its strength is the portability of JMS clients.

    JMS is a standard that works. So you can talk what you want - Jini isn't an alternative to JMS, exept may be for some exotic applications.

    -- Andreas
  48. Well as an alternative to JMS (the technology/spec as is) you're obviously right, you can't just 'snap-in' a Jini implementation (unless the Jini impl. is JMS compliant) however as an alternative to what JMS is _capable_ of (i.e. as a concept) yes it can be an alternative where someone does not have J2EE or a JMS server, but does have access to a Jini/JavaSpace solution, under given parameters (i.e. no enforced ordering, class based lookup rather than topic,etc)

    We did something where an entry was written to a Space, it was picked up by a
    system that drew down some data from a DB, then stored it back into the space as a different entry class, whereupon it was picked up by a second system that merged and printed that data. In this kind of instance both JMS and Jini could've solved the problem

    Calum.
  49. <Andreas>
    The corresponding JMS message type for such an application is javax.jms.ObjectMessage. You can transfer any Serializable with it. I'm sure there isn't any JMS provider which depends on the object class.

    The point is that JMS is a standard in messaging and its strength is the portability of JMS clients.
    </andreas>

    Here you are contradicting your self. In order for ?ObjectMessage? types to work, both consumer and producer must be Java programs, at this point it doesn?t matter if JMS is an open standard, if you want to distribute Serializable objects, then you are locked into Java. Using ?ObjectMessage? is only useful between Java clients. There goes your open standard, and the strength of heterogeneous clients. In JMS there?s no way to query or match the ObjectMessage payload, as a matter of fact all you know is that your getting an ?Object.? With JavaSpaces you can query the space with a template that defines the attributes of the Object, therefore you have the ability to receive exactly what you want. In JMS the producer and consumer, must have the ?Custom Object? that is encapsulated in the ?ObjectMessage? type in their classpath, otherwise you get a nasty ClassNotFoundException. JavaSpaces makes use of dynamic class loading, thus clients can receive unknown objects.

    <Andreas>
    JMS is a standard that works. So you can talk what you want - Jini isn't an alternative to JMS
    <Andreas>

    What your saying here is that because there is a well-known standard in a certain technology, there?s no need to expand that technology, and we should just stick to the standard. If that was the case I don?t think I would like software engineering. :(

    Cheers,
    Abel Perez
  50. Jini is not an alternative to JMS[ Go to top ]

    <Abel>
    ?ObjectMessage?
    </Abel>

    Excuse the annoying "?" symbols that appear on my last reply, they should be single quotes and double quotes, sorry guys...
  51. Here you are contradicting your self. In order for ?ObjectMessage? types to work, both consumer and producer must be Java programs, at this point it doesn?t matter if JMS is an open standard, if you want to distribute Serializable objects, then you are locked into Java.

    JMS is a Java standard, isn't it? Java Message Service.

    In JMS there?s no way to query or match the ObjectMessage payload, as a matter of fact all you know is that your getting an ?Object.?

    Usually you will add message properties which you can use in a message selector on the consuming end.

    With JavaSpaces you can query the space with a template that defines the attributes of the Object, therefore you have the ability to receive exactly what you want.

    Attributes of an Object? So you need the class at the server? What about versioning? It is hard to sync clients with the same class versions but if you have a server that transfers multiple versions of classes then you have a version problem.

    What your saying here is that because there is a well-known standard in a certain technology, there?s no need to expand that technology, and we should just stick to the standard. If that was the case I don?t think I would like software engineering. :(

    Well, the value of JMS is the standard and its acceptance. I know that you are looking for some new fields for your Jini products. You should check some other spaces than JMS.

    -- Andreas
  52. <Andreas>
    Attributes of an Object? So you need the class at the server? What about versioning? It is hard to sync clients with the same class versions but if you have a server that transfers multiple versions of classes then you have a version problem.
    </Andreas>

    no, the class doesn't have to be at the server. that is the beauty. smart JavaSpaces implementation will recognize the changes on the object and will act accordingly. so JavaSpaces implementation will do its best but maintainers of the system has to their job to keep message type (object types) as consistent as possible. i think this is fair. what do you think?

    -talip
    see JPower @ jpower.org
    free JavaSpaces implementation
  53. <Andreas>
    JMS is a Java standard, isn't it? Java Message Service.

    JMS is a standard that works. So you can talk what you want - Jini isn't an alternative to JMS
    </Andreas>

    JMS is a Java API that can be used with many different MOM vendors. If a vendor provides a compliant service provider for JMS, then JMS clients work. It isn’t any different with JavaSpaces, I can use a Java Space interface and dynamically discover and download an array of different Smart proxies that all represent different Space implementations from multiple Space providers—the Space implementation is transparent to the clients. The fact that JMS is a standard is irrelevant to a comparison of the two technologies. Only participating JMS provides can allow JMS clients the benefits of JMS, and only Java Space implementation providers can allow Space clients the benefits of Java Spaces. I don’t see your appeal to pointing out that JMS works well because it’s a standard, standard or not, standards also decay and paradigm shifts happen quite often in technology.

    BTW, Jini has never anticipated to replce JMS, that makes no sense at all. Jini
    is a whole different collection of concepts.

    <Andreas>
    Usually you will add message properties which you can use in a message selector on the consuming end.
    </Andreas>

    Sure this works, but it's not quite as flexible as matching is in Java Spaces.

    <Andreas>
    Attributes of an Object? So you need the class at the server? What about versioning? It is hard to sync clients with the same class versions but if you have a server that transfers multiple versions of classes then you have a version problem.
    </Andreas>

    Look at any commercial JavaSpace and you will see that bright developers know how to get around class versioning problems.

    <Andreas>
    Well, the value of JMS is the standard and its acceptance. I know that you are looking for some new fields for your Jini products. You should check some other spaces than JMS.
    </Andreas>

    Personaly I never once intended to invade the JMS space, my Jini services fall under a differnt scope.

    Abel Perez.
  54. Hi,

    I think all this forum should review this great chapter from a book by Bill Brogden :

    http://www.perfectxml.com/sybex/Files/2928ch08.pdf

    Regards,
        Shay

    Here is a summary of this chapter that explains why JavaSpaces is better than JMS for messaging:

    SOAP messages: JMS vs JavaSpaces.

    SOAP
    è Messaging

    Messaging
    è JMS
    è JavaSpaces

    Message-Oriented Middleware (MOM)
    Takes responsibility for transmitting application messages over a network and provides support for load balancing, fault tolerance and transactions.

    Advantages of MOM
    è Asynchronous
    è Fault tolerance
    è Ignore network architecture
    è Security

    Disadvantages of MOM
    è Speed (slower than direct client-server or RPC connectivity)
    è Complexity (of maintaining another layer &#8211; message server, attendant storage, network traffic & processing power)

    JMS
    è Point-to-point model
    è Publish/Subscribe model

    JMS Message Characteristics
    è Delivery Mode
    o PERSISTENT
    o NON_PERSISTENT
    è Time-to-live (TTL)
    o Specified in milliseconds
    o Set at the time of transmit
    o Default is infinite (never expire)
    è Priority
    o 0-9 10 levels
    o Default is 4 (DEFAULT_PRIORITY)

    Types of JMS Messages
    JMS message content is very similar to a SOAP message: there is a header for routing and identifying messages, a set of properties to be used by the receiving application, and a message body.
    è TextMessage
    è BytesMessage
    è MapMessage (name-value pairs where value can be a Java primitive or object)
    è ObjectMessage
    è StreamMessage

    JMS Performance
    The main time consuming operation is the creation of the initial connection to the messaging server.

    JavaSpaces
    In theory, the basic data structure in a space is called a tuple. This is essentially a collection of fields, where each field contains a typed value. Values can be primitive types or complex types such as an array, Java objects or Java classes. Everything in a space is a tuple. In a JavaSpaces, a tuple is represented as a Java object with a collection of public values.
    Another major &#8220;spaces&#8221; initiative, also in Java, is IBM&#8217;s TSpaces project.
    An essential feature of the space architecture is the use of associative addressing. This means that entries are located according to their content, rather than any sort of index or a single valued locator such as a topic in JMS.
    The intent of JavaSpaces is to provide a simple unified mechanism for distributed computing. Computing entities can exchange messages, share data and distribute objects by means of a shared space in a very loosely coupled architecture. This shared space is managed by a JavaSpaces server. A single JavaSpaces server can manage a number of separate spaces, each identified by a unique name.

    Operations in a JavaSpaces space
    è write
    è read
    è take
    è notify

    Selection by Template
    The revolutionary concept embodied in spaces is selection of entries by means of a template. In JavaSpaces, the template for retrieval of objects of type A is simply another object of type A with instance variables set to values that control retrieval. The rules are very simple:
    - Only entries with the same type as the template are eligible for selection.
    - If the template has a variable set to null, any value for that variable will be accepted.
    - All template variables that have a reference will be checked versus the matching candidate entry variable using the equals method. If all match, the entry will be selected.
    It is important to note that selection by template does not provide for any sort of selection by a range of values the way a JDBC compliant database does.

    Persistent vs Nonpersistent Storage
    When choosing a messaging system for SOAP messages, you must balance your requirements for persistent and safe storage of messages vs your requirements for speed and simplicity. Both JMS and JavaSpaces servers can be set up for simple and fast nonpersistent storage of messages or for persistent storage.
    The JavaSpaces approach offers greater control over long-term storage. One advantage is that because the retrieval mechanism does not depend on pre assigned topics, new applications can be written to access entries long after the program that wrote them is no longer connected to the system.

    What&#8217;s Different About Spaces?
    It is reasonable to ask &#8220;what&#8217;s the big deal&#8221; about JavaSpaces &#8211; at first glance, it looks like a slight extension from JMS messaging. Here are the differences:
    è Truly asynchronous &#8211; When an entry is written, a process does not have to be a subscriber to read it.
    è Controlled persistence &#8211; The lease concept used by JavaSpaces is considerably more flexible than the simple time-to-live used by JMS. For example, a lease can be renewed or cancelled.
    è Associative lookup &#8211; The flexibility of template matching goes far beyond the simple topic selection of JMS. Essentially, a space functions like a simple object database.
    è Object storage &#8211; JavaSpaces applications are not limited to the simple variable types of JMS. Because a complete Java object is stored and retrieved, applications can execute operations directly on retrieved objects.
    è Event notification &#8211; Processes may be notified when an entry matching a particular template has been written.

    Applicability to SOAP Messages
    It seems to me that JavaSpaces technology is a very good match for SOAP messaging. For example, each of the message processing functions that are indicated in SOAP headers could be carried out by Java processes watching a space. Given the following header on a message to be processed:
    <SOAP-ENV:Header>
    <a:Authenticate xmlns:a=&#8221;AuthenticateURI&#8221; mustUnderstand=&#8221;true&#8221;>username,password
    </a:Authenticate>
    </SOAP-ENV:Header>
    The entry object placed in the space could have the following values:
    needsAuthentication &#8211; A Boolean with the value true.
    authenticated &#8211; A Boolean with the value null.
    soapMsg &#8211; A String containing the full SOAP message.
    The authentication process would simply read entries where needsAuthentication has the value of true, process the entry and rewrite it with changed values.
    Some SOAP applications naturally seem to match JavaSpaces capabilities; for example, distributed processing of complex calculations. Suppose your SOAP service processes credit applications received over an enterprise-wide network, and the load is more than any single machine can handle. You can solve this with a pool of systems on a network, all connected to a JavaSpaces server.
    The initial application in the form of a SOAP message could be placed in a space with Boolean variables indicating the type of processing needed set to true. Any available machine can take the entry and perform the needed calculations. This automatically balances the load and makes it easy to add new processing power without taking the system down.
    As a further improvement, processing could be broken down into smaller steps, each handled by a specialized application. For example, one application might specialize in lookups in a particular database.

    Timing Results
    JMS - As with the point-to-point example, in the publish-subscribe the main time consuming operation is the creation of the initial connection to the messaging server. In one test run, creating the connection took about 5.5 seconds, whereas sending a single message took between 100 and 150 milliseconds.
    JavaSpaces - The time to get a JavaSpaces reference averaged about 1700 milliseconds (or 1.7 seconds) and the time to write the entry about 110 milliseconds. This compares favorably with the JMS publishing times.
  55. JavaSpaces - The time to get a JavaSpaces reference averaged about 1700 milliseconds (or 1.7 seconds) and the time to write the entry about 110 milliseconds. This compares favorably with the JMS publishing times.

    Is that considered to be good? That's over 1/10 of a second! Are you sure that's not supposed to be 11.0 or 1.10 milliseconds? Or maybe even .110 milliseconds? Maybe that is writing to a disk or something to get to be over 100ms?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  56. Is that considered to be good? That's over 1/10 of a second! Are you sure that's not supposed to be 11.0 or 1.10 milliseconds? Or maybe even .110 milliseconds? Maybe that is writing to a disk or something to get to be over 100ms?

    That quite old stuff. I know the guy who wrotes the book. He got the permission from us to use and supply our old SwiftMQ 2.1.3 (the freeware version with a 1-file-per-message store) along with his book. His statements about JMS publishing times is certainly persistent. The performance has been a bit improved in the meantime.

    -- Andreas
  57. Andreas,

    Those are some impressive numbers. Much more in line with what I would expect.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  58. Another interesting example that demonstrate how Jini/JavaSpaces can be integrated with J2EE can be found under the following url:

    http://www.onjava.com/pub/a/onjava/2002/07/17/tomcluster.html?page=1

    "This article describes how Web applications can benefit from clustering and presents a clustering solution that we developed for the Jakarta Tomcat Servlet Engine to provide high scalability, load-balancing, and high availability using JavaSpaces technology."

    Nati Shalom
    CTO GigaSpaces Technologies
  59. Complex tasks processing can be done in a very limited way with J2EE.


    Yep. Jini's amorphous and J2EE ain't.
  60. What JINI Needs[ Go to top ]

    J2EE is better for centralized static software services. JINI is quite the oppoisite, being better for decentralized dynamic services.

    The corporate world has not really found too many uses for JINI. Can you think of many business processes which have dynamic rules?

    Here are the top three things Jini needs to survive.

    1) Jini needs a killer app, a dynamic parallel processing service is a nice thought, but horsepower is cheap and parallelism is more easily handled by the OS. I don't think Javaspaces is it, queuing is already cheap and main stream. I think being a turbo web service repository is it.

    2) Jini needs security. Version 1 had no security, and they are trying to address this in Version 2. A RMI security spec which Jini was going to use got shot down by the J2EE vendors. A security service in the SDK, and not a 300 page spec would help.

    3) Jini needs Web Services. Jini will become Web Service roadkill unless it is interoperable with SOAP and UDDI. JINI has some nice features that web services don't, like the service user interface, and better lifecycle/registration managent. But Jini has no support from IBM, Oracle, and BEA, and they drive the Java community. Making JINI a killer Web Services backbone with major vendor support would help.

    I love JINI but short of these 3, I think SOAP/UDDI will kill it.

    Cheers,

    Mark
  61. What JINI Needs[ Go to top ]


    > I love JINI but short of these 3, I think SOAP/UDDI will kill it.
    >

    Actually I think SOAP/UDDI will demonstrate (if it ever gets that far) the fragility (lunacy ?) of developing to data structures (XML) instead of objects/interfaces (Jini)

    ;-)
  62. Services, the future.[ Go to top ]

    Agreed!
    Jini is a technology ahead of its time, services are the way of the future, not data structures.
  63. SOAP/XML buzz words...[ Go to top ]

    Hahaha...
    At what point do you consider SOAP/UDDI anything special, for one you are talking about administrative overhead, the actual need for a "HUMAN" to take a wsdl file and generate java objects from it. This is more primitive than RMI...
    Why do you think that XML is something special, its nothing more than a mark up language, and UDDI is nothing more than a static data structure that solves nothing that JNDI or any registry has already solved. Its this kind of appeal to commercial hype that scares me, I should act like others on this discussion and raise the question, where is a SOAP/UDDI system that reflects anything special? Personally I believe SOAP/UDDI is an "OK" technology, but fails incredible when it comes to complex behavior. Sure if you want to send a "HELLO" string across the net, then use SOAP, hence "SIMPLE OBJECT ACCESS PROTOCOL", but if you want to send complex dynamic behavior across the net with SOAP, then I would say, good luck my friend, try encapsulating real logic in a flat meta-language like XML... SOAP and UDDI, are nothing more than "BUZZ" words in today’s industry, the technology is purely driven by giants, and definitely fails to reflect anything robust. SOAP/UDDI is nothing more than an attempt to displace CORBA and RMI.
  64. Hmmmmm[ Go to top ]

    While it may sometimes fall short in some areas, I don't think you can really discount SOAP/UDDI as a viable protocol. Sending complex data structures around in SOAP gives you a little more freedom in changing your data structure, as well as being able to analyze any anomilies that you might encounter. Of course there is also the obvious benefit of being able to talk to different types of systems. Anyway, doesn't seem fair to completely discount this ability all together.
  65. SOAP/XML buzz words...[ Go to top ]

    Hahaha...

    > At what point do you consider SOAP/UDDI anything special, for one you are talking about administrative overhead, the actual need for a "HUMAN" to take a wsdl file and generate java objects from it. This is more primitive than RMI...
    > Why do you think that XML is something special, its nothing more than a mark up language, and UDDI is nothing more than a static data structure that solves nothing that JNDI or any registry has already solved. Its this kind of appeal to commercial hype that scares me, I should act like others on this discussion and raise the question, where is a SOAP/UDDI system that reflects anything special? Personally I believe SOAP/UDDI is an "OK" technology, but fails incredible when it comes to complex behavior. Sure if you want to send a "HELLO" string across the net, then use SOAP, hence "SIMPLE OBJECT ACCESS PROTOCOL", but if you want to send complex dynamic behavior across the net with SOAP, then I would say, good luck my friend, try encapsulating real logic in a flat meta-language like XML... SOAP and UDDI, are nothing more than "BUZZ" words in today&#8217;s industry, the technology is purely driven by giants, and definitely fails to reflect anything robust. SOAP/UDDI is nothing more than an attempt to displace CORBA and RMI.

    I can't agree more. Web Services is just hype and a replacement for CORBA. It's kinda funny isn't it? I mean, why would you realy want to know anything about the transport protocol? To me, Web Services should never have gone beyond:

    http://www.xmlrpc.org/spec

    You can't get more simple than that. You really don't need anything more.
  66. The road less traveled[ Go to top ]

    Petite Josh wrote:
    > Why do you think that XML is something special, its nothing more than a mark up language, and UDDI is nothing more than a static data structure that solves nothing that JNDI or any registry has already solved.

    You're right, XML, SOAP, WSDL and UDDI are nothing special in and of themselves. Primitive in fact.

    What is special is the industry agreement that has built up around them. Classic network effect, market tip dynamics. This leads to higher order protocols like UBL, which will allow me to integrate someone into my supply/info chain without any new coding.

    I used to work in the object database world, so perhaps I know better than most the draw of desperately cool technology that solves problems that established technologies don't. We could do wonderful things with object databases, but they were just far enough out of the mainstream that only those whose problems couldn't be solved using relational would try.

    Several Jini advocates in this thread have said things like "Jini apps don't have to be distributed", and "With Jini you can solve the same sorts of distributed apps that J2EE solves." Both are no doubt true.

    But it doesn't matter. J2EE solves these apps. The design center for J2EE provides technology specific to the solving of these apps, and people know it, so they will use it until they *really* need something it doesn't do. Jini doesn't specifically address this kind of app, so it will by and large not be considered.

    I can drive screws with a hammer, but I tend to choose a tool designed for screws because it is a whole lot easier. There are lots of books on writing web commerce apps in J2EE. There are tools to build J2EE components for web commerce apps. Lots of people write web commerce apps. In short, there is a pile of existing infrastructure that leads those interested in web commerce apps to J2EE as a technology.

    Does this mean that J2EE should be used for everything? No! Jini solves real problems. One key use is to solve distribution / discovery problems within the appsever cluster. This is cool, and useful. Developers of appservers are different folks than developers of applications, with different problems to solve.

    Someone else in this thread berated another poster for not taking the time to read the specs and (paraphasing) gain enlightenment that Jini was solid technology. Get real! You (the Jini community) need to provide better reasons for me to read the specs. Like a list of useful classes of applications that Jini is better suited for than the other platforms, and why (pros and cons). Sell people on using Jini for their next app by telling them why their app is easier to solve in Jini, or will work better afterwards. What are the cost/benefit tradeoffs? Etc.

    In other words, market the darn thing. XML et. al. are important because they've captured people's imaginations, so the network effect adds to their value. Jini has not, so it doesn't.

    glen
  67. JXTA[ Go to top ]

    All this talnk and nothing about JXTA? It is the marriage of JINI and XML. The cool thing it adds to JINI (I beilive, let me know if I am wrong) is Routing at the Application level, for devices that are not always on the network, behind firewalls etc.
  68. It's about avoiding distribution[ Go to top ]

    As the JINI folks say, Jini is great for distribution and this is its strength. My guess is that this is why Jini hasn't been widely adopted yet. Anybody who has written a real distributable application knows that, you must AVOID distribution whenever possible. You minimize communication between nodes. Distributed transactons are expensive, distributed method calls are expensive. One of the first optimizations when I go on a client site is to run as many services WITHIN VM to avoid serialization and network calls. I mean, come on, that's distributed computing 101.

    This whole idea of distributed services dynamically discovering and communicating with eachother on a B2B environment is such a pipe dream. DCE, CORBA, and Web Services all promised the same thing. It is a nice dream, but the reality with production systems is that you must know all the parameters of your system so that you can minimize faults and minimize your risks.

    Maybe I'm way off base here.

    Bill
  69. It's about avoiding distribution[ Go to top ]

    Sorry one more thing.

    THis is why J2EE is so popular. J2EE was never about defining distributed communication. It was actually meant to be built upon and to leverage other standards like RMI and CORBA. J2EE was meant to expose a transaction manager, define transaction demarcation on method calls. Provide security role definition, persistence mappings, etc. This functionality really doesn't care or even need to know whether things are remote or in-VM. I guess what I'm saying is that J2EE is a definition of services rather than a definition of how services should interact and be discovered on a dynamic network.

    Bill
  70. Who says that Jini needs to operate in a distributed environemnt? If you look at the Jini spec, nowhere does it say you cant do traditional client/server, it has the tools to do both. All Jini really focus' on is the fact that networks are inherintly failable and it deals with these issues with its leasing, failover and transaction paradigms.

    J2EE is inherintly deficient at the spec level because it doesnt take any of this into account. It basicailly lies to clients, and servers alike, that eveything is always reliable on the network and nothing will ever break, nothing will go wrong, now would you want to build a mission critcal system over that logic? I think not.

    >It was actually meant to be built upon and to leverage other standards like >RMI and CORBA. J2EE was meant to expose a transaction manager, define >transaction demarcation on method calls. Provide security role definition, >persistence mappings, etc

    You said yourself, J2EE is flawed, and until the spec is change or the ideas Jini embraces come to the fore, J2EE will remain flawed, flawed to the core!
  71. Who says that Jini needs to operate in a distributed environemnt? If you look at the Jini spec, nowhere does it say you cant do traditional client/server, it has the tools to do both. All Jini really focus' on is the fact that networks are inherintly failable and it deals with these issues with its leasing, failover and transaction paradigms.


    I'm not saying that Jini isn't a good piece of software. I'm saying that traditional client/server tries to avoid any and all distribution if possible. Where does Jini fit in, in a non-distributed environment?
     
    Bill
  72. It's about avoiding distribution[ Go to top ]

    <bill>
    THis is why J2EE is so popular. J2EE was never about defining distributed communication. It was actually meant to be built upon and to leverage other standards like RMI and CORBA. J2EE was meant to expose a transaction manager, define transaction demarcation on method calls. Provide security role definition, persistence mappings, etc.
    </bill>
    that is not entirely true. here is my reasons why J2EE is so popular.
    1. container managed transactions and database access. people love it.
    2. 'all in one' concept. JMS, JMX, JDBC, JNDI, JTA.. brings comfort
    3. good marketing...brings trust.
    4. so many J2EE vendors and developers. that shadows other solutions to gain popularity.

    J2EE is definely has its own place in the industry; very comprehensive solution for many problems or needs. J2EE is a good fit for most of the people but there is a little percentage that needs more than J2EE for whom there is JINI. That little percentage is growing as time goes. systems are getting more and more complex and Jini or something other will be needed more and more.

    In every day work, i use j2ee. we have j2ee applications in production running on weblogic and jboss. after learning Jini, i now realize that some of the stuff that we have done would be done much better with Jini. from the environment i am in, I also realized the fact that most of the developers learn and care about what the market dictates; J2EE for now. so they don't want to go deep down into new stuff. managers, they are another story; they don't want to hear any other big word like Jini. they want to go with what market does. these are known things i know but i think, this is one of the biggest reason why Jini could not reach to mainstream market.

    btw. Bill, you should see JPower at jpower.org. JPower is a JavaSpace implementation that is built on top of JBoss micro kernel and written in custom dynamic proxy based AOP. i thought you might be interested in seeing this because of your mission at JBoss and JBossAOP.
  73. AOP in JPower[ Go to top ]


    > btw. Bill, you should see JPower at jpower.org. JPower is a JavaSpace implementation that is built on top of JBoss micro kernel and written in custom dynamic proxy based AOP. i thought you might be interested in seeing this because of your mission at JBoss and JBossAOP.

    I'd be interested in speaking with the JPower guys if they're interested in hearing about JBoss AOP. You can reach me at bill at jboss dot org. I'll try to find one of their addresses.

    Regards,

    Bill
  74. Container...[ Go to top ]

    What if IBM, BEA or Sun or JBoss makes a "container" that uses Jini/JavaSpaces and gives you the same things that WebSphere, Weblogic or One7 -and all that thigs you can do whith Jini/JS-?

    Would you use J2EE or Jini solution?
  75. Container...[ Go to top ]

    No, because the Enterprise Bean Specification is flawed, you just have to read all the discussion forums on Entity Beans to find that out. Its just far to heavyweight and much too complicated.