Sun to Simplify Java

Discussions

News: Sun to Simplify Java

  1. Sun to Simplify Java (87 messages)

    Sun Microsystems said it wants to make Java simpler and more straightforward. Sun CTO, John Fowler, said his team plans to "reduce the amount of fragmentation" going on in the Java community by doing more outreach and education for developers and vendors.

    They also said it will establish a new advisory council in April, and that they will not offer up Java as an open source format, nor join IBM's Eclipse project.

    The "metadata" approache also seems to be a key new feature for the language:

    "The company is emphasizing the use of layers - or "abstractions" - basically metadata that would allow the core kernel of the runtime language to perform in different ways. Such is the case of the metadata being addressed in Java Standard Review (JSR) number 175. Currently under review, the spec would "allow classes, interfaces, fields, and methods to be marked as having particular attributes." Sun cited JSR number 198 as another example of its metadata approach, but conceded that Oracle was the driving force behind the proposal."

    Read about Suns strategy

    Threaded Messages (87)

  2. Sun to Simplify Java[ Go to top ]

    I hope JSR175 gets ratified. I've used attributes extensively under C# and it can handle a number of cross-cutting issues (knows as the AOP - aspect oriented programming approach.)

    Standardizing attributes will be important and there is a huge potential for linking these to UML profiles.
  3. Sun to Simplify Java[ Go to top ]

    This is very good news if Sun are serious about simplification. Managing the complexity of J2EE is the biggest problem faced by Sun and the typical J2EE developer face. Previously Sun have tended to pretend that the complexity isn't a problem.

    I think JSR 175 is the most important of many promising enhancements scheduled for Java 1.5. Metadata attributes can be used as a more elegant replacement for some of the things that are presently handled in J2EE XML deployment descriptors, such as EJB transaction attributes. As transactional behavior is an integral part of the code, which it doesn't make sense to modify without changing the application, the source file is the right place for it. As the previous post pointed out, metadata will provide a perfect hook for AOP.

    Personally I would like to see Sun become more open with Java, whether through standardization or true open source. I'm not convinced that the present JCP approach allows the J2EE community to have adequate input.

    Rod Johnson, author of Expert One-on-One J2EE Design and Development
  4. Metadata Would Simplify EJB to Death[ Go to top ]

    <rod>
    Metadata attributes can be used as a more elegant replacement for some of the things that are presently handled in J2EE XML deployment descriptors, such as EJB transaction attributes. As transactional behavior is an integral part of the code, which it doesn't make sense to modify without changing the application, the source file is the right place for it.
    </rod>

    I appreciate that the metadata approach is favoured by many of those who use EJB, particularly through tools like ejbgen and xdoclet, but can't help feeling it simplifies EJB to the point where you might as well not bother with it. I can imagine scenarios where I might want the same bean to have different transactional characteristics and if we throw security into the mix then it becomes obvious to me that there are many characteristics of a deployment that can vary without needing source code changes.

    When you write an EJB with all this deployment metadata embedded within it you are no longer writing a component that can be redeployed in different scenarios, you are simply modularizing an application. Maybe that's enough for most developers, but the strength of EJB is that it is a component model and it seems a bit daft to me that this aspect is so widely ignored.

    I'm all for simplifying EJB, and embedded metadata could contribute to that, but it's not the real solution.

    Ian.
  5. Metadata Would Simplify EJB to Death[ Go to top ]

    <ian>
    I appreciate that the metadata approach is favoured by many of those who use EJB...but can't help feeling it simplifies EJB to the point where you might as well not bother with it.
    </ian>
    If a simpler approach proves equally effective, would this be such a bad thing? At least having a choice would demonstrate the cases when the EJB way of doing things is necessary and superior. And as you point out, many developers are already using EJB this way, with XDocLet and the like, to manage the complexity.

    <ian>
    When you write an EJB with all this deployment metadata embedded within it you are no longer writing a component that can be redeployed in different scenarios, you are simply modularizing an application.
    </ian>
    Yes and no. Attributes can be handled differently by different interceptors, assuming you're doing AOP. For example, a transactional attribute would define semantics, but a different aspect could handle it for JBoss or WebLogic without compromising the portability of application code. My point was that the idea of using an EJB with different transactional scenarios is unrealistic. Transactional behavior should be an annotation on the code itself. However, this isn't appropriate for everything we find in ejb-jar.xml. Sometimes getting things out into a separate DD is good; sometimes it's undesirable and unduly complex (as I would argue, with transactions).

    <ian>
    The strength of EJB is that it is a component model and it seems a bit daft to me that this aspect is so widely ignored
    </ian>
    I agree with this. However, because too few developers appreciate this EJB is often used inappropriately.

    Regards,
    Rod
  6. What is there to simplify?[ Go to top ]

    Previously, I always been highly irritated by these "Java is complex / J2EE is complex" arguments. (You only have to find some of my earlier posts on the subject)
    I mean, what is there to be simplified? I have asked "Show me how 'X' could be simplified" - but never gotten a response.
    Now, I still get irritated, but I also think I have begun to understand the problem.

    Why are people's impression of J2EE as being complex? What is unnecessary that can be dropped?

    I think that the reasons for this impression are two-fold:
    1) There are a raft of new people coming to Enterprise programming technologies that are not from an enterprise programming background. The whole concept of distributed systems is complex to these people - so they dont understand the reasons why some "complexities" are inherant. Moreover, they dont have an understanding of what J2EE technologies are used for what problems (hence the over-use of EJB in simple web applications). This doesnt at all mean that these people have no business using these technologies - it just means the some of us who have come from a C++/CORBA/DCOM backgound, dont see the problem through the same eyes as the "newcomers".

    2) The J2EE specs were written in such a way as to allow some freedom for the implementers to write competitive implementations. Some of the spec features (e.g. standard + vendor specific deployment descriptors) are essential complexities needed to achieve this. However, these largely tedious "complexities" are a barrier to entry. To get a simple (even stateless) EJB up and running takes a little leg work - especially if you are starting from scratch (I tend to copy from "one I prepeared earlier". In the context of a serious application, this is negligible. In the context of slapping up a quick demo, or a newcomer feeling their way, just a simple mistake like WEB_INF instead of WEB-INF can waste a couple of hours.

    So whats the answer?

    J2WE:
    I think that there is a definite class of applications where JSP + Webwork/Struts and BeanUtils+JBC are all that is required.

    I propose a J2WE (Web Edition) consisting of JSP/Servlet/JDBC/(Webwork/Struts).

    a) It would simplify deployment. Only the Struts/Webwork configuration is required.

    b) It would aid in right-sizing of applications - in that it will encourage a simple Action-oriented approach to simple web applications. However, if more sophisticated transaction control was required or if remoting was required, the plain java Action classes can just delegate to EJB's for the Business Logic.

    Tool Vendors:
    I also hold out hope that the tool vendors wills start to help with some of the tacky work you have to do around J2EE (deployment descriptors and the like). They shouldnt pretend that the deployment descriptors dont exist - but they should make it easier to write them and keep them in synch with the CODE. IntelliJ helps somewhat with this - so does Eclipse. But neither of these tools fully adress the problems.

    Attributes/Metadata?
    I dont have a firm opinion on this one. There are some things (such as Transaction demarcation) that Metadata *might* help with.
    However, one of the things that I like about the current deployment descriptors is that you can employ such "failsafe" strategies as using '*' in the assembly descriptor to set a default security/transaction for a whole EJB.
    This means that if anyone adds a new method it will be automcatically caught by the deployment descriptor's default setting - and any exceptions to the default can be explicitly defined.
    Doing such a thing would still be possible in Metadata, - I just wonder whether it will be as easy to check/verify with the settings scattered throughout the src code.

    -Nick
  7. What is there to simplify?[ Go to top ]

    <nick>
    Previously, I always been highly irritated by these "Java is complex / J2EE is complex" arguments
    </nick>
    Java is simple, J2EE is complex. (Swing is arguably over-complex, but that's a separate issue.) I'm intrigued that you find such criticism of J2EE so irritating. 2 or 3 years ago I was a J2EE and EJB zealot, but I've changed my mind.

    What is there to simplify? A couple of things off the top of my head... I'm talking about an ideal world, not what's possible tomorrow.
    - EJB. There's a strong argument that looking up EJBs via JNDI and having to create 3 Java source files for every EJB is over the top. Most containers now use dynamic proxies, meaning that the original approach of container-generated code is looking dated. An AOP approach could be far nicer.
    - The entity bean deployment descriptor mess. It's impossible to edit all the required files by hand--it's possible with JDO, for example. You might say "use XDoclet or an IDE" but I'd rather have less complexity than rely on tools to manage it. For example, to implement an entity bean in WLS, I need to edit 3 Java source files, plus ejb-jar.xml, weblogic-ejb-jar.xml and weblogic-cmp-rdbms-jar.xml.

    You and I may know J2EE inside out, but _many_ developers lack a thorough knowledge of it and are busy creating flaky applications. This is worrying.

    <nick>
    There are a raft of new people coming to Enterprise programming technologies that are not from an enterprise programming background. The whole concept of distributed systems is complex to these people - so they dont understand the reasons why some "complexities" are inherant.
    </nick>
    True, but J2EE is partly at fault for encouraging many people to model applications as distributed for no good reason. Also, I came from C++/CORBA/MTS, yet I consider J2EE unnecessarily complex. We should have learnt more than we have.

    I really like your J2WE idea. It's a question of horses for courses: J2WE would provide the right technology set for a _lot_ of applications. However, I don't think a particular MVC framework should be an integral part of the platform.

    Rod
  8. Quite a few things to simplify[ Go to top ]

    1) Persistence must become a quality of the object model (part of it). Attributes and a smart container can make this happend.

    2) Better library design (nobody with their head in the right place thinks that Swing has a good design - academically sound, yes, but hopeless in large realworld apps)

    3) EJB 2.x made things worse (different argument passing semantics for local and remote calls, etc)

    4) Standardized deployment process
  9. Quite a few things to simplify[ Go to top ]

    2) Better library design (nobody with their head in the right place thinks that Swing has a good design - academically sound, yes, but hopeless in large realworld apps)


    You're 100% right on this. When you're coming from the Microsoft world (Visual C++), you simply regret there's nothing to write good thick clients for your EJBs. Swing is just bullshit for this. I definitely never recommend using Java for thick clients : productivity is just wasted. And Microsoft has again improved on this track : with Visual Studio .Net, it's just as easy as with VB or Delphi. With WinForms, you can even design graphical components that run both in thick clients and in browsers (IE only, of course). Gracefully it's possible to call your EJBs from Windows clients.
    If Sun does not improve on library design, they'll loose the J2EE market : it takes much more time to write an Enterprise application with Java rather than with .Net (see http://www.middleware-company.com/j2eedotnetbench/report.shtml page 40 "Appendix 1 Comparing Lines of Code"... and a rematch won't change this).
  10. "If Sun does not improve on library design, they'll loose the J2EE market : it takes much more time to write an Enterprise application with Java rather than with .Net (see http://www.middleware-company.com/j2eedotnetbench/report.shtml page 40 "Appendix 1 Comparing Lines of Code"... and a rematch won't change this). "

    Yes, you can certainly write an app with shitty design much faster than one with good design. What's you point? And how does the Swing library have anything to do with the J2EE?

    Ryan
  11. Simplification?[ Go to top ]

    What is complicated? Truly. There is soem dead weight in the JDK, namely AWT, but nothign in the JDK is particularly complicated. The reality is exactly what Sun admitted to. That this initiative is beign driven by Oracle. There is only one word here, "greed."

    The fact is that all of the .NET advocates fail to realize is that Java and J2EE is a language for professionals. Not amatuers. If you find Java overwhelmingly complex than you are perhaps in the wrong business.

    In fact, the industry has been suffering from an influx of amatuers that can talk a good game but complain of "complexity" when anyone wants them to actually accomplish anything. Instead of learning how to program properly, they troll the JCP and the other various initiatives looking for "simplification." Java and J2EE programming was never supposed to be somethign that Joe Bob with his 2 weeks of visual basic trainign was able to master. If you cant handle writing J3EE apps without usign the fancy tools than you are in the wrong field. Quite frankly, consultants such as myself, are sick of cleaning up the messes the amatuers make.

    The myths are staggering. Even in this thread, we hear such preposterous claims such as "Swing in overcomplicated." This is rediculous. Swing is a beautiful trim way to make powerful and performant GUI applications. If I had a euro for every time I heard someone say, "Swing GUI's are slow" and then showed them one that is exceedignly complicated and basically lightning, I would be a rich man. The problem here, as elsewhere in Java, is that people are too dependent upon their tools. How do you do your swing apps? I can hear a fleet of people out there thinking, "Well, I start up the GUI builder in JBuilder and start creating forms." Good god man! You dont have the slightest clue whats goign on under the hood and you are blaming java? Using a GUI builder to do anythign but prototyping is like usign a chainsaw to trim your fingernails. You might get it working but it will be dangerous, problematic and likely cut your finger off.

    What I am personally sick of are two things. First of all, the fleet of incompetent Java developers blaiming their lack of education and talent on "complexity in java." Second of all, the .NET people commign to a J2EE forums as if Microsoft (the most unethical company in the history of computing) was the hols savior of distributed applications.

    All of you who think java is "complex" shoudl really go to .NET. Leave the development of J2EE applications to the professionals ..


    /rant_mode off
  12. Spellchecker needed[ Go to top ]

    Hmm ... needed feature ... spellchecker. Wow, my typign in that last post was lousy.
  13. Simplification?[ Go to top ]

    "In fact, the industry has been suffering from an influx of amatuers that can talk a good game but complain of "complexity" when anyone wants them to actually accomplish anything."

    Amen. Preach it brother.
  14. Simplification?[ Go to top ]

    <quote>
    All of you who think java is "complex" shoudl really go to .NET. Leave the development of J2EE applications to the professionals ..
    </quote>
    Yes, I think J2EE is an overly complex solution for many problems.
    No, I don't want to go to .NET. I would rather do my best to improve J2EE. I don't want Microsoft to dominate middleware, although it sounds like you wouldn't care so long as you get to feel smarter than the people who still have jobs.
    I wouldn't imagine I fit your definition of amateur. I have a strong academic background in computer science, I've worked with Java for 7 years in several large projects, I've written or contributed to 4 books on J2EE, and I'm involved in the JCP. Prior to Java I worked in C and C++.

    I just don't understand why so many in the J2EE community can't accept any criticism of J2EE. And I don't understand this arrogant "if you don't enjoy complexity you're dumb" attitude. I seem to remember something similar from the CORBA community a few years ago. And where are they now? I also remember many Visual C++ programmers patronising Java programmers a few years back--I've since advised two on how to go about getting Java jobs.

    Much of the value of the Java language is that it's simple, compared with predecessors such as C++, and its simplicity translates into increased productivity and reduced bugs. Certain parts of J2EE (not the whole of J2EE, by any means) have lost this value.

    As I consultant I've cleared up more J2EE messes from people who loved complexity for its own sake (and produced applications like the Pet Store) than the "amateurs" you describe who were after simplicity.

    <quote>
    If you cant handle writing J3EE apps without usign the fancy tools than you are in the wrong field.
    </quote>
    I assume you write all your CMP entity bean deployment descriptors by hand, then. Or do you accept that that's complex?

    Regards,
    Rod
  15. Simplification?[ Go to top ]

    Rod;

    First of all, Entity beans are somethign I distinctly dislike. They are an overengineering solution that doesnt work. If that is what we are talkign about "simplyfing" than Im all for it.

    My post was in respose to the fleet of .NET and C# evangelists that you see all over this board includign in this thread. If you are a java guy workign from the inside out to change things such as pitching Entity beans out the window in favor of JDO, I will be right beside you.

    No, java isnt perfect. But there are allot of amatuers screaming bloody murder and failing to relize that with java comes power, which brings with it the ability to cut your hand off if you dont know what you are doung. Technology hopping isnt going to solve it.

    One thing about Java is the JCP. It may be clunky and make the wrong decisions sometimes (not including generic in JDK 1.4 :rolleyes: ) but at least we have a process. The .NET project is so new, but come 2 or 3 years when .NET needs to revolutionize, they will be petitioning to microsoft whoe will be happy to upgrade in their own good time and for a hefty price tag. As they will be coded into a proprietary platform they will once again learn a very hard lesson of having no alternative.

    Whatever the failings of Java, the differences between java and c# or between EJB and .NET is that in java/EJB we have CHOICE.

    No, Im nt against improving the JDK, but if they try to dumb it down to .NET levels, Ill beat them over the head with a broomstick.
  16. Simplification?[ Go to top ]

    Robert,

    I think we're on the same side.

    <quote>
    First of all, Entity beans are something I distinctly dislike. They are an overengineering solution that doesnt work. If that is what we are talkign about "simplifying" than Im all for it.
    </quote>
    Exactly my point. I don't want to throw out J2EE, just focus on what delivers real value. And some of the most complex things, like entity beans (around 30% of the EJB spec) don't offer much.

    Regards,
    Rod
  17. Simplification?[ Go to top ]

    Yep, I agree with you.
    This reaction is easy to explain : if you're frustrated and don't know what to reply, you just say that the other is dumb. It's easier than trying to understand what he really means. I'm not a .Net evangelist (that's what I've read in some reactions to my previous post). But I know quiet well both technologies : I've been professional C++ developer for 2 years (with Windows) and now I'm Java developer for 3 years (that's not a lot, but i'm only 25). I would just like that Sun takes a bit more from Microsoft (not all). They sometimes have good ideas too. I want the best for Java because I think that, at the end, only the best will survive ... and I'm not sure that Java is currently the best. :-((
  18. Alive and well[ Go to top ]

    Robert,

    Oh thank god, I was a little afraid that you had become sick or something, - but now am I reassured. The old Java community in action again!

    Regards
    Rolf Tollerud
  19. Alive and well[ Go to top ]

    Rolf,

    Most people complain about you but I must admit, you crack me up.

    Long live Rolf!
  20. Stockholm Syndrome[ Go to top ]

    Race, I'm afraid you've developed Stockholm Syndrome...you've learned to identify with a tormentor and eventually embrace them. :)
  21. Stockholm Syndrome[ Go to top ]

    Hmm. As fact I really do live in Stockholm..

    Regards
    Rolf Tollerud
  22. Alive and well[ Go to top ]

    Im not sure how to take that Rolf. I merely speak my mind. After spending another 3 weeks unraveling the mess of pathetic EJB and GUI code made by yet another JBuilder autogeneration jockey, I get a bit punchy.

    Java is Powerful. What you dont find in the JDK is in other specifications. What others call "complexity" I call richness. Java can do a whole lot of things and this is what people are complainign about?

    Instead I come here and get innundated with people that Microsoft has to be payign to troll this site and advertise .NET. Im a little sick of it.

    This is a J2EE forum and page. The .NET people need to learn where the bloody door is and use it. I wont come troll the .NET forums and I expect them to do us the same courtesy.
  23. Yes, you can certainly write an app with shitty design much faster than one with good design.


    How can you say that the .Net application will automatically have shitty design and the Java will have good design ? Design is much more a matter of analysis of requirements and quality of the code that the programmers produce (based on how well they know the language and tools to produce this code), than of the programming language. It's partially a matter of the programming language, but Java and C# are quiet the same in their basic functionalities. And to tell the truth, C# has a small advantage on Java in design issues : properties, getter and setter methods and events a part of the core language.

    > And how does the Swing library have anything to do with the J2EE?
    It's obvious. If a company decides to start an enterprise application, it needs also to write the client side. For the client side, it has basically two choices : thin web client or thick client. If it goes for J2EE with a thick client (you cannot do everything with thin client and sometimes the thick client is the only possible solution), it'll want to use Swing to have only one technology in the project : that seems less expensive and easier for maintenance. The problem is that Swing is missing a lot of nice features (partially a side effect of "write once, run everywhere"; partially because it's not well designed since the beginning) that the users want. For example (and if you want more like that I can give you a lot : i'm talking by experience), a very basic component like the formatted text field has been only added in JDK 1.4. It means that before JDK 1.4, you had to add an external component (bought or built in house) to your project. Not nice for a company. So, after having spent a lot of money (and time) to Java in doing very basic things and noticed that they could have be done the same much faster with .Net, they'll switch to .Net for client and server side (again to have the same technology on both side) in the next projects.
  24. What is there to simplify?[ Go to top ]

    |
    | The entity bean deployment descriptor mess
    |
    Its like I said - these sorts of things are necessary in order to have some vendor neutrality with respect to a) the appserver and b) the persistance provider.

    Agreed, editing these buggers is a PITA - however, its reassuring to know that I can plug in Toplink and re-write just 1 descriptor...

    |
    | I'd rather have less complexity than rely on tools to
    | manage it
    |

    I dont particularly agree - and this brings me to a rather important point that I forgot to make earlier:

    Most of these "complexities" are a trade-off. Flexibility comes at the cost of complexity. You can make a platform simple or flexible but not both - you can only choose a optimal point on the curve.

    Essentially, these platforms are targeted to solve a certain class of problems. EsSentially, there is a bell curve where

    You can either have a tall narrow bell curve (e.g. where a platform is exceptionally simple for 10% of the problems - but exceptionally difficult or impossible for the other 90%) or you can have a wider lower bell curve, where 100% of the problems are do-able, but its actually all difficult)

    Now, if we look at the pre-.net Microsoft platform (just to avoid the .net / java distraction), it was exceptionally good at solving a particular class of problems. The barrier to entry was quite low, and the amount of assistance provided by the platform and tools was quite high. But once you stepped outside of the bell-curve of the problems it was targeted at (which was a bit narrow), things became exceptionally difficult - or practically impossible.

    Now, I would say that J2EE (without the tools) is a wider, flatter bell curve. There is a higher barrier of entry, but its also very flexible. There are not too many problems that are not sensibly solveable in J2EE.

    The benefit of tools in J2EE therefore, is that they can raise the bell curve without narrowing it.
    In the enterprise application environment, I think we always find ourselves with some weird and wonderful problems - which always tends to pull us away from the ideal middle of the bell curve. I am very happy that I dont have to drop J2EE and look to another platform to solve this class of problems.

    |
    | However, I don't think a particular MVC framework should
    | be an integral part of the platform
    |
    I think it should. I personally think that it simplifies web development - and at the same time encouraging very good design.

    -Nick
  25. Right-sizing applications[ Go to top ]

    In chapter 1 of my book, which is available online, I present some criteria for right-sizing applications: specifically, deciding when to choose a distributed architecture and when to use EJB. This is an important topic that doesn't seem to get the attention it deserves.

    Rod
  26. Comments on your chapter...[ Go to top ]

    Thank you for posting your writing on the web, however you fail to give any real justification for a distributed application. The title of the chapter is "Deciding Whether to Use a Distributed Architecture", however you do not answer this question, or give any criteria for determining an answer.

    To give two "benefits". The first, lets call it "shared middle tier" is not a benefit. It is simply describing a deployment scenario. Why would an application need to share a middle tier? this is what your section should be answering.

    And again, your second "benefit" is not a benefit at all, the ability to deploy an application component to any physical server is more of a qualification or precondition for defining an application component as distributable, it is hardly reason for making an application distributed.


    I can think of two reasons such an architecture is necessary...

    - broker resources : the machine might pool expensive connections to a remote system, or have a great deal of processing power to solve complex problems. Or it might have access to unique information like the mp3 you have been searching for.

    - political : the code must run within our Atlanta office because we can't have Pepsi finding out our secret formula.

    - interface demands : the third party product must run as a separate process, and can not be embedded in our application.


    the last one is a bit of a stretch as it was not us that made the choice of making the application distributed but the product vendor, so there really is no reasoning to be done.

    What others?

    Perhaps some of my confusion comes from my definition of distributed architecture...

    "a process that must invoke a service on another process in order to fulfill a request"


    stretch
  27. Comments on your chapter...[ Go to top ]

    Dear Anonymous, thanks for your comments.
    <quote>
    The title of the chapter is "Deciding Whether to Use a Distributed Architecture", however you do not answer this question, or give any criteria for determining an answer.
    </quote>
    It's not the title of the chapter: it's a heading near the beginning. The chapter as a whole does address this question, amongst other things.

    I give several criteria for making the call. From your comments on p 18, the "shared middle tier of business objects" (the complete quote) is indeed a benefit in some distributed applications: I refer to the possibility of different client types, such as application clients and web UIs that need to share business objects. This is one of the "classic" J2EE scenarios, although in fact it's not that common as a business requirement.

    My second criteria, "the ability to deploy any component on any physical server" is important in load balancing in a minority of applications. I talk about using SLSBs to achieve this later in the chapter. Imagine that we have very slow calculations in our EJBs and a thin web tier: we might want to run the EJBs on 10 servers and the web interface on 2.

    Two of your 3 justifications for a distributed architecture are questionable. Your point about brokering is basically describing a 3 tier architecture. This doesn't need to be distributed. It could be a web app using servlets and a JDBC connection pool in the middle tier.

    Splitting application components for "political" reasons is a rare requirement. Anyway, it comes under my second benefit, the "ability to deploy any application component on any physical server."

    Your third point about a service needing to run out-of-process is valid, and a good point.

    Regards,
    Rod
  28. Comments on your chapter...[ Go to top ]

    |
    | This is one of the "classic" J2EE scenarios, although in
    | fact it's not that common as a business requirement.
    |

    It depends on the kinds of apps and the industry.

    It is a reasonably common requirement for some of our apps. What we provide to our clients on the internet (html-based app) wont be the same as what we provide our intranet users (swing-based app) - but they share the same middle tier. Generally our intranet users want a better UI than our clients. They want such features as asynch notification, live data etc. Also, applications may have other systems as clients.

    Its fair to say that most of the apps we write do not have html based UI's - therefore a distributed architecture is necessary.


    You can add to the list:
    + Corporate Security requirements dictate that your presentation and business logic tiers are seperated by a firewall.

    + Your web tier and EJB tier are on different appservers (apart from development, where we have used Tomcat and Weblogic, we havent encountered this in real life)

    -Nick
  29. Comments on your chapter[ Go to top ]

    "Its fair to say that most of the apps we write do not have html based UI's - therefore a distributed architecture is necessary. "

    Why? why can the swing client not connect directly to the database? why can you not run you busniess logic on the client machine?

    "+ Corporate Security requirements dictate that your presentation and business logic tiers are seperated by a firewall. "

    Very interesting "requirement"

    "+ Your web tier and EJB tier are on different appservers (apart from development, where we have used Tomcat and Weblogic, we havent encountered this in real life) "

    This is not a justification for distribution, you are runnning around in circles.. "they should be seperate, because they run on different machines" does not make much sense.. why put them on different machines is the real question that should be answered.

    The question about the swing app above is pretty silly, I can think of two off the top of my head why you would want the client application to not communicate directly with the database..
    - you have many clients, and they will overburdden the database if they all open up a connection.
    - they don't have access to the database, a connection can not be established for security reasons.

    these are the TRUE reasons for creating the middle tier.. diffrent ui's over common logic does not necessitate out of process communication. Perhaps you can think of some others?
  30. Comments on your chapter[ Go to top ]

    anonym,

    The firewall requirement seems to be a pretty standard way of doing things. I haven't seen many big companies that don't do this.

    -Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  31. Comments on your chapter[ Go to top ]

    The requirement is ill defined, What is presentation logic? how does it differ then business logic? Who defines what presentation logic is and what business logic is?

    You are right that it is pervasive, and often system administrators will put up a fire wall between two machines and limit access between them. I have even seen it used more then once as justifiaction for splitting code across two machines just as you described, but in the end it has no impact on security, as a compromise on the client still allows any request to be made to the server, it will just fly right by the firewall as another valid request.
  32. Comments on your chapter[ Go to top ]

    |
    | Very interesting "requirement"
    |

    Well, interesting or not, its a common requirement in banks and financial centres.

    |
    | in the end it has no impact on security, as a compromise on
    | the client still allows any request to be made to the
    | server, it will just fly right by the firewall as another
    | valid request
    |

    Essentially, there are usually 3 different DMZ's and in order for an intruder to gain direct access to the data, they must breach all 3. If a hacker gains access to the "presentation tier" - ie the tier that does the rendering of the display (ie servlets/JSP's) then all they can do is access the (secured) business logic tier. The only operations that are available to them are regulated by the middle tier - they still have to abide by the business logic of the middle tier and bypass the security of the middle tier.
    Not only is a physical seperation (enforced by a firewall) mandated, but also a protocol/semantic break.
    By protocol break, I mean that if http is the protocol allowed throught the 1st firewall, then no http is allowed through the second firewall.
    By semantic break, I mean that the API's between 2 tiers should also be different - this means no RMI JDBC drivers, and no proxying (ie using t3 to proxy onto an identical API on iiop)
    Some very security conscious companies (usually by necessity) even insist on custom/proprietary protocols - that no-one else uses or knows, for communications between the different tiers.

    I hope this is enough detail to assure you I am not making stuff up in order to build distributed applications ;-)

    |
    | diffrent ui's over common logic does not necessitate out of
    | process communication
    |

    It depends on what your business logic is. Its too simplistic to say "does not necessitate".

    Quite often there are a number of clients that use the same service. Think about a pricing service. There are trading applications, risk calculation applications, marketing applications - all want to be assured of getting the SAME price. The only sensible answer to this is to have a server-side application. The maintenance overhead of SIMULTANEOUSLY releasing a new version of ALL clients every time a business logic change is required is an overhead that wouldnt be tolerated for long.

    There are also a number of other reasons why distributed applications are required.

    1) Depending on the application, the CPU resources of the client may be insufficient:
    In some kinds of trading applications, a large proportion of the CPU time of the trader workstation is devoted to repainting the screen. If complicated analytics are also required for pricing, then these need to happen on elsewhere - on a dedicated multi-cpu clusters. (here also, the pricing server may cache results - which is useful if many users are pricing the same product)

    2) Depending on the application, the interaction with other back-end systems may not be suitable for the network quality (e.g WAN):
    The back-end system may not always be a database connection. It may be a connection to a legacy system. As is usually the case with a database, the interface to that legacy system may be very fine-grained - therefore you want to perform as many of the operations as you can as close to the legacy resource as you can - leaving an optimised, course grained interface to the client which may be connecting over the WAN. Connection limitations arent the only reasons for server-siding an application - there is conserving bandwidth as well.

    3) Not all server-side (distributed) code is Java - so network classloading is not necessarily an option. If you start having to distribute native code to client machines, then the maintenance costs spiral. (In any case, you always want to avoid even the POSSIBILITY that a user can be running different code than the person trying to support it).

    4) Depending on what the server-side application is, to distribute the entire implementation to the client may be a large overhead. Imagine every client workstation requiring installations of: MQSeries client, Oracle Client, Sybase client, Ingres Client etc. Not only that, then imagine there is some cludgy stuff that reads from a filesystem - then all clients need to map this drive. Etc etc. Not only that, but when you need to apply a service pack or a patch to any one of the above client installations, you now have 50-500 machines to update....

    5) Depending on the application, the RAM requirements may be prohibitive. Imagine a static data cache holding that caches 100's of 1000's of entities. It doesnt make sense for each client to have their own copy of this cache - and the RAM to hold it.

    6) Depending on the application, there may be a requirement for all clients to be looking at the same in-memory results of some calculations. A real-time position/risk calculation engine caclulates and publishes the current position and risk - and this is updated for every new trade or change in market parameters. A) - it doesnt make sense for these complicated calculations to be duplicated on each client machine for each input change. B) You want to have ONE referential result - not (potentially) each client having different results...

    7) Security again:
    You may not want each client workstation to even have network access to a highly sensitive resource - like the ledger. A server-side application not only hides this resource, but also allows a finer grained security control (ie accept connections from only the server machines' ip addresses)

    Theres plenty more...

    -Nick
  33. Distributed applications[ Go to top ]

    Anonym twice,

    I too tend to think that distributed applications are useless in many occasions. My definition of a distributed application is that of a system that is divided into components that expose an interface written for a middleware protocol, that can run independently from each other and that can be called from a local or remote server through an interoperability and a network protocols.

    There are many cases where truly distributed systems are unavoidable. Off the top of my head:

    - A requirement dictates that an existing application written in C and accessible through CORBA be made accessible to web browsers through a rich Java client;
    - An application written in PL/SQL needs to be web-enabled;
    - Several existing J2EE applications offer functionality than can be reused as business processes in a workflow (distributed resources);
    - Rod's statement about load distribution is perfectly valid: optimising resources naturally results in separating the heavy-weight components from the light ones and assign them just the resources they need (if the network latency/distribution trade-off is proven valid);
    - Security issue: the requirement dictates a physical layer between the part of the application that manages data and the part that deals with presentation for instance, the two being separated by a secure proprietary network protocol on a very specific port;
    - The integration of a third-party product that runs on its own JVM, such as Oracle iFS;
    - A central J2EE application that runs on an intranet that uses applets and run daily batches on the server;
    - A peer-to-peer system that triggers federated searches.

    There are certainly many other valid reasons to use a distributed architecture but these could be summed up as follows:

    - Integration of existing systems written in different languages, or that demand their own JVM, or through BPM;
    - Heavy-weight components segregation;
    - Security requirements;
    - Web-based presentation too limited, rich client needed on internet clients;
    - Assets reuse within different services of a big company;
    - Peer-to-peer model.

    However, the widespread way of using J2EE, pure web applications that run queries against a DB, does not require a distributed model at all. Clustering works fine with colocated applications running on different servers. The remote interface for EJBs should only be envisaged if the application serves business processes. Even then, the tendency is to use web services for that.

    Distributed applications comes from the middleware background and are primarily aimed at collaborative heterogeneous applications. J2EE is distributed for this very reason and IIOP was chosen as the mandatory protocol due to the CORBA standard. Granted, CORBA is great, but for some reason (it's arguably too complex), it has had a mitigated success that jeopardises its reuse within J2EE and web services are preferred even though they still lack a true security, stateful and transactional environment.

    I don't understand what your problem is with Rod's distributed architecture section p.18. I found it extremely clear. Later in the book and in many occasions, he opposes it to colocated applications. You have to accept that there will unfortunately always be haze around technological concepts and definitions. Words like clusters and migration for instance are differently interpreted in the developers and database communities. The best thing I can recommend to you is that you actually buy and read the whole book. Perhaps you will consider it in its entirety and would not bicker at details like this. This book is probably the best thing that recently happened to J2EE mainstream architecture, design and development.

                    Yann
  34. Distributed applications[ Go to top ]

    "There are many cases where truly distributed systems are "
    unavoidable. Off the top of my head: "

    Thank you very much Yann, this is the kind of content I was expecting after reading Rod's post and introduction to the posted chapter. But feel that the document failed to deliver.


    "However, the widespread way of using J2EE, pure web applications that run queries against a DB, does not require a distributed model at all."

    Right, and I agree with all of your points and everyting that Rod has written as well. Until the industry can
    define it's terms it is hard to carry on any meanigfull dialog.

    "My definition of a distributed application is that of a system that is divided into components that expose an interface written for a middleware protocol, that can run independently from each other and that can be called from a local or remote server through an interoperability and a network protocols."

    Thats pretty good.
  35. Comments on your chapter...[ Go to top ]

    "I refer to the possibility of different client types, such as application clients and web UIs that need to share business objects. This is one of the "classic" J2EE scenarios, although in fact it's not that common as a business requirement. "

    Sorry Rob, we are missing each othere here. You are again defining the traits of a distributed system as rather then justifying it. What requirement might lead to these remote business objects? why not run this same code in the web container? why do they need to be on a different machine or even in a different vm? How does sharing a busness object running on a remote machine differ then deploying the object so it runs on all systems that need it?

    "This doesn't need to be distributed. It could be a web app using servlets and a JDBC connection pool in the middle tier. "

    If this is not a distributed system, then I cleary don't understand your definition of what a distributed system is. Could you please explain why the system above is not "distributed"? or mabye it is your definition of three tier? which is also very vauge. It is a real problem in our industry that these terms are so ill defined.

    I assume you mean the jdbc pool is running within the webcontainer? If these connections are expensive, (becuase the db is underpowered) then pooling them at a global level, so they are shared by all web containers will open less connections, especially with a very large number of web containers. While this example is a little fake as most people would just buy a better machine, consider connections to the local registry of motor vehicles, these connections are often monitored heavily, so the more that are opened, the more logging and processing that must be done. If each web container must open a connection, you will be limited as to the number of webcontainers you can run. But if you pool these connections so that all containers share them you can open fewer then one connection per a container.


     "the ability to deploy any component on any physical server" is important in load balancing in a minority of applications"

    Then perhpas you should rephrase it to be..

    "the ability to deploy any component on more then one physical server"

    The component must of course be running "out of process" for this to be done, so this is a specific kind of distribution. It is definitly a good reason for distribution that does not seem to fit into any of my reasons I described above. But perhaps the cluster manager or jndi server is really just brokering the cpu resources of the cluster? So this is a from of resource brokering?


    From your reading, I think you agree that all to often a distributed system is assumed to be better and more flexable. While in fact they are slower, more complex and harder to maintain, if reasons for building such systems can be enumerated then perhaps we will see less of them around.
  36. Comments on your chapter...[ Go to top ]

    <quote>
    You are again defining the traits of a distributed system as rather then justifying it
    </quote>
    No, I am justifying a distributed architecture to meet some business requirements. A Swing client obviously can't be in the same VM as business objects. We mightn't want to run business objects in each VM in this scenario (for example each Swing app) if they are shared by other client types such as web apps.

    My definition of "distributed" in the chapter refers to distributing J2EE components such as EJBs and servlets across multiple app server instances. Thus I class a web app that communicates with a database via a connection pool as not being distributed. I don't think the fact that the database is out of process makes an application distributed. I think everyone agrees on the definition of three tier--I don't think this is vague. The motivation of connection pooling is not because the "db is underpowered". It's because it's expensive to create a connection. For example, Oracle isn't "underpowered" yet creating an Oracle JDBC connection is expensive.

    <quote>
    But perhaps the cluster manager or jndi server is really just brokering the cpu resources of the cluster?
    </quote>
    Yes, this is one way of looking at it.

    I do think many applications are made distributed for no good reason. I think we agree on this.

    Rod
  37. Comments on your chapter...[ Go to top ]

    "A Swing client obviously can't be in the same VM as business objects. We mightn't want to run business objects in each VM in this scenario (for example each Swing app) if they are shared by other client types such as web apps. "

    Sorry to differ, but you can deploy any class within a swing application. There are no limitations to what byte code can execute within a stand alone swing application. If a "busniess object" is a synonym for ejb, then please just say ejb, but the next question is, why use ejbs in this case and not package your logic in a more reusable manner like a javabean? This sounds much simpler then making remote calls at runtime to an external system. (please see my previous post for the REAL reasons why the middle tier might need to exist)


    There is no upgrade issues as there are many products that allow dynamic byte code loading, and creating a smilar scheme is very simple. Any update you make to the shared code will be seen by the client applications the next time they are started.
  38. Comments on your chapter...[ Go to top ]

    "A Swing client obviously can't be in the same VM as business objects. We mightn't want to run business objects in each VM in this scenario (for example each Swing app) if they are shared by other client types such as web apps. "
    OK, the first sentence was unclear. The second explains what I mean: in this scenario we don't want business objects held on every machine running the Swing client. This would be a 2-tier approach. For example, one db connection per standalone client won't scale.

    I'm quite aware of the fact that "there are no limits what byte code can execute within a Swing application", so you can spare the Java lecture.

    You seem to assume I'm very pro EJB and pro distributed applications--if you read the chapter carefully, you'll see that I view distributed architectures as complex solutions to complex problems, and EJBs similarly.

    As I noted previously, your "REAL" reasons for using a distributed architecture are flawed. Also you continue to confuse a "middle tier" with a distributed application.

    Rod
  39. What three tier really means[ Go to top ]

    "This would be a 2-tier approach. For example, one db connection per standalone client won't scale."

    Which is why you need a server to broker the valuable resource, the db connections.

    "You seem to assume I'm very pro EJB and pro distributed applications"

    Rob, I am only trying to get at the heart of the matter, and clearly express what I am sure everyone reading these posts already knows. It all comes down to defining the terms and reasoning about and justyfing through logical conclusions why these systems exist. This thread seems to have done some of that, which is good.


    "Also you continue to confuse a "middle tier" with a distributed application. "

    A three tier application is a distributed application. It is hard to imagine a definition of distributed that will not encompase this common deployment scenario. In your last post, you clarified your definition slightly and said that you where reffering only to "distributing J2EE components such as EJBs and servlets across multiple app server instances" which is almost always called simply "load balancing" or clustering.

    My very first post assumed that our definitions differed, and I was correct. It would help if you clearly define your terms in your chapter, it would help if you used a clearer term like "load balancing" or clustering. Rather then distributed which almost always encompases the three tiered model that you speak of.
  40. What three tier really means[ Go to top ]

    Early in the chapter I define how I use "distributed". I make it clear in the text that the definition of distributed is a common J2EE usage, in distinction to "collocated" J2EE applications in which all J2EE components run in the same JVM. So would you call a Swing application that accessed a database "distributed?" I guess technically it is, but I doubt most J2EE developers would understand your meaning.

    It seems that we basically agree that distributed architectures, as I've just defined, are a complex solution to complex problems, rather than an automatic choice. So it seems that we're having a pointless debate about definitions.

    P.S. It seems you want to keep your anonymity, but you might bother to spell my name (which isn't a secret) correctly.
  41. When to EJB[ Go to top ]

    EJB should only be used in case of CORBA.

    EJB should never be used for persistence.


    More:
    Since EJBs are slow, and not scalable, they should not be used on high load applications.

    Since EJBs are complex tecnology, they are complex to develop. If a client has a complex bus. problem, EJB will make it more dificult. When clients have complex problems, a simple solution is needed.

    EJB is fastest way to make your client go to .NET.

    EJB is FUBAR. J2EE.jar for 1.4 includes Castor.

    .V
  42. When to EJB[ Go to top ]

    <vic>

    EJB is fastest way to make your client go to .NET.

    When clients have complex problems, a simple solution is needed.

    </vic>

    Excellent points Vic!!! Simple solutions are best solutions.
  43. When to EJB[ Go to top ]

    Vic,

    Thank you for speaking the obvious!

    In 1581, a group of philosophers, musicians, artists, intellectuals, and scientists all met in Florence to discuss where society was headed. Resulting from what became known as the Florentine Camerata, a shift from the current complex polyphonic systems which they thought implied strangeness and abnormality...

    Maybe it's time for a new Camerata?

    Regards
    Rolf Tollerud
  44. Define the term "polyphonic" as you have used it in this context. For extra credit, discuss Vincenzo Galilei's views on just intonation.
  45. Strange question..[ Go to top ]

    Frank,

    <Define the term "polyphonic">
    In this context:
    a confusion of polyphony, excesive and artless use of counterpoint

    The late 1590..
    music had fallen (after Palestrina and Orlando di Lasso)..
    into the hands of theorists..
    with a intellectualist approach to music...

    Bardi and Corsi...
    great connoisseurs of music..
    decided to see what could be done to ensure not only that the music does not prevent one from catching the words, but more, that it helps bring out more clearly their meaning and their representative intent..

    they became convinced they had found the way to bring it off -and they were not mistaken..

    Is there anything unclear?

    Regards
    Rolf Tollerud
  46. When to EJB[ Go to top ]

    |
    | EJB is fastest way to make your client go to .NET
    |

    How would you adress remoting without EJB?

    -Nick
  47. When to EJB[ Go to top ]

    Nick,

    "How would you adress remoting without EJB?"

    - RMI/JRMP;
    - RMI/IIOP;
    - XML/RPC through SOAP;
    - COM;
    - JMS;
    - CORBA;
    - Object serialisation through sockets;
    - FTP;
    - Mail;
    - Basically using any server protocol;

    I'm not saying that you should use these, but CORBA is a very efficient way of tackling remote method calls. It is specified, transactional and secure.

                   Yann
  48. When to EJB[ Go to top ]

    Thanks Yann. I wasnt really after a catalogue of all networking protocols ;-) I am aware of them.

    My point was that EJB Session beans solve remoting very nicely indeed - in a very SIMPLE way. They provide declarative security, declarative transaction demarcation, a single-threaded programming model, clustering and, above all, I dont have to write a server.

    ALL the other options (with the exception of SOAP) (especially CORBA) involve (amongst other things) the writing of a server. When you write a server for a non-trivial application you have to:
    1) Write documenation on how to manage it in production (start/stop it)
    2) Management utilities to inspect its health/status
    3) Configuration utilities to configure it.
    4) Modify it when you add new services
    5) Deal with threading issues
    6) Manage redundancy and fail-over
    7) Maintain all of the above infrastructure code.

    Writing your own server is a distinct waste of time - one that many underestimate.

    EJB Session beans are the right fit for many Java remoting situations.

    -Nick
  49. Nick, huh?[ Go to top ]

    "They provide declarative security,"

    Very few people need this, or use it. It is complex, and overtly general. Custom code is far more usefull maintainable and clearer.


     "declarative transaction demarcation,"

    The same as the above. Very few times does a transaction really span method calls, client transactions are generally a bad idea, starting and stoping your own transaction on the server is really like 10 lines.

     "a single-threaded programming model"

    Fair enough, but most services exposed by ejb session beans are already inheriently stateless. Don't forget that any method call you make to a third party libarary or your own applciation code outside of the ejb will still need to be thread safe. This feature saves you very little, and if you have trouble writing a stateless method then you really need another job.

    "clustering "

    There is nothing in the ejb spec about clustring. Many servers offer clusting for other protocols including rmi and http.

    "Writing your own server is a distinct waste of time - one that many underestimate. "

    What, you can't find an implementation or java integration with ALL of Yann's recommendations? Every task you wrote down will STILL need to be done for ANY ejb dep/loyment.

    If you think you can ignore threading,configuration,fail-over,maintienece utilities with an ejb deployment then you are wrong. And guess what, NONE of that is specified by the standard. Many vendors offer management and utilities for the products they sell if it does not have the feature you want choose another. EJB is not even a protocol! it is a layer of needless fat.


    "EJB Session beans are the right fit for many Java remoting situations. "

    They offer little over the simplicity of rmi. It shocks me why anybody would deal with the packaging nightmare that a j2ee appilication is, rather then just run rmic. If you really do use declarative security and transactions then fine, but that is really a VERY small percentage of deployments.
  50. Dont huh me! ;-)[ Go to top ]

    Very few people need this

    Except those who have concerns about security.

    >> It is complex
    I dont think :

    <method-permission>
        <role-name>TicketUsers</role-name>
        <role-name>administrators</role-name>
        <method>
    <ejb-name>BondSearchBean</ejb-name>
    <method-name>*</method-name>
        </method>
    </method-permission>

    is particularly complex.

    >> Custom code is far more usefull maintainable and clearer.
    How is this so?
    Custom code that is in no way related to the business domain is far more usefull??

    >> Very few times does a transaction really span method calls
    What has transactions spanning client method calls got to do with declarative demarcation?

    >> starting and stoping your own transaction on the server is
    >> really like 10 lines.
    Jolly good. 10 methods = 100 lines of non business logic code.

    >> Fair enough, but most services exposed by ejb session beans
    >> are already inheriently stateless
    What has statelessness got to do with thread safety?
    Where did the stateless object come from in the first place!

    >> There is nothing in the ejb spec about clustring
    Well spotted. And can you point me to an EJB container that *doesnt* support seamless clusterering (ie, no code required)?

    >> Every task you wrote down will STILL need to be done for
    >> ANY ejb dep/loyment

    Really?

    1) Here is how I dont write documentation for managing server : http://e-docs.bea.com/wls/docs70/admin.html

    2) Here are the management utilities I dont have to write : http://e-docs.bea.com/wls/docs70/ConsoleHelp/index.html

    3) Here is the configuration management that I didnt have to write : http://e-docs.bea.com/wls/docs70/config_xml/index.html

    4) Here is the server src code I have to modify in order to deploy a new service : SweetFA.java

    6) Here is the clustering I dont have to implement : http://e-docs.bea.com/wls/docs70/cluster/index.html

    5) Threading:
    Anonym, I dont know what sort of applications you have been involved in building - but I can tell you that I have worked on systems that have been in production for years - and still suffer from threading problems that no-one can get to the bottom of.
    On the other hand, I have been involved in EJB applications where the first time its ever load tested, it doesnt hang, it doesnt corrupt data, and it doesnt crash. Do you think this is pure luck?

    >> They offer little over the simplicity of rmi
    Except that with RMI you have to write most of the above...

    Regards,
    Nick
  51. Dont huh me! ;-)[ Go to top ]

    I dont think :

    >is particularly complex.

    You seem to have left out a geat deal, such as role decleration principal and authoriztion.


    >What has transactions spanning client method calls got to do with declarative demarcation?

    Very little, lets for the sake of our example assume a new transaction is started for each method call.

    >Jolly good. 10 methods = 100 lines of non business logic code.

    Do you automaticly assume we will cut and paste? what kind of developer are you? There are many ways to include thoese ten lines through method calls, preprocessors and macros, and even dynamix proxies.

    >What has statelessness got to do with thread safety?
    Any mutable object must consider how it will remain consistent. If an object is immutable then it can never be inconsisten, there is no need to consider the effects of concurrent access.

    >can you point me to an EJB container that *doesnt* support seamless clusterering (ie, no code required)?

    ATG Dynamo 5.1

    >ANY ejb dep/loyment
    >Really?
    As I said before ALL of these services have NOTHING to do with EJB and are available in many other products. Why don't you instead of promoting the use of ejb's start promoting bea. There is nothing wrong with promoting bea, but don't get bea and ejbs confused. If you like the product use and tell everyone how great it is, but don't think any of this has anything to do with how great ejbs are.


    >in production for years - and still suffer from threading problems that no-one can get to the bottom of

    No surprise here, our industry is full of idiots.

    >On the other hand, I have been involved in EJB applications where the first time its ever load tested, it doesnt hang
    Glad to hear it, but yes you are lucky. One still has to worry about multi threaded code if two ejbs call the same object. Any method call you make to another object might be executing concurrenly with other threads if they have access to that object. Not understanding this, and coding for it will lead to trouble. The pooled single threaded nature of ejbs are really not all that usefull.
  52. Interface based libraries[ Go to top ]

    Most of the enterprise APIs are interface based. A lot of things are interfaces just because multiple companies would be implementing the API. So there is tons of factory code to go through when it is unecessary. Make something an interface just in the case it would be an interface if one company was implementing an API. That would simplify it. Or at least reduce line count by 99%.
  53. Interface based libraries[ Go to top ]

    "Most of the enterprise APIs are interface based."

    One could hope this were true. Far too few are.


    "A lot of things are interfaces just because multiple companies would be implementing the API."

    If true, it doesn't sound like a good reason. At least not the best. Unless we are talking about specifications.


    "So there is tons of factory code to go through when it is unecessary."

    It is? Can you see the future? I can't tell you many times I've seen it very necessary and unfortunately it wasn't done because the original developers thought it wasn't necessary. It wasn't at the time.
  54. Interface based libraries[ Go to top ]

    I'm not saying i think we should throw away interfaces. But some of the enterprise specs specify an interface when they could just as well (it seems to me) specify a class. For example, the JAXP spec has parser factories wich look at property files to find the name of the class to use. The different parser distributions include these files in an effort to be compliant with the api. Why don't they specify a Parser class and say just implement a class with this name. Then depending on which distribution i have, i would use thier Parser class (with the same name) and be able to write new Parser().
  55. Dont huh me! ;-)[ Go to top ]

    Anonym twice,

    "No surprise here, our industry is full of idiots."

    Given that it's a known fact that any industry has its share of competence-challenged people, writing standalone RMI applications is therefore not recommended because RMI is too low-level and IMO too error-prone. EJBs are one layer of abstraction above and though they are still complex, they are less error-prone. Above all, one of their main objectives is to separate applications into reusable components in a formalised and standard way (though components inheritance is not easily achieved). This is good IMO because:

    - Standards federate skills: standards create communities of people and skills, which results in a higher technology transfer. Good standards build momentum, flaky ones just melt away. According to that principle, J2EE is probably a good standard (with its set of imperfections). Similarly, RMI alone is not such a good standard: it's a low-level commodity. And even if I have no doubt you can write good applications with it, I have doubts the majority of developers can write good software with it.
    - It tackles transactions, multi-threading, security, state management, persistence in an elegant way - but yes XML DDs are a PITA, especially on TextPad :). And soon web services. Programming transactions is not exactly a challenge, being able to configure components to put them in or out or transactional contexts is nice and easy. Security is not that hard either. Multi-threading and persistence are other issues. Writing EJBs does not prevent you from writing some thread-safe code, but it removes big chunks of it. Persistence through the entity bean model is debatable though :) Again, its widespread use or rejection from the community will tell whether it is the best approach. I tend to think JDO suits better. In the meantime, my own choice is to use JDBC. State management through SFSB is also arguable.
    - This model even though it does not specify it, promotes availability, failover, scalability, manageability, reusability, interoperability, and other *ility terms. And performance (despite what many people say). Of course, a bad understanding of the technology is likely to defeat those purposes. The model is quite complex and covers many areas, but when you're through with it, it delivers. Clustering ability is more and more widespread and easy to configure. JMX standard (mandatory in J2EE 1.4) is a nice step forwards in terms of manageability, profiling and monitoring. Pooling and caching comes out of the box, and even if you don't seem to be too keen on it, it can make life easier.
    - Applications are more and more built as sets of reusable business processes. If J2EE is the next legacy system, integration with it will be a breeze. RMI alone can also provide this sort of integrability.

    You should not assume people who participate to successful J2EE projects are lucky. As I said, just like with any other technology, you can do good and bad things. Successful J2EE projects require that architects and designers know very well the J2EE model, the application server's capabilities, and in addition have strong skills in other areas such as communication, team leading, design patterns. Building applications with maintainability and performance in mind is definitely complex. Frankly, if you know RMI inside-out, you can build successful applications. I remember on another thread here around 2 years ago someone bashing the hell out of the EJB model to promote JINI. JINI certainly has an ability to deliver successful projects yet the community has chosen EJBs or parts of it from J2EE.

    J2EE is not perfect. Knowing J2EE reasonably well implies that you know its strengths and weaknesses, when to use it and when not to. Using all J2EE for the sake of it is plain stupid. EJBs suffer a mitigated reputation because most people (and me too when I started) have used it without understanding it well. However, less and less people use entity beans for reading or SFSBs for maintaining state. More and more people cache JNDI lookups and pool resources. So it slowly gets better. Friends of mine who were good C programmers told me that it takes 5 years to become an expert. J2EE is hardly five years old. Its mature 1.3 version is only 1.5 year old. What can you expect ? But one thing is certain, the hype phase of J2EE is history now.

                     Yann
  56. Dont huh me! ;-)[ Go to top ]

    | our industry is full of idiots

    Yep.

    | You seem to have left out a geat deal

    As have you.
    "preprocessors and macros, and even dynamix proxies". Sounds really simple.

    | ATG Dynamo 5.1

    A *recent* version of an appserver perhaps?

    | don't get bea and ejbs confused

    Dont start a discussion assuming your counterpart is an idiot.

    | The pooled single threaded nature of ejbs are really not
    | all that useful

    If you think that doing your own explicit thread management is productive, then excellent. Certainly not the case for 95% of the server side systems I have seen.

    -Nick
  57. RE: Yann & when to EJB[ Go to top ]

    Yann wrote:

    >- RMI/JRMP;
    >- RMI/IIOP;
    >- XML/RPC through SOAP;
    >- COM;
    >- JMS;
    >- CORBA;
    >- Object serialisation through sockets;
    >- FTP;
    >- Mail;
    >- Basically using any server protocol;

    >I'm not saying that you should use these, but CORBA is a >very efficient way of tackling remote method calls. It is >specified, transactional and secure.

    Lets see with a single EJB you can export your service to
    RMI, SOAP(1.4), CORBA, JMS, and with JCA in 1.4 nearly anyother protocal.

    I think you just made a clear case when to use EJBs.
    When your component may have a wide veriety of different clients accessing it. For example replacing a legacy backend system to one that can serve existing clients and provide interfaces to new ones.

    weo
  58. RE: Yann & when to EJB[ Go to top ]

    Mauricio,

    "Lets see with a single EJB you can export your service to
    RMI, SOAP(1.4), CORBA, JMS, and with JCA in 1.4 nearly anyother protocal.

    I think you just made a clear case when to use EJBs.
    When your component may have a wide veriety of different clients accessing it. For example replacing a legacy backend system to one that can serve existing clients and provide interfaces to new ones."

    The EJBs only offer up to 4 external interfaces until J2EE 1.4:

    - RMI/IIOP (synchronous);
    - XML-RPC through SOAP 1.1 over HTTP (synchronous since J2EE 1.4);
    - RPC through JMS-compliant messaging systems (asynchronous);
    - A proprietary protocol like t3 or ormi (synchronous).

    This in many cases more than enough for them to be used as an out-of-the-box server interface that services business processes for integration purposes. The other technologies, like JCA, are only internal to the server in that they can't be used to call a remote method on an EJB.

                    Yann
  59. RE: Yann & when to EJB[ Go to top ]

    |
    | The other technologies, like JCA, are only internal to the
    | server in that they can't be used to call a remote method
    | on an EJB
    |

    The new J2EECA spec does allow you to call into an EJB Container.

    -Nick
  60. RE: Yann & when to EJB[ Go to top ]

    Nick,

    I agree that JCA can be used to call into an EJB container, just like any other Java object. My point is that JCA is not a communication protocol in that case, but only a proxy that uses one of the 4 protocols described before (it's actually JMS/MDB used in a synchronous fashion).

                    Yann
  61. RE: Yann & when to EJB[ Go to top ]

    Ya, OK, I agree with you (I think).

    I just hold a different view on what we care about when it comes to EJB clients.
    I am not sure that the protocol is really the bit we need to be interested in. In the end, what we are interested in is the API - or as you put it "the interface". (this is getting a bit off-topic). Its what work we have to do write to it.

    For example, we dont really give a damn that we use t3 as the underlying implementation of RMI - we just write clients to the RMI API (with just 1 exception in iiop to do with narrowing).

    With particular reference to JCA, its my understanding (but I havent looked nearly enough at the latest incarnation of JCA1.5 to understand it fully) that the connector can use any protocol it likes to call into the container - and it will be the MDB that will turn it into an RMI/java call. It doesnt have to be 1 of the 4 above...

    -Nick
  62. RE: Yann & when to EJB[ Go to top ]

    Nick,

    "I just hold a different view on what we care about when it comes to EJB clients. I am not sure that the protocol is really the bit we need to be interested in."

    Our views are not different. It's just that I was splitting hair about the direct communication means to EJBs. Now in reality, noone really cares about that and using a proxy object, you can invoke an EJB using any protocol you like. Having said that, the new MDB specification actually allows any messaging system to provide messages and not JMS only through the JCA 1.5, which means that you are right and I was wrong in my previous post. You can use any protocol you like and use it through your MDB's message listener method.

                    Yann
  63. When to EJB[ Go to top ]

    EJB is FUBAR. J2EE.jar for 1.4 includes Castor.


    And Java XML Pack includes dom4j.
  64. Comment on your Comments on your chapter...[ Go to top ]

    "The second explains what I mean: in this scenario we don't want business objects held on every machine running the Swing client. This would be a 2-tier approach. For example, one db connection per standalone client won't scale."

    Depends on how you define "business objects". And how you write your business objects. Do business objects contain the business rules? What are business rules? I would say you can (and should) have business objects (or at least part of them) "running" on the Swing client. And this can be done without having one db connection per machine. Of course, if properly architected, this technique could be used without the user ever knowing it (not including problems that come up by having the db client installed on every machine). We are doing it without having db clients installed locally.
  65. Comments on your chapter...[ Go to top ]

    I forgot to say: the title of the chapter is "J2EE Architectures" and it covers questions such as whether to use a distributed architecture and whether to use EJB. (Of course these issues are discussed in greater detail later in the book). It also presents 4 alternative architectures which cover the needs of typical applications. These architectures range from the J2WE style Nick suggested here to a distributed EJB architecture. I absolutely agree with Nick about "right-sizing" an application: this is crucial to the success of a project.

    Rod
  66. Comments on your chapter...[ Go to top ]

    |
    | I absolutely agree with Nick about "right-sizing" an
    | application: this is crucial to the success of a project.
    |

    I think most people would agree. I really think, however, that the Java Standards should reflect this right-sizing approach by having more than one level of J2EE.

    -Nick
  67. What is there to simplify?[ Go to top ]

    I agree with you on a number of levels. However, since I work at a university, a lot of students ask me what is important or even difficult in learning java.

    My answer is that, while learning the language is relatively easy, learning all the API's takes time. Now, for me, the key words are _takes time_. I don't feel it's all that _hard_ to learn the API's, but there is a TON of stuff out there, both in specifications and in third party stuff. It takes quite some time not just to know how to do things, but to know, choose, and use your options effectively.

    Take persistence. I've worked now with JDO, EJB, Object Mapping tools, and ODMG stuff. It takes some time just to use one well. Or take MVC. I learned to do MVC a little before the wave of third party MVC dev environments. Now I feel overwhelmed just trying to keep up. Struts, Webwork, Velocity and more and more. I want to keep up with these things because it's fun, and it can be important in my job. But none of us really has the time. In business, do you use a slightly lesser framework because of the learning curve (and developers _are_ costly), or do you take the time to switch? It's a situational decision, but it can be a critical one.

    For new people coming in, do you learn how to do an MVC and how it really works? or do you skip that and go directly to struts or velocity? Do you read the EJB spec, or skip it? If you do skip it, are you missing something? What happens when you have to learn another one...the learning curve all over.

    The API's are large, incredibly diverse, and getting bigger every day. Don't get me wrong, I LOVE the choices that I have. I came to Java/J2EE from developing MS stuff. It's a double edged sword. With MS, you get one choice, and a short learning curve. With Java, you get all the choices, but you need the time to be aware of the choices.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  68. What is there to simplify?[ Go to top ]

    |
    | Do you read the EJB spec, or skip it?
    |

    I think that in all cases, the J2EE specs are advanced reading. For me at least, only read the specs when you already have an understanding.

    To gain that understanding I have always been lazy - I leverage the understanding that others have. I talk to them or I read their books, or I read their Web articles. I have personally found O'Reilly books to be the best at gaining that initial understanding of a technology - but thats just me.

    |
    | But none of us really has the time.
    |

    I dont believe thats a good excuse either. Everyone has the time to learn, if they want to make it available. In train travel time alone (1hr each way) I have found time to read countless numbers of books and printed web articles and PDF's. But, in addition, I also discuss stuff with colleagues to get an alternative point of view and therefore a better understanding. It certainly wont fall on your lap.

    When I interview people, the first thing I do is ask them questions that are off-topic with respect to the interview - just to see if they actually take an active interest in their work, or are they just 9-5'ers.

    -Nick
  69. What is there to simplify?[ Go to top ]

    Nick,

    I wasn't really referring to the personal issue of learning. I agree, with you there. Gotta keep up.

    However, I meant it in a more institutional sense. Some times there a limitations on this sort of thing that managers and lead developers have to make. Having the latest and greatest is often not in the best interests of a firm.

    Say you have a team of 20 developers who are comfortable with Struts. Maybe you know that Your AWesome New Framework (YAWN-F) is better. But struts will fit the bill more than well enough, and you'll save a ton of money sticking with it. Sometimes it's a good management decision to go with struts, and sometimes it's a better decision to go with YAWN-F, if it'll help the institution.

    The goal here is not for us to get better as developers (although it is a "sub" goal). It's to do a good job developing and protecting the information architecture of our companies. Our first responsibility is to the people who pay us, our second is to ourselves.

    As for "but none of really has the time," I'll bet since I'm in research, I spend more time researching the stuff out there than most of the people in this forum. It may sound like an excuse to you, but you must be a far better learner than any developer I've met.

    I'm pulling your chain a little, but noone I've met can keep up with it all, and that was really my point.

    On top of that, reading a book or talking doesn't always cut it. You gotta really do a lot of these things for them to sink in. I can read all kinds of books and talk to people about flying an airplane, but noone's gonna let me.

    -Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  70. J2 Web Edition[ Go to top ]

    "I propose a J2WE (Web Edition) consisting of JSP/Servlet/JDBC/(Webwork/Struts)." -- Nick

    A better combination would be Java Server Faces and JDBC.
  71. What is there to simplify?[ Go to top ]

    Define Enterprise. This term gets used without much definition by many people and of course, the vendors. J2EE complex? Of course, thanks to the battles between competing vendors. Many of you are just chasing technology that is constantly changing because of Sun and Microsoft. Proprietary JAVA products of the mid to late 90s did much more with less complexity. I'm talking about server side Java products which would guide you through the entire application development process. From data source, to data objects, to web content mappings, and dare I say, even page flow security. A transaction web page that was built with all the necessary database plumbing. But no, that was too easy for the vendors and for many developers that just couldn't accept framework wizard tools. Oh no, "WIZARD" tools! What kind of inefficient code will the product produce? So instead, many developers favor to build everything from scratch. Thereby, keeping developers from focusing on areas that truely require custom coding. Even worse, work with Web development platforms requiring separate skill disciplines. Therefore, when an error occurs one would have to talk to several developers instead of any developer that can follow everything from the database to the web page content. I bet many of today's unemployed GUI developers wish they would have learned more about databases/programming/business logic during their development. Just look at what has happened over the years to Sun. Sun purchased several JAVA and application server products. Basically trashed some of them, continues to restructure their development products, and has taken them forever to come out with a so called ENTERPRISE development tool. It's amazing to see where prices started. 35K/CPU, then 19K/CPU, 10K/CPU, free editions with the OS, and now even WEBLOGIC included with the Solaris OS. Instead, why not demand to see some real technology comparisons. Like between Sun, IBM, BEA, Microsoft, Macromedia, and Apple WebObjects. How do these products compare in the real world. Instead, the entire IT industry focus is on what the rivals keep fighting over, J2EE versus .NET. Oh, but of course, it's now about WEB SERVICES. Sorry, but there are better things to do than to keep rewritting applications. So, you want to know what is there to simplify? Check this out: How about a tool that you can develop and compile on WIN98, WIN NT, or Win 2K. Then take the compiled version and simply FTP it onto a Solaris server. That's it, it's ready to run. All server side JAVA. Everyone of our developers have experience from the database schema to the web page content. Database inserts, updates, deletes and browsing. If a problem comes up I can ask any developer. I don't need a conference meeting with a bunch of developers pointing fingers at each other.
  72. Sun to Simplify Java[ Go to top ]

    This might also be of interest to language wonks regarding changes coming up for C#:

    Here's the whitepaper in HTML: The C# Programming Language: Future Features

    Of specific interest may be the comments comparing proposed C# and Java "generics" implementation.

    Here's the whitepaper's parent page with links to Anders Hejlsberg's original presentation at OOPSLA last November and an FAQ:
    New C# Language Features

    I apologize ahead of time if this comes across as trolling--it is not intended to be such. Please ignore if you feel this doesn't belong here.
  73. It's relevant[ Go to top ]

    Robert, your links are indeed relevant. IMO, having used both Java and C# for some time, I think the Java community has quite a few things to learn from C# and even .NET.

    Whatever you think of Microsoft, the CLI initiative is simply great. Ignoring .NET and CLI will be a huge mistake, especially now that several open source projects is gaining momentum - including porting the entire .NET thing to Linux/UNIX/whatnot (mono, DotGnu, etc)

    Whether you like it or not, .NET is going to get HUGE when ported entirely (which will be soon), because it'll be a productive, multi-platform, multi-language infrastructure (last time I checked, obscure/lesser known languages like Haskell, COBOL and Eiffel were supported)
  74. ?!?[ Go to top ]

    "obscure/lesser known languages.....COBOL...."

    Those two things don't belong in the same sentence. I don't know if it's true anymore, but as of 4 years ago, the number 1 language in terms of lines of new code written was COBOL, outdistancing all other languages combined. Never underestimate the importance/prevalence of so-called "legacy" code.
  75. ?!?[ Go to top ]

    Yes, but that's because to write 'Hello world' in COBOL you need to type two pages of stuff :) (I had to write something in COBOL in late 80s)
    Regards,
    Vlad
  76. COBOL[ Go to top ]

    Maybe because there was a lot of COBOL code being re-written four years ago due to the Y2K frenzy. Besides, LOC is always a deceiving metric.

    Ryan
  77. Robert,

    Thanks for the link to Anders Hejlsberg's C# presentation at OOPSLA 2002.

    Given what is coming up in the forthcoming CSharp feature set, now is the time (for me) to "convert" from C++/Java to C#.

    Folks, will Java ever support "generics"?

    Regards,
    /Ravi
  78. Ravi,

    What is a "generic"?
  79. As heard will be expecting "Generics" in Java 1.5.
    But you can write your own small set of API's and later transition to Java standard.
  80. Java and BPEL[ Go to top ]

    This sounds very promising for allowing Java to address such requirements as better handling of XML, interacting with asynchronous (Web) services and in general enabling developers to work at higher, more productive, abstraction layers, while still leveraging their Java/J2EE skills.

    I believe that vendors will jump at the opportunities opened by this approach, for example Business Flows with BPEL (aka jBPEL)

    Cheers.

    Jill.
  81. Not for Salespeople[ Go to top ]

    Jill,

    Please leave your sales pitches at the door.
  82. Java and BPEL[ Go to top ]

    Hardly a sales pitch. And your response to my viewpoint is? I assume you have one...

    Cheers.

    Jill.
  83. Java and BPEL[ Go to top ]

    My point is that every time I read one of your posts, it includes a link to some company that you appear to be promoting.
  84. Java and BPEL[ Go to top ]

    How is your point relevant to the subject matter? I'm sure you have some intelligent response to what I was talking about or is that wishful thinking?

    Cheers.

    Jill.
  85. Sun to Simplify Java[ Go to top ]

    Briefly, here are some of my ideas. First and foremost, its time to admit that the enterprise component market never took off and refactor EJB into a biz and persistence logic framework, not a component framework. This could manifest as:
     
     - incorporate jsr 175 (metadata) and eliminate deployment descriptors
     - refactor entity beans into a JDO-like transparent persistence mechanism
     - incorporate new language features from JSR 201 such as autoboxing, generics, to simplify the API's. If you havn't checked it out yet, take a look at them
     
    I really like what I am hearing about jboss 4 giving you the services that EJB provides to plain java objects.

    Floyd
  86. Sun to Simplify Java[ Go to top ]

    Floyd,

    Could you please give a word of explanantion on what Jboss 4 will provide?

    Thanks
    -Vincent.
  87. The way forward?[ Go to top ]

    Floyd,

    I agree absolutely. Replacing DDs with metadata could be combined with a move to an AOP approach.

    However, I rate the chances of Sun doing any of this as about the same as George, Tony and Saddam forming a boy band. Unfortunately Sun and the app server vendors have too much riding on the takeup of the existing specs.

    The question is whether any of this will happen through open source projects and the like.

    Regards,
    Rod
  88. Open letter to SUN[ Go to top ]

    We greatly appreciate SUN's contribution and commitment to Java but I think we should opensource Java for further acceptance and future of java.