WS-Discovery: borrowing Jini Ideas?

Discussions

News: WS-Discovery: borrowing Jini Ideas?

  1. WS-Discovery: borrowing Jini Ideas? (14 messages)

    Sun announced Jini to big fan-fare in 1999. It hasn't hit off in the way that many thought it would, and it sits in a no mans land in Sun's marketing (like JDO and other technologies). The ideas behind Jini are coming back in a new form, WS-Discovery, a new specification lead by Microsoft, Intel, BEA, and Cannon.

    Article Excerpt:

    "Microsoft and Intel see Web services popping up everywhere, but their vision is strangely reminiscent of arch rival Sun Microsystems' with an earlier technology called Jini.

    Will it be yet another example where industry clout and marketing savvy pull off a transformation that the original technology innovator could not?"


    Will Jini-like wishes come true?

    There is definitely still a lot of interest in Jini out there, and a lot of large organizations are using it. Orbitz choose to use Jini rather than jump on the web services hype train.

    Jini Community Meeting

    In related news, there is a Jini community meeting, March 23-25 in Boston, MA

    Threaded Messages (14)

  2. I think the problem here, is that Jini has been doing this kind of stuff for 5 years, and WS-Discovery is therefore a far cry from being called revolutionary.

    The key issue is devices - Jini has long tried to braoden it's field away from just devices into it's core ideas - dynamic networking. So devices are just part of what Jini can offer.

    What get's me about WS-* is the huge amount of specs, and lack of true substance


    Calum
  3. Commercial usage for Jini[ Go to top ]

    Can anyone tell some real production sotries about Commercial usage of Jini technologies?

    Isnt there new relevance to Jini with the new WiFi buzz?

    Yuval.
  4. Commercial usage for Jini[ Go to top ]

    http://wwws.sun.com/software/jini/news/success.html

    http://www.jini.org/pressrelease.html
  5. The J2EE application server we use, Macromedia's JRun4, utilizes JINI as a means to identify servers as part of a cluster. We utilize JRun4 because of the cheap price and low number of concurrent users (we're lucky to have 2000 people hit our site in a day so that's not even an average of a 100 an hour). But JRun4 uses JINI and it was much easier to setup clustering for JRun then it was for Weblogic. It took me just a few seconds in the administration tool to setup 2 machines for clustering (I know not a huge cluster but still a cluster).
  6. Isn't peer 2 peer a good technique for discovery? Could JXTA (www.jxta.org) also be a good alternative?

    I haven't reviewed JXTA detailled enough to be sure if it's valauble for WS discovery, but does someone now?
  7. Peer to peer for discovery[ Go to top ]

    Isn't peer 2 peer a good technique for discovery? Could JXTA (www.jxta.org) also be a good alternative?

    I suspect that WS-Resource renders JXTA obsolete. I'm unaware of any features that JXTA has and WS-Resource doesn't.
  8. RE: Peer to peer for discovery[ Go to top ]

    I suspect that WS-Resource renders JXTA obsolete. I'm unaware of any features that JXTA has and WS-Resource doesn't.


    Apples and Oranges I think. JXTA is a toolkit that builds a virtual network overlay on top existing networks. It also has P2P functionality for managing groups of peers and performing distributed search.


    It's what the world might look like if every device was connected to a single global network, with no firewalls or NAT to get in way.

    JXTA doesnt have much to say about what kind of data peers will exchange. You could send SOAP message, binary data, serialized java objects, etc.
  9. JXTA-based discovery[ Go to top ]

    In my master thesis I have developed a JXTA-based service registry. Instead of having a centralized registry, every service provider hosts their own service description (OWL-S + WSDL). Services are discovered by distributing JXTA queries to all peers. If a peer provides a service description that matches the query, a reference to that description is returned to the requester. This is quite similar to Jini, where multicast requests are used to discover Lookup Services, which again are queried for services.

    Kind Regards,

    Rune Peter Bjørnstad.
  10. So devices are just part of what Jini can offer. What get's me about WS-* is the huge amount of specs, and lack of true substance.

    The problem with Jini is that it's mired in Java and also held as Sun's property. As for devices, there are many more native programs that talk WSDL than there are native programs that talk Jini. Jini will learn to speak the new wire protocols, and that will keep Jini alive as a member of a greater peer-to-peer scene.
  11. The problem with Jini is that it's mired in Java and also held as Sun's property.

    Not strictly true (at least the part about being mired in Java). Jini's surrogate architecture allows non Java devices to participate (as long as thier is a proxy VM somewhere on the network).

    A company called Psinaptics has a small footprint (less than 60K) implementation of Jini's lookup service written in C that is fully JCK compliant. It is designed for embedded applications.

    Try the following link for more info:

    http://archives.java.sun.com/cgi-bin/wa?A2=ind0402&L=jini-users&P=R16129&D=0&H=0&I=-3&O=T&T=1
  12. So devices are just part of what Jini can offer. What get's me about WS-* is the huge amount of specs, and lack of true substance.

    >
    > The problem with Jini is that it's mired in Java and also held as Sun's property. As for devices, there are many more native programs that talk WSDL than there are native programs that talk Jini. Jini will learn to speak the new wire protocols, and that will keep Jini alive as a member of a greater peer-to-peer scene.

    Jini doesn't mandate that a service/system/device talks Java or Jini(technically you can't 'communicate' using Jini as a protocol, as Jini is protocol agnostic) just that you have some process somewhere that acts as a joining delegate on behalf of the service/system/device, in fact I could have, as you say, WSDL, in a proxy stored into the LUS that is downloaded into the client that then uses WSDL and SOAP to talk to a webservice on the other side of the world, that never even touches RMI, JERI or any other Jini-connected classes ever again, once it's been downloaded.

    I would say that WS do help in B2B enterprise integration, however, inside a company that uses mostly Java for it's integration, WS are too much of a bandwidth hog, for a LAN, and Jini suits very well. Especially since Jini moves away from hub and spoke architecture of J2EE

    Calum
  13. So devices are just part of what Jini can offer. What get's me about WS-* is the huge amount of specs, and lack of true substance.

    >
    > The problem with Jini is that it's mired in Java and also held as Sun's
    > property.

    Nonsense...Jini can operate in any network that has at least one virtual
    machine available. i.e. You do not need a Java VM for each device, service,
    application to represent them as a Jini service, the surrogate architecture.
    You can very easily write a service in C that can expose itself to a Jini
    enabled network. As for being the property of Sun, true, however you can download both binary and source code, freely implement the specification
    and promote your software as Jini enabled/certified if it passes the
    (free) TCK :-)
     

    >As for devices, there are many more native programs that talk WSDL >than there >are native programs that talk Jini. Jini will learn to speak the new >wire >protocols, and that will keep Jini alive as a member of a greater >peer-to-peer >scene.

    You are missing the point of Jini - Jini was designed to be protocol agnostic -
    there is no reason why you could not implement Jini with XML based wire protocols and thus also talk to WS-* stuff.

    However a simple way to view this is to think about what you would have to
    do if you changed some element of WSDL spec if you were in a pure WS-* environment vs. what you would *not* have to do in a Jini environment that treated WSDL as 'just another contract'
  14. Let me remind myself and others why Jini is good or what Jini offers.
    1. Designed with distribution in mind. Even though Distributed Computing 101 teaches 'Avoid distribution as much as you can' we see that the need for distributed computing is moving faster than the technological improvements. If distribution and parallelism are the requirements of your enterprise, then you should build your system on top of a platform that natively supports distribution.

    2. Designed with Network failures in mind. As known, network is a very vulnerable environment. I don't mean network connection only, I mean every participant of the network from application to process to device to machine to network. you need a mechanism that will tell you that the service (or service proxy) is no longer available or valid. Jini achieves this by simple Lease approach. If you cannot renew the lease which is about to expire, then service is no longer available or valid in your network.

    3. Promotes SOA. Instead of having all-in-one approach that J2EE is pushing, Jini says you should have your services like txn, lookup, persistence(...) running in your network in a loosely-coupled way.

    4. Code mobility. Jini takes advantage of Java's code mobility. Coolness here is that proxy(~stub) that moves to client can be the service itself or a hint to the service. Client doesn't have to download/install anything ahead a time.

    5. Interface based design. This is old-fashion but proven/simple/fast/effective way of software development.

    6. Rich lookup mechanism. Unlike JNDI which has primitive lookup mechanism based on name matching, Jini lookup supports attribute, and type matching.

    7. Discovery. Finally discovery. Services will discover lookup services, by which discover services registered in the network. Nothing special about it. all it takes is couple of multicast which is even optional. if it is unicast discovery used then it is nothing more than standard lookup, just like in J2EE/JNDI.

    IMHO, Discovery is just one little/tiny part of Jini...

    -talip
  15. WS-Discovery: borrowing Jini Ideas?[ Go to top ]

    "The fundamental difference is that WS-Discovery has nothing to do with Java. It's the difference between 'write once, run anywhere' with Java and 'write once, access everywhere' with Web services."

    I think that is the point. Web service is populated more and more today, but I don't think web service equals java either.