Replace EJB bloat with Jini Pattern

Discussions

J2EE patterns: Replace EJB bloat with Jini Pattern

  1. Replace EJB bloat with Jini Pattern (61 messages)

    I must admit that I am cheating a little here...This next item was cut and paste from something I wrote in a previous thread:

    Almost any Jini application, overall, is going to be faster and less of a CPU/Memory pig than most EJB-based applications. It can't help but be. For instance:

    - Instead of the completely brain-dead idea of pooling beans that are already RMI capable, you only get one remote object in RMI. What about "resource-pooling" you ask? Well, Sun's JRMP implementation can handle as many socket-connections as the host platform allows. Yes, it's true, you as the developer would have to worry about threads, but for most real developers, this is not an issue.

    - Jini-based applications have no need to store resource references such as JDBC connections into a JNDI reference pool. (Of course you could if you wanted to.) You are free to do as you like.

    - 3/4 of the services most EJB vendors provide(well, I'm mainly referncing my experiences with Weblogic) are not needed for EJB development, and thus are mainly useless wastes of memory.

    - Are you seeing a trend here? In Jini you can do WHATEVER you want with your services, while in EJB you are comforatably blanketed inside a safe, non-thinking world clearly defined by contracts and interfaces that have to be implemented by your implementations.

    - Jini has the notion of LookupCache's. This enables you to store locally on your client redundant references to remote services, as well as the ability to search and scan those references without having to actually query the LookupServices directly. This has helped me immensely in load-balancing services in my apps.

    - EJB vendors and their developers are stuck in a world where network outages, machine failures, and other anomilies are considered to be "abnormal" and thus aren't addressed. Jini on the other hand, is built and modeled around the fact that nothing on the network is reliable. Thus, you as the programmer are obligated(but not forced) to ensure that your services "play well" within this universe. Therefore, most Jini applications will be far more stable and fault-tolerant than there EJB counterparts. Go read up on it at http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-jiniology.html .

    Very cool stuff! And, if you really do like your appserver environment as I do, you can try building your own(not reccomended) or you can download the RIO project from www.jini.org.

    I would love to hear some responses from the more EJB inclined as to which technology they think is better for building enterprise software.

    Jesse



    Threaded Messages (61)

  2. 1. Questions of the "fool" man:
    - Are Jini transaction oriented? (I mean ACID transaction properties)
    - How distributed transactions (not services) are implemented using Jini (for example: transactions over multiple different databases / systems etc.)

    Do you have to manage distributed transactions by yourself (implement own 2PC) or is it done by ... (hmm) something.

    2. And - the second question:
    Is it the design pattern or the technology advertisement?
  3. Hmmm..interesting answer.

    "- Are Jini transaction oriented? (I mean ACID transaction properties)
    - How distributed transactions (not services) are implemented using Jini (for example: transactions over multiple different databases / systems etc.) "

    Yes, Jini does fully support transactions, and comes with an implemented distributes transaction manager called mahalo. Distributed transactions are handled by mahalo, which calls your services, which in turn implement methods that support transaction objects being passed in.


    "Do you have to manage distributed transactions by yourself (implement own 2PC) or is it done by ... (hmm) something."

    Hmm...Well, yes and no. Mahalo handles managing the transaction process and ensures that the overall ACID properties are met, whereas it is up to you as the service provider to implement the actual methods. In most cases this is easily achieved by using setAutoCommit(false) on your database, but in other scenerios you may have different requirements. That's what makes Jini great! You are not constrained to any particular method of participating in a transaction.


    "Is it the design pattern or the technology advertisement? "

    I think it is both. It is just a different way of thinking.

    Jesse
  4. Hi there :)
    Here are some comments on the points you made:

    1. Nice point. there are a couple of problems though:
     - beans are not RMI capable. As you know, beans don't even implement their remote interface. Any decent app server has just one remote capable object, which defers calls to the actual beans.
     - Multiplication of beans is required to enable transactionally aware entity beans. Of course, you could say you don't want entity beans all together. But then only stateless beans are pooled, and this is required for handling thread safety.
     - You and I must be living in different worlds. In my world, almost all java books, specifically those addressed at threading, has up until recently used completely broken threading concepts such as double checked locking. IMHO, Multithreading is one of the most complex concepts in computer science in general, and particularly important when writing enterprise-scale applications.
     - In my understanding, resource pooling in EJB is broader then pooling of sockets. Pooling of resources such as database connections is more important. Of course, you could write a pool yourself. But it's probably not going to be as efficient as the one your app server has. As a rule of thumb, don't reinvent the wheel.

    2. I kind of lost you here. EJB provides a standard way to look up the resources pool that provides pooled, transactionally controlled resources. If you want to access your resources without pooling or transactional control supplied by your app server, EJB is probably not the thing to use. Any way, what's the point with JNDI? EJB had to choose some standard way to do it. Besides, if you don't choose a standard way, developers new to the team will have more to learn.

    3. Our expiriences clash here, but when you don't need a service shut it down.

    4. IMHO, Interfaces and contracts are maybe the most important principle of OO design. If they annoy you so much, you can write your services in C. They'll probably run faster, too.
    Each programming restriction in EJB is there for a purpose. Please show me one that isn't.

    5. I really don't know that concept, so I can't comment. Care to explain a bit about LookupCaches?

    6. First of all, the world Jini is designed for and the enterprise world are quite different. Anyway, where do you get the idea that EJB servers are not designed to support reliable applications? If we talk about what EJB was "designed" for ("Jini on the other hand, is built and modeled around the fact that nothing on the network is reliable") you should note that reliability was one of the major design goals of EJB. Whether or not a particular server achieves it is a different point.
    I doubt you (or anyone) can implement clustering and fault tolerance better than an app server vendor within a reasonable time frame. If you can, go work for BEA. IMHO, implementing state replication, tolerant stubs, etc shouldn't be the work of a particular domain expert.


    Regardless to that, I do think many times Jini can be more appriopriate than EJB. IMHO, EJB is only efficient for maybe a fifth of the commercial projects (probably less). But EJB and Jini are not designed to do the same thing, and I don't think you can compare them. When I have a project that requires EJB, I can't even think of implementing it with Jini. For different projects, of course, Jini can be a good choice. I personally don't think it has matured enogth yet. Than again, I say the same thing about EJB :)

    Have a nice day.
    Gal
  5. Hmm...more good stuff to tear into here. I'll try as best I can.

    "- beans are not RMI capable. As you know, beans don't even implement their remote interface. Any decent app server has just one remote capable object, which defers calls to the actual beans. "

    What difference does this make?

    "- Multiplication of beans is required to enable transactionally aware entity beans. Of course, you could say you don't want entity beans all together. But then only stateless beans are pooled, and this is required for handling thread safety. "

    Hmmm...Why do you need multiple objects to handle thread safety? Isn't this a little too much overhead? Why can't your methods handle thread concurrency issues? And yes, you are right. I very much dislike the entire notion of entity beans. And what do "stateless" beans buy you? Transaction support? That is already provided for by almost all JDBC drivers, as will as sun's transaction package. Also, why would you need thread safety in a "stateless" bean? If it has no state, where are the thread concerns? Another brain-dead concept of EJB creators...


    "- You and I must be living in different worlds. In my world, almost all java books, specifically those addressed at threading, has up until recently used completely broken threading concepts such as double checked locking. IMHO, Multithreading is one of the most complex concepts in computer science in general, and particularly important when writing enterprise-scale applications. "

    Yes, I agree that they are very important concepts, and Java as a whole does not really properly handle parallelizing tasks very well in default. The one very useful Java book that I have read on this subject is "High Performance Java Platform Computing" released by Sun press which does have a great Monitor package that helps with some issues. Still, if you are scared of writing multi-threaded programs, you probably don't have any place writing enterprise software. Just MHO.

    "In my understanding, resource pooling in EJB is broader then pooling of sockets. Pooling of resources such as database connections is more important. Of course, you could write a pool yourself. But it's probably not going to be as efficient as the one your app server has. As a rule of thumb, don't reinvent the wheel. "

    This statement is rather stupid, so I will try not to flame you too much. Connection pools are VERY VERY easy to implement on your own, with test threads and all. Mine took about 45 minutes total with full unit tests complete. How is it not going to be more efficient than the app server pool? Do you think the programmers working on app-servers are ultra geek gods or something? Your assumptions are all wrong here.

    "I kind of lost you here. EJB provides a standard way to look up the resources pool that provides pooled, transactionally controlled resources. If you want to access your resources without pooling or transactional control supplied by your app server, EJB is probably not the thing to use. Any way, what's the point with JNDI? EJB had to choose some standard way to do it. Besides, if you don't choose a standard way, developers new to the team will have more to learn. "

    Was this in response to the Jini lookup service remark? Good. Well, no you have it wrong. Jini does pool your "services" (or, resources as you call them) in memory as marshalled objects that it scans for matches. The one major difference here is that in Jini you search for an Interface, not text. What transaction control do you have over your resources other than what JDBC provides with database transactions. I think some of you EJB guys have sort of warped views of what transactions are and how app-servers provide them. Do you know what they are?? JDBC transactions! Wowee! Do you know how to do this yourself?
    conn.setAutoCommit(false);
    //do something
    conn.commit();

    //exception
    conn.rollback()..

    Wow...Not too hard huh? Anyway, back to the flame. What's the point with JNDI? Well, to be quite honest, JNDI sucks.

    -Why should I look up my objects by some textual name if I already know what object I'm dealing with? Ie, interface.

    -JNDI introduces single points of failure in the lookup service location that you must hard-code into your EJB apps. JINI apps do not have this problem as most of them find lookup services dynamically without ever knowing their I/P dns address..Ever.

    "Besides, if you don't choose a standard way, developers new to the team will have more to learn. "

    That's another thing. Since we don't use EJB where I work, we don't get most of the shitty developers that that technology breeds. Our developers are most capable people fully able to understand the JINI concepts just as well as JNDI or anything else. Give me a break.

    "Our expiriences clash here, but when you don't need a service shut it down. "

    Really now? Just bring it down in EJB? I'd like to see that. Will all of your client apps run perfectly well with this service "down", and will they automatically re-discover it when it comes back up?

    "IMHO, Interfaces and contracts are maybe the most important principle of OO design. If they annoy you so much, you can write your services in C. They'll probably run faster, too.
    Each programming restriction in EJB is there for a purpose. Please show me one that isn't. "

    No no no...You read me wrong there. I like interfaces, just not stupid redundant interfaces, that's all. I'm sure the J2EE folks meant will with their EJB features, and I'm sure all had a "purpose" of some kind or another. I'm just saying that there is a better way, and that EJB sucks as an enterprise programming paradigm all together.

    "I really don't know that concept, so I can't comment. Care to explain a bit about LookupCaches? "

    Sure thing! One of the many concepts behind Jini, is the most standard one of you as an application developer creating your "service". Typically in most Jini deployments you will run multiple redundant services to achieve higher fault-tolerance in the face of unknown environment catastrophes. The lookup cache serves many purposes, but the main one that I like is it's ability to go out and find services that you are interested in and stores their proxy references remotely. This way makes it MUCH faster to find services that you are interested in, and discard bad services that either don't meet your QOS(quality of service) expectations , or are just plain behaving badly.


    "First of all, the world Jini is designed for and the enterprise world are quite different. "

    Oops....Quite wrong here my friend. Unfortunately, Sun's marketing department has not done much to help this sort of Jini awareness. Devices are what the Jini group gave to them to help make it easier for people to understand Jini. The real value of it (in my opinion, as well as many others) comes in its use in the enterprise. We use it as an enterprise wide solution for building medical systems for hospitals, where peoples lives depend on your app running flawlessly and EJB "bloat" and mistakes are not allowed. Cisco, WorldCom, and many others are also using it in the enterprise.


    "Anyway, where do you get the idea that EJB servers are not designed to support reliable applications? If we talk about what EJB was "designed" for ("Jini on the other hand, is built and modeled around the fact that nothing on the network is reliable") you should note that reliability was one of the major design goals of EJB. Whether or not a particular server achieves it is a different point. "

    Wrong again my friend. What a pity. This is another problem with most programmers today. They seem to always try and ignore issues such as server-crashes, network outages, bad code, etc.... Jini on the other hand is built from the ground up to provide this. The major design goals of EJB was reliabilty?? What a crock of shit. The major design goals of EJB were to make it easy for bad programmers to continue to write bad code in an environment that makes it easy for them to do so.

    "I doubt you (or anyone) can implement clustering and fault tolerance better than an app server vendor within a reasonable time frame. If you can, go work for BEA. IMHO, implementing state replication, tolerant stubs, etc shouldn't be the work of a particular domain expert. "

    Actually, I have. And no, I wouldn't work for BEA if my life depended on it.


    Your assumptions in this post are all wrong. Jini provides a means for service interaction and discovery, whether it be between two devices, or Cisco routers, it makes no difference to the Jini protocol.

    Jesse

  6. Hi there :)
    I'll refer to what you wrote by order without quoting, cause this "Replace EJB bloat with Jini Pattern" is getting to be quite a bloat itself :)

    1. - You said the idea of pooling remote capable objects is brain-dead. Maybe it is, but it isn't done in EJB. that was my point.
     - Stateless beans have state related to their processing. They probably use running resource connections, for instance, which cannot be reused. Hence the thread-safety concerns.
     - Coding multi-threaded code tends to produce more errors (that was the point of my example). The argument that "good developers won't make such mistakes" is childish. They have, they do and they will.
     - Actually, I once worked 5 days on a paper about dynamic/greedy and other optimization aproaches for pooling of several kinds of resources (actually, resources with several kinds of statistical access patterns). I assure you there is a lot of optimizations to explore, and each can produce quite different amortized costs.

    2. My point was that the reason JNDI is used is that there must be some standard way to get the pool from which you get the resoruces. You don't create that pool yourself as in Jini, so you must have some way to access it.
    As for your point about transactions, here are two notes:
     - Why do you assume enterprise applications will only use JDBC? What about JMS, connectors, etc?
     - The way you implemented transactions in your example, you won't be able to use transactions that encompass more than one resource efficiently. If that point isn't clear I can elaborate, or you can find details in lots of formal sources such as X/OPEN DTP spec.
     - If you want some papers reasoning why is declarative transaction preferable to coded transactions, I can mail you a dozen.
     - JNDI sucks? I guess that means LDAP, NDS, etc suck too?

    3. "Why should I look up my objects by some textual name if I already know what object I'm dealing with? Ie, interface."
    In my LDAP directory I have 3 different Connection objects and atleast 5 Topic and Queue objects, which I need to tell apart. Should I define an interface for each although they all stand for different instances of the same thing? not quite OO. Maybe I should use attributes for them, that's the Jini solution, right?... no, that's text!

    4. As the matter of fact, many app servers (iAS for instance) use LDAP client implementations of JNDI. LDAP is a very stable service with tens of years of improvements and there are plenty of ways to make it fault tolerant. Ofcourse, this is just an example. But any app server can implement the naming service in a very reliable manner, such as this.

    5. "shitty developers"... no need to get so upset. This is begining to sound more like a religious discussion than a technical one. Anyway, for most developers I know, including those who code non-EJB apps, learning more API takes more time.

    6. If your clients don't need a service turn it off. When you release new clients that do need it turn it on. No problem there. It seems to me like you're intentionally trying to glue this up to Jini features that are not especially relevant here (although very relevant elsewhere).

    7. OK. Your opinion is that EJB sucks. That's what this point is all about. No technical facts, just opinions. That's fine.

    Next two points are irrelevant (first requested explanation (thanks), second some Jini promotion text).

    7. I really don't see you're point here. EJB as well as Jini *allow* for reliability. As for how app server programmers implement it, we must discuss every case seperately. I do not take the statement that all application servers in the industry are unreliable as a general conclusion.

    8. You wouldn't work for BEA if your life depended on it...
    I guess that makes you a sound technical advisor with no irrelevant religious bias :)


    "Your assumptions in this post are all wrong. Jini provides a means for service interaction and discovery, whether it be between two devices, or Cisco routers, it makes no difference to the Jini protocol."

    Once again, this sounds more like a Jini marketing line than anything else, and is completely unrelated to our discussion. Did I assume the opposite? I happen to like Jini just fine, and I agree with this quote. All I'm saying is Jini as a framework is not complete enogth to enable efficient development of enterprise software. Such framework could very weel be built on top of Jini, but that's besides our current point.

    Have a nice day.
    Gal
  7. Touche touche...Alow me to reply.

    1. -Hmmm..Nonetheless, Stateless beans are pooled, and I can still see no reason why this is needed. Do you have any examples of where and why you would need to pool multiple instances of Stateless beans? What "resources" could it be pooling? You don't think this is too much overhead? Why not have one object service all client requests when the underlying operating system is perfectly capable of handling this?
    - Yes, coding multi-threaded applications is harder, but the trade-off of less code/memory bloat seems to justify their existance. Especially when you are able to run multiple redundant services throughout your network to achieve high fault-tolerance. I do disagree with the skill-level argument very much though. In my personal experience, most good developers tend to make less mistakes. If your team of developers is not competent enough to unit test and write thread-safe code, then that sucks for you. But problems of developer competence are not really related to the subject are they? Or, are you implying, as I have stated, that EJB is for the less technically inclined developer? Once again, multi-threaded applications are almost mandatory in enterprise development, and if you can't handle that, then you shouldn't be developing enterprise apps. The JDK developers have made every effort to make thread use as easy as possible. It almost becomes trivial in Java. Thanks for proving my point.

    -What is this? Fluff? Are you saynig that an EJB pool of stateless beans can perform their task more quickly than one multi-threaded object? Shall we write some comparison code to find out? I think you will find that you are wrong, but I'd love to be proven otherwise.

    2. Wrong again. You do not create any pool in Jini for resources. Jini IS much better than JNDI as a lookup mechanism. You bind your object to a lookup-service, which is handled transparently as you the developer by Jini utilties..Here is an example:

    _luMgr = new LookupDiscoveryManager(_luGroups, null, null);
    _joinMgr = new JoinManager(_proxy, _attrs, _serviceID,
    _luMgr,_leaseMgr);

    This fragment of code will take your remote object proxy and register with every lookup service that it can find on the network. Location is not hard-coded anywhere here in the code, you only specify the "group" that you wish to belong to. This eliminates your single point of failure, as you would have in JNDI by having to define your Context.PROVIDER_URL for doing lookups. In Jini you do not have to specify a url, services will dynamically be discovered through muticast announcements. Once again, Jini addresses issues such as machine and lookup service failure that EJB simply does not.

    -As for the transactions piece, what I should have said is that MOST EJB applications are not participating in multiple storage instances of a database, but are all using the same DB. Have you written transactionally aware EJB's that participate in transactions across multiple database instances? I think the majority of answers for people using them is no. So, once again, unneeeded bloat.

    -But, here you have fallen into my trap. Jini does not define the implementation of how your services participate in a transaction. You can use JMS, JDBC, etc...whatever meets your particular needs.

    -As far as declarative transactions go, how is it bad to call conn.setAutoCommit(false) in your code? If you do not want declarative transactions in Jini, you can use whatever means you want. That is the point, you as the developer are not constrained to any particular method of participation. I do agree however, that I would not personally want to write JTA transaction code declaratively in my code.

    - Yes, I do think overall that JNDI, LDAP protocols are not the best choice for Java programming in general. I like dealing with objects, not text, not XML definitions of some notion of data like JXTA, but objects. JNDI/LDAP/etc.. all produce single points of failure in your lookup mechanism. We actually almost used JNDI/LDAP in our project, which is what first led me down the path of using Jini. Lookup/Discovery, discarding of bad lookups, etc... where all very important points for our requirements. By the time we finished outlining all of the things that we needed from JNDI, we had discovered that we were basically implementing the Jini protocol. So, we decided to not re-write what had already been done and used Jini instead.

    That is the point again, Jini forces developers to deal with almost any and all failures that can occurr in a system. Most previous jobs that I worked in did not require such finicky environments where failures are not an option, so I, like the rest,k was happy to ignore failure issues of services. It's all about changing your view of how you think software should work. Most people/developers these days seem to have lowered their expectations of software quality drastically, no thanks to the tyrant in Redmond. If we built cars the way that we build software, we would be in a lot of trouble.

    Going along the same line, peer-to-peer makes a lot more sense than the typical thin client-fat server model that everyone is used to. The more you distribute your services on the network, the less susceptible you are to failures. That is the main point against EJB. EJB folks are always trying to throw more memory and power at monolithic app-servers to somehow try and solve scalability and reliability issues. It's just a different way of thinking. JXTA really uses the same paradigm, but once again, I don't really like JXTA either because of the XML communications required. I'm an object fairy, and like my objects very much.

    3. "In my LDAP directory I have 3 different Connection objects and atleast 5 Topic and Queue objects, which I need to tell apart. Should I define an interface for each although they all stand for different instances of the same thing? "

    I don't understand your application, so I can't make any assumptions here, but Jini provides a 128-bit UUID for every service running in the network, if you need to tell them apart, then there you go. This all plays into the LookupCache implementation provied. There is a wrapper class around every service that it finds that gives you its unique id if needed. Does this solve your problem while still allowing you to lookup through interfaces? I think so. What's even better is being able to define object heirarchies that match your criteria even better. You have all probably seen the example before, but just for clarification:

    Say you have many different printers on the network, if you simply want to print something out, do a search for all "Printer" objects. However, if you really need color, search for "ColorPrinter" objects. But, you are right, items such as location would probably be better served as an attribute. But you are wrong here again. Attributes are not defined as text, but are also actual objects. You could have a Printer attribute such as:

    public class PrinterAttr extends Entry {
      public String location;
      public Int group;
      public Whatever you want.....
    }

    5. I still don't understand your point here. Jini DOES provide a standard way to lookup services on a network. Discovery of services is one of Jini's best qualities. What's the difference between learning JNDI vs Jini? None. It would probably take the same amount of time for both. Can you elaborate more on why it would be harder for new developers to learn one over the other?

    6. Ahah! Got you here. See what I mean?? EJB developers try to ignore issues such as service reliability and say it's not relevant??? I think it's very relevant to this discussion. It shows how Jini services will almost always be more reliable than EJB services. You can't ignore these issues forever. That's the whole point with Jini. It addresses all of the nasty issues that everyone tries to ignore. Anything producing failures in any code anywhere would be a problem for me, because I take pride in my code and want it to run as reliably and efficient as possible. We have been living with Microsoft-ish quality products for too long, and it is time for a change.

    ". All I'm saying is Jini as a framework is not complete enogth to enable efficient development of enterprise software. Such framework could very weel be built on top of Jini, but that's besides our current point. "

    Ah well, but you are wrong here again. What defines in your mind efficient development? The RIO project over at jini.org provides a thin app-server'ish environment for Jini quality service code to run in if so desired. Efficient development for whom? Less apt developers who do not want to get their hands dirty? Once again, fluffy answers with no real facts behind them. Why on EARTH do we keep concentrating on making things easier for the timid developer?? I would think in the enterprise world reliability/scalabity/fault-tolerance would have higher precedence than some notion of efficient development. I really doubt you can develop the same service in EJB faster than I can in Jini, with the same amount of reliabilty and fault-tolerance built in. Care to prove your assumptions here?

    Jesse
  8. I don't usually do this but...

    Jesse, you sound like a junk hotshot kid that touting what you have found the holy grail of knowledge and you can't imagine anything better. I'm sorry, but grow up. If you really honestly want some good feedback, stop bashing on other people who give different replies and give serious thoughts of ideas that are contradicting your own. No one likes hearing "your wrong" every couple of lines and just because you give some smart answers, that doesn't mean that your right (or we're right too).

    As for your idea, you're talking about peer to peer compaired to a more tiered model. Can both architectures do the same... of course because each one provides the same features (transactions, connectivity, etc etc) but I personally believe they provide different advantages and are totally geared for different things. For one, there are a lot of resources available for EJB development (auto code gen., deployment tools, support for UML tools... hell it's a cottage industry just based on a spec) and it fits well with the server farm architecture. Why do I want to spread all my services everywhere? Why do I need to think about network connectivity when (most widely used) app servers do the work for me? I could emulate everything you build in Jini in J2EE form. Big deal but J2EE has the cottage industry and JINI doesn't (or not yet anyhow).

    For Jini... I wouldn't run a website on that. I just don't see the reason why after all your points. What I would run it for something like Seti, Gnutella, or turn my lights off at home from the office. Everythings' a service and automous.

    Personally I think you're saying that your leatherman army knife (jini) is better than swiss army knife (ejb). Both do alike stuff but after looking at what you offer, which is no better that my knife, why?
  9. Hmmm.....Nice flame Albert, but I didn't see any discussion in your post.. Is there something you wished me to respond to, other than the obvious fact that you're a moron?

    Jesse
  10. Oops...I guess I could respond to one item in your post:

    "For Jini... I wouldn't run a website on that. "

    Yes, you are right. I wouldn't run a website with Jini either, nor would I use EJB's. Now, if I were running a web-service, that other software used and talked to, I most definitely would use Jini. But, then again, I don't really consider a "website" to be enterprise-level software anyways.

    Why would you use EJB's for a website? What I would run a website on would probably be a combination of apache + tomcat. Anything else would just be overkill. Then again, most websites that I've built have not needed to access multiple databases across a distributed backend enterprise structure as well, as I'm sure you MUST be doing if you are using EJB's..Right? If not, then maybe you are abusing the technology a little too much. My motto is to use the best tools for the job, and to not treat everything as a nail to beat on with my golden hammer. Of course, opinions always do differ....

    Jesse
  11. What a highly inappropriate posting. Calling someone a moron in this group is really sad, this is a technical forum not Jerry Springer.

  12. Hi.
    No offence, but I'm pretty sick of this discussion. I'll try for the last time to explain my points, for the argument's sake.

    First of all let me state that by "resource" I allways mean resource in the JCA sence, e.g JDBC/JMS connection. And by "pool" I mean a pool of such resources.

    "Stateless beans are pooled, and I can still see no reason why this is needed. Do you have any examples of where and why you would need to pool multiple instances of Stateless beans? What "resources" could it be pooling? You don't think this is too much overhead? Why not have one object service all client requests when the underlying operating system is perfectly capable of handling this?"

    A stateless session bean may very well have an instance member which is a resource connection, such as a JDBC connection. Such resources can't be simultaneously used. As for the overhead, it slight if any. When the stateless bean doesn't have any "heavy" members, what's the problem with holding five instead of one? take up 200 bytes instead of 40? come on.

    "Yes, coding multi-threaded applications is harder, but the trade-off of less code/memory bloat seems to justify their existance. Especially when you are able to run multiple redundant services throughout your network to achieve high fault-tolerance. I do disagree with the skill-level argument very much though. In my personal experience, most good developers tend to make less mistakes. If your team of developers is not competent enough to unit test and write thread-safe code, then that sucks for you. But problems of developer competence are not really related to the subject are they? Or, are you implying, as I have stated, that EJB is for the less technically inclined developer? Once again, multi-threaded applications are almost mandatory in enterprise development, and if you can't handle that, then you shouldn't be developing enterprise apps. The JDK developers have made every effort to make thread use as easy as possible. It almost becomes trivial in Java. Thanks for proving my point. "

    In enterprise applications we need multi-threading. I agree. This can be achieved by coding multi-threaded code, or by letting the container manage multi-threading. My point, as well as my example, was to show that the first is far more risky and therefore less adiquate for enterprise-level applications. Did you know the JDK code had used a broken threading idiom over 20 times? It's easy to make such mistakes, and IMHO it's better to have a strong tested base (in the container) and write the rest of the code to be single-threaded.

    "What is this? Fluff? Are you saynig that an EJB pool of stateless beans can perform their task more quickly than one multi-threaded object? Shall we write some comparison code to find out? I think you will find that you are wrong, but I'd love to be proven otherwise. "

    Again, by pool I mean a pool of resource connections. And yes, a sophisticated implementation can out-perform a naive implementation. Implementing a sophisticated pool takes time, and I see no reason why I should do it time after time.

    2. (no quote)
    - First of all, you must either create a connection pool in Jini, or you will have a very inefficient program. In EJB, you don't create that pool, but just get it from the server. So my point really isn't related to Jini's lookup mechanisms.
    However, I would like to disabuse you of the notion that in JNDI you must provide a provider URL. There can very well be a JNDI provider that uses the Jini lookup service and is every bit as powerful. When you use JNDI in ejb you allways use java:comp, which is mapped to a local provider implementation. How that implementation (server specific) get's it's info is it's own business. It's quite possible that for a pool it won't even contact the network, just return the object by calling some local methods.
    - I very often need to use several different resources in an EJB application. A common architecture is a database and a messaging systems. Many others exist.
    However, even if you do use a single database, if you access it in the same transaction from several different services which are not necceseraly running on the same box, you still have a problem.
    - That's obvious. JTA doesn't define what resources are in the transaction either. And if you want to code the JTA calls to coordinate the transaction knock yourself out. I personally consider it a waste of time, when this code is so generic and is standartized in architectures such as EJB anyway. I don't see what "trap" are you talking about (or why would you want to set "traps" for that matter.
    - It's not bad. But when you need a seperate transaction (i.e, TxRequiresNew) you will need to create a new connection. And when you want the same transaction you will need to pass the connection, and only commit if you indeed created the connection and not got it from somewhere else. And if you want a transaction if available you should do something else. That's plenty of code changes.
    - Well, that's your opinion. I disagree, and I don't want to get into this unrelated discussion.

    "That is the point again, Jini forces developers to deal with almost any and all failures that can occurr in a system. Most previous jobs that I worked in did not require such finicky environments where failures are not an option, so I, like the rest,k was happy to ignore failure issues of services. It's all about changing your view of how you think software should work. Most people/developers these days seem to have lowered their expectations of software quality drastically, no thanks to the tyrant in Redmond. If we built cars the way that we build software, we would be in a lot of trouble."

    EJB relies on the server to deal with those problems, and by restricting beans gives the server the tools to solve these problems. The server can implement reliability just as good, and probably much better than everyday Jini developers. It also implements features such as automatic state replication that you would have to work hard to implement in Jini. If Jini was the most and the only powerful tool to do this, servers would use it. But it isn't, and until you read up about the advanced clustering support in WebLogic for instance, I don't think you should make an opinion. You think using netmask echos to get rid of single points of failure is a new idea? It's been here for 30 years.

    "Going along the same line, peer-to-peer makes a lot more sense than the typical thin client-fat server model that everyone is used to. The more you distribute your services on the network, the less susceptible you are to failures. That is the main point against EJB. EJB folks are always trying to throw more memory and power at monolithic app-servers to somehow try and solve scalability and reliability issues. It's just a different way of thinking. JXTA really uses the same paradigm, but once again, I don't really like JXTA either because of the XML communications required. I'm an object fairy, and like my objects very much."

    Peer-to-peer is a great programming paradigm, and in some cases it makes a lot of sense. EJB, and generally J2EE is aimed more towards the multi-tiered approach, in which you have different tiers with distinct different jobs. This paradigm can also be great. When it is, use it. When peer-to-peer is needed, use someting else (Java still doesn't have a real standard).

    3. (no quote) I can't see how I would use the UUIDs. Hardcode them in my app? I don't think so. I just want to be able to get "DataCenterConnection", "WarehouseConection", etc.
    I don't need any further classes or anything like that. This is why it makes sense for me to look the connection up by name, not by class (ConnectionFactory) which is the same for all of them. Your soultion doesn't help me one bit.

    5. This really isn't what I ment. I was talking about a pool of connection, which is a local class (you can pass Connections over the network anyway). Getting this pool, and getting connections from it is a new API. In EJB it is standartized, because the pool API is always the same and you always get the pool the same way.

    6. Say your EJB server comes with a "time" service that implements the standard network time protocol. If you do need it, turn it off. That doesn't matter for your clients. If suddenly a new version of the client needs it, turn it on before releasing them. That's the type of service I was thiking about. If you ment something else where this strategy could cause problems, please elaborate.

    Last paragraph:
    First of all, all of this discussion revolves around Jini, not some platform such as this RIO project which I get from you is built on top of Jini.
    As for your question about making things easier for the developer, it's a trend that's been going around since the late 70's. Why do you suppose we are not developing our software in Assembler? It would lead to faster code. However, the time-to-market, amount of code to maintain and amount of programming errors makes it beneficial to try and make developers more efficient (in terms of time) and less error prone, even when there are some costs.

    "I really doubt you can develop the same service in EJB faster than I can in Jini, with the same amount of reliabilty and fault-tolerance built in."

    IMHO, if you have to write the resource pooling code, transaction management code, security code, load balancing code, etc. (everything EJB gives you), I can. Also note that many development tools have integrated support for EJB (including UML-based code generation, automatic deployment, etc).

    Have a nice day.
    Gal
  13. Hi. Just noticed some mistake in 5:
    "(you can pass Connections over the network anyway)."
    should be
    "(you can't pass Connections over the network anyway)."

    Gal
  14. Gal,

    Could you please elaborate the need for pooling stateless session bean.

    "A stateless session bean may very well have an instance member which is a resource connection, such as a JDBC connection"
     - Why would i store the connection in my session bean when it's already pooled by the app server? Moreover i am supposed to close the connection and return it back so that it can potentially be used in the same transaction. I didn't get it quitely.

    I would like to know the real value of pooling stateless session bean?
    thanks...sanjib
  15. Hi sanjib.
    I have a couple of examples where keeping your own connection can help performance (some I had used, some taken from books). I admit this isn't the best example I could come up with (really didn't pay that much attention to it when I wrote the reply to Jesse) so I also added some more "standard" examples.
    As for what you said about closing the connection so that it can be used in the same transaction, you don't need to do that. The transaction association is maintained behind the scenes using the transaction's id, so it really doesn't matter what connection is used by what bean.

    You may want to keep a JDBC connection live if you have a prepared statement you are using and do not want to prepare over and over again (this is solved in JDBC 1.3). You may also want to keep an open connection is you are using an updatable resultset as a cursor instead of re-issuing the statement. Other less important issues, such as maintaining the connection's sql-to-java type mapping can also be relevant.
    However, a better example is probably holding an instance XML parser (or any other sort of resource that isn't inherently pooled).

    Anyway, I really don't see what the big fuss is about pooling stateless beans. If you really don't hold any state in them (so that they can run multi-threaded) what's the problem with instanciating 10 instead of 1?

    Gal
  16. Hi Gal,

    Thanks for your reply.

    On the closing of the database connection, I thought that's how app server knows when to delist the corresponding XAResource and when i call getConnection, the app server enlists the XAResource. Now if i hold the connection and never close it, i wonder how it would affect the transaction demarcation.

    thanks...sanjib
  17. "A stateless session bean may very well have an instance member which is a resource connection, such as a JDBC connection. Such resources can't be simultaneously used. As for the overhead, it slight if any. When the stateless bean doesn't have any "heavy" members, what's the problem with holding five instead of one? take up 200 bytes instead of 40? come on. "

    Slight, if any, overhead? First of all, what are you doing with an open database connection in a "stateless" session bean? Second of all, do you think that having multiple beans present does not incurr any overhead? Something has to manage those beans don't they? They have to be created, etc....This will incurr a performance hit in the overall scheme of things eventually if this is how you design your application. The added byte value of 200 over 40 is rather wishful thinking on your part now isn't it?

    "In enterprise applications we need multi-threading. I agree. This can be achieved by coding multi-threaded code, or by letting the container manage multi-threading. My point, as well as my example, was to show that the first is far more risky and therefore less adiquate for enterprise-level applications. Did you know the JDK code had used a broken threading idiom over 20 times? It's easy to make such mistakes, and IMHO it's better to have a strong tested base (in the container) and write the rest of the code to be single-threaded. "

    What?? Am I hearing you correctly? Writing multi-threaded code is "less adequite" in the enterprise? Have you ever done any real enterprise work before Gal? From your response one would tend to think otherwise. If you are writing web-apps, then the answer is probably no, you don't...I am talking about ACTUAL enterprise software, not web-sites here. Once again, if you are afraid to write multi-threaded code in Java, then wow, you're a pussy. Sorry to be so harsh man, but that's all it comes down to. The "container" is not a magical fault-tolerant beast that can handle everything for you. One day you might have to venture out and write your own code...

    "Again, by pool I mean a pool of resource connections. And yes, a sophisticated implementation can out-perform a naive implementation. Implementing a sophisticated pool takes time, and I see no reason why I should do it time after time. "

    What are you referring to hear? A "resource" pool? When did I ever say I wanted to implement my own resource pool? In Jini, the distribution of services is all handled by your LookupService.

    On the other hand, if you are referring to my implementing a JDBC pool... You are right on the one hand, where it does not make sense to re-write it over and over again. I've written it once, and I re-use it in most of my apps. What exactly do you mean by "sophisticated" vs. naive pool anyways? What exactly is a "sophisticated" pool? Another magical box that the App-server gods create for you? It's really not that hard to create, nor is it a very compelling reason to tie myself completely in to the brain-dead EJB paradigm. Have you ever implemented a JDBC pool before?

    2. "- First of all, you must either create a connection pool in Jini, or you will have a very inefficient program. In EJB, you don't create that pool, but just get it from the server. So my point really isn't related to Jini's lookup mechanisms. "

    What are you talking about again? What do you mean by "create"? I've already done that, been there. My application performance is just fine. And, you just "get it" the same way as any other pool. Are you trying to sell EJB with connection pools now? EJB has nothing over Jini in that area....

    "However, I would like to disabuse you of the notion that in JNDI you must provide a provider URL. There can very well be a JNDI provider that uses the Jini lookup service and is every bit as powerful. When you use JNDI in ejb you allways use java:comp, which is mapped to a local provider implementation. How that implementation (server specific) get's it's info is it's own business. It's quite possible that for a pool it won't even contact the network, just return the object by calling some local methods. "

    Oh no? No provider url in JNDI? Which application server is it again that provides this funtionality? None you say? But you are right, the EJB heads would be smart to start incorporating Jini into their apps. On the other hand, you are wrong regarding the "every bit as powerful" portion of your pool idea. Jini's LookupService "pool"(as you may call it) also works with a Leasing mechanism that ensures services that go down are automatically taken out of the pool. This is just another one of the fault-tolerant features that Jini provides..Why do you use "java:comp" in EJB? I really like objects, so I guess that I just don't "get it" yet...

    "- I very often need to use several different resources in an EJB application. A common architecture is a database and a messaging systems. Many others exist.
    However, even if you do use a single database, if you access it in the same transaction from several different services which are not necceseraly running on the same box, you still have a problem. "

    Again, you are using one database right? So where's your problem? No, you don't have a problem accessing the transaction from several different boxes. That's where Jini's distributed transaction services comes in(mahalo). It handles joining all the necessary resources in the transaction together.

    --ejb server quote...

    This is where you are just dead wrong. Most applications servers today(including your beloved Weblogic) are far from being as reliable as a distributed Jini-based application. In my current environment, I can pull the plug on any number of machines(well, not EVERY last one..then no more services would be available!), databases, etc...and everything in the network "self heals" in the context that Jini provides. Leases expire, services renew their state with LookupServices, etc... Can you do the same with your app-server? I doubt it....

    As far as why app-servers aren't using Jini features, you should read-up on the JavaOne articles at java.sun.com.(I didn't actually read them per say, but attended some of the discussions..). They are trying to incorporate Jini into the J2EE structure already!

    Wow, netmask echo's have been aroud for 30 years? Well then why in the hell aren't app-servers using them? Isn't it a single point of failure in your PROVIDER_URL? I thought that app-servers handled failures for you. Well, I guess they "handle" some failures for you that is..

    "3. (no quote) I can't see how I would use the UUIDs. Hardcode them in my app? I don't think so. I just want to be able to get "DataCenterConnection", "WarehouseConection", etc.
    I don't need any further classes or anything like that. This is why it makes sense for me to look the connection up by name, not by class (ConnectionFactory) which is the same for all of them. Your soultion doesn't help me one bit. "

    Why would you hard-code the UUID into your app? Ohh...you are talking about DB connections again? Well, in that case it does make sense to specify a String for the connection that you desire. But, on the other hand, if I were looking for my distributed connection pool, I probably would want to search on a "ConnectionPool" interface, and the call getConnection("WarehouseConnection") in my app. (Which is exactly what I am doing..). Yoy must have gotten confused about searching for services, and using services...

    "This really isn't what I ment. I was talking about a pool of connection, which is a local class (you can pass Connections over the network anyway). Getting this pool, and getting connections from it is a new API. In EJB it is standartized, because the pool API is always the same and you always get the pool the same way. "

    EJB has a standardized pool? Well, great! Actually though, you are wrong. You CAN pass connections over the network. (Although, implementing the RMI code for it is not very fun..). Or, you can grab the connection pool directly from a local class. Once again. DB connection pools are easy stuff. How does this make EJB particularly better than Jini. I use a connection pool in Jini, very easily. What's your point?

    "Say your EJB server comes with a "time" service that implements the standard network time protocol. If you do need it, turn it off. That doesn't matter for your clients. If suddenly a new version of the client needs it, turn it on before releasing them. That's the type of service I was thiking about. If you ment something else where this strategy could cause problems, please elaborate. "

    Ahhh..This is an area that EJB will never be able to compete with Jini in. What do you do if your "time" service fails and you are fast asleep dreaming up new EJB's for your app? In the EJB world, you would be fucked. However, in a typical Jini application, you would have multiple distributed services across the network providing the same service. If the "time" service fails, or is otherwise not working, it is summarily removed from the "pool" of services and clients go on to use the next one. There is no single point of failure. The "pool" is dynamic and self-healing. If the time service does not maintain its lease, it will be discarded, saving the poor clients from encountering the same bad time service again and again. When the time services feels like behaving again, it can ask for a new lease and start working away.

    In another model, clients can use a Quality Of Service paradigm to get and use the most efficient service available on the network...I won't go into detail with that here, since it has already been covered heavily by others, but you can read more on it at: http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-jiniology.html.

    "First of all, all of this discussion revolves around Jini, not some platform such as this RIO project which I get from you is built on top of Jini. "

    Well, then why are you talking about Weblogic clustering? If we are simple comparing specs for the technologies, then let's do so. However, if we are comparing them as a whole, then your point is kind of off-base. Wouldn't you think?

    "As for your question about making things easier for the developer, it's a trend that's been going around since the late 70's. Why do you suppose we are not developing our software in Assembler? It would lead to faster code. However, the time-to-market, amount of code to maintain and amount of programming errors makes it beneficial to try and make developers more efficient (in terms of time) and less error prone, even when there are some costs. "

    I disagree very much with you here. While yes, it is of course important to make deadlines, etc....This is all part of project management. My point in the original post is that software quality seems to have taken a back-seat in our field. If we have developers out there who are afraid to write multi-threaded code, then this poses a serious problem. Our industry is plagued with faulty and innefficient software. I think this sucks as a whole. We call ourselves "engineers", yet most of us don't come anywhere close to imposing the rigorous standards that most engineering fields require.

    It's time that you woke up and smelled the (roses/coffee/whatever...) Gal. The industry has still not given us our "silver-bullet" with which all software development problems can be solved. No monothilic app-server is going to make the quality of the code you write better, nor is it going to make you as a person a better coder. You have instead turned into a mindless drone pumping out factory code to a paradigm that is already dieing, only you are too blinded by buzzwords and "transactions" to see it.

    I have to admit, Jini is far from being a silver bullet for all the woes that you encounter in the world, but it is far ahead of most J2EE client/server implementations out there. The basis of the technology is great, not the particular service that you are implementing.

    If you reallly cringe for all of those app-sever features that you so love, then the RIO project will give you all your heart desires...Only it won't force it down your throat, nor will it require you to spend $13k per processor for it(Unlike Weblogic, which, from what I've heard, is really the only way to go when using EJB reliably..), nor does it require you to come up with ridiculous "pattern" repositories for a broken and crippled paradigm that makes creating class heirarchies about as much fun as an enema.

    "IMHO, if you have to write the resource pooling code, transaction management code, security code, load balancing code, etc. (everything EJB gives you), I can. Also note that many development tools have integrated support for EJB (including UML-based code generation, automatic deployment, etc). "

    Well, let's not get stupid here. Why would I have to write resource-pooling code, transactions, etc...from scratch just because I'm using Jini? I have already implemented all of these features. So, put your money where your mouth is Gal. Let's both write something and see who does it faster, with the same amount of reliability built in, as well is seeing whos code runs faster. We would have to be able to run multiple client tests on the code, as well as have the abillity to kill the services involved nicely, and harshly. Are you up for it? Or are you just making fluffy statements again?

    Regarding the "UML" generation, I saw those guys at JavaOne.(We actually stayed in the same hotel..) You wouldn't actually use a code-generator would you? God...Why don't you just move over to the Visual Basic camp and stop pretending that you are a programmer.

    Jesse
  18. Hi.
    As I said, I'm not going to argue with you on this, because by now I have realized you really don't care about what others have to say, and after having heard you I don't care about what you have to say. So I only comment briefly on the issues I think you didn't get by now.

    Let me just say that most your comments again arise from the fact that you do not interpert "connection pool" as a pool of resource connection, i.e JDBC pool. I have stated this is what I ment in the top of the post.
    As for the clustering part and sophisticated pool parts, you are plain wrong. I've tried to explain why twice, and I'm pretty sick of it by now. Go read up about metroids in greedy algorithm design.
    As for JNDI, WebLogic does implement the feature I have mentioned (getting the pool locally) as does iAS. The use of "java:comp" is a standard part of JNDI that tells the system what provider to use, in this case a local one. Get a clue before you make an opinion. Never does an EJB developer specify a URL for the initial context.
    The Jini transaction service coordinates your services. However, if two services from different computer access the samwe database and need to see a consistent view (i.e, see each other) they must coordinate the transaction between themselves using JTA. As i said, if you want to write the JTA calls have fun.
    You can't pass Connections over a network because they are not Serializable, and require external resources.
    Clustering implementations use netmask echos as well as a bunch of other techniques to manage the cluster. Again, go read up on it.
    If you really don't understand what's the difference between discussing EJB implementations (WebLogic) in the context of EJB and discussing the RIO project on Jini (not a part of the Jini spec), I'm not gonna explain it.
    Services such as time cannot be clustered or loaded across the network (all it is is a standard port over a box). So I guess you ment a more normal service. Such a service would be clustered in EJB.

    Have a nice day.
    Gal
  19. Hi Gal

    I've came across this - by now nicely flaming discussion - almost by chance and my question is irrelevant to the topic (sorry, Jesse; I guess you'd want to classify me as a moron for that; oh well).

    Gal, I've read in your replies about "completely broken threading concepts such as double checked locking" - could you please elaborate???? I must've been out of it! I use double-checked locking all the time for implementing Singletons; it is indeed quoted in many computer books such as, for example, Design Patterns (PLOP vol1, I believe; pattern by Douglas Schmidt) - so what is the problem with it? Could you point me to some info/literature on that?

    Once again, sorry for being irrelevant to the topic.

    Thanks
  20. Check out the "Double-checked locking: Clever, but broken"

    http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html

    article on JavaWorld. It covers this topic quite nicely.

    Farley

  21. Hi Sasha.
    Don't be so sorry, this is the first flameless message I got in this discussion.
    You can look at the article from JavaWorld that is linked in the preveious message. If you want a more complete technical description of the problem (including descriptions of how the problem can *actually* occur on alpha processors), a great source is Bill Pugh's Java page:
    http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

    This is an excelent page if you are into the topic. Also has links to more subtle less known problems such as violation of Coherence in existing JVMs.

    As for this pattern being documented in Java books, you are right. It has been documented in many books, even those especially addressed to thread programming.

    Gal
  22. "As for the clustering part and sophisticated pool parts, you are plain wrong. I've tried to explain why twice, and I'm pretty sick of it by now. Go read up about metroids in greedy algorithm design. "

    Yawwwwnnn....Nice fluffy response Gal. You can't refute my arguments, so instead you ask me to read up on it...Whatever.

    "As for JNDI, WebLogic does implement the feature I have mentioned (getting the pool locally) as does iAS. The use of "java:comp" is a standard part of JNDI that tells the system what provider to use, in this case a local one. Get a clue before you make an opinion. Never does an EJB developer specify a URL for the initial context. "

    Get a clue? What on earth are you talking about? If I want to reference an EJB remotely from another JVM I don't have to provide a PROVIDER_URL? This is a lie. Please, once again, show me the app-server that makes this possible.

    Accessing another EJB from within the same app-server is very different though...In that case though, you are really not doing distributed computing though are you? Just because "java:comp" is a standard it does not make it particularly good.

    "The Jini transaction service coordinates your services. However, if two services from different computer access the samwe database and need to see a consistent view (i.e, see each other) they must coordinate the transaction between themselves using JTA. As i said, if you want to write the JTA calls have fun. "

    Jeez Gal...You just don't get it yet do you? Transaction semantics of remote method calls are all very specific items for specific tasks. JTA is not neccesarily needed in all situations, nor would I overly enjoy writing the JTA calls. But, let me tell you something that I would enjoy, the peace of mind knowing that my system is fault-tolerant and scalable...But of course you must have different requirements.

    "You can't pass Connections over a network because they are not Serializable, and require external resources. "

    You CAN pass connections over the network GAL..Just not in the sense that you are referencing. Stop using your EJB world tunnell vision. Even Weblogic has implemented remote connection passing via RMI calls.

    "Clustering implementations use netmask echos as well as a bunch of other techniques to manage the cluster. Again, go read up on it. "

    So what? Again, how much has this Weblogic clustering cost you? And, you still have a single point of failure with your LOOKUP SERVICE. Clustering doesn't buy you anything here. Another fluffy remark I should read up on?

    "If you really don't understand what's the difference between discussing EJB implementations (WebLogic) in the context of EJB and discussing the RIO project on Jini (not a part of the Jini spec), I'm not gonna explain it.
    Services such as time cannot be clustered or loaded across the network (all it is is a standard port over a box). So I guess you ment a more normal service. Such a service would be clustered in EJB. "

    What kind of nonsense is this? I can't talk about the RIO project because it's not mentioned in the JINI spec? How retarded is that statment Gal?? Look, it exists ok? So I'm going to continue discussing it whether you like it or not.

    Wrong again Gal. Time services can be distributed across the network on multiple boxes, not neccessarily having to use a "port" . Why would I want to "cluster" a time service? What exactly does clustering buy you here? What exactly do you mean by "clustering" anyway?

    Jesse
  23. Well this has been an entertaining thread...

    Gal, obviously I don't know you personally so I can only take your comments at face value and assume that you've been around the block a bit.

    From my perspective, weblogic (and any other app-server out there) provides little more than a convenient way to roll out an app. Some of the implementations of the facilities it gives me are good, some are not so good.

    If I had a choice, I'd probably roll my own versions of those facilities and would probably use jini as a way to glue the lot together. Could I do it faster than using an app server? I guess that depends on the nature of the app and, assuming a race between the two styles, who ran into a showstopper first or more often.

    You've already said about not writing everything in assembler and I agree. Use what (mostly) works and is conventient is a good way to proceed.

    However, there's a couple of points you make about the pitfalls with writing your own facilities, connection pools being an example, which don't gell for me.

    In my experience you're unlikely to need to optimise the logic of things like db connection pools because chances are, your app is going to be spending more time waiting for the database to return from a stored proc than anything else. I can't see how the relatively simple task of handing out connections could be hyper optimized to greater benefit than hyper optimizing your data handling.

    Also you seem to have a *very* high degree of trust in the quality of code from 3rd parties. The largest software vendor I ever worked for (>700 employees) was typical of all of them: major chunks of functionality were written by one, maybe two coders. They were all smart guys but just guys after all, churning out (mostly) stable code, avoiding rocket-science.

    When we use weblogic we're not "standing on the shoulders of giants". Maybe certain facilities in weblogic *were* coded by gurus but not *every* facility. I believe that most competant coders could put those facilities together with little effort, given a reasonable amount of time.

    I use weblogic 'cause for the most part, I never have a reasonable amount of time.

    Alas, my relatively small amount of real-world experience (10 years) means that this might be a simplistic view. It doesn't help that I mostly do web applications and (according to some) am not doing "real" enterprise programming (for some reason most enterprise integration in my industry revolves around "can we put some procs in your database?". dunno why ;-).

    You have a nice day too.
    Trevor
  24. ". It doesn't help that I mostly do web applications and (according to some) am not doing "real" enterprise programming (for some reason most enterprise integration in my industry revolves around "can we put some procs in your database?". dunno why ;-). "

    Yeah, you're right. I was being a major a$$-hole with that response. I was just getting frustrated trying to argue my points and have mostly been resorting to put-downs and arrogant remarks...Apologies to all who were offended. (Beside Gal, of course..)

    Jesse
  25. Hi.
    I'd like to summarize my stand on this discussion instead of addressing the specifics, as it seems to me like we're repeating outselves and there is little to no convergence.

    I think Jini ultimately has great tools to offer for enterprise applications. It's architecture naturally allows reliability and scalability, and is probably the best *formalized* standard technology to do so yet.
    In my humble expirience with projects that require EJB (which are not most prjects), implementing the EJB services you need on top of Jini would be too time consuming, although I don't argue that a good developer could implement them. Again, if you don't need advanced services that are a part of EJB, you probably shouldn't use EJB anyway, regardless to whether or not you use Jini. Also, in my expirience the programming paradigm of EJB does tend to produce better results in terms of amount of errors. This is probably due to it's restricted environment, and does have a cost in terms of efficiency and project cost as Jesse has mentioned. Like most things in life, it's a tradeoff. I do think there are projects where this tradeoff is worth making. These are the projects where I would use EJB.

    I completely disagree with the generalization Jesse has made, by suggesting EJB programmers are less capable than the rest of the community. I don't know any developer that started right on EJB without any prior expirience, so I really don't see how can such a generalization even be made.

    That being said, a platform built on top of Jini to supply further services (such as pooling or transactions, for instance) is a different issue, and I cannot address such a platform without having had expirience with it. This holds for the RIO project, which I have no knowledge of. Throughout the discussion I was relating to the comparison of Jini and EJB, not RIO and EJB. I agree with Jesse that such a discussion (RIO-EJB) is legitimate, but having no knowledge of RIO I would not actively participate in it.

    I think this disucssion has drifted off the mark. I apologize to Jesse if I have said anything to offend him, even though I don't think I was the one doing most of the flaming :) Of course, any side will always tell you that.

    Best regards
    Gal
  26. J2EE is very usefull, especially in very large (high volume / concentrated) applications (ex: ASP with 100M+ users).

    JINI is a very nice technology for all the good reasons already pointed out.

    We even wrapped EJBs with JINI to (try to) get the best of both.

    Concurently, SUN has been working on JXTA and W3C (and almost everybody now) on web services (ex: GLUE, SOAP) which all offer interesting distributed/collaborative paradigm.

    How do you see JINI evolving/competing with GLUE/SOAP based web services, and also with JXTA ?

    Thanks

    ac
  27. "We even wrapped EJBs with JINI to (try to) get the best of both. "

    Kick Ass! This seemed to be inevitable.

    "Concurently, SUN has been working on JXTA and W3C (and almost everybody now) on web services (ex: GLUE, SOAP) which all offer interesting distributed/collaborative paradigm.

    How do you see JINI evolving/competing with GLUE/SOAP based web services, and also with JXTA ? "

    That's a very good question, and one that I'm not fully qualified to give a "good" answer on, but I can give you my humble opinion of course...Which I will :).

    JXTA is a complete rip-off of the JINI paradigm, only they have replaced object-object communication with XML-ish SOAP-like protocols, as you have pointed out. I'm being a bit of an object fairy here again though....Given a choice, I would probably stick to Jini until I was required to start speaking to a non java-based system. If I did run into that problem, then I would only build that particular service that needed to speak to the non-java system using (JXTA/RMI-IIOP/insert your favorite method here), and leave everything else in Jini.

    Jesse
  28. Hey Jesse, are you member of a Nazi party or something? Grow up kid! Life is about finding the right way, problem is, sometimes there is no right way, only different paths. To think different from you is not a crime, nor a sin. And hey, maybe yours is the right way, but I don’t have to believe you hands down, I have the right to doubt, and yes, I also have the right to err. I could find thousands of people who would think you’re the biggest stupid of the Creation for the sole reason of choosing Java as your development platform, after all (they would think) .NET and C# are the biggest inventions of humankind since the wheel, aren’t they? I personally think they are wrong, but I’m only human, so are them, and –oh revelation!- so are you, ‘cos you’re not a prophet, nor God, although lately I have my doubts on that, maybe you *are* God Almighty -c’mon, give me a break! For what I’ve read you must be a hell of a programmer, and that’s a pity, because as a person you are disgusting.
    Now, for the rest of you –Jess, don’t even bother answering me, I just won’t read- I’m somewhat new to the J2EE world, and I’m trying to catch up with a lot of things at the same time –trying to find the right way- can’t I just sort of emulate a peer-to-peer architecture like Jini (‘cos Jini is peer-to-peer, right?) with JMS (or more recently, Message Driven Beans)? What would be the pros and cons? How would Jini and JXTA compare? I just heard about then both and at first sight they look almost the same to me, well, maybe that’s heresy ;)
    Thanks in advance

      Javier
  29. I actually agree with you on that EJB's are commonly used for things where it is not really needed. It is quite possible to build reliable, high-performance applications without EJBs, or JINI, or RMI, or CORBA or whatever. Im not sure if its going to be cheaper though, since developer costs usually exceed both hardware and software costs. Hence it doesnt really matter if you can write your own jdbc pool or not (which Im sure you can since it is a trivial task), it will almost always be cheaper to buy someone elses implementation.

    When you say that a web application isnt an enterprise application then Im not really sure if your joking or not. Surely this depends on what purpose the application serves?

    regards - J
  30. Have some idea after finish reading this thread, but as I not have much experience so I may make wrong comment, please correct me you find. Besides, sorry for poor English.

    >"java:comp" in JNDI vs. LookupService
    I guess there is a confuse in this discussion, I think what Jesse like to tell is the level of find component. In JNDI, even if you can use some notation that need not provide IP address, you still need to know a THING that you want to call. In jini, it is not the case, e.g.: If I sit in a jini office and I would like to send a message to somebody, I might call a sendMessage service. But what sendMessage is? I don't need to know, if you guy still in office and available to chat, the system might send my message to a chat service. If the guy just out to a client office, and the system can't find a chat service of that guy, then the system may forward the message in a email service and send a email to that guy. Both email service and chat service may implement a sendMessage proxy. Seen to me that this is not possible to be done at JNDI.

    >connection pool debate.
    I have work for a company that use servlet at a very early stage, at that time, that is no jsp and this company have no $$ to buy a application server. That it must implement everything from scatch with jserv and apache. Include DB pool. Yes, implement it is easy, but it come with trouble late. After the server start running, we eventaully find that the system go slow after a long run and we need to restart the server. After a long time investigate, we find that there is more than one instance of DB pool which suppose to be singleton!! Then we need to do work to fix this. For more information, you might check for this article:
    http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton_p.html
    What I want to say is, implement a DB pool is easy, but implement a good DB pool is absolutly not just make a static hashmap and then put some connection object in it. If you don't have the app-server provided DB pool. I guess you need to put many time on it. Not only implement it, but also monitor it if it have bug or not. But if you have $$ for weblogic, I guess it is valid to assume DB pool of weblogic is bug free.
    On the other hand, in jini world, this might not be as serious as j2ee, because it has leasing. In jini, every service will expire. In the case of DB connection, we can set it need to renew for every 20 min. If there is something bad in the system, e.g.:there is more than 1 instance of DB pool, the other instance will not get renew and thus it will expire. Leasing is one of the great concept programming that j2ee is not provide by default. So Gal have a point that app-server help j2ee programer to due with failures of the system, I don't agree his point. System architecture is obvious the advantage of jini. Although app-server help programmer a lot, you still need handle numerous exceptions at your only, rare than jini clear and clever architecture.

    >resource pooling code, transaction management code, security code, load balancing code, etc. (everything EJB gives you)
    I guess this is a valid point and I don't agree about Jesse that he REUSE his object all the time. The point is, if you don't implement a jini server, how can you REUSE?? Most obvious, there is no similar existing JMS service in jini, if you need similar thing, you have to build it first. Hey, how much time you need to implement a whole app-server in jini if you need most of the things that j2ee server provided? If you argue that most item that you don't need, that only your case. I don't think there will be a guy spend money to buy weblogic if he only need a JMS server. Besides, develop thing like j2ee is not only develop it. As I say, you need to write some thing on your system to monitor it and maintain it every day, can you sure you write bug-free code?? Of course even weblogic not write absolut bug free code, but you just pay for them to monitor it for you.
    You have said that you can use a JMS server in jini. I think you really trick at this point, because in theorem, you can use most thing in j2ee with jini, why not?? But if you would like to compare j2ee with jini, then what is your point?? If the other reply, "hey, I can use jini in j2ee", do you think it is meaningful? JMS in included in J2EE. Just like you compile with JNDI and jini lookup service, I think you should compare JMS with some jini service. But in fact jini haven't provide it yet.

    >The RIO project over at jini.org provides a thin app-server'ish environment for Jini quality service code to run
    In my understanding of of Rio and app-server, they are quite difference. According to jguru.com:
    An Application Server is any server that supplies additional functionality related to enterprise computing -- for instance, load balancing, database access classes, transaction processing, messaging, and so on.
    http://www.jguru.com/faq/view.jsp?EID=5917
    While Rio: The goal of the Rio project is to provide an approach to simplify the development and deployment of Jini services with built in support for Quality of Service.
    http://developer.jini.org/exchange/projects/rio/
    So, in my point of view, Rio provide is a infastructure of jini service, while app-server are providing some tools. May be your point is Rio provide reliabilty and fault-tolerance that app-server provide, but in my understand, that is some how too far away from a app-server.

    Actually, I will think this is the fundamental difference between jini and EJB, jini bring a new vision of network computing that make thing clean and nice, just like what Jesse say. And what jini provide is a network infastructure. While j2ee is a set of standard that build on top of existing network architecture (3-tier model) that make programmer program enterprise system more easy. What j2ee provide is a set of spec. and tools that help programmer to do this. You can build enterprise system in jini, of course, but other than that, you can program home network, conference room network, even smart card in jini. While it is non-sense to apply j2ee in these field. On the other hand, it is true that jini is no as mature as j2ee for enterprise programming, just a simple word, have anyone REALLY inplement a jini enterprise system which have 10M+ user??So, for me, it is not a good idea to directly compare jini and j2ee.
  31. -...I am talking about ACTUAL enterprise software, not web-sites here. Once again, if you are afraid to write multi-threaded code in Java, then wow, you're a pussy. Sorry to be so harsh man, but that's all it comes down to.

    I'm amazed that you think this group should listen to you when you are obviously thinking emotionally instead of logically. Remember it's just programming. This is a community. Humans still have a hard time not killing each other in the street, primarily because we can't seem to use our heads first.


    - You wouldn't actually use a code-generator would you? God...Why don't you just move over to the Visual Basic camp and stop pretending that you are a programmer.

    The funny thing is this is EXACTLY what the reaction is EVERY time we move up on the food chain. Assembly -> C ->C++ -> Java -> Components -> EJB or JINI or What ever. How are you going to react when time to market dictates we stack full frameworks (ie. Inventory, Shopping) on top of each other in newer better ways?
     
  32. Replace EJB bloat with Jini Pattern[ Go to top ]

    well reading this thread has certianly made me go and check out JINI a bit closer to see if it's suitable for some part of our process.

    but i have to comment on some language used in the thread. references to "real programmers" and "real enterprise software" and the like, smacks of pure macho posturing and nothing else. it's nothing to do with patterns or programming or making solutions that work for the end user, it's proving the size of one's genitals and little else. if that matters to you more than anything else, then write it in assembler and see you in 10 years pal.

    imho, 'real' programmers use what works best, here 'best' is being defined as the most suitable time/cost/benefit for the customer. religion has no place in providing workable and affordable solutions to real-world problems. whatever works, should be the motto. if that's J2EE/EJB, that rocks. if it's JINI, that rocks too.

    really, i don't care as long as it makes the customer happy (exceeds their expectations), i can take some pride in the work that i did, i feel like i learned something while i did it (even if all it was is not to do it like that again), and best of all at the end of the day the paycheck is big and fat. keep religion for sundays (or saturdays. or fridays. wherever. you know what i mean).
  33. Well...All I can say to all of you is ~whatever~. Attacking my personal character still proves nothing other than the fact that you have nothing to attack in my arguments. I never pretended to be a "nice" person, nor do I particularly care if any of you like me or not. I've made my point, and you all have a broader opinion of the subject now. Nuff said.

    Who said anything about writing code in C++/Assembler? Why would I want to do that? I've been talking about Java/JINI.

    "really, i don't care as long as it makes the customer happy ". Yes, I'm sure we all want the customer to be happy, but I want to be happy as well. And I'm not happy having to develop sub-standard code, nor am I happy developing with other people who only care about their paychecks and making the customer happy.

    Jesse
  34. Ah, Jesse mate - i have no problems with your language and stuff... makes for a more colorful debate. I guess this is why you guys sue the arse off each other in the US of A.

    And this forum has definitely inspired me to check out JINI. Thanks!

    One question... (from a complete and utter stupid arse point of view!!)

    Given that JINI currently lacks the Security framework (from what others were saying on this forum)... is it even worth considering for internet based applications (at least until a framework is completed) at this point in time?? If so, can you provide an example (you or your company may have completed) where JINI was used to develop an internet based web-service(??) and how you overcame this security issue.

    Rock on with (fingers crossed) those open source services... that is what really makes the world go round!

    Cheers
  35. "Given that JINI currently lacks the Security framework (from what others were saying on this forum)... is it even worth considering for internet based applications (at least until a framework is completed) at this point in time?? "

    From what I understand, no. They are currently working on this feature(it may be in the recent beta alewife release), although I'm not sure when it will be ready for prime time.

    Of course, there's no one stopping you from using SSL/RMI. (http://java.sun.com/j2se/1.3.0/docs/guide/rmi/SSLInfo.html). I'm not currently developing any web-apps with Jini, so my expertise in this area is non-existant. This would be a better question posted to the jini-users at java dot sun dot com mailing list.

    Jesse
  36. please read the rest of my sentence jesse, before you quote it out of context.

    and please don't take it so personally.

    regards
    scot.
  37. Regarding the connection pool you wrote in 45 minutes with all unit tests... Does it support PreparedStatement caching too? I'm afraid, it's off-topic though...

    Denis.
  38. No, at it's base, it provides connections, and allows you to throw them back into the pool. Although, aren't batched operations already available through some JDBC drivers(Oracle comes to mind first.)? I'm sure if there were a need for something like that to be done, it could be added, but we haven't needed it thus far.

    Jesse
  39. Understood. What I tried to demonstrate was that developers need to rely on an infrastructure for many things. Vendors do have time and resourses to provide such elaborative solutions, teams of developers often do not. You may not always expect that a solution that could have been implemented in 45 minutes could be an argument against a probably "phat" and heavy framework such as EJB.

    Denis.
  40. Well..., not sure what to argue about here. I'm not sure that I can even think of a reason for a conn-pool to cache prepared statements, since most good databases are smart enough to do these sort of things for you.

    Anyway, when we realease our codebase, it will be open-source, so if someone is really aching for a feature,they can add it themselves.

    As far as Vendors go, do not think that because you're using a Vendor, you neccesarily get better code written. Many open-source developers are quite capable of joining dynamic effective teams that produce extremely high-quality code. Witness apache.org. And, unlike their counterparts, they are able to focus on solutions that matter, instead of pissing contests and feature bloat to try and "capture" the market.

    Implementing prepared-statement caching would probably fall under one of these "unneeded" categories in my mind, but obviously opinions do differ.

    Jesse
  41. It has been fun reading this thread.

    There is this fundamental issue:
    "Centralization versus De-centralization".

    E.g. is it better to have centralized authorities or is it better to have local authorities? Each having its own pros and cons.

    Nevertheless, EJB is a centralization approach while Jini is a de-centralization approach.

    In my humble opinion, we need both in the world of web. Web has grown up too much to fit in purely centralized applications.
  42. Jesse,
      I learned 2 things in this thread.

    1) You are a insecure egotistical ahole. Atleast that is the only explanation I can come up with for why you feel a need to put people down and use that type of language in a public forum such as this.

    2) Jini rocks! This thread inspiried me to read up on Jini and take a more critical look at EJB (which our current app uses extensively). I totally agree that Jini appears to be a superior technology for the sort of enterprise applications for which most people use EJBs. I don't necessarily agree that because someone is not good at writing multi-threaded code, they are of no value however in writing enterprise applications. The ability to understand the full ramifications of threading and concurrency, in my opinion, take years of study and hands on experience to fully grasp. Being the obvious super smart guy that are or atleast would like us to think you are, I have a question for you.
     Why do you use Java at all and not C++? It seem to me that most people with your attitude think Java is inheretly innefficient and obviouslly every programmer worth anything should be able to manage their memory usage as well as some slow and stupid virtual machine.

  43. Unfortunately due to my lack of experience i can't contribute intelligently to the debate. However, I would like to break out of my lurker status and request something. Everyone agrees that Jesse started out arrogant and insulting as hell, etc. However, if you actually read the entire thread you'd notice that about halfway down he admitted this, apologized, and eliminated the vast majority of it from his future posts. The last few posts from other people are starting the flaming again referring to some of jesse's first remarks. Yes, Jesse was an ass for his first half dozen or however many posts. Yes, he admitted it. Yes, he apologized. Yes, his posts have been much better of late. Now everyone get over his first posts and move on. :)

    Bob
  44. Replace EJB bloat with Jini Pattern[ Go to top ]

    Hey Jesse. I like your tude.
    And, agree with most of what you had to say.
    Especially the segment about "EJB allowing bad developer to
    continue writing bad code."

    I like JINI there just are'nt any development/deployment tools
    available for JINI. So, how can JINI be sold to
    corporate types. Also, you may want have a look
    at JXTA, I think that there is probably going to be
    some overlap in these two technologies.
  45. Some of my concerns with EJB are the following:

    It's a client server protocol. The server can't easily make calls to a server except by using JMS.

    It's not peer to peer. This means that code written to run in the server can't be easily ported to run in the client if required. I'd like to see a light weight EJB container that can host beans in a client application. This gives me the flexibility to deploy beans either locally in a client or remotely in a server, for the bean it's the same. Corba was nice this way but of course lacked the runtime services you get with J2EE.
  46. "Some of my concerns with EJB are the following:

    It's a client server protocol..."

    Exactly! See guys, Billy gets it. Once you get over that initial hump of understanding what the major differences are, you will never want to look back at EJB again.

    Jesse
  47. Jesse,et al.

    Regrettably, this thread has turned in to bit of a
    flamefest. Having read all of the above posting I would
    like to point out that Jini and J2EE (EJB) are both from
    Sun. From Sun's point of view, Jini is intended for
    connected devices, whilest J2EE is a framework for
    pluggable Java components.

    I have nothing but accolades for both technologies. With
    that said however, I have an idea when both may or may
    not be used.

    If I was writting print services with the intent of
    hot-pluggable printers, I would use Jini.

    If I was writting an Enterprise-critical application
    running across diverse platforms and data-stores I would
    would not hesitate to use J2EE/EJBs.

    A comment was made earlier that JXTA was simply a rip-off
    of Jini. Might I repsectly point out that both projects
    are pets of Bill Joy. Maybe he knows something that we all
    don't?

    Maybe it might be appropriate to ask Bill what he thinks of
    this debate?

    Just some random thoughts.

    Cheers,

    Noel.


  48. "From Sun's point of view, Jini is intended for
    connected devices, whilest J2EE is a framework for
    pluggable Java components. "

    Actually no, this is not Sun's point of view at all. This is just a bad move from the marketing people as to how they introduced the technology. I have spoken to some of the people involved in creating Jini, as well as many other developers currently using the technology, and all have very different views of Jini than what you just described, as well as where J2EE fits into the overall scheme of things.

    Jini is a protocol/methodology for creating distributed dynamic services on a network that operate in a fail-safe/network-tolerant mode that allows the network to grow and change dynamically without the need for human intervention. You can post this same question to the Jini users mailing group, and I'm sure you'll get a similar response.

    "A comment was made earlier that JXTA was simply a rip-off
    of Jini. Might I repsectly point out that both projects
    are pets of Bill Joy. Maybe he knows something that we all
    don't? "

    Yes, he does know something. Although I most certainly can't speak for him, I'm sure that you'll find JXTA/JINI ahead on his list as to what is best fit for the enterprise over J2EE. Or, if you are really curious, finding an e-mail address for people at Sun is not really hard.. It's sort of a firstname dot lastname at sun dot com thing. I think it works for most anyone there.....

    Although, for obvious reasons, Bill Joy will probably not join this debate, I did hear that Gosling and Joy were both arguing over which is a better form of communication. At the time that I heard it from my friend, Gosling was arguing in favor of RMI communication, whilst Joy was in favor over the new JXTA/XML schema. Of course, this is all speculation and heresay, and I'm not sure if it's truthful and correct. It's just what I heard at the conference....

    As far as it not being fit for the enterprise, I guess that a number of people are in trouble:

    - Me, using it in life-saving mission-critical medical systems.
    - Cisco using it in a new product in combination with Javaspaces, to be announced sometime in September.
    - Worldcom
    - U.S. Army
    - U.S. Navy destroyers
    - etc....

    This is not a list of people connecting mobile phones together, but mission-critical systems that MUST work under all network/service failure conditions. Just thought I'd clear that up for you. =P

    For more information to back up what I just stated, please go check out http://www.sun.com/jini/ . (Got the partial list from "Success stories" link.)

    Jesse

  49. G'Day Jesse,

    Thanks for your reply.

    It is rather unfortunate that Sun is sending mixed messages
    in this regard. Marketing. What can I say. It is appearant
    that each group is lauding their side of the paddock.

    It is also appearant that you have found a toolset that
    works for you, in the situations that you encounter.

    If your use of that toolset makes your customer
    successful, at the end of the day that is what is
    important and good on you.

    I have found a toolset that does the same.

    I read your list of current users of Jini technology and
    do not deny that it is successful in those situations.

    I noted a common thread amougst them. They all appear to be
    extremely dynamic and real-time. I certainly would not
    advocate the of EJB on a Aegis class destroyer!

    When I mentioned my criteria for the appropriate use of
    a technology I would take this into account.

    Whilst not as sexy as Jini, I personally feel that EJB and
    J2EE in general is best suited for things like stable
    (read not very dynamic and real-time) business systems.

    The pluggable, container (coccooned) oriented nature of
    EJB suits these type of implementations.

    I concede that we agree to disagree on our use of tools.

    For what it is worth I am a Sun employee and Bill was a
    fair dinkum sort of bloke when I knew SUN to mean
    Standford University Network...

    All The Best,

    Noel.




     
  50. To all,

    In my advanced years I fat-fingered the following:

    Standford University Network...

    It should obviously read:

    Stanford University Network...

    Noel.





  51. Cool..Just to clarify though, your comment of

    "Whilst not as sexy as Jini, I personally feel that EJB and
    J2EE in general is best suited for things like stable
    (read not very dynamic and real-time) business systems. "

    rubs me just slightly the wrong way. While I agree that using EJB/J2EE DOES make it easier for developers to build enterprise systems.....Well..I was trying to be nice and non-biased here, but you already know my opinions on OOP practices used in EJB, as well as the maintenance nightmare of 4-5 files for one single class to work.....

    Anyway, IMHO Jini provides a much more stable platform to build enterprise systems on than the current EJB/J2EE spec can possibly hope to perform.

    I'm just gonig to steal this quote from Waldo for my point:

    "Waldo lamented that we often build unreliable systems where if one thing breaks, everything is affected. Customers are used to rebooting a computer without thinking.

    As technology progresses to a point where the distinctions of what constitutes a computer become blurred, people won't accept rebooting a computer. As an example, he reminds us that there are computers involved when we break our car. But can you imagine having to wait while these reboot in order to use your vehicle?

    (Here comes my main point..)Waldo emphasized that you can't make large pieces of software reliable. He suggested instead that you work on making small pieces of software reliable and then assemble them into a system that is resilient when one of the smaller pieces fails.

    In this way we can build reliable systems out of non-reliable parts." --taken from http://www-106.ibm.com/developerworks/java/library/j-j1jini.html

  52. Well, that was interesting. Quite why Floyd hasn't moved this out of the design patterns section I don't know, but it's still an interesting commentary.

    I won't get involved in this debate in detail (I don't have the time!) but I will say this.

    1) Do EJB and JINI solve the same problem? This has been discussed in this thread and my comment is "It depends what problem you are trying to solve." Some things work really well in JINI and not in EJB, some the other way round and some will work in both. There is no right way, there is simply the right way for the problem you are trying to solve.

    2) As Billy said, EJB is really a client server protocol. A slight over-simplification but he was trying to make a point, which he did. JINI operates on a "slightly" lower level than the EJB spec. For instance, using JMS as another example. JMS is a spec. Well, JavaSpaces does a "similar" thing, but JavaSpaces is something built on top of JINI. It's something very cool built on top of JINI as it happens but that's a different discussion.

    3) It is _very_ true that EJB has been over used. I refer to it as the Mount Everest of technology in the last 2 years. It has been used because it's there. In many cases it was a totally wrong choice of technology. XML falls into the same category IMHO.

    4) JINI is built around the concept of services and service aggregation. It's lookup service is based on interfaces because the idea is that you build services which provide their functionality by talking to other services. Computers really suck at talking to each other in words (ala JNDI) but they are really great at talking to each other using interfaces (ala the JINI lookup service.) This is why it was built that way. That is almost a direct quote from a JavaOne technical session on JINI. There is nothing "better" about them, just something different that may make one thing "better" for you.

    5) It is true that most distributed systems (EJB included) make the 7 assumptions about networks in the full knowledge they aren't true. EJB does it, so does JINI. However JINI directly tackles at least some of them, while EJB really doesn't. Remember, EJB is a spec, it's up to the vendor to deal with these things. They might, but they don't have to. JINI does make it harder to avoid these things it's true.

    6) Right now, JINI has no effective security model. One is in the works, but given the paradigm of JINI it has to be decentralized, hence they are looking into things like certificate chains to authorize use of services. As it stands today, this alone could kill JINI as a valid way to build your system, depending on your requirements.

    So yeah, JINI is cool. So is EJB.

    At the same time, JINI sucks, so does EJB.

    Depends on what you're trying to do. I've built whole systems where the ONLY EJB thing in it was one stateless session bean. That got me all my fault tolerance, load balancing and everything I needed in one fell swoop. There was ONE line of code in the bean, it delegated to another class. Everything else, EJB independanty. I could easily deploy this thing as a JINI service if I felt like it too, without even breaking sweat.

    Don't get hung up on pointless arguments about what technology is best. Get excited about solving real business problems using the right technology, life is much more fun that way! :-)

    Just my 2c worth!

    Chz

    Tony

  53. Hi Jesse,

    I skimmed much of tis tisn't debate. But you will make me take a detailed look at Jini.

    My history includes telecomms and writing object replication, and databases and so on. I have indeed coded it all from scratch - and I agree that these vendors of containers produce code that is seldom better than my own, often inferior. Mostly because they are solving generic problems rather than my problem (or they used a new grad with no experience....)

    Anyway, the entire point of J2EE is that it is in fashion, and developers are climbing on board to protect their CV's. Few folks have the time to do both J2EE and JINI - and have a day job :)

    So, because J2EE is in wider use it wins for the next 12 to 18 months, and all the techie arguments in the world are irrelevant. After that the counter arguments gain more weight - it's way too hard to support, deployment tools are rubbish and goal posts are moving too quickly, and EJB's really slow everything down.... So Sun will promote something new - JDO, Jini whatever.

    My guess is they will do this through evolving J2EE, which means they bring along all those developers trained in J2EE. It may be an entirely new technology, but it will be called J2EE.

    So, it's a war of hearts and minds, and EJB/J2EE is winning for the next year. After that who knows, it could be Enterprise Basic XP (or some such).

    Jonathan
  54. Very well put. I do have to agree with you on some of the points about Jini. Just as with any technology, there are good and bad sides to it, depending on your point of view. While using Jini in the enterprise is not a completely new concept to the Jini community, it does still have a ways to go before it is ready for mass consumption.

    We were one of the fortunate(unfortunate?) shops that did have to go ahead and write our own version of a thin app-server for Jini, but at the end of the day we are very proud of our little server.

    It handles:
    -Connection pool..Dynamically grows/shrinks for load, tests connections, etc..
    -Logger...Using Log4j
    -Memory management...Separate thread checks memory state and throws the server into different zones(red/yellow/green) depending upon memory state. Once it reaches the red-zone, the app-server will remove all services from the lookup-caches they are attached to and run garbage-collection until they are at least back in the yellow zone.
    -Hot swappable services...Simple re-deploy your jar file of the service and it will be dynamically re-deployed for you.
    -A very EJB-ish packaging mechanism..Ie all service classes go into one jar file, along with one properties file for configuring it within the app-server.(Thread-pool management, what default DB connection it wishes to use when calling static method ConnectionPool.getConnection(), whether or not to publish as Jini service, etc...)
    -Telnetable administration interface for app-server, and services if they support it. (Great for remote administration, where doing it from the web would pose a security concern...Telnetable admin is only available by typing telnet localhost <specified port>..So you have to log-in to the box as some user first..
    -Other miscellaneous things that I might be forgetting...

    We do plan to release this as an open-source project for the community at large over at www.jini.org as soon as we're done with the next realease of our product(sometime around September). So, hopefully the next brave souls that venture into our world won't have to re-invent what we've done.

    "Depends on what you're trying to do. I've built whole systems where the ONLY EJB thing in it was one stateless session bean. That got me all my fault tolerance, load balancing and everything I needed in one fell swoop. There was ONE line of code in the bean, it delegated to another class. Everything else, EJB independanty. I could easily deploy this thing as a JINI service if I felt like it too, without even breaking sweat. "

    That is EXACTLY what we have...We have one single EJB left to kill, which does exactly what you described above, instantiates another object that does the real work. It knows its time is coming soon, so it is acting very meek at the moment, but we will be coming for it. :) (Along with the greatly anticipated removal of any trace of Weblogic in the system...)

    My whole point with this thread was mainly to try and at least get a few people interested in what exactly Jini is, as well as to open the possibility of using it in the enterprise, instead of the prejudice that some people feel regarding devices...(Yes, we are using it to connect devices as well, but that's beside the point.)

    Anyway, thanks for the well-put reply. I enjoyed it very much.

    Jesse
  55. Hi,

    I think that tony finally gave the real reason Jini is not a viable solution right now.

    "... JINI has no effective security model. One is in the works, but given the paradigm of JINI it has to be decentralized, hence they are looking into things like certificate chains to authorize use of services. As it stands today, this alone could kill JINI as a valid way to build your system, depending on your requirements. "

    The way I understand it is that right now you can have a running Jini architecture in a closed environment where services are all known to be safe and are all under your control.
    If you let Jini run on the internet you will have tons of security problems.
    Tony talks about being authorized to use Jini services,
    what about malicious code?

    Let's use the printer example.
    What is stopping someone to register a service called printer that while printing my document sends it via email to my competitor?
    How would my client program distinguish between the two?

    Are we really going to need certificates for all Jini participants? Will then all Jini components need to check certificates? It cannot be done by the lookup service, what if it was a "renegade" lookup service sending you to the wrong services?

    I also have a question for Jesse. What hardware are you using to run Jini? My understading is that you would use many low end PC's without needing any workstation or mainframe other than for legact components. Since Jini does well with failing components does it make it a Windows-Intel domain?

    Marco Bonechi


    P.S. By the way I am half way through an EJB project, I'll try to do it over in Jini and see what happens.
  56. Marco, Thanks for your reply. To answer your questions:

    "The way I understand it is that right now you can have a running Jini architecture in a closed environment where services are all known to be safe and are all under your control.
    If you let Jini run on the internet you will have tons of security problems.
    Tony talks about being authorized to use Jini services,
    what about malicious code? "

    Yes, I would agree that in the web-services area, Jini might have some more tweaking to do to get it tight. The Jini group is however completely focused on getting the security model taken care of right now as their next major project, from what I understood at the BOF session regarding it. (Ailwife release...Some sort of fish.)

    Of course, I am not using Jini to provide web-services, so it doesn't really concern me overly much.

    "Are we really going to need certificates for all Jini participants? Will then all Jini components need to check certificates? It cannot be done by the lookup service, what if it was a "renegade" lookup service sending you to the wrong services? "

    Hmmmm. I have absolutely no idea. I'm not exactly a huge security buff, but I'm sure that you could get a very detailed response from the developers of jini if you posted your question to the jini-users at java dot sun dot com group. Everytime I've asked similar questions, I've always been delighted by almost over-detailed responses from them. The point is though, that yours and Tony's concerns are valid, and they are being addressed by the group as we speak. I'm not sure when the next major release of Jini is going to be, but I think that the security model should be implemented in it.

    Don't be afraid to go over and ask the real experts in the Jini group what it's all about, nor should anyone think that the majority of them are as callous and arrogant as most of my posts here have been when fighting the Jini cause. As I have stated, this was only temporary hot-headedness on my part, and should not be taken as the majority mindset of most Jini users.

    "I also have a question for Jesse. What hardware are you using to run Jini? My understading is that you would use many low end PC's without needing any workstation or mainframe other than for legact components. Since Jini does well with failing components does it make it a Windows-Intel domain? "

    While I'm sure that you could run everything on Windows if you wanted to, our particular deployment doesn't include any windows components. :) We have clusters of ultra-10's providing the sort of "middle-tier" of application services, many boxes running Solaris/Intel, and finally large garguantine 250/450's running Oracle for permanent persistance.

    Jini services run on all of these boxes, some provide more functionality than others, but all participate in the growing dynamic nature of our network.

    "P.S. By the way I am half way through an EJB project, I'll try to do it over in Jini and see what happens. "

    Good for you! I finally killed off the last remaining EJB yesterday myself. :) The results were phenominal, and MUCH cleaner. Although I'm not sure if our app-server is general enough for the mass-population quite yet, as we are still very busy developing new parts of our product, I'd be happy to get you a release of our Jini codebase/appserver when you get around to it. No sense in re-inventing the wheel. (Although I think RIO may provide these services as well, but we are not using it so I wouldn't know.)

    Jesse
    jkuhnert at ekosystems dot com
  57. Everyone,

    In this discussion I have lurked, read, considered,
    contributed, lurked, etc.

    At the end of the day I can only say this is honestly
    *not* a pattern discussion. This comes down to the use of
    technology tools.

    There are people on both sides with strong options, this
    thread is proof of that.

    Maybe we are all missing an important point. If we call
    ourselves IT professionals (at least in my mind) our
    job is to make our customer successful

    If I may use an analogy.

    A customer wants the simplicity of touching a switch to
    get light in a room

    They do not *care* whether it comes from coal, nuclear or
    battery, all *they* want is light.

    Whether you used Jini or J2EE or some stupid bastard
    peddling away on a push bike in the back garden is
    completely relevant.

    Use the technology (or combinations thereof) that is
    appropriate and be done with it.

    No one technology fits all.

    Unless you are Bill Gates...

    Final Thoughts,

    Noel.



  58. Since when do we care about the stupid users? :)

    Jesse
  59. "Whether you used Jini or J2EE or some stupid bastard
    peddling away on a push bike in the back garden is
    completely relevant. "

    Although I'm sure it was a mistake, the mistake is right. It IS completely relevant which technology you are using.

    "A customer wants the simplicity of touching a switch to
    get light in a room

    They do not *care* whether it comes from coal, nuclear or
    battery, all *they* want is light. "

    It's actually pretty funny that you should use this analogy, since it fits in perfectly for where Jini works best. It's just that, customers don't care what we use, so long as it works.

    That's the power behind Jini. Building reliable software that works. Jini could give a damn about the developer (not really true, but it works for this argument), it only cares about software reliability in an unreliable environment.

    On the other hand, if you are using EJB, all most people seem to be concerned about is making life easier for the developer, and achieving some demented view of a faster time to market, which in most cases is only wishful thinking.

    The world is changing my friends, and like it or not J2EE simply doesn't work. Jini may not be the last/best solution, just like Java is not the last/best solution when being compared with C++. But, it most definitely is a step in the right direction in how real world conditions need to be met.

    Take a look at the human brain for instance.(No, I didn't stay at the Holiday Inn last night, but I did watch an episode on Discovery Health Channel =p .) Nothing in software/hardware today can even begin to be as advanced a system as the brain. But, some are starting to come closer to the ideal world. The brain is a constantly adaptive and self-healing entity made up of millions of neuron connections. In patients that lose half of their brains, studies have shown that areas typically chosen for speach enablement are moved and adapted to new areas never before used for the task. Connections are lost, systems shutdown, but for some reason the system keeps chugging along and adapting to new situations.

    Not that Jini can really be compared with this situation, but it is kind of nice to philosophise on the possibilities..

    Anyway, my final thoughts on your final thoughts.

    Jesse

  60. I follow this discussion with interest.
    I agree with some of the points Jesse makes (but not the language!)
    J2EE has failed to deliver. CMP 1.1 is for kids that do not go far from the shopping cart mentality. Even CMP 2.0 is scarry, people are asking themselves to "JDO" or to "CMP2.0". Anyway, there is a lot of bloat and XML files to get your beans packaged, although some smart tools like ANT and EJBDoclet come to rescue. And it is not only the ejbs, but the JSPs and the MVC frameworks(the most bloated of which has been demonstrated in Java Pet Store Demo, the best one being webwork).

    I also researched the "other side" quite a bit. Two frameworks seems to be promising - Jiro/JINI and Rio/JINI. Jiro is based on FMA (federated management architecture) and is very similar to project RIO (Does anybody at Sun notice that?).
    The common things between the two is:
    - They are built upon the Jini model
    - They are 90% similar and fully incompatible! (cybernode=jiro station, JSB=fbeans, events, logging,....)
    - In both cases Sun made the wrong marketing: Jiro is for "storage networks" and RIO is for devices. But indeed, you can use them very well to replace J2EE applications.
    Another thing I do not quite figure out is how JMX fits in
    the picture. JMX Beans/services are seen by many as a way to escape the limitations of ejbs(threading/ io / sockets ...), providing your ejb server is an JMX container as well. It looks like that both Jiro and RIO provide their own bean containers, standart services and patterns/interfaces for beans, but they are not mature as those in JMX. On the other hand, JMX does
    not let its beans/services to be accessed remotely yet.

    Any one care to comment?

    Regards,
    Hristo
  61. "The common things between the two is:
    - They are built upon the Jini model
    - They are 90% similar and fully incompatible! (cybernode=jiro station, JSB=fbeans, events, logging,....) "

    Yes, you have hit upon an unforunate note that is still being thrashed over in the Jini community. It was very fervently discussed at the recent Jini Jam Session at JavaOne. See http://www-106.ibm.com/developerworks/java/library/j-j1jini.html for more about that.

    Yes, Jini developers are pissed, because it doesn't seem like Sun(not including the Jini development group itself) wants to fully market the technology. Everyone in the Jini community knows where its real value lies, on the server-side and in enterprise applications(opinions may differ, as I am biased mainly working on the server end of things..). It seems somewhat understandable, in that Sun has already blown its wad on promoting J2EE, and doesn't seem to want to market Jini in the enterprise just yet.

    Similarly, Joy just came out with JXTA, which he is now fervently sponsoring, so I have a feeling(don't know for sure, pure speculation), that this might also help to contribute to its non-marketization.

    I can only say that we all know it works/belongs/is in the enterprise, so the only thing to do is to just jump on board and join the fun.

    You can try checking out these web-sites for more info:

    http://www.jini.org
    http://jini.groupserver.com

    They are the two that I check out the most, as well as signing up on the jini-users mailing list.

    To quote from the very latest e-mail seen on the jini-users list (well, very latest as of this very second)

    "...Where is Jini in the master plan for Sun's Java roadmap (i.e. J2EE)? The answer is that it is not; it is never mentioned in the mainstream Java community. Yet the rage is now web services, which revolve around what? Service discovery!.."

    So, as you can see, what I'm trying to do here is open up the idea of Jini in the enterprise to more people, whether Sun wants to promote it fully or not. If enough people start using it for what it's best at, it can only help but be adopted mainstream.

    I will hopefully be able to follow-up on this thread very soon with our App-Server codebase release on Jini.org, we still have a few things to pretty up first.

    Jesse
  62. Hi,
    I have worked on Jini and what are u suggesting is certianly
    true but not practical for following reasons:
    a. Jini is based on loosely coupled architecture.
    b. Although it supports Transactios using MAHALO as its
       TX Manager, it has not been practically tested on
        enterprise applications.
    c. Ya, its really cool to work on it , as itis simple
       elegant and provides no cluttering as required when
       to develope EJBS.
    d. Right now if u want to implement WEBSERVICES layer
        on exisiting EJB layer .... i think JINI provides
        an excellent framwork for implementing SMART WEB
        SERVICES....not currently supported in WEBSERVICES
        JSR SPECIFICATION.
    e. Also for locating specific services JINI has the
        flexiblility for specifiying runtime extra paremeters
        which i think is not feasilble in EJB.
    I hope u should get a farewell idea about it.
    Regards
    Swapnil S