----- Original Message ---- > From: Sam Chance <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, November 14, 2008 8:52:30 PM > Subject: Re: Future of Jini/River > > All, > > Many of you may be familiar with companies like GlobalInfoTek and Paremus. > GlobalInfoTek has implemented a capability called "Intelligent Services > Layer" (ISL) and a composition layer on top of it called CHAIN. You can go > to their website to learn more. > > Paremus has built a distributed services framework that manages OSGi bundles > (components) and assembles them into systems using a Service Component > Architecture (SCA) based model. > > Both of these feature the various autonomic properties provided by > Jini...and more. They're awesome and we never have to talk about Jini. >
Seems with significatn differences in memory requirements, OS targets, and as far as I can tell application targets/markets. Always more to read though. > Then we have "SOA". I suppose we've bemoaned the fact that XML Web Services > don't = SOA and vice verse. However, SOAP/WSDL and REST/WADL remain all the > rage. I always argue we have JBOWS and not SOA. (Just a Bunch of Web > Services). But I doubt anyone cares! :-) > > Still, the static nature of mainstream SOA presents *yet another* > opportunity for Jini/River to emerge as relevant. For example, service > discovery is some pathetic attempt to register service descriptions in a > UDDI. Nobody uses or likes UDDI. Well, I'm sure someone does. :) > UDDI has it's place. Just like JMDNS below. These are all targeting different problems necessarily. I have seen you use irrelevant for describing Jini a couple times. My view is it is very relevant in its current form just maybe not as popular or well known, which may be your meaning, but it isn't a model one would use in every application nor is it related to web services necessarily, nor is it really understood by many. I would argue the same thing about Java EE and EJB. Not understanding something doesn't mean the issue it solves isn't relevant nor is it wrong at the base layer in the overall approach to solving the problem, but don't let that confuse the issue that things can always be made simpler such as deployment or installation and embedding etc. Realizing no one needs a course on WS, XML web services are all about interoperability and single point RPC and data transfer; at least this is their initial design, and this is why we now see REST and different remoting protocols for things to try to make these things more performant as they were not designed to be used the way they are actually being used today as full blown application support, and is why RMI and other things still have their place versus XML web services. I feel most of these technologies have been a little misused for the sake of heterogenious front ends at the expense of performance, or in the case of RMI at times, used for data transfer at the expense of heterogenious data access calls; at least this is the only way I can explain the constant shift in patterns as it relates to them JAX-RPC, JAX-WS, *-RS, what's next :-). Jini as I see it is about performance driven distributed discoverable services which provides not only services, in the sense different from web services, but distributed and concurrent memory through JavaSpaces. A totally differnet technology though solving some of the same issues. Now, if there is a market for such support under the hood, to operate over SOAP and web services, but not as the default or main reason for Jini's being, then I don't think that is a bad thing necesarily. The transport layer is already pluggable, but to me really, the only thing that solves, as services are not defined in something like WSDL but instead interfaces etc, and that seems that would just be a whole lot of work to not necessarily solve the real issues with Jini at the moment which seem more related to learning curves and not the technology itself except for those things listed as needing to be addressed. Folks are using Rio and like and they seem to find most useful the general concepts of Jini because they solve unique problems really. As it relates to web services or any other kind of service, and as it relates to Java per the nature of Jini, I think Jini could be used to locate or integrate about anything. > As another example, I recently attended a "No Fluff, Just Stuff" conference > wherein the speaker was talking about REST and Resource Oriented > Architecture. In his talk, he showed an example of (location independent) > service discovery. His discovery mechanism? JMDNS (jmdns.sourceforge.net). > I asked him if he heard of Jini and, if so, what he thought of it. His > answer: Yes. It's too complicated and overkill. He's a smart, well informed > technology leader and HE doesn't appreciate Jini! > Again I argue solving different problems here. Jini isn't WS nor REST, and the discovery mechanisms in Jini, through interfaces and remote downloadable code, are more descriptive and powerful than what DNS Srv and multicast DNS (JMDNS) is trying to solve. JMDNS tells you where a given service is by protocol and what port where as Jini gives you the services and they can use what ever kinds of proxies and interfaces they have been programmed to use and then system administrators need to follow whatever documentation is available for those services such as open ports XYZ on firewalls and routers etc. Take my Dell 1720dn printers. The driver is installed by a disk, and is running in the OS as an OS level service as a printer driver. It then communicates on the ports the service in the printer is configured. I have to configure my network or them to deal with the situation depending on my needs. Jini works on this level except the device or remote services remotely install their own code through the service versus a driver disk. This can be in a desktop or server computer or on some other small type device which can implement the Jini protocols and class interfaces etc. This is a little different than DNS level services or service by name or protocol. Suttle from a birds eye view, but very different at the implementation and problem/domain level. > Why couldn't Jini explicitly address the service discovery challenges > currently prominent in mainstream SOA? Why can't I log into my machine and > see available services pushed to me - perhaps filtered by security, roles, > interests, etc? I don't care where they are; I just want to use them. > Pretty much Jini solves this although not through a UI of some sort, but instead for other applications through API. Now, the security stuff I'm not all sure about yet, but you can do that for sure. It would be very easy to filter per roles and security as long as the services you have coded are using some kind of interface and you can ask them if you have rights to use them etc based on some credential. I don't really know what is and isn't supported at the Jini level as it relates to security other than building it in yourself, but this is one of the things which has been talked about addressing in the thread where a list of wants and needs was listed. > Why can't we do discovery over the Internet? At least an Enterprise > Intranet? > There isn't anything keeping Jini from working on a broader network now that I know of. Routers need to be configured to forward multicast packets. Over the internet can be an issue because of packet delivery etc. Many ISPs won't support multicast. This is where Unicast comes in handy. > I would (almost) bet money that various Jini/River-based projects (currently > floundering in obscurity) address or begin to address these challenges / > needs? > Sure. This happens with anything solving harder problems. This is the exact same thing with Spring, Hibernate, and others as it relates to JEE, and look at the ideas which have been moving into JEE over the passed two iterations (one in the works 6). That makes the core standards and ideas better. There has to be some central ideas for other things to build atop. Had there not been JavaBeans would Spring look the same today? I doubt it. What about JEE? What if JEE didn't exist? Then would Spring exist? If so, then where would the standards related to clustering and session replication have come, what about those central ideas? This is the nature of the business yet folks tend to forget it and not see it, and is why JEE tends to get a bad rap too, and folks forget all the problems JEE solves such as clustering, session replication, distributed and remote services and data, transactions, and scheduling. > I think we ought to confront the reality that technology does not > necessarily rise to large-scale adoption based on merits, but ease of > understanding and ease of use and marketing. In fact, I've heard folks > nicely describe the process as "Awareness, Appreciation, then Preference." > Here I point to my last paragraph how things build on top of other things. At the heart of Jini is a pretty unique problem solving solution; similar here and there to other things yet not the same. That core value is there. Now, making that core value easier to use and more approachable/adoptable shouldn't limit what it can do, but should merely allow a set of abstractions which make it easier yet do not get in the way when one needs to get low level with the technology. I have used different APIs in different technologies and environments which could have been much better if there hadn't been too much hand holding without exposing the hairy details if needed, and those things are fine when the problem you solve is simple, but when it gets complex it is better to have the details in the open so that one can become an expert and get the most from the system. > River lacks the first two, and thus never makes it to the third. The > "River" community arguably is "balkanized". Each time this issue comes up, > a group of VERY smart technologists/engineers talks about things like > "serialization, marshaling, interfaces, namespaces..." and all manner of > deep, into the weeds, technical jargon. But there is no coordinated effort > to simplify, educate and evangelize. No vision will lead to its eventual > death. > > I constantly bring up Jini, and the aforementioned companies, in my circles, > and I get the same results: Ignorance and apathy. > > If we can't rally around a couple of relevant uses and we if we can't > simplify it and if we can't (then) spread the gospel, then we'll not create > Awareness that leads to Appreciation and ultimately Preference. > I don't want to beat a dead horse, but I feel it would be useless to simplify or as has been said to dumb down the technology. It has to be kept in mind that the capabilities do not need to be simplified except where it might improve them, but some abstractions and fluff needs to be added to simplify the technology. No fluff is great when a problem is as easy as REST or a single connection to a single point or asking something where something is in a very generic sense, but Jini solves more technical and difficult problems. I'm all for simplification where it needs to be done, but not at the expense of functionality, and I think you can get both with abstractions, build systems, installers, tooling etc, for making things more approachable for beginners and intermediate use, but those at the top of the food chain are not going to find use in the technology if overall things are simplified and dumb downed. In that regard I don't think it is possible, and folks need to realize the differences in the problems being solved by the different technologies being talked about and not just the differences in the technologies. I agree some uses need to be detailed and some applicability needs to be demonstrated for folks to see. I too agree that it needs to be more approachable, but I think that is best handled through abstractions and tooling leaving the capabilities intact. Too, the web site and advertising the technology is important. > There is simply no way I can successfully evangelize Jini by telling people > it is a "...dynamic, distributed SOA framework..." The recipient perceives > that as a gnat on a horse's ass. They're going to ride the horse and not > even realize there's a gnat on it! > Yes, and this is where examples can help. Examples from different walks of life. Jini can be used for simple things such as: *) Service to lookup databases, servers, and ports for data access in a relaxed client server model applications. *) Service to locate web services of a given type within a network. *) Service to lookup and load code which embeds libraries to access the server layer of strict client server model applications. and for more complicated things: *) Service to lookup and operate on premises cameras. *) Service to lookup and monitor different security systems and devices on premises. *) Service to lookup and manage different on board sensors on a car or other transportation machine. *) Service to lookup and access RFID readers. and of course both lists can go on and on. I believe some good and simple examples can be created for the application level support. Some of the others can be done as well but depending on those examples where hardware is involved more expense can be involved, so those have to be studied more closely to see who wants to do them or what can be done cheaply and show off what can be done. > Since I learned about Jini in 2001, I've been a big fan. I see incredible > uses that scale from services within a machine up to planes, trains, and > automobiles... worldwide! :-) > Yes! I guess I get a little confused as you bring up Web Services and REST. Do you mean support those things in tandem or what exactly? Do you mean more example uses of Jini using these technologies? Do you mean to change Jini to use these technologies instead of the way services and logic are downloaded now? Wade
