Summary
I had a conversation with my brother about Jini technologies. He got the difference in thinking, do you?
Advertisement
I was talking with my brother about a project that involved using Jini. He was using terms and technologies in his part of the conversation that are prevalent in the non-Jini way of thinking. So I tried to provide a useful example of how thinking the Jini way, and using the Jini technologies provided some recognizable benefit. Here's roughly what I said to him:
"In this application, you could just write some code that queried the SQL database and configure the security model of that database to allow certain people to do certain things with certain tables and rows. But, in the Jini world, we would manifest the operations that you wanted to perform as a Java interface, and then provide some code as a service that implemented that interface and did the database work.
If you need duplicity in the server, for fail over, you'd normally need to configure the database clients with the addresses of the servers. Also. if you wanted to use a different vendors database, you'd have to distribute new drivers potentially. What if the cost effective database can't do security in the model you need. What if its not fast enough, later on and you need a Object database or some other incore solution with write through caching etc. There are other things that you might end up with in your client code, that would really not be details that you wanted to be manifested everywhere. The Jini service concept used as a facade for the database operations can hide many of these types things.
If you buy into using a Jini service instead of SQL server, then you also now get the ability to use the lookup server to find the different database instances. Now you get ability to not distribute server addresses everywhere because you can use multicast discovery to find the database facade services through the Jini LUS.
Another interesting thing is that you've codified the exact actions of the system as an interface. You can use the Jini 2.0 security model against this model to protect specific actions of the system explicitly, in ways that people can understand. There aren't 10 different security constraints hidden in the database that provide the security model which might not work in another database.
Using the Jini 2.0 security mechanisms, you can implement the required security model you need through the use of the Jini 2.0 Configuration implementation. You could have fast databases that are only accessible to a select group of individuals, and slower, or time based access for others. This is all implementable completely separate from your database vendors security model.
So, in summary, this is not really magic, or amazingly complex technology. But, what it really is, is a way to think about problem solving that provides an enabling, flexible architecture.
You use a facade service to hide the details of what happens with databases, behind the scenes.
You can then use Jini multicast discovery to remove explicit IP addresses from the picture for database/persistent storage server access from the clients perspective.
Because you're using the LUS, you get leased presence in the system so that systems
that are not up do not get in the way (a TCP SYN, sent to a non-visible IP address will typically cause a very long timeout delay). A database facade server that is not up, quickly disappears from the LUS list, and the clients will stop trying to access it.
When you want to change the implementation of the database storage, you can do that, and deploy a new service with the new implementation. It will appear in the LUS, and be
accessible to those who have access as configured in the security model (including
limiting it to developers for testing when complex interactions need special testing).
And, there are several other interesting capabilities and enabling factors that the Jini way adds to the picture."
What my brother recognized was that it wasn't magic or amazingly complex, but Jini provided a tremendous amount of flexibility in how the system was managed. It could be changed over time to use different technologies, The system was independent of the 3rd party technologies, such as databases, that could be likely to change on a moments notice.
All of the patterns that are prevalent in Jini technologies, don't always amaze people. But, if you put all of them together, and use them in your day to day problem solving, you will find yourself developing some rather amazing applications that will amaze people and will provide seemingly magic capabilities to repair, heal and extend themselves day in and day out.
Encapsualting database-access has nothing to do with jini, does it?! If this is desirable (and in contrast to the author I think there are situations, where this is NOT desirable), there exist many options, none of which is especially "jini" (and also: none of which is especially app-server)- jini just happens in a different layer. To make the benefits of jini clear to the non-jini-world, it's important not to compare apples to oranges: Which topics does jini address and which it does not address - encapsulating databases is definetely a topic where techniques like jdbc/DAO, JDO, CMP, Object-Relational-Mappings play a role - whereas jini just provides easy, convenient remote access to these services - It's about the difference about a services-infrastructure and the services-implementation.
> Everything described here can be achieved with J2EE based > middleware. So why would I bother with Jini?
Let's apply that kind of reasoning to cars:
I've got a Ford Taurus that accepts petrol and goes from A to B in reasonable time why would I want a BMW ZM Coupe?
Now, if you're a petrolhead like me, you turn around and say, because the BMW is faster, accelerates better, handles better and has a fantastic engine note. Other people might say because it looks better, comes with a better set of default options, that they prefer the customer service or whatever.
So what am I saying? You have to look deeper than just, I can do it with X so why would I use Y? We used to use sockets and custom protocols to do all remote communication so why did we switch to RPC and then CORBA - after all they just do the same thing right?
> Everything described here can be achieved with J2EE based > middleware. So why would I bother with Jini?
Well, I guess that is still for you to decide. Please explain how you would solve this problem with J2EE. Please include how you would implement security from the clients perspective and from the servers perspective. Please include in your explanation how you would keep the client software up to date with the current requirements of the server. Also, explain how you would make this work in an insecure network environment. Also, let me know how you would provide distributed transactional services that would allow a client to disappear off of the network while a transaction was in progress, and be able to rejoin that transaction later.
I am serious, here's your chance to educate the world!
> encapsulating databases is definetely a topic where > techniques like jdbc/DAO, JDO, CMP, > Object-Relational-Mappings play a role
From my perspective these look like database-access technologies not technologies I'd use to encapsulate a database.
IMHO, you've chosen to compare apples to oranges - Gregg hasn't. The perspective he's presenting comes from an entirely different place than "how to do database access".
> Encapsualting database-access has nothing to do with jini, > does it?!
In this example, we are not just hiding the database. We are designing a programatic API for the exact operations that we need the database system to support so that the contract is very clearly documented. This allows users of this API to know exactly what the system was designed to support. It constrains the users in a natural way, and in empowers the implementors to optimize the operations, because they are bounded by the methods declared in the interface.
The name Jini does infact correlate to a specification of programatic logic. It indicates a number of things that have nothing to do with database encapsulation. But, just like Java is not just a language (it is a platform), the name Jini is not just the specification. The Jini way is a thought process that involves thinking about system design in a way that makes distributed processing truely possible.
If I wanted this database to be accessible off of a bluetooth network in 10 different regions of the world, and it was not important for them to be consistent (think read only), there is no reason to document the interface as strictly database centric. The use of Jini discovery mechanisms via multicast allows the users 'machines' to find the databases without any direct effort. Thus, by using the Jini infrastructue to build the facade, we've made it possible to distribute the applications more readily, and vary the implementation when needed.
> Which > topics does jini address and which it does not address - > encapsulating databases is definetely a topic where > techniques like jdbc/DAO, JDO, CMP, > Object-Relational-Mappings play a role - whereas jini just > provides easy, convenient remote access to these services > - It's about the difference about a > services-infrastructure and the services-implementation.
This is an interesting observation. Encapsulation via a local programatic API is a completely different notion from enacapsulation via a remote API. You are right that Jini 'provides easy, convenient remote access'. That is the power, idea, notion, improvement, issue, etc. that is Jini. But, I left out the word 'just' from the front of that phrase. Jini is not 'just' remote access. It includes a whole different thought process for solving problems.
Is the computer your network, or is the network your computer?
Jini enables your software to see the network as the computer!
Jini makes the network the container where you run your software. J2EE makes the JVM instance your container.
With Jini, you can take your Jini service anywhere there is a JVM. Your service can talk to anything visible on the network that implements the interface you need.
With J2EE you can take your software anywhere there is another J2EE container, and it can talk to anything it originally was programmed to talk to.
From the start, writing a Jini service empowers you to make the decision to distribute your application services whereever you need to.
From the start, J2EE makes sure that you need a container, and all the other pieces of your application to be structured and organized the same way they were when you designed your application.
I'll grant that if you are starting to thing correctly about distributed computing, you may have provided some programatic and configuration based variation in your J2EE service to allow it to be restructured.
Jini provides this as part of the design and API of the system. You use service discovery from the start, so, its not extra programming work to make your application find its piece parts anywhere on the network that you want to put them.
I don't know call me skeptical - Jini was first pitched for rapid assembly of casual networks of portable devices - only that doesn't work. Jini doesn't fit into most J2ME devices.
Jini was then pitched as a way to distribute drivers for printers and such. I didn't see a tremendous amount of uptake on that front either. I imagine the fact that a lot of software isn't written in Java (like nearly all shrinkwrapped apps) has something to do with that.
Now it seems that its supporters want to pitch it as an alternative to J2EE/EJBs. Maybe that's good. I certainly think EJBs are pretty pointless. But the Jini crowd's credibility is looking a bit thin at this point. I'm not sold.
Using your example, I'll have to implement all my database access using some database technology - and if I want to change the technology, I'll have to re-implement all the database accesses. Or if I want to extend the sorts of things I can do I'll have to do it all in code.
JDBC is already a facade for accessing a database. Tools like Cayenne provide a facade for data access using - among other things - JDBC.
Maybe you have a more compelling example. That might be good. If you can argue that we could pitch JNDI, EJB, and a lot of other things and make Jini THE logic distribution system for Java I would probably support that.
But right now Jini is looking a bit like a 5th wheel. It duplicates a lot of mechanisms for benefits that do not look at all clear.
I think some of the problems with Jini "evangelism" are in some ways similar to those of XP -- a bit too much arrogance by those who "get it."
I've more than once heard Jini proponents use that code phrase referring to Jini. There are those who "get it" and those who don't "get it." If you don't "get it" it is because you don't understand; i.e. you are stupid. It is impossible for you to understand Jini (or "get it") and not agree that you should use it. Likewise, in XP: if you look at it, try it and decide it isn't for you, they say you haven't tried it enough, or you haven't done it correctly, or completely and that's why you don't "get it" (reminiscent of Bolkonski's (or Toltoy's as it were) musings the German general Pfuel). In Christianity, they say you have not "seen the light." In Islam they say simply that you are an infidel. And so on.
I think this does a disservice to the promotion of the technology, because it is a real turn-off to those who might otherwise have some interest in it. I also think it is generally a mistake to assume those who don't agree with you simply don't understand, or are ignorant and stupid (not to mention stubborn).
Additionally, it must be recognized that while Jini is a useful technology (or specification, or thought process, if you prefer), it is by no means of universal applicability. It is useful where certain conditions and needs exist. It does take extra work, education and time to implement a solution using Jini, so like anything else, the advantages and disadvantages of it need to be balanced.
(by the way, is duplicity in a server a good thing? ;-)
> I've got a Ford Taurus that accepts petrol and goes from A > to B in reasonable time why would I want a BMW ZM Coupe?
My job is to solve the customers problem. I don't care if it's a freaking bus driving between points A and B as long as it gets me there. Ok?
> So what am I saying? You have to look deeper than just, I > can do it with X so why would I use Y? We used to use > sockets and custom protocols to do all remote > communication so why did we switch to RPC and then CORBA - > after all they just do the same thing right?
So rather than reciting trite car analogies, why don't you explain to me and everyone else what does Jini do so differently compared to J2EE based middleware that I should care?
> Please include how you would implement security from the > clients perspective and from the servers perspective.
Specify your security requirements. What are you looking for beyond propagating the clients principals and credentials?
> Please include in your explanation how you would keep the > client software up to date with the current requirements > of the server.
Specify the server's requirements for the use case.
> Also, explain how you would make this work > in an insecure network environment.
Please be more specific. Downloading class implementation from the server to the client? What are you looking for beyond encrypted network layer and digitally signed classes?
> Also, let me know how > you would provide distributed transactional services that > would allow a client to disappear off of the network while > a transaction was in progress, and be able to rejoin that > transaction later.
Specify your requirements as they go beyond existing DTM functionality.
> I am serious, here's your chance to educate the world!
I'm looking to understand what does Jini offer beyond the established middleware solution we have today. I would not think this is so difficult to answer.
> > So rather than reciting trite car analogies, why don't you > explain to me and everyone else what does Jini do so > differently compared to J2EE based middleware that I > should care?
Man, why are you coming across so angry? Did you really want to have a discussion? I presented the analogy as a genuine effort to try and encourage a dialog with you and what I got back was flame.
> > My job is to solve the customers problem. I don't care if > it's a freaking bus driving between points A and B as long > as it gets me there. Ok? >
Okay, so if I read you correctly, you're saying that all you care about is getting from A to B? You don't care about what kind of solution? If that's really your position, what is there left to discuss?
> Jini was first pitched for rapid assembly of casual > networks of portable devices only that doesn't work. > Jini doesn't fit into most J2ME devices.
It does work in small devices using the Surrogate architecture or a similar solution where the devices can talk to something that mascarades the devices as Jini services to the rest of the world.
> Jini was then pitched as a way to distribute drivers for > printers and such.
The fact that Microsoft and Apple haven't provided the client side implementation is a bigger issue.
> Now it seems that its supporters want to pitch it as an > alternative to J2EE/EJBs. Maybe that's good. I certainly > think EJBs are pretty pointless. But the Jini crowd's > credibility is looking a bit thin at this point. I'm not > sold.
I see that some members of the Jini community, beside myself are trying to make Jini more visible. I sense that developers are not sure of the technologies penetration into the marketplace. Thus they think it is dead. Some people are using phrases that come across as "Jini doesn't provide anything new". So, I (and others it seems) are making efforts to try and provide examples of where Jini technologies and architectures provide benefits in our view. Now, clearly, we all don't see things the same way, so we will likely get to have some arguments about details...
> Using your example, I'll have to implement all my database > access using some database technology - and if I want to > change the technology, I'll have to re-implement all the > database accesses. Or if I want to extend the sorts of > things I can do I'll have to do it all in code.
The issue is codifying all of you database activies as operations such as. public interface RemoteEditor { public void addUser( String name ); public void addGroup( String grp ); public void addGroupMember( String grp, String name ); public void removeUser( String name ); public void remoteGroup( String grp ); public WidgetDescriptor createWidget( String name ); public void grantUserAccess( WidgetDescriptor widge, String user ); public void grantGroupAccess( WidgeDescriptor widge, String grp ); public void removeWdiget( WidgetDescriptor widge ); }
> JDBC is already a facade for accessing a database. Tools > like Cayenne provide a facade for data access using - > among other things - JDBC.
What happens when you need to reorganize your database structure to improve searchability? Now you get to change all your database access code in lots of places to make all the correct calls. In a large system, there might be multiple client software tools accessing the system. It makes no sense to design your system so that maintainence is spread everywhere I think.
> Maybe you have a more compelling example. That might be > good. If you can argue that we could pitch JNDI, EJB, and > a lot of other things and make Jini THE logic distribution > system for Java I would probably support that.
The network is the computer. EJBs could generally be better wrapped as Jini services. JNDI lookup by name is not nearly as powerful as Jini lookup. With Jini, you can ask for a service by interface, and by name so that versioning happens programatically, not administratively.
> But right now Jini is looking a bit like a 5th wheel. It > duplicates a lot of mechanisms for benefits that do not > look at all clear.
I have learned to solve problems differently, and to think about projects differently. One of the primary issues with Jini is that it appears to be very Java Centric. But, it actually has everything that the Java platform provides, plus more that the Jini Extensible Remote Invocation (JERI) implementation provides for interfacing to the world.
The Jini design compels you to think about remote errors and exceptions up front because of the RMI programming model. This makes me automatically think about how I will distribute the system in a way that it can continue to function as best as possible. I design APIs to be idempotent so that I can avoid global state.
Jini design pardigms and concepts are part of my basic thought processes...
> I think some of the problems with Jini "evangelism" are in > some ways similar to those of XP -- a bit too much > arrogance by those who "get it."
There is certainly a bit of mystery we all feel when the obvious to us, appears as not so obvious to others. I am sorry that you perceive some arrogance in some of the 'get it' commentary.
What I am trying to do is provide enough information so that arguments against help us to understand that they do "get it", but still "don't need it".
There is much about distributed computing that is not well understood until you get "under the hood". It can be overwhelming.
In 1995, I was having an argument on an internal newsgroup at AT&T with a gentleman who said that Java was slow and useless to him and that he would not spend anytime to learn more about it. I told him that was a short sighted position to take. I stressed my feelings that Java was here to stay and that if he didn't keep up with it, even if he couldn't use it, that some day all his competitors would be using Java and running right over him in the market place. I don't know if that is what actually happened as I left in 1997.
But, I feel that Jini needs the same attention. You might not see the need for it yet, but there are so many people using it internally to make their businesses work better. They are creating a competitive advantage by having systems that are more robust and more flexible than their competitors might have, and thus providing a operational cost advantage to themselves.
I heard from the Sun Jini team that there was not a huge participation from industry at the 7th Jini community meeting because many did not want to share the advantages that they have with their competitors. I, myself would say that Jini is so simple to use and provides such a powerful solution with such a small amount of software, that from a time perspective, if your competitors knew what you where doing, they could recreate it very quickly, from scratch. So, I too would be a bit reluctant to talk about some of the things that we do with Jini.
Flat View: This topic has 21 replies
on 2 pages
[
12
|
»
]
Previous Topic
