Simpler Java - Combatting the complexity of J2EE

Discussions

News: Simpler Java - Combatting the complexity of J2EE

  1. Simpler Java - Combatting the complexity of J2EE (124 messages)

    J2EE, EJB, and XML are complex technologies, and although there's a tradeoff between simplicity and power, people are moving away from monolithic frameworks back toward cleaner, simpler ones. In this article, Bruce Tate examines the basic principles behind a few simple yet successful frameworks and looks at how vendors are creating smarter tools to insulate developers from the complexity of J2EE.

    Read Simpler Java

    J2EE complexity debated in the community

    At a recent symposium, Dave Thomas challenged people to write "Hello World" on his Mac, using JBoss. Now, many people say "If you are using a full J2EE stack for Hello World, then you are a fool, but others are delving deeper into the issue.

    Mike Clark in Hello Cruel World discusses the original challenge from Dave.

    Glenn Vanderburg in Wrong Turn takes a comparitive look at J2EE versus other alternatives.

    Erik Hatcher in J2MU thinks that the question needs to be unasked.

    Threaded Messages (124)

  2. Lots of JDO implementations[ Go to top ]

    There are a lot more than just 2 JDO implementations on the market. Here is a list from JDO Central:

    JDO Central - JDO implementations

    There are open source ones at the end of that page.

    Cheers David
    JDO Genie - High Performance JDO for JDBC
  3. Well the article was a little bias towards persistence but the point is quite valid. There seem to be a lot of people using technology for technology's sake. They'll quite happily start with a J2EE server before looking at the problem, perhaps it’s a resume thing?

    Many of applications will work far better on a simple Servlet/JSP/Struts engine with sprinkles of other goodies like JavaMail, JMS, JAAS, JNDI, JDO and JavaSpaces etc.

    True, you quickly fall into the security issues, authentication, authorisation, deployment, packaging, XA transactions, external interfaces etc. but the more of these you use the more complex it gets, it's a vicious circle. Personally I don't think the switch over point for "we need the full J2EE server" is as soon as it needs to be.

    My £5s worth,

    -John-
    C24.biz
  4. <quote>Many of applications will work far better on a simple Servlet/JSP/Struts engine with sprinkles of other goodies like JMS</quote>

    Tell me how you use JMS and deploy a Message Driven Bean without a J2EE Application Server?
  5. <quote>Many of applications will work far better on a simple Servlet/JSP/Struts engine with sprinkles of other goodies like JMS</quote>

    >
    > Tell me how you use JMS and deploy a Message Driven Bean without a J2EE Application Server?

    What's your point?
  6. My point is. If you're going to use JMS you need an Application Server. So your not going to just use a "Servlet/JSP/Struts engine".
  7. My point is. If you're going to use JMS you need an Application Server. So your not going to just use a "Servlet/JSP/Struts engine".


    It works for me without app server and I have no problems. Just try it before to buy a new big server for all of use cases.
  8. It works for me without app server and I have no problems. Just try it before to buy a new big server for all of use cases.


    Tell me how you can implement JMS and deploy a MDB without a J2EE 2.0 Compliant Application Server? I've obviously missed something!
  9. JMS etc[ Go to top ]

    The original only mentioned JMS - nothing about MDB's..
  10. It works for me without app server and I have no problems. Just try it before to buy a new big server for all of use cases.

    >
    > Tell me how you can implement JMS and deploy a MDB without a J2EE 2.0 Compliant Application Server? I've obviously missed something!

    It is useless, but you can implement EJB interfaces in your listener too.
    I use simple homemade framework on to of plain JMS API.
  11. Tell me how you can implement JMS and deploy a MDB without a J2EE 2.0 Compliant Application Server? I've obviously missed something!


    Just drop the MDBs and you'll find everything works much faster and simpler.

    I use EJBs every day in wholesale banking, I wrote the JMS/MDB chapter in Wrox's Pro Java Server 1.3 book and was the technical editor of Learning Tree's EJB course so I [should] know what I'm talking about (another debate). I can give you many uses for Entity, Session and MDBs but too many people just use them for the sake of it, it's like driving a bus to the corner shop, overkill in most cases but buses please an important part in our world, as do EJBs and J2EE App servers.

    -John-
  12. It works for me without app server and I have no problems. Just try it before to buy a new big server for all of use cases.

    >
    > Tell me how you can implement JMS and deploy a MDB without a J2EE 2.0 Compliant Application Server? I've obviously missed something!

    JMS != MDB
  13. I wouldn't use MDB in the first place. The J2EE 1.3 spec for MDBs is a complete balls up and provides virtually nothing unless you're stuck with an EJB server and have to integrate a JMS, even then it's poor. J2EE 1.4 does a lot more but what the hell do I want a MDB for if I don't have an EJB server? It's the EJB server that is the sledge hammer in this scenario. I can get transactions and better security without and better still I can have dynamic queues and topics which is imposible in J2EE 1.3 since you have to bind the name into the DD.

    Next question please...

    -John-
  14. endless cycle[ Go to top ]

    1. Start with X
    2. People notice X can be abstracted and made more powerful which
       gives us Y and Z.
    3. People notice Y and Z never quite fit so we make A and B.
    4. People are disatisfied with the whole bit and start over at C.
    5. Goto 1.

    If we ever make any actual progress is unclear.
  15. Most of the time J2EE is unnecessary[ Go to top ]

    J2EE defines an application server framework. It's an architechture where multiple web applications can live together, share some resources use the same database through common connection point, query about different services.

    What's wrong with that?

    Most of us don't need an application server. Most of us are in a situation where dedicated server is better (and sometimes the only) option. I too bought the J2EE hype and built a server on top of JBoss. It was only later than I came to question the need for an application server..

    JNDI - what do I need that for? There's nothing to be found, the server is always in the same address (or if that changes, the clients simply type different address to connection dialog box)

    ENTITY BEANS - I was using entity beans to cache my objects. They are much more effectively cached by simple homemade object pool. (Ringbuffer).

    SESSION BEAN - replaced by service threads. we need to support maximum of few hundred (rather thick) clients. There's no problem of having 200 threads doing simple service tasks. The overhead is practically non existent. If we need to support thousands of clients in the future I can either implement thread pools or switch to NIO and non blocking sockets. But since the application needs to talk through firewalls it's much easier to persist connections as long as the client is logged in.

    RMI - too complex and requires RemoteException on each method call. Homemade protocol and serialized objects is much more easier and more lightweight. Just read/write objects from/to sockets. (The homemade protocol < 100 lines of code.. using the RMI requires more extra lines in itself than that. And I can throw RuntimeExceptions instead of Checked exceptions from remoted methods)

    DB CONNECTION POOLING - There are lots of libraries for this and it's not hard to write your own.

    TRANSACTION MANAGEMENT - Use proxy classes (interceptors) to access your DAO objects. It's very easy to implement tx management in interceptors, not harder than defining it in various XML files.. IMHO..

    INTEGRATED WEB - embedding LWS took ~10 lines of code. Again easier than configuring the web stuff through some obscure XML mess.

    What did I lose?

    Hotswap: this is a minor issue since the JBoss took some 20 seconds to load whereas the homemade server starts in few seconds. The current cache state is persisted upon shutdown so the next startup is almost like the hotswap. Clients can be notified about the shutdown and they can automagically try to connect after certain time period.

    Distributed transactions: Not needed in our case. (besides there are JDBC drivers that can implement this transparently)

    XML configuration files =)

    The gains?

    Smaller memory footprint, faster startup time, easier configuration (good old ini file), faster & easier wire protocol, less code.

    I bet there are lot of companies that deploy their application on a J2EE server when there's really no need for that. I suspect that e.g. Avalon framework would have been equally good choice but the bottom line is that the server infrastructure code is less than 5% of the whole application business/object persistence logic.

    P.S.
    sorry for my english..

    P.S.II
    Although the main use is through swing clients, we also need to have a web frontend. Struts proved to be too complex and too fragile when used together with tiles and velocity. Any suggestions for simpler and more effective framework? Maybe Tapestry? Lightweight is the key since everything needs to be dynamic (totally user dependant views to underlying data)
  16. Most of the time J2EE is unnecessary[ Go to top ]

    For a Java programmer friendly and expressive web GUI api try the echo framework:
    http://sourceforge.net/projects/echo/

    If you like working with widgets and oo api (tired of JSPs and XML tags) then try echo.


    >P.S.II
    >Although the main use is through swing clients, we also need to have a web frontend. Struts proved to be too complex and too fragile when used together with tiles and velocity. Any suggestions for simpler and more effective framework? Maybe Tapestry? Lightweight is the key since everything needs to be dynamic (totally user dependant views to underlying data)
  17. Most of the time J2EE is unnecessary[ Go to top ]

    If you like working with widgets and oo api (tired of JSPs and XML tags) then try echo.


    Echo seems pretty nice, I've test tried their examples and the API seems really nice. But... We already have a client and writing the other with echo seems like doubling the work that is already done.

    The purpose of web frontend for us is to provide a JRE free solution to do some simple custom tasks and browse the 'database'. I think Echo offers more than that and the problem is that there are restrictions I'd rather not see.

    Downsides:
    - Echo forces you to have Javascript on browser
    - Disables back button (the users are really used to that!)
  18. Here's one[ Go to top ]

    Although the main use is through swing clients, we also need to have a web >>frontend. Struts proved to be too complex and too fragile when used together >>with tiles and velocity. Any suggestions for simpler and more effective >>framework? Maybe Tapestry? Lightweight is the key since everything needs to >>be dynamic (totally user dependant views to underlying data)


    Try SOFIA. Its free, open source, easy to get started and to learn, but powerful enough to handle most any enterprise application. It uses the simpler parts of the J2EE like servlets and JSP, but doesn't require the heavy parts like EJBs so all you need is a web container like Tomcat for deployment. It's a tool that does for J2EE web applications what Powerbuilder did for client/server. It also can help you out with database driven Swing applets and Web Start applications.

    http://www.salmonllc.com/sofia.
  19. Here's one[ Go to top ]

    Try SOFIA. Its free, open source, easy to get started and to learn, but powerful enough to handle most any enterprise application. It uses the simpler parts of the J2EE like servlets and JSP, but doesn't require the heavy parts like EJBs so all you need is a web container like Tomcat for deployment. It's a tool that does for J2EE web applications what Powerbuilder did for client/server. It also can help you out with database driven Swing applets and Web Start applications.

    >
    > http://www.salmonllc.com/sofia.

    Thx! We'll add that to the list of 'to be evaluated' frameworks.
  20. Here's one - Tapestry[ Go to top ]

    Try Tapestry! Its a component oriented framework that keeps the page design in HTML (nice to work with layouts in a WYSIWYG fashion even after it is deployed!), the dynamic parts of the page in XML and the data/logic in Java. And its component nature let's you create a component once and just drop it into any page. Check out the Palette component to get an idea.
  21. Most of the time J2EE is unnecessary[ Go to top ]

    The point about xml config files is well-taken, especially given the ugly nature of most of the j2ee config files. But xml-based configuration can also be a positive thing. The use of declarative mappings and configuration in XML files is done a lot in J2ee, while .NET , for example, makes heavy use of metadata attributes. There's a lot of support for metadata in code these days, but in my opinion, declarative xml is a better long-term solution. There is a lot less coupling of implementation decisions if your integration with your environment is done from an xml file outside of your code. Sometimes you can't always decouple implementation details from things in the J2EE spec, but a lot of times you can, and that's one of the main reasons we have even a little server portability.

    I think that the hibernate website has an excellent discussion on the use of XML files for dealing with the implementation details of your code (where it hits an actual deployment environment). They mention the other alternative, hard-coding deployment details, and show how the xml files work better. I agree, especially if (as is the case with hibernate) the developers have made an effort to really take advantage of the fact that xml files are human-readable. If done right, an XML configuration or descriptor can very clearly and concisely describe the manner in which your code can integrate with a server environment. I'd much rather deal with that, personally, than with hard-coded hooks or metadata markup that is partial to one deployment scenario (e.g., xdoclet hooks for ejb generation; what if I don't want to use ejbs all the time, and my code is littered with ejb metadata markup?).
  22. Complex ? Use a few brain cells ....[ Go to top ]

    Some parts are, but surely using a few brain cells ... and hey ... presto ... solution ....

    If there are *so* many concerns w.r.t. ejb .. MDA ??? that will alleviate lack of brain cells w.r.t deployment on diff platforms ?

    Hmm ... me needs a beer
  23. Complex ? Use a few brain cells ....[ Go to top ]

    Well .. lets not get all confused, the original Idea behind EJBs was to have a solid transaction server (like) capabilities built in to an app server.
    And the transparency it provides while updating or retriving a single or multiple resources (Say an DB and a SAP data using JCA).
    I agree that there J2EE could have provided these transactional functionalities with out complicating matters , but that was when the OEM App server vendors kicked in and made matters worse.and started implementing their own complications...
    And yes they are also the folks who have a say in what goes in to J2EE...


    > Some parts are, but surely using a few brain cells ... and hey ... presto ... solution ....
    >
    > If there are *so* many concerns w.r.t. ejb .. MDA ??? that will alleviate lack of brain cells w.r.t deployment on diff platforms ?
    >
    > Hmm ... me needs a beer
  24. xdoclet[ Go to top ]

    the funny thing is that you still have to hardcode all the crap into
    your code to generate the xml files.

    Net gain ?
  25. RMI Coplex ?[ Go to top ]

    I agree with you most of the time, but:

    >> RMI - too complex and requires RemoteException on each method call. Homemade protocol and serialized objects is much more easier and more lightweight. Just read/write objects from/to sockets. (The homemade protocol < 100 lines of code.. using the RMI requires more extra lines in itself than that. And I can throw RuntimeExceptions instead of Checked exceptions from remoted methods)

    How's that! RMI complex! RMI is the simplest object-based RPC on the world. And it works and works well. All you need is interface and implementation class. And threading is already done for you. Writing stateless servers with RMI is a breeze, although adding session state is not too hard too. RMI is itself heavily based on Java serialization and is a very thin layer around it. RMI is fast, almost as fast as plain socket communication. I do not see any drawback of RMI compared with plain socket connection, only benefits.

    MC
  26. RMI scalability problems[ Go to top ]

    I agree with you most of the time, but:

    >
    > >> RMI - too complex and requires RemoteException on each method call. Homemade protocol and serialized objects is much more easier and more lightweight. Just read/write objects from/to sockets. (The homemade protocol < 100 lines of code.. using the RMI requires more extra lines in itself than that. And I can throw RuntimeExceptions instead of Checked exceptions from remoted methods)
    >
    > How's that! RMI complex! RMI is the simplest object-based RPC on the world. And it works and works well. All you need is interface and implementation class. And threading is already done for you. Writing stateless servers with RMI is a breeze, although adding session state is not too hard too. RMI is itself heavily based on Java serialization and is a very thin layer around it. RMI is fast, almost as fast as plain socket communication. I do not see any drawback of RMI compared with plain socket connection, only benefits.
    >
    > MC

    Actually there is a scalability issue with ObjectInputStream/ObjectOutputStream that comes into affect when you have a lot of concurrent threads. If you look in java.io.ObjectStreamClass you will see that there is a cache for ObjectStreamClasses and another Field cache that is a globally synchronized object. GLobal contention on these caches can slow down RMI on extremely heavy load. The simple solution is to replace these caches with ConcurrentReaderHashMap from Doug Lea's awesom oswego package. I have done the modifications, but unfortunately, because of the way Sun has licensed the JDK source, I cannot distribute this code. :(

    Bill
  27. RMI.. vs custom Protocol[ Go to top ]

    How's that! RMI complex! RMI is the simplest object-based RPC on the world. And it works and works well. All you need is interface and implementation class. And threading is already done for you. Writing stateless servers with RMI is a breeze, although adding session state is not too hard too. RMI is itself heavily based on Java serialization and is a very thin layer around it. RMI is fast, almost as fast as plain socket communication. I do not see any drawback of RMI compared with plain socket connection, only benefits.

    > >
    > > MC
    >
    > Actually there is a scalability issue with ObjectInputStream/ObjectOutputStream that comes into affect when you have a lot of concurrent threads. If you look in java.io.ObjectStreamClass you will see that there is a cache for ObjectStreamClasses and another Field cache that is a globally synchronized object. GLobal contention on these caches can slow down RMI on extremely heavy load. The simple solution is to replace these caches with ConcurrentReaderHashMap from Doug Lea's awesom oswego package. I have done the modifications, but unfortunately, because of the way Sun has licensed the JDK source, I cannot distribute this code. :(
    >
    > Bill

    Ookey - I was being a bit too harsh on RMI it's not bad at all but sometimes you just can get by with even 'simpler' solution..

    - With RMI you have to run RMIRegistry on the server (yet another process to run)
    - You have to throw RemoteExceptions on your remoted methods so clients using your interface have to try catch all the time if you don't build another interface and layer to blanket that. I prefer RuntimeExceptions.
    - I want to control the sockets and in RMI there's no easy way for that.
    - RMI uses sockets to transfer it's data just like everyone else.. there's no magick alternative to that. (Maybe it'll use NIO nonblocking sockets in the future?)

    I will have to look at the cache issue more. Basically it's useless since the cache outsmarts itself by not serializing the same objects again.. Sometimes you want that same object to be serialized since that object contains changes you want to be updated to the database. So you'll have to call reset to stream before it agrees to serialize your object. There aren't yet any performance reasons to go into that detail and I suspect than when there starts to be performace issues they are database and I/O related. (As said before we're not planning for thousands of simultaneous connections)
  28. RMI.. vs custom Protocol[ Go to top ]

    - With RMI you have to run RMIRegistry on the server (yet another process to run)


    You can embed RMI Registry in your server. When using RMI, I always have configuration option to embed RMI Registry in the server. For small deployments and test environments it is a good choice.

    MC
  29. Most of the time J2EE is unnecessary[ Go to top ]

    Technology is never necessary - solving problems is.

    True, EJB can be complex. Real programming can be complex.

    The fact is, EJB solves some problems in a standard way that are common to many enterprise applications. If you don't need to deal with these problems, don't use EJB. If you do, you have a few choices. You can use a standard, you can use an available non-standard (open source), or you can role your own.

    Personally, I think using a standard has value.
  30. I remember 10+ years ago when I work with Novell 3.12 and FoxPro for DOS. Some of these ERP/CRM systems are still running ! My team was able to deliver any project on schedule and budget without bad surprises.

    So 4 years ago I quit my job to start work with Java/J2EE and I since then I have been fighting a lot to understand the "J2EE/EJB/SOAP/UML/RUP/CMM/PMI/etc" obsession.

    Just now I finally start to fell I didn´t a mistake (to quit my previous job) and in part because guys like Gavin King and Rod Jonhson. They have been doing a great job for Java community.

    IT focus must be the business ! Does not matter if I am using X or Y (the last new buzz), we have to deliver a human readable code (simpler) that met the requirements ! Just it !

    Rodolfo

    PS : Sorry for my english too. :)
  31. Java programmers must understand that their paycheck doesn't come from the magic money tree in the corporate parking lot.

    <flashback year-2000>
    I was working for a medical company in Tampa FL specializing in Workers' Comp. Even though I was the most senior java developer on the staff (of 15 developers), I had to listen to the pointy-haired boss that was convinced that EJB 1.0 was the holy grail. Most of the team knew better. We knew that our paycheck was coming from an Angel investor and that we must have a product quickly or we would tank. All the pointy-haired boss(es) focused on was cool new technology, cool UML diagrams, and anything else that seemed to be "neat" (and waste precious time). To make a long story come to an end, I bailed, sensing that I was on the Titanic and EJB 1.0 was the iceberg. A few weeks after I bailed, almost all of the team (and company) was fired. Burned up all the money and produced jack-squat for a product. The company is alive today and doing very well thanks to some last minute funding and the miracle of signing some nice sized accounts.
    </flashback year-2000>

    I am now the I.S. Director for a medical company in Tampa focused on Workers' Comp. Guess what? I don't use EJB or most other buzz words. I run a scalable J2EE application processing real-time transactions. I used the simplest thing that would work (i.e. POJO's - I am looking at Hibernate to help me out). I KNOW that my paycheck DEPENDS on the speed of delivering bug free applications that can scale as fast as the sales team can cut deals. Am I anti-EJB, nope. I see TONS of American jobs going overseas....and in part, I blame too many J2EE developers concentrating on technology instead of solving business use cases and getting money flowing. We need to be J2EE developers AND care about the overall business at the same time. Tunnel vision will send your job overseas in the blink of an eye.

    I say keep things simple, and if you can't, hide all the nasty stuff and provide me with products like log4j and Hibernate.

    Kindest Regards,
    Tom Pridham
    I.S. Director
    Matrix Healthcare Services
    Tampa, FL USA
    www.MatrixHCS.com

    P.S. - Yes, I know our "business card" part of our site runs in asp....we have already migrated our internal/external applications to JSP....but asp is nice and simple for the "business card" type stuff. :-)
  32. Couldn't have said it better.
  33. Every academic exercise in a new programming environment starts with a hello world application as a simple way to "present" some output. My earliest reference point is in K&R for The C prog. lang. And that was never an "enterprise" problem. However, it is a problem that seeks to answer a question with brevity as in "what is the simplist/shortest way to create a ... application in that language?" So I think that it is totally a relevant question for J2EE because if you can't answer such a question I don't know how you can teach a new student, or a new junior programmer, or an over curious management type, or convince a legacy (Cobol or .Net) programmer to use J2EE. And it's OK if there is no one line programming answer either. I've seen that question answered by just a servlet, or a JSP page or even an EJB pulling a string from a database, a portlet, a JMS messaging queue, on and on.

    And if the answer requires a suggestion to use a Mac IDE tool with jboss, so be it. Just don't make the answer too complex, by implementing every layer in the J2EE technology stack!
  34. To some extent it feels great to hear that EJB and other complicated stuff is just making our lives miserable. I m a strong supported of simple patters like MVC - command etc.
       Its so funny that EJB was kind of a stolen idea from MSFT Transaction Server. ( now dont question that , we all know the truth ). Ofcourse EJB was better than MTS in a lot of ways. But MSFT stopped working on MTS . Why ? they realized the complications in configuration, network issues and the benefit you got from all the complexity. Now that we are in the 4th year of EJBs, we have realized JDO might be better, Entity beans have trouble in heavy systems and EJB as a whole is complex. So what next ???
       I m glad that I m not into EJBs and wont ever be unless I really run out of simple options. and when I do that I will assign atleast 2 months for build and configuration issues in my project using EJBs. It simply sucks !!
       Its good to see this article on TSS, echoes a lot of us frustated with - No proper documentation - complicated - supposed to be very advanced & "cool" technology.

    Happy coding !!
  35. What an app server is for[ Go to top ]

    I've said it before and I'll say it again. If you are not doing ditributed, coordinated transactions amongst multiple transactional resources, I don't think the bang-for-buck quotient justifies using EJB. And I can't think of ANY situation where an Entity Bean would be desirable. Even if you need ditributed trx, just front JDO with a session bean. THAT is what an app server is for.


    -geoff
  36. What an app server is for[ Go to top ]

    I've said it before and I'll say it again. If you are not doing ditributed, coordinated transactions amongst multiple transactional resources, I don't think the bang-for-buck quotient justifies using EJB. And I can't think of ANY situation where an Entity Bean would be desirable. Even if you need ditributed trx, just front JDO with a session bean. THAT is what an app server is for.

    >
    >
    > -geoff

    Hey, I've always been listening! :)

    (Seriously though ... even JDO ... can't that go too?)
  37. When did MTS Die?[ Go to top ]

    Not sure how you figure that Microsoft Stopped working or developing MTS.

    MTS evolved into COM+ Transaction Services in Windows 2000. A much enhanced, easier to use transaction manager. COM+ (and hence MTS) is actually one of the keys to using transactions in the .NET environment.

    MTS hasn't gone anywhere, it delivers excellent performance to any programming language and is available on 90% of the worlds PCs. Not sure why you would need transactions on a PC, but its a nice idea :)
  38. When did MTS Die?[ Go to top ]

    Not sure how you figure that Microsoft

    > Stopped working or developing MTS.
    > MTS evolved into COM+ Transaction Services
    > in Windows 2000. A much enhanced, easier to
    > use transaction manager.

    The only *significant* COM+ enhancement over MTS would be, IMHO, true object pooling. Otherwise, COM+ is pretty much what MTS gave us. It is also debatable whether COM+ is much easier to use than MTS ... the burden of understanding transactional semantics, security contexts and object lifetimes via JITA is as confusing in COM+ as it was with MTS. The reason? It didn't change much. :)

    > COM+ (and hence MTS)
    > is actually one of the keys to using
    > transactions in the .NET environment.

    A lot of MS documentation punts the usage of COM+ (with distributed/global transactions) indiscriminately. There are some voices, however, that say "use COM+ only when necessary" etc ... but these voices go largely unheard. The end result? Disgruntled developers with inappropriate tools. EJB anyone?
  39. When did MTS Die?[ Go to top ]

    Dude,

    MTS died last month. Where you been?
  40. EJB Complex or Complicated?[ Go to top ]

    You can use EJBs and J2EE with many patterns (MVC/multi-tier, Factory, Business Interface, Business Delegate, DTO, etc.). Before complaining that EJBs are "complicated" (it seems that you don't understand the idea behind EJBs), please check a very good article collection from Brett McLaughlin:

    http://www-106.ibm.com/developerworks/java/library/j-ejbcol.html

    IMO, he wrote some very good introduction articles to EJBs.

    Cheers,
    Lofi.
  41. Hello Cruel World[ Go to top ]

    Current versions of JBoss ship with BSHDeployer, which allows you to hot-deploy BeanShell scripts into the server.

    So, solving the problem is as simple as opening up your text editor and typing:

    void start() { System.out.println( "Hello world!" ); }

    Save as hello.bsh, drag-and-drop onto the server, and you are done.

    This is kind of a cheap solution, since Bruce's point was about J2EE in general and not JBoss in particular, but it works!
  42. Hello World web app[ Go to top ]

    cd jboss/server/default/deploy
    mkdir Hello.war
    cd Hello.war

    create file index.jsp:

    <%@page contentType="text/html"%>
    <html>
    <head>
       <title>Hello</title>
    </head>
    <body>
      <h1>Hello <%=System.getProperty("user.name")%></h1>
    </body>
    </html>

    browse to localhost:8080/Hello/index.jsp

    takes maybe 30 seconds to do, can be done on a live server
  43. Post J2EE[ Go to top ]

    <reply type="On Topic">
      The 'trick' to J2EE or any framework for that matter is using the right tool for the right job. There are things EJB's are good at, things they are bad at, and ultimately, every framework or technology could be better. Someone on the Jakarta Struts users' mailing list asked which MVC framework is best. Thankfully Ted Husted responded with:

    "Which framework is best for a particular project is going to depend on the project, and more importantly, the people working on the project. Most any tool can do the job, so long as the people using the tool *want* to make it so.[1]"
    </repy>

    <reply type="Plug">
      That said, there are some really cool alternatives to J2EE, some of which have already been mentioned in other replies. I'll add a short list of my own:

      Enterprise Object Broker: http://enterpriseobjectbroker.org/
        "Welcome to the post-J2EE era. This open source application server cherry picks the best from J2EE (Servlets) and completely ignores the arguable worst (EJB)."

       And of course, any of the "IoC" frameworks like Apache Avalon or PicoContainer are great too!
    </reply>
  44. Re: Post J2EE[ Go to top ]

    Oops, meant into include a link to that email:

    [1] http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg86718.html
  45. EJBs...[ Go to top ]

    <quote>
    From Enterprise Object Broker:
    - No formal definitions of 'Home' interfaces and methods.
    - No formal definitions of 'Entity' and 'Session' beans and methods.
    - JNDI does not have to be used for lookup of other 'things'.
    </quote>

    The idea of EJB is actually to offer you a factory (Home interface) and a business interface (EJBObject or EJBLocalObject). This is a *very* good design => Factory- and Interface-based development! The use of JNDI is also great. You use JNDI everywhere to make the programming model just always the same. Want to look for an object? Use JNDI. Want to look for a database resource? Use JNDI. Want to look for a topic in JMS? Use JNDI. Want to look for a resource in your SAP system ? Use JNDI.

    I just don't understand, why everybody think, that their component models are the best solution??? EJBs (and J2EE) are for such a component model and it is already mature! The guys and folks who invented EJBs are not stupid, so please, do not make such a comparisons...

    Cheers,
    Lofi.
  46. Business platform[ Go to top ]

    When Java broke through into the mainstream back in 1995, it was embraced as an excellent lightweight, small footprint, agile platform, specializing in the network computing (remember Sun's slogan "the network is the computer"?)

    Everything was hunky dory, and many industry experts predicted that Java will make huge inroads into Microsoft's territory. The NC were envisioned as being a huge threat to the Wintel PCs. Today, all that hoopla seems ridiculous, as Java hasn't made any visible dent into Microsoft's desktop kingdom.

    After being spectacularly beaten by the Microsoft (mainly thanks to the phenomeal success of the Internet Explorer, which quickly managed to dwarf Netscape), Java had, with its tail curled between its legs, crawled back into the non-Microsoft territory (namely, the enterprise server side), and claimed to be the ideal platform for the server side development.

    Many people complained back in 1997/98 how Java, as good and as neat as it was, lacked qualities of a robust business platform (no security, no support for transactions, no logging, no failover, no framework supporting business development, and on and on, the list was huge).

    At that same time, IBM was touting its latest product, San Francisco Shareable Frameworks, which was supposed to deliver up to 40% of the fully workable business code for many of the typical business applications. The project was initially designed with C++ in mind, but changed its course midway when IBM poured lots of resources into rewriting it in Java. The whole thing was a fiasco that died a quiet death sometime in 1998/99. All was not lost, however, because at that time IBM seemed to be in the same bed with Sun (and with some other strange bedfellows, such as Oracle and BEA). So, many of the concepts, designs and even source code from the San Francisco framework reportedly found new home in the very ambitious J2EE platform. This platform claimed to offer a one stop shop for all the developers wanting to build robust business applications.

    Now, IBM have lots of experience in building business machines. The best example would be their iSeries server (a.k.a. AS/400). This server is a turn key solution that packs a lot of punch and replaces an army of baby sitters that a typical Unix shop must employ. So, their expertise carved inside San Francisco framework must bring a lot of credibility to the table.

    However, as many people have noticed, something went terribly wrong. What was it? My hunch is that it has to do with the distributed nature of the web based applications. In the good old days of the monolithic computing, it was relatively easy to build a robust platform that would hide the complexities from the developer. But, in a distributed, loosely coupled world, that proved to be a challenge that no one seems to have the ability to solve (so far).

    There is very little doubt today that standard J2EE platform is a big honking failure. No matter how one puts it, it's unwieldy. For example, in the old days of mainframe computing, the machinery was so clunky that to try out any change to the application would take hours. The knowledge about the change had to propagate through many layers in the system, making it practically impossible to perform any iterative development work.

    Because of that, people have enthusiastically embraced Java, knowing that it will support the agile development model. But guess what? Today, with all the incredibly complex layers comprising J2EE, it again takes hours to propagate any minor changes in the system. The huge machinery has to really go through a lot of motions before all the obscure and convoluted descriptors and XML files get read, processed, all the Ant scripts executed, bla bla bla.

    Bottom line -- we're back at square one. Only, this time we have a much, much more complex thing on our hands. So, everyone loses.

    So, how do we solve this conundrum? Tune in for the next installment, where I'll outline the way out of this misery.

    Alex
  47. Business platform[ Go to top ]

    So, many of the concepts, designs and even source code from the San Francisco framework reportedly found new home in the very ambitious J2EE platform.


    FWIW, it's been published before that many J2EE concepts actually came out of the Managed Object Framework (MOFW) programming model used on IBM's ComponentBroker product.

    >> There is very little doubt today that standard J2EE platform is a big honking failure....Bottom line -- we're back at square one.

    Sorry, but to me this sounds like pure, sensationalistic flame-bait. From what I see out in the marketplace and in customer shops, the J2EE platform has been the most successful, widely-used distributed computing platform to date. The number of high-volume, high-visibility internet and intranet apps built and successfully running on J2EE speaks for itself. As with any technology there are areas it can and should be improved....developer productivity being one, and work is ongoing in that area as we speak (this is a major theme of the upcoming EJB 3.0 spec). I am always a little wary when I hear "what we have today is a complete failure...but hold on, I can show you the way out..." :)

    I have seen it happen twice now:

    1. Someone invents a simple, basic distributed computing model.
    2. While simple, it doesn't address the needs of commercial distributed computing. (Security, Transactions, Scalability, ...) So these concepts are added to the model, making it necessarily more complex. Customers who want to do real business are now able to, albeit at the expense of some additional complexity (because commercial distributed computing is still _not_ child's play, no matter what you wrap it in).
    3. People say "Boy, XYZ is so complex that no one can use it. But I have a way to solve this, look at my simple, basic distributed computing model!"
    4. Go to step 2 and repeat.

    on the evolution from Java RMI to J2EE, and again on the current evolution of the Web Services standards. It's actually somewhat humorous.

    Randy Schnier
  48. Business platform[ Go to top ]

    Sorry, but to me this sounds like pure, sensationalistic flame-bait. From what

    >I see out in the marketplace and in customer shops, the J2EE platform has been
    >the most successful, widely-used distributed computing platform to date. The
    >number of high-volume, high-visibility internet and intranet apps built and
    >successfully running on J2EE speaks for itself.

    This is a very poor argument. It's like saying that we don't need high definition TV, because there are milions of TV sets installed nationwide, and obviously these TVs are working like a charm.

    True, there are many J2EE-based applications in production today, but this is not because J2EE is such a good platform, it's more because it was the ONLY platform available for hosting distributed apps.

    If now someone comes up with a better solution, we should not reject it merely on the fact that some solution, no matter how half-assed, already exists.

    I understand where you're coming from with this fear of change -- you are a J2EE developer, and you'd hate to see your skillset go down the drain. I'm in the same boat. I made a (foolish) decision back in 1999 to assoiciate my name and my career with the J2EE platform, not knowing that it'll grow into a monster that it is today. I make my living by selling my J2EE expertise, and I'm getting tired of it. I am convinced there's gotta be a better way. J2EE is just too geeky, too explicitely complex in a hard core engineering way, while neglecting the business needs. This flaw will be remedied, like it or not.

    Many engineers like it when things get hairy and complicated. That gives them the upper hand, as the complexity serves as a filter to weed out the wannabes. This ensures not only their job security, but also the highly exalted status as gurus of the technology. Well, guess what? Business executives are getting mighty upset about this state of affairs. They'd like to see server side computing demystified in the same way client side computing got demystified 10 - 15 years ago. And, it's going to happen.

    Nowadays, no one can strut (pardon the pun!) around the office claiming to be the Word, or Wordperfect guru. No one can make a living anymore doing that. But many people can strut (here's that pun again!) around claiming to be the deployment descriptor gurus, or Ant script builder gurus, or Struts gurus and so on. Big freaking deal. I think we need to get rid of those roles. No one in their right mind should be expected to look into the ugly XML files, ever.

    So, something will come along that will render J2EE obsolete. Same as people claimed back in 1996/97 that Java was a heaven sent for the desktop computing (while Sun was hurriedly working on polishing Swing), they are clamoring today how J2EE is the heaven sent for the back end processing. Today, Swing is a marginal platform, and tomorrow J2EE will face the same fate. Complex, bloated solutions are on the way out. Everyone advocates agile development today. J2EE is your quintesential anti-agile platform. I just can't see how will it survive? J2EE is going to continue to get bad rap, bad press, until most people drop it. It's already got a black eye from numerous people complaining how unwieldy it is. And the complaints will not subside, they'll only get more vocal.

    Please don't interpret this view as coming from someone who's in the Microsoft camp. I also don't think that Microsoft's COM model is any better. Besides, Microsoft has a huge problem in that they tend to attract only developer-wannabes, and who wants to be counted as a part of that crowd?

    Like I said, I'm in the same boat as the rest of you, in that I need to reinvent myself in order to continue making a living doing server side development. It is obvious to me that J2EE won't be able to cut it in the long run (same as Swing failed to make a sizeable dent in the desktop world), and now I'm looking at alternative disciplines.

    All I ask you is to join me in this search. But, if you're too too paranoid, go ahead and be defensive.

    Alex
  49. Business platform[ Go to top ]

    Sorry, but to me this sounds like pure, sensationalistic flame-bait. From what

    > >I see out in the marketplace and in customer shops, the J2EE platform has been
    > >the most successful, widely-used distributed computing platform to date. The
    > >number of high-volume, high-visibility internet and intranet apps built and
    > >successfully running on J2EE speaks for itself.
    >
    > This is a very poor argument. It's like saying that we don't need high definition TV, because there are milions of TV sets installed nationwide, and obviously these TVs are working like a charm.

    Your original statement was "J2EE is a big honkin' failure." I would dispute that kind of blanket assertion and was offering evidence to back it up.

    > If now someone comes up with a better solution, we should not reject it merely on the fact that some solution, no matter how half-assed, already exists.

    When someone truly comes up with a better solution and not just a "new" one that forgets or ignores the problems that commercial distributed computing needs to solve, I'm all ears. Until then, I would hesitate to declare what's out there a "failure" and therefore needing wholesale replacement.
     
    > I understand where you're coming from with this fear of change -- you are a J2EE developer, and you'd hate to see your skillset go down the drain. I'm in the same boat. I made a (foolish) decision back in 1999 to assoiciate my name and my career with the J2EE platform, not knowing that it'll grow into a monster that it is today.

    Believe me, it's not a fear of change. Change for the right reason is good and I relish it. Change for the sake of change is bad. Skill set isn't the issue either...my skillset is in solving commercial distributed computing problems, not J2EE itself. J2EE is just a vehicle to solve the problems that need solving.

    > Nowadays, no one can strut (pardon the pun!) around the office claiming to be the Word, or Wordperfect guru. No one can make a living anymore doing that. But many people can strut (here's that pun again!) around claiming to be the deployment descriptor gurus, or Ant script builder gurus, or Struts gurus and so on. Big freaking deal. I think we need to get rid of those roles. No one in their right mind should be expected to look into the ugly XML files, ever.

    Use any of the fine IDE's available today and treat the XML DD's as the machine-readable files they were intended to be. I never look at them; the tooling and system management infrastructure handles that gorp for me.
     
    > So, something will come along that will render J2EE obsolete.

    That is certainly possible, but in order for it to be successful it will have to solve the commercial distributed computing problems that businesses have.

    > All I ask you is to join me in this search. But, if you're too too paranoid, go ahead and be defensive.

    Hmmm. I don't consider myself paranoid or defensive...but I do have a sense of history, and I prefer to improve on what's out there rather than chucking it all purely to try something that purports to be better.

    Randy
  50. Business platform[ Go to top ]

    Your original statement was "J2EE is a big honkin' failure." I would dispute

    >that kind of blanket assertion and was offering evidence to back it up.

    Yes, my blanket statement was of the same caliber as stating that VHS technology was a big honkin' failure. True, almost every household owns a piece of VHS technology, but it is now being phased out, squeezed out by a better technology. Just because certain technology has been embraced doesn't automatically mean that it's good, and that there could be no better solution.

    >When someone truly comes up with a better solution and not just a "new" one
    >that forgets or ignores the problems that commercial distributed computing
    >needs to solve, I'm all ears.

    Then, I'm barking up the wrong tree. You see, I'm not convinced that the problems that commercial distributed computing needs to solve are actual problems. I have a hunch they are mostly made up problems. In other words, engineers came up with a fascinating solution for the challenges of the distributed computing, and now they are shoving that solution down everyone's throats. It's a proverbial solution in search of a problem.

    Most business applications in production today contain nothing that would inherently convict them to must use the distributed computing model. Everything I ever worked on, every problem domain I've solved so far, fits nicely into the non-distributed model. Even if, for some reason, certain organizations feel that they should distribute their resources, the distribution is usually very mild, and toy-like. I've never encountered the large scale, wildly changing configurations that LDAP and other J2EE advanced concepts propose to solve.

    >Believe me, it's not a fear of change. Change for the right reason is good and
    >I relish it. Change for the sake of change is bad. Skill set isn't the issue
    >either...my skillset is in solving commercial distributed computing problems,
    >not J2EE itself. J2EE is just a vehicle to solve the problems that need
    >solving.

    Yes, this is exactly the question this thread is trying to solve. Do we really, as an industry, need people whose skillset is in 'solving commercial distributed computing problems'? Maybe these problems are mostly imaginary? Maybe we need to re-focus our attention on something else, on some more pressing issues?

    >Use any of the fine IDE's available today and treat the XML DD's as the
    >machine-readable files they were intended to be. I never look at them; the
    >tooling and system management infrastructure handles that gorp for me.

    I couldn't agree with you more. I'm also convinced that XML is only meant to be machine readable.

    However, the problem is -- which IDE? As a consultant, I travel lightly. I must be able to walk into any situation and start running as soon as I hit the ground. Whining that they don't have my pet IDE won't land me the contract.

    >That is certainly possible, but in order for it to be successful it will haveto >solve the commercial distributed computing problems that businesses have.

    It's funny how you're convinced that these are the actual problems, without ever stopping to examine the situation. Have you ever considered that maybe you have been taken for a ride? It's been known to happen, you know.

    >Hmmm. I don't consider myself paranoid or defensive...but I do have a sense of
    >history, and I prefer to improve on what's out there rather than chucking it
    >all purely to try something that purports to be better.

    Great. Different people have different predictions. Only time will tell.

    Alex
  51. VHS a failure?[ Go to top ]

    "Yes, my blanket statement was of the same caliber as stating that VHS technology was a big honkin' failure. True, almost every household owns a piece of VHS technology, but it is now being phased out, squeezed out by a better technology. "

    Well, I am still happy that I invested in a VHS player back in the early 80's, even if it wasn't necessarily the best technology. When it died after 10 years, my tape collection wasn't wasted because I could buy another (cheaper) one that supported VHS. After 20 years,I can still buy, as well as play VHS tapes. If J2EE has a run like that, companies will be delighted they standardized on it.

    On the other hand, I am a little bitter about my 8-track tape collection....
  52. Business platform[ Go to top ]

    <QUOTE>
    Most business applications in production today contain nothing that would inherently convict them to must use the distributed computing model. Everything I ever worked on, every problem domain I've solved so far, fits nicely into the non-distributed model. Even if, for some reason, certain organizations feel that they should distribute their resources, the distribution is usually very mild, and toy-like. I've never encountered the large scale, wildly changing configurations that LDAP and other J2EE advanced concepts propose to solve.
    </QUOTE>

    Alex, if that is true, you are probably highly overpaid. Every situation that deals with more than one data store - probably the most common situation in todays enterprises - <em>is a distributed model</em>. It is not that organization <em>feel</em> that they should distribute - it is that their resources <em>are</em> distributed. On a different note: As a consultant you should be able to get fairly productive with any decent IDE within days if not within hours or again your not worth your money.
  53. Business platform[ Go to top ]

    Alex, if that is true, you are probably highly overpaid. Every situation that

    >deals with more than one data store - probably the most common situation in
    >todays enterprises - <em>is a distributed model</em>. It is not that
    >organization <em>feel</em> that they should distribute - it is that their
    >resources <em>are</em> distributed.

    Karl, looks like you and I have different definitions of distributed computing. For me, accessing distributed data stores does not amount to distributed computing. Accessing distributed processing logic is what I'd call distributed computing. My application can combine data coming from a database, a configuration file, an XML document etc., and all these data stores could be located somewhere on the network, but I think it would be a stretch to call that distributed computing.

    >On a different note: As a consultant you should be able to get fairly
    >productive with any decent IDE within days if not within hours or again your
    >not worth your money.

    I'm not so sure. You see, I sell my services based on the fact that I'm a business systems integration and development expert. That's my reputation. Nowhere in there do I sell the fact that I'm an IDE specialist. I usually work in the low tech mode (paper and pencil, whiteboard and eraseable markers, voice and waving my hands). No one is interested in hiring me or paying me because I can operate certain IDE.
  54. Business platform[ Go to top ]

    Well, guess what? Business executives are getting mighty upset about this state of affairs. They'd like to see server side computing demystified in the same way client side computing got demystified 10 - 15 years ago.


    I agree that business executives are upset, but have different conclusions. The fact that J2EE has been around for awhile, and many J2EE applications have been deployed successfully is quite comforting to an executive. They want a programming model that will last a few years, and one for which there is an existing pool of developers. This does not mean J2EE is simple, but it means it is not a risky choice. That may sound wimpy, but managing and reducing risk is an important part of an executive's job. It is pretty certain that J2EE app servers (from IBM, Oracle, BEA, JBoss and others) will be around 5 years from now. So will J2EE development and management tools. The latest/hippest framework that leading edge developers on theserverside are raving about may not be. That doesn't mean the technology isn't good. If a framework, product,or architecture is brand new, it is inherently risky. If it doesn't gain marketshare, it will be gone quickly and applications developed with it are soon hard to support.
    Executives are also sensitive to the fact that client-side computing APPEARED to have been demystified 10 years ago, but that was only because they didn't properly understand the costs and challenges of deploying and managing those applications. 10 years ago, many companies had plans to rewrite and phase out ALL of their mainframe applications within 5-7 years. Often they failed completely.
  55. Business platform[ Go to top ]

    Executives are also sensitive to the fact that client-side computing APPEARED

    >to have been demystified 10 years ago, but that was only because they didn't
    >properly understand the costs and challenges of deploying and managing those
    >applications. 10 years ago, many companies had plans to rewrite and phase out
    >ALL of their mainframe applications within 5-7 years. Often they failed
    >completely.

    Hmmm, I think you're ignoring an extremely large and important chunk of the desktop computing -- spreadsheets. Before spreadsheets have been made easy to use by the non-technical personnel, desktop computing was all the rage. Many propeller heads used to make good living writing those Mickey Mouse DBaseIII, Paradox, FoxPro etc. 'applications'. The need for many of those apps had been supplanted long time ago when a workable version of MS Excel was released. The whole thing got demystified big time. Sales reps now know how to crank their own pie charts and so on.

    What many executives are expecting to see nowadays is the same thing happening on the server side. Give non-technical office users some tool to let them organize their work environment without depending on the highly paid distributed computing gurus.
  56. Cheaper tools not cheaper programs[ Go to top ]

    <QUOTE>
    Hmmm, I think you're ignoring an extremely large and important chunk of the desktop computing -- spreadsheets. Before spreadsheets have been made easy to use by the non-technical personnel, desktop computing was all the rage. Many propeller heads used to make good living writing those Mickey Mouse DBaseIII, Paradox, FoxPro etc. 'applications'. The need for many of those apps had been supplanted long time ago when a workable version of MS Excel was released. The whole thing got demystified big time. Sales reps now know how to crank their own pie charts and so on.
    </QUOTE>

    Hmm, interesting point. But quite wrong. A lot of the spreadsheets used by the "sales reps" are still programs that are provided by the sales support tools of their employer. The switch was not from a "complex and expensive" program to a "simple and do it yourself". It was from an expensive engine to a cheap one. For example my dad - basically a salesrep type of person - had far less problems using and programming foxpro than using and programming excel. Oh, and while we are talking pie charts: Excel charts are still way off any decent presentation quality.
  57. Business platform[ Go to top ]

    However, as many people have noticed, something went terribly wrong. What was it? My hunch is that it has to do with the distributed nature of the web based applications. In the good old days of the monolithic computing, it was relatively easy to build a robust platform that would hide the complexities from the developer. But, in a distributed, loosely coupled world, that proved to be a challenge that no one seems to have the ability to solve (so far).

    >
    I agree. Handling distributed apps is a main stumbling block for why we don't have better tools to provide faster development. What I'm wondering is what percentage of J2EE applications really need to be distributed? How many J2EE apps are but never should have been? I'd really like to know that. Though some requirements surely merit it, I'd venture to say it's far from the norm.
  58. Business platform[ Go to top ]

    However, as many people have noticed, something went terribly wrong. What was it? My hunch is that it has to do with the distributed nature of the web based applications. In the good old days of the monolithic computing, it was relatively easy to build a robust platform that would hide the complexities from the developer. But, in a distributed, loosely coupled world, that proved to be a challenge that no one seems to have the ability to solve (so far).

    > >
    > I agree. Handling distributed apps is a main stumbling block for why we don't have better tools to provide faster development. What I'm wondering is what percentage of J2EE applications really need to be distributed? How many J2EE apps are but never should have been? I'd really like to know that. Though some requirements surely merit it, I'd venture to say it's far from the norm.


    Most J2EE applications that I've seen are built with a tacit assumption that something will drastically change in the future. That is to say, almost 100% of all J2EE apps seem to be essentially monolithic, but with a proviso that, when the business switches to the distributed computing model, they'll be ready. Just flip the switch.

    The million dollar question is: when will that furure arrive? Will it ever arrive? In my experience, typical business applications have a life span of about 5 to 8 years. If in that time frame we consider it very unlikely that the overal computing infrastructure will drastically change, why build with the unforeseen change in mind? Isn't it somewhat wasteful? Yet, all the business apps are being built nowadays as if they'll be running for the next several hundreds of years. This is ludicrous and counter-intuitive. But, the engineers have taken over the asylum, and they are running the show.

    However, from where I'm standing, seems to me that the business executives are getting mightily fed up with the fact that lunatics have taken over the asylum. Something's gotta give, sooner or later.

    Alex
  59. Business platform[ Go to top ]

    That is to say, almost 100% of all J2EE apps seem to be essentially monolithic, but with a proviso that, when the business switches to the distributed computing model, they'll be ready. Just flip the switch.

    I think only peer-to-peer messaging is up to that task. So I mostly agree with the earlier poster who lauded Jini as the better service architecture -- except that JXTA likely beats Jini at scalability, topology, and reliability.

    ...why build with the unforeseen change in mind? Isn't it somewhat wasteful? Yet, all the business apps are being built nowadays as if they'll be running for the next several hundreds of years. This is ludicrous and counter-intuitive. But, the engineers have taken over the asylum, and they are running the show.

    It's the low level managers who are hopelessly distracted with the myth of reuse. A manager is someone who sees himself at the same company years into the future and whose appreciation of mechanics is weak enough for false goals to emerge. Engineers tend to be eXtreme developers who know better than to let anything (except blogging) jeopardize time-to-market.

    However, from where I'm standing, seems to me that the business executives are getting mightily fed up with the fact that lunatics have taken over the asylum. Something's gotta give, sooner or later.

    Natural selection fixes anything eventually. The worse the economy, the greater the selective pressure to optimize.
  60. Business platform[ Go to top ]

    two corrections to this post:

    1. The lifetime of apps is WAY longer than 6-8 years. That's why >50% (or more) of all programs are still mainframe based.

    2. ALL J2EE apps ARE distributed (unless the database and browser are colocated with the app server). The shift from browser-only access to app-to-app access is relatively minor and is already very common.

    If you assume that code is throw-away, you will eventually be replaced -either with someone with a longer-term focus, or with an offshore resource that your company can afford to have write throw-away code.

    Matt
  61. Business platform[ Go to top ]

    Matt Gunter wrote:

    >1. The lifetime of apps is WAY longer than 6-8 years. That's why >50% (or more)
    >of all programs are still mainframe based.

    You've got things upside down, so to speak. The reason why we still have those 20 plus years old applications running on the mainframes is not because they are still good enough to support the business, but because it would be exorbitantly expensive to re-write them/write them again from scratch. These apps are a necessary evil. People have learned to somehow live with them (don't ask me how, I haven't got a clue myself), in the same way that people who don't have dental coverage sometimes learn to live with a toothache.

    However, whenever there is a situation where the businesses can move in an agile fashion, meaning the cost of developing from scratch is not that exorbitant, we see that they tend to throw out the 5 to 8 years old code in favor or writing a new one. In 5 to 8 years, most businesses undergo such dramatic changes in their overall strategies and internal ways of doing business, that the old code base becomes a real stretch at that point. That's why it usually is cheaper/more efficient to write a new app from scratch, than to try and morph the existing code base to fit the unforeseen changes.

    >2. ALL J2EE apps ARE distributed (unless the database and browser are colocated
    >with the app server). The shift from browser-only access to app-to-app access
    >is relatively minor and is already very common.

    The above statement belies your naivete when it comes to understanding the J2EE architecture. Saying that ALL J2EE apps are distributed is the same as saying that ALL Java-based apps are object oriented. In my experience (and I have plenty of field experience, plus 4 years of teaching experience), on an average only one in 100 Java-based applications could qualify as being object oriented. The remaining 99% of the Java-based apps consist of purely procedural code masquerading as objects.

    Yes, Java is an object oriented language, but nothing in Java compells us to stick with the object oriented design and implementation. It is perfectly possible to write full blown procedural systems in Java. By the same token, J2EE is envisioned as being a distributed computing platform, but nothing in there compells us to design and develop distributed apps using this platform. As a matter of fact, most J2EE apps I've seen are pure vanilla homogenous, monolithic apps, masquerading as distributed apps. Just because your database is located on another server doesn't automatically mean that your application is distributed.

    Alex
  62. Business platform[ Go to top ]

    That's why it usually is cheaper/more efficient to write a new app from scratch, than to try and morph the existing code base to fit the unforeseen changes.

    Totally. Have the reuse fanatics ever heard of "internet time"?! There are several factors at play here. Tools are always improving, and the barrier of rolling from scratch is always lowering. Most reuse fanatics neglect this. If a company seriously evolves a homemade legacy with a mandate of preservation, the resulting internals are much more awkward than if the company rewrote subsystems as needed. Again, reuse fanatics don't acknowledge this.

    Then there's the sad fact the so much reuse is motivated by emotional attachment, where rational impact analysis seems less important than hilighting the supposed flexibility of one's own grand architectural vision. Pride is a lame way to steer technology, and sophomoric obssession with evolutionary reuse is big red flag for me.

    Consuming commodity solutions is the best form of reuse. The efficiency of commodity use comes from reducing labor. Whereas reuse fanatics preach a handicap of increased effort when a project is still in its vulnerable infancy. That's decidedly neither RAD nor XP.
  63. Best tools currently for RAD?[ Go to top ]

    Brian/Alex,

    It seems we share the same views on this subject. I'd be interested to know what RAD tools right now you're using, or have played around with, that fulfill this vision, including non-J2EE tools.

    Read an interesting review in eWeek a few weeks back for a product to enable end users to create simulated apps called iRise. They, or somebody, possibly even developers, wire up the framework (work flow, view layout, etc.) then, presumably, hand it off to the development team so they can code their business objects: I've played a bit with Bea's workshop tool - it seems pretty helpful, but maybe a bit more technical then the previously mentioned product.

    Application simulation seems very promising to me. That product is quite pricey but I'm sure they've got competition I'm not aware of.

    Mike
  64. Best tools currently for RAD?[ Go to top ]

    It seems we share the same views on this subject. I'd be interested to know

    >what RAD tools right now you're using, or have played around with, that fulfill
    >this vision, including non-J2EE tools.

    Michael,

    At this point, I don't think the problem lies in the toolset we're using. Sure, right toolset for the right job is mandatory, but what good is the right toolkit if the master plan is wacky?

    In other words, if you're building a house, and are using the most skilled builders and craftsmen money can buy, plus are following the most prudent building practices and are equipped with the most sophisticated and time-tested toolkits, you still won't get very far if the architectural blueprints for the house are faulty (e.g. the angles are all wrong, the specified lengths are incorrect, etc.)

    This is what's happening today in the world of software development. Those blueprints are totally off, completely useless. Someone comes up with a half baked, half assed idea for a software product, hires a bunch of highly paid professionals, watches his project go down the tube, and then blames those professionals for their incompetence. All along, the only thing to blame was his Mickey Mouseish half baked blueprint for the product. But, no one ever stops to consider this simple truth.

    That's why I pay most attention to what I call "Quality before design' principle. Even before we even begin to contemplate the design, we must be sure that we have a quality idea, a precisely described quality product on our hands. It is then, and only then, that it makes any sense to start working on the design of the product. And only once we're clear on the design, does it make any sense to start coding it, implementing it.

    Any other approach is a recipe for disaster, as is amply demonstrated worldwide with countless failed or barely functional software products.

    Now, how many people do you know who adhere to this approach? Zero, right? There's your description of the problem. Until we solve it, software in general will continue to be lame and useless.

    So, simulated apps are all fine and dandy, but you've gotta ask yourself a question: what is it we're simulating? If we're attempting to simulate some lame, half baked idea, we'll invariably end up with a weak, flakey product. The jist of the problem is that people don't have crystal clear ideas. This being so, what we need to work the hardest on is how to articulate the ideas.

    Alex
  65. Best tools currently for RAD?[ Go to top ]

    It seems we share the same views on this subject. I'd be interested to know

    > >what RAD tools right now you're using, or have played around with, that fulfill
    > >this vision, including non-J2EE tools.
    >
    > Michael,
    >
    > At this point, I don't think the problem lies in the toolset we're using. Sure, right toolset for the right job is mandatory, but what good is the right toolkit if the master plan is wacky?
    >
    > In other words, if you're building a house, and are using the most skilled builders and craftsmen money can buy, plus are following the most prudent building practices and are equipped with the most sophisticated and time-tested toolkits, you still won't get very far if the architectural blueprints for the house are faulty (e.g. the angles are all wrong, the specified lengths are incorrect, etc.)
    >
    > This is what's happening today in the world of software development. Those blueprints are totally off, completely useless. Someone comes up with a half baked, half assed idea for a software product, hires a bunch of highly paid professionals, watches his project go down the tube, and then blames those professionals for their incompetence. All along, the only thing to blame was his Mickey Mouseish half baked blueprint for the product. But, no one ever stops to consider this simple truth.
    >
    > That's why I pay most attention to what I call "Quality before design' principle. Even before we even begin to contemplate the design, we must be sure that we have a quality idea, a precisely described quality product on our hands. It is then, and only then, that it makes any sense to start working on the design of the product. And only once we're clear on the design, does it make any sense to start coding it, implementing it.
    >
    > Any other approach is a recipe for disaster, as is amply demonstrated worldwide with countless failed or barely functional software products.
    >
    > Now, how many people do you know who adhere to this approach? Zero, right? There's your description of the problem. Until we solve it, software in general will continue to be lame and useless.
    >
    > So, simulated apps are all fine and dandy, but you've gotta ask yourself a question: what is it we're simulating? If we're attempting to simulate some lame, half baked idea, we'll invariably end up with a weak, flakey product. The jist of the problem is that people don't have crystal clear ideas. This being so, what we need to work the hardest on is how to articulate the ideas.
    >
    > Alex

    I agree about running off and building before you know exactly what the product should be. I think though that might just be human nature taking over. Having a structured methodology (RUP?) and using it correctly, should in theory, eliviate alot of this. The reason these methodologies don't help in many cases, I guess, is not the medthodology but human weakness.

    I guess what struck me about the app simulator is that a larger part of the actual software design could be done by business-types, and it could be done reasonably well (ie. developer wouldn't have to rework what they did), and it would be fast. The more involved the people are who actually understand the business requirements of an application, the less likely gaps are to occur.

    Mike
  66. Best tools currently for RAD?[ Go to top ]

    I guess what struck me about the app simulator is that a larger part of the

    >actual software design could be done by business-types, and it could be done
    >reasonably well (ie. developer wouldn't have to rework what they did), and it
    >would be fast. The more involved the people are who actually understand the
    >business requirements of an application, the less likely gaps are to occur.

    The only problem I see with this approach would be the inexperience of the lay software 'developers'. Most users out in the trenches have been abused by lousy software for many, many years. Consequently, their horizon is very limited, which means that they are capable of envisioning only so much. Plus, they are bound to repeat the same mistakes that they've been conditioned to by using lousy software. For example, we all know by now that throwing a dialog box at the end user is a big No-No, because it is akin to giving the users jolts of electric currents each time we need to inform them of something. So we, as developers, will abstain from doing that. However, end-users, who have been subjected to this electro-shock 'therapy' for many years now, think that that's the only way to go, so they'll build countless dialog boxes into their simulated solution.

    Of course, the above is just a small example of what could go wrong if we let end users design an application. Many other horrible things may happen if we bypass experts and go straight to the end user and ask him what is it that he wants. That's why I think the extreme programming approach stands very little chance of delivering succesful products, because it has the end user too tightly involved in the loop. And end users generally know very little about what is it that will make an application function successfully.

    >The reason these methodologies don't help in many cases, I guess, is not the
    >medthodology but human weakness.

    You are right, but the real question is do we really need methodology? Often times common sense will suffice. Understanding the objectives, and understanding the goals of the end users is sometimes the only thing that really matters. And in order to grasp these things, we really don't need any methodology.

    Alex
  67. Best tools currently for RAD?[ Go to top ]

    <quote>
    That's why I pay most attention to what I call "Quality before design' principle. Even before we even begin to contemplate the design, we must be sure that we have a quality idea, a precisely described quality product on our hands. It is then, and only then, that it makes any sense to start working on the design of the product. And only once we're clear on the design, does it make any sense to start coding it, implementing it.
    </quote>

    Completely agree. The first problem I encountered is that I work in a team and management is not that particularly interested in trying something like iRise to verify their ideas. They don't question quality of their ideas. In fact, it costs me nerves and headaches just to demonstrate them that certain ideas cannot be implemented or does not make sense. The second problem is that product/project objectives are changed 4 month after the development start by same management despite my warnings to think as much as possible from the beginning. Obviously, we don't need a lot of magic to have successful products but do need the magic of careful planning, requirement analysis and producing "crystal clear ideas".

    Valeri
  68. Best tools currently for RAD?[ Go to top ]

    That's why I pay most attention to what I call "Quality before design' principle. Even before we even begin to contemplate the design, we must be sure that we have a quality idea, a precisely described quality product on our hands.

    This is known as 'business analysis'. It can be done on a white board or with tools of varied sophistication.

    So, simulated apps are all fine and dandy, but you've gotta ask yourself a question: what is it we're simulating?

    Conversely one could insist on simulation as just another mandatory phase of the development process, somewhere between analysis and implementation.

    If we're attempting to simulate some lame, half baked idea, we'll invariably end up with a weak, flakey product. The jist of the problem is that people don't have crystal clear ideas.

    That's precisely why simulation is so valuable. It lowers the cost of validating ideas. This enables two crucial aspects of RAD as follows. As the product vision gradually unfolds and requirements evolve, simulation makes it easier to sanitize newly identified features. And simulation encourages feature speculation by minimizing the loss-of-work cost of abandoning a tentative feature.

    Of course simulation and business analysis are best managed with MDA.
  69. Best tools currently for RAD?[ Go to top ]

    That's precisely why simulation is so valuable. It lowers the cost of

    >validating ideas. This enables two crucial aspects of RAD as follows. As the
    >product vision gradually unfolds and requirements evolve, simulation makes it
    >easier to sanitize newly identified features. And simulation encourages feature
    >speculation by minimizing the loss-of-work cost of abandoning a tentative
    >feature.

    This is too narrowly focused, in my opinion. The business analysis must be performed outside of the software domain. The business case has nothing to do with software. Stakeholders need to agree on what the business should pursue, and on how should the business pursue its goals. Still nothing to do with software.

    Typically, once the business goals are crystalized (and I'm pretty sure you cannot crystalize them by using some software development simulation), the most prominent players will emerge. These players will be the ones who will conduct the business (i.e. customer support personnel, sales clerks, shipping and receiving, accounting, HR, payroll, you name it). These players must work harmoniously with each other, in order to realize common business goals. Work out the work flow, the logistics, the processes. Still nothing to do with software.

    Now, at a certain point we come to the conclusion that these players might need some tools to support them in their daily work. And we may reach the conclusion that it would be useful to give them some software based tools.

    This is the point where software team gets to be called in. Until we reach this point, it is meaningless to call the software guys in.

    Software architect will take the directions from the stakeholders and will try to understand the objectives of the business. Then, the architect will work on understanding the goals of the identified players. Once those goals have been identified, the architect will articulate them (like, "a shipping clerk needs to process at least 5,000 orders per day", or something like that). Knowing these goals, the architect will start thinking about the software based solution that will support the players and enable them to reach stated goals.

    Software architect will not mobilize software developers until a high quality blueprint of the product has been established. Goals need to be identified, documented, and solutions articulated. All this, of course, happens at the conceptual level, meaning we still have no need for any software development simulation platform at this point.

    When articulating the solution, the Quality before design team will focus on serving the goals of the key players. If they are elaborating on the solution for the mail order receiving department, for example, they will focus on understanding the most prominent goals of the receiver's day-to-day job. What's his threshold of tolerance when it comes to creating the order backlogs due to the unforeseen increased volumes? Does the system need to be mildly fudgeable to allow for slight, but nevertheless inevitable holdups in the whole workflow? All such concerns go into forming the optimal solution that will make receiver's job easier and more tolerable, not harder and more miserable.

    Only once all of the identified goals have been conceptually addressed and articulated, do we proceed with designing the software solution. This solution will be driven entirely along the goals/solutions axis. No consideration will be given to serving the underlying computing machinery at this point (remember, 'premature optimization is the root of all evil').

    The intention is to deliver a system that will fully serve key players within the organization (or, key customers outside the organization), by fully supporting them in fulfilling their most pressing goals. The rationale is that no one wants to use a piece of software unless it is doing something extremely useful for them. Unlike people, software is tireless and doesn't take lunch breaks, coffee breaks, sick leaves and vacations. Thus, it must be employed to work tirelessly towards the good of its masters (i.e. human players).

    Experience has shown that if we manage to identify all the important goals of the players who will be using the system, and if we manage to deliver the solution that will fully support those goals, the system we deliver will be accepted at the face value. Meaning, no more seemingly endless "oh, actually this is quite nice, but it's not really what we had in mind; could you please go back and change it along these vague lines?" The maintenance of a system whose main focus is fulfilling the goals of the key users is thus minimized. Very little needs to be added or changed once we manage to fully and selflessly support the users in their daily work.

    As I've mentioned elsewhere, the lifespan of such systems will depend on the inner dynamics of the business. As the business evolves and changes, there comes a time when the practices identified during the previous business analysis stage do not apply anymore. It never happens overnight, but it can occur after just a couple of years, most likely after a span of 5 to 10 years. At that point, it is more prudent to go to square one and do the entire process from top to bottom, instead of trying to stretch the existing solution to fit the new needs.

    Alex
  70. Best tools currently for RAD?[ Go to top ]

    Only once all of the identified goals have been conceptually addressed and articulated, do we proceed with designing the software solution. ... Software architect will not mobilize software developers until a high quality blueprint of the product has been established.

    Congratulations. You well describe the waterfall method, which was invalidated a decade ago. Iteration, RAD, and XP have long since proven more effective. The reality is that subject matter experts typicly don't now how to specify a product by themselves. They don't explore possibilities, they forget details, they balance their engineering discourse with other unrelated work. Their vision emerges slowly, usually only after iterations with a prototype nudges further consideration. Only agile process accomodates this.

    Meaning, no more seemingly endless "oh, actually this is quite nice, but it's not really what we had in mind; could you please go back and change it along these vague lines?" The maintenance of a system whose main focus is fulfilling the goals of the key users is thus minimized. Very little needs to be added or changed once we manage to fully and selflessly support the users in their daily work.

    Still more fantasy. Requirements change, and there are two approaches to managing this. One is painstakingly-designed flexible code that allows for evolutionary reuse. That's the approach I've been bashing in this thread. The other approach is cheap code, which minimizes the cost of lost work, so that artifacts can be readily scrapped and replaced. This is what RAD, XP, and MDA enable. Since one never knows which part will be scrapped, all code should be written as throw-away code. That's my unique insight. Only someone with the unholy clairvoyance to predict the final requirements could do better.
  71. Best tools currently for RAD?[ Go to top ]

    Congratulations. You well describe the waterfall method, which was invalidated

    >a decade ago. Iteration, RAD, and XP have long since proven more effective.

    It seems like it's incredibly difficult for software engineers to grasp the fact that there are processes outside of the hard core engineering. What I was talking about has nothing to do with the waterfall methodology, nor with RAD and XP. I was discussing things that need to happen before we even get to the point of considering whether to use XP or RUP.

    Apparently, you haven't got a clue what I'm talking about. Try and leave the boxed world you're in right now, and look around a bit. Many things happen that are not concerned with XP and RUP, same as XP and RUP may not be concerned with the actual programming language or the underlying platform. I'm talking about things that are important before the software development commences, not once it commences.

    >Still more fantasy. Requirements change, and there are two approaches to
    >managing this.

    False. Requirements don't change. Requirements always stay the same, up until the moment when the business strategy changes (which, in reality, is not that often).

    What actually changes throughout the software development cycle is our understanding of the real requirements. We typically start with a very vague, very nebulous understanding of the requirements. We then develop some half-baked product, which invariably gets flatly rejected by the customer. We try again, armed with the additional knowledge of what was it that the customer didn't like about our solution. Then, we deliver the next iteration, only to be rejected again. And on and on, the ever diminishing circling starts unfolding, and we're proud of our smart achievements. Meanwhile, the customer gets shortchanged.

    But, if you look at it, it really is stupid. Instead of throwing these ever diminishing circles at the customer, why don't we set aside the time to really figure out customer's requirements? In other words, don't start any design and development until we're absolutely sure we understand what is it that the customer really needs/wants.

    Once we understand this, we'll find ourselves in a very stable world. Customer's needs/wants don't change. In the example I've used earlier, if the customer needs to cut 5,000 paycheques every week, that requirement is fairly stable. It's not like one day the customer will show up at work and realize that he now must cut 5 milion paycheques!

    So if we clarify the real requirements, and deliver the solution, we'll discover that the maintenance miraculously ceases to be a big issue (other than fixing inevitable bugs, of course).

    Alex
  72. Best tools currently for RAD?[ Go to top ]

    I was discussing things that need to happen before we even get to the point of considering whether to use XP or RUP.

    Yes, I got that. But to make things more clear for me, please tell me which of the following in your opinion are "things that need to happen before" engaging engineers: requirements gathering, knowledge transfer, requirments analysis. I believe that engineers can become excellent business analysts, and that these engineers should be engaged ab initio on all three of the points I just listed.

    What actually changes throughout the software development cycle is our understanding of the real requirements.

    Such an assertion might just be metaphysical gassing. When you say "our understanding", are you refering to that of engineers or subject matter experts such as users?

    We typically start with a very vague, very nebulous understanding of the requirements.

    At this supposedly typical start, has requirements gathering already occured?

    We then develop some half-baked product, which invariably gets flatly rejected by the customer. We try again, armed with the additional knowledge of what was it that the customer didn't like about our solution. Then, we deliver the next iteration, only to be rejected again. And on and on, the ever diminishing circling starts unfolding, and we're proud of our smart achievements. Meanwhile, the customer gets shortchanged.

    A reasonable complaint. It isn't often that I encounter an articulate criticism of RAD, and I appreciate yours. I'd also like to know more about how you might avoid this in practice. Like hey dude, what's your praxis?

    Instead of throwing these ever diminishing circles at the customer, why don't we set aside the time to really figure out customer's requirements?

    I only go a few rounds with subject matter experts. I can only stand so many knowledge transfer sessions before I burn out. So of course I get it over with as expediently as possible by initially interviewing a subject matter expert intensely. That's the first thing I do when applying RAD. So now I'm not so sure you're actually criticizing RAD. It seems more like you're generally denouncing haphazard requirements gathering.
  73. Best tools currently for RAD?[ Go to top ]

    Yes, I got that. But to make things more clear for me, please tell me which of

    >the following in your opinion are "things that need to happen before" engaging
    >engineers: requirements gathering, knowledge transfer, requirments analysis. I
    >believe that engineers can become excellent business analysts, and that these
    >engineers should be engaged ab initio on all three of the points I just listed.

    What I'm talking about is the 'low tech' phase of working on providing the solution. You seem to be confined only to the 'high tech' phase, which comes later.

    'High tech' phase is losing its supremacy as we speak. It used to be very domineering, to the point of dictating the overall solution (c.f. SAP's arrogant dictum that businesses must change their time honored practices in order to accommodate the high tech solution offered by the SAP engineers). In the future, we can only expect 'high tech' to decrease in its significance even more. Part of the reason for that is the phenomenal success of technologies like Java, which managed to diminish the importance of the underlying computing platform. The focus is rapidly shifting from implementation to conceptual solutions. And conceptual solutions are decidedly 'low tech' (requiring only 'wetware').

    Here is how things usually go in my world:

    1. Business stakeholders identify there is a problem.

    2. Stakeholders perform the feasibility study -- is it cheaper to learn to live with the problem, or is it cheaper to solve the problem?

    3. If the conclusion is that it would be cheaper to learn to live with the problem, there is no more action required, and everything goes back to business as usual.

    4. If the conclusion is that the business cannot afford to ignore the problem, the request for the solution is launched.

    5. Business analysis gets performed (due dilligence), the bottlenecks get identified, and the solution gets proposed.

    6. The proposed solution may or may not involve software; maybe hiring more people, or leasing more office space would be enough to solve the problem; maybe simply restructuring and realigning operational processes is good enough, etc.

    7. We may reach a point, however, where software solution is also required; if that happens, software architect (that would be myself) gets summoned.

    8. The architect works with business analysts to determine key players that are delivering the solutions.

    9. The architect then works on determining the goals of these key players.

    10. Those goals get translated into the most prominent mental pictures that key players are using in their day to day jobs. For example, a payroll clerk mostly works with a mental image of a paycheque, etc.

    11. Following that analysis, the architect launches into the quick iterative low tech prototype building. No software concepts are involved. Everything is pretty much paper and pencil, or flipchart and crayons, or whiteboard and erasable markers.

    12. The architect arrives at the low tech solution focusing on two archetypes -- the centerstage metaphor, and the prototypical user.

    13. The prototypical user (i.e. 'persona') gets profiled rather exhaustivelly; we give him/her real name, age, income bracket, character traits, etc. We also identify that hypothetical user's personal, professional, and corporate goals. This practice helps us stay on track later on.

    14. Using the prototypical user, we now embark upon designing the solution that will be strictly focused on serving that person's needs and supporting him/her in achieving the identified goals.

    15. Keeping an eye on the identified goals, we elaborate by producing use case scenarios (low tech, paper and pen only, or typing it into the word processing editor).

    16. The designed solution may or may not depend on a particular technology (such as the request/response architecture, or the client/server architecture, or the mobile devices, or the character-based monolithic architecture, and so on).

    17. Once the underlying technological architecture is settled, we embark upon design. The architect may or may not be full time involved in designing the high tech solution.

    18. The UML diagrams get handed to the development team, who start building the codebase any way they find fit (using RAD, or RUP, or XP, I don't really care).

    >Such an assertion might just be metaphysical gassing. When you say "our
    >understanding", are you refering to that of engineers or subject matter experts
    >such as users?

    I'm referring to the understanding of the people involved in providing the solution. Sometimes the situation can be extremely grotesque, as in end users coming to us and telling us that to solve their problem they would need a database with three tables with the following primary and foreign keys, and so on. They then expect us to build exactly to their specifications. But, they are no experts, and they are not paid to tell us how to do our jobs, same as we're not paid to tell them how to do their jobs. We will deliver the solution, but the internal working of that solution is no one else's busness, really.

    Software product is by nature very nebulous. No one sees its shape and its edges clearly, as it is intangible. Grab any three people working on the same software project, interview them asking what is this product they're building all about, and you'll no doubt receive three completely different answers. Everyone tends to form a different picture about what is it they are actually doing when building a software product.

    This is actually a huge problem. This problem leads to disfunctional products. Our practices are focused on clearing this confusion. Before we start building, everyone involved must understand perfectly clearly what is it we are building. And the only way to achieve such understanding is to be clear on how is the behavior of that software product going to serve our end users' goals. Everything else is of secondary importance.

    So, what are those much touted end user's goals? It largely depends on the context, of course, but there are certain invariants, such as:

    1. Every human user invariably has the goal to be treated with respect. If a software product is being disrespectful to the human user, it will be perceived as a failure, and will not be used.

    2. Every human user invariably has the goal of not being put on the spot when doing his/her job. If the software product puts the end user on the spot, and thus exposes end user's inadequacy, it will be rejected. So, every human has the goal of not feeling inadequate.

    3. Every human user has the goal of accomplishing as much as is possible in the alotted time with the least amount of effort. If the software product is standing in the way of achieving that goal, it will be rejected.

    And so on, to cut the long story short, I should say that we always religiously keep our attention focused on the above goals. Any feature of the product we're building that tends to violate any of these goals gets to be rejected right away. Only features that support these goals are allowed to creep into our product.

    For example, if someone comes up with a brilliant idea to throw a wizard into the product, in order to guide the user along some perilous path, we will examine and scrutinize the wizard from the viewpoint of the end users' goals: is the wizard's behavior being disrespectful towards the user? Is the wizard's behavior making the user feel inadequate in any way? Is the wizard's behavior slowing the user down, forcing him/her to spend more time than necessary on accomplishing the task? And so on.

    If the answer to any of these qestions is yes, then the wizard is unanimously thrown into the shredding bin.

    Same consideration is being lavished upon any dialog box, any form thrown at the end user. Only those that show nothing but utmost respect for the end user, and never put the user on the spot, never force the users to all of a sudden become experts, are being adopted. A feature of the software product's behavior that expedites users' jobs while maintaining full respect can qualify as a candidate to be included in the final product. Anything less than that is history.

    >At this supposedly typical start, has requirements gathering already occured?

    Yes. Despite the fact that the due dilligence in collecting requirements has been performed, many software development teams still have only nebulous understanding about what is it they are actually required to build.

    For example (this is just a hypothetical example, offered in the form of an analogy), the requirements experts may come back to the team and tell them that they need to build a product that will have a steering wheel, four wheels with rubber tires, internal combustion engine, a gas pedal, and a brake pedal. Sounds concrete and specific enough, doesn't it? Sounds like the requirements gatherers did a great job at nailing the real requirements.

    But, how clear are the designers and builders at that point? What are they going to design and build? When I offer this example to my class, they usually say that they are going to build a car, or a truck, or a bus, or a tractor, and so on.

    So you see, the requirements invariably end up being vague, even nebulous.

    Instead of collecting requirements in the form of a list of features, it's much better to collect them as a list of goals. In the above example, the requirements focused on the goals would morph into something like this:

    Cut grass while sitting comfortably.

    Right away, we understand that we are talking about the ride lawn mower! How was this magic transition possible? Simply, by shifting our attention from the feature list to the goals list. Now, the team knows exactly what to build, and their product will be accepted right off the bat. No more itertive dwindling with the customer. And, more importantly, no more endless maintenance ightmares.

    >A reasonable complaint. It isn't often that I encounter an articulate criticism
    >of RAD, and I appreciate yours. I'd also like to know more about how you might
    >avoid this in practice. Like hey dude, what's your praxis?

    My praxis is to recognize that software products only exist in order to support the jobs of human users. Human users do not exist in order to support the functioning of software products, no matter how ingenious and elegant those products may be.

    No one in their right mind ever uses a software product just for the heck of it. Any time anyone operates a software product she's doing it because she has an immediate and pressing goal to fulfill. If the product she's using is standing in the way of fulfilling her goal, then that product is a failure. The end user will complain about product's behavior, and will explain that that's not what she had in mind.

    Even if the delivered product does everything perfectly from the functional point, and really supports user's job, but fails to treat the user with respect, and furthermore tends to make the user feel inadequate, that product will be proclaimed as failure.

    This is what actually mystifies software engineers. They know that their product works like a charm, and yet they see that the end users are rejecting it, saying that it's not what they had in mind. How infuriating! What software engineers fail to comprehend is the human dimansion of the interaction, how humans demand to be treated with respect and not to be put on the spot.

    This is why there are software architects (like myself), who are gainfully employed. In order to turn software development into a success, we need people who are sensitive to how end users interact with the technology. Engineers don't know that, nor how to achieve that (and frankly, they couldn't care less). Engineers specialize in how to serve the underlying technology. Technology is their dark master, and they bow before it (some of them even prostrate before the technology).

    End users, on the other hand, feel extremely uncomfortable being slaves to the technology. They want technology to be their slave. That's my job -- to ensure that we deliver a personal slave in the form of a software product. This slave is faithful, loyal, tireless (no coffee breaks, no washroom breaks, no sick leaves, no problems with spouses and kids, and so on).

    >I only go a few rounds with subject matter experts. I can only stand so many
    >knowledge transfer sessions before I burn out. So of course I get it over with
    >as expediently as possible by initially interviewing a subject matter expert
    >intensely. That's the first thing I do when applying RAD. So now I'm not so
    >sure you're actually criticizing RAD. It seems more like you're generally
    >denouncing haphazard requirements gathering.

    Yes. I implore you to allow the human component to enter the picture. You'll immediatelly reap thousandfold rewards. Your users/customers will fall in love with you. Your maintenance efforts will get decimated. I've been through all this, and I'll never look back.

    Alex
  74. Best tools currently for RAD?[ Go to top ]

    I agree - it is not so much that requirements change but that the requirements begin to clarify as a project progresses.
    Fleshing out all the requirements at the beginning of a project is a noble goal and needs to be attempted but will never be accomplished.
    The dreaded "analysis paralysis" sets in. I think the power of iteration is accepting that the initial views of the requirements are myopic. As a project progresses, we will have to update requirements, design and code.

    Projects need to be planned and managed based on this fact.
    Good designs facilitate iterative development.
    Test Driven Development facilitates code rework.
  75. Best tools currently for RAD?[ Go to top ]

    I agree - it is not so much that requirements change but that the requirements

    >begin to clarify as a project progresses.

    This is a major milestone. We've reached a point where people are starting to slowly realize that requirements don't change! What a concept! Right on.

    >Fleshing out all the requirements at the beginning of a project is a noble goal >and needs to be attempted but will never be accomplished.

    Why do you say this? What makes you think that it is impossible to understand requirements at the beginning?

    >The dreaded "analysis paralysis" sets in. I think the power of iteration is
    >accepting that the initial views of the requirements are myopic. As a project
    >progresses, we will have to update requirements, design and code.

    How about the dreaded "iteration paralysis"? Ever been involved in that one?

    >Projects need to be planned and managed based on this fact.
    >Good designs facilitate iterative development.
    >Test Driven Development facilitates code rework.

    Sounds like a well learned lesson (by rote). Who taught you that lesson? Whose mantra are you repeating here?

    All these things you've mentioned here are just another myth. Don't be such an easy prey for the hype-mongers. Many people in this industry are making their living by putting spin on things that really don't need any spin. All you need to be successful in building software is common sense. And everyone has common sense, so it's a bargain. But then, how will the snake oil salespeople make their living?

    My advice to you would be to stick to your realization that requirements seldom change, and see where it takes you. Forget about iterative development and the rest of the hype. Just focus on capturing the requirements, and keep in mind that it's a low-tech process (you don't need computers nor software to capture the requirements). Usually, all you would need to gather requirements is a paper pad and a pencil -- can't get any more low-tech than that, right?

    Oh, and don't let the customers force you into talking any computer lingo -- no databases, tables, keys, servers, web pages, browsers, sessions, keyboards, mouses, screens and such should ever be mentioned during the requirements gathering phase. Only talk in business lingo. What are their goals? Forget about how are those goals to be fulfilled.

    Alex
  76. Best tools currently for RAD?[ Go to top ]

    What makes you think that it is impossible to understand requirements at the beginning?

    There are two reasons why an engineer would have a fuzzy understanding of requirements:

    1) The requirements might not be formally expressed unambiguously. For example, RUP doesn't specify a requirements language. Natural language can be ambiguous.

    2) An imperfect human can only accurately describe a business process which he has personally used. By definition Business Process Reengineering (BPR) entails the creation of processing that is new to the audience. So BPR requirements are necessarily speculative. Iteration is a proven way to sanitize flawed requirements.

    How about the dreaded "iteration paralysis"? Ever been involved in that one?

    I've contributed to a few dysfuntional projects, but never one so bad that iteration didn't show progress.
  77. Best tools currently for RAD?[ Go to top ]

    There are two reasons why an engineer would have a fuzzy understanding of

    >requirements:

    I will venture out here and propose, in the spirit of thinking outside of the box (just for a minute), that it is a myth that engineers need to be the ones who would gather the requirements. Engineers' job is to provide a solution for the requirements, not to gather them.

    >1) The requirements might not be formally expressed unambiguously. For example,
    >RUP doesn't specify a requirements language. Natural language can be ambiguous.

    This is true if we treat natural language as a medium that needs to be translated into the formal language. But that's not the case here. Natural language, with all its ambiguousness, is used to express the goals that the application will help achieve.

    Once the goals have been identified, the designers/engineers can work on the most optimal ways to support those goals.

    >2) An imperfect human can only accurately describe a business process which he
    >has personally used. By definition Business Process Reengineering (BPR) entails
    >the creation of processing that is new to the audience. So BPR requirements are
    >necessarily speculative.

    This is another myth. We need not worry about business processes. We only have to worry about identifying the goals, and delivering a solution that will help fulfill those goals. If we manage to do that, our application will be deemed success, even if we know nothing about the business processes involved.

    >Iteration is a proven way to sanitize flawed requirements.

    This is absolutely correct. However, we need to clarify which iteration are we talking about. I'm saying that the iteration is absolutely necessary, but not at the coding level. Experience had shown that the most expensive iterative processes are related to the coding activity. What I'm proposing is that we iterate mercilessly in the pre-coding stages. It is way cheaper to iterate on paper, or on a whiteboard, than using an EDI or a source code editor.

    Alex
  78. Brian: There are two reasons why an engineer would have a fuzzy understanding of requirements...

    Alex: I will venture out here and propose, in the spirit of thinking outside of the box (just for a minute), that it is a myth that engineers need to be the ones who would gather the requirements.

    Strawman. That myth hadn't been touted in this thread.

    This is true if we treat natural language as a medium that needs to be translated into the formal language. But that's not the case here.

    Bzzt. Wrong. If novel software is needed, then natural language reguirements must ultimately be implemented by a formal programming language. There's no way to create software without a formal language.

    We only have to worry about identifying the goals, and delivering a solution that will help fulfill those goals. If we manage to do that, our application will be deemed success, even if we know nothing about the business processes involved.

    That's absurd. Ignorance of a business is necessarily an obstacle to business evolution. It takes experience to evolve.
  79. We only have to worry about identifying the goals, and delivering a solution

    >>that will help fulfill those goals. If we manage to do that, our application
    >>will be deemed success, even if we know nothing about the business processes
    >>involved.
    >
    >That's absurd. Ignorance of a business is necessarily an obstacle to business
    >evolution. It takes experience to evolve.

    You seem to be confusing business evolution with attempts to solve some of the business problems. We, as solution providers, are not driving the business. Business evolution does not depend on whether software developers understand or don't understand the business.

    It is possible to identify and understand business goals without understanding business processes. If, for example, a business goal is identified as the need to increase the upsell volumes when closing the sale, I need not really understand the underlying business process (whose complexity may be daunting). All I need to know is what are the goals of the sales person using my software solution when selling a product.

    Alex
  80. You seem to be confusing business evolution with attempts to solve some of the business problems.

    The introduction of new software is itself a form of business evolution. So requirements gathering and requirements analysis occur within the context of evolution.

    Business evolution does not depend on whether software developers understand or don't understand the business.

    Agreed. But requirements gathering and requirements analysis suffer when performed by someone who doesn't understand the business. Developers often aren't included in requirements gathering, but developers usually do participate in requirements analysis.

    It is possible to identify and understand business goals without understanding business processes.

    Yes. That's what an investor is expected to do. Eg, I can wisely invest in Intel by only knowing Intel's business goals and not knowing Intel's internal operations. But innovation requires more awareness than is expected of an investor, though you make it seem otherwise.
  81. Best tools currently for RAD?[ Go to top ]

    I believe the argument of whether requirements actually change or if they never do (and our understanding does) is not overly important here. Maybe they never change. But, for large, complex projects, I would say the likelyhood that developers can come away from a few meetings with BAs/SMEs and fully understand the requirements at around 0%.

    I've been a part of several large projects and this has never failed to be the case. And it's nobody's fault. It's just very difficult to transfer that knowledge. Assumptions are made that prove to later be incorrect, etc. and apps turn out to be far less than perfect. I do agree that some new-age development mantras tend to be over-hyped. One example is TDD. I think TDD can be a very, very good thing- to a point. But in its extreme, can also slow things down quite a bit uneccessarily.

    But one thing that I am sure is of vital importance is adopting an iterative development cycle, for all the reasons explained above. Given that we can never fully grasp the requirements, it's better to flush out those mistakes early rather than build some monstrosity the business users hate and will soon ditch.

    I guess Alex, where you, and Brian and I, fundamentally disagree is that you feel everything can and should be crystal clear before any code is written. I just don't believe this is or will every be possible and I venture many share that belief.

    So, what I think we need are better tools to help bridge the gap between business/developers. UML fits nicely here, but the more I ponder this, the more I become convinced that tools like application simulators will become an important part of the SDLC in the future. The larger role that the business community(who actually will use the software) play in it's design and construction, the happier everyone will be.

    Mike
  82. Best tools currently for RAD?[ Go to top ]

    But, for large, complex projects, I would say the likelyhood that developers

    >can come away from a few meetings with BAs/SMEs and fully understand the
    >requirements at around 0%.

    That's because it's not developers' job to gather the requirements. The requirements gathering (the 'Quality before design' practice) is the job of the architect. The developers are not qualified to know which questions to ask, period.

    >I've been a part of several large projects and this has never failed to be the
    >case. And it's nobody's fault. It's just very difficult to transfer that
    >knowledge. Assumptions are made that prove to later be incorrect, etc. and apps
    >turn out to be far less than perfect.

    That was all due to the fact that you didn't have a qualified professional for the job on the team (I suspect you didn't have a fully qualified architect leading the project). Attempting the knowledge transfer is the first mistake. The knowledge doesn't have to be transferred. Software people need not become domain experts. Software people are not superhumans, and they cannot become experts in the area of software development, plus in many other areas.

    There is also no need to make assumptions. Like I've said many times already, all you need to do is make sure you identify the goals, and then deliver the solutions that will enable users to achieve those goals. That's all.

    >But one thing that I am sure is of vital importance is adopting an iterative
    >development cycle, for all the reasons explained above. Given that we can never
    >fully grasp the requirements, it's better to flush out those mistakes early
    >rather than build some monstrosity the business users hate and will soon ditch.

    Yes, but how early? You're talking about flushing out mistakes made in the coding phase. I think it's the least productive, least efficient way to go. Once we hit the coding phase, things become exorbitantly expensive. It is much better to iterate during the requirements gathering phase. These iterations are low-tech, do not involve developers, and are kept at the conceptual level. Mistakes can be easily identified and easily fixed, because everything is still on paper. It is quicker, cheaper, and less humiliating than coding and recording till the cows come home.

    >I guess Alex, where you, and Brian and I, fundamentally disagree is that you
    >feel everything can and should be crystal clear before any code is written. I
    >just don't believe this is or will every be possible and I venture many share
    >that belief.

    You're correct. The myth is widespread, and we've all been conditioned by many years of faulty software development practices to think how it is impossible to clarify what is it that the application is supposed t obe doing. But, all I'm saying is that this sentiment is wrong. All it takes is shifting our focus from code (implementation) to goals (intentions), and everything will become much clearer.

    >So, what I think we need are better tools to help bridge the gap between
    >business/developers.

    No, what we need is better experts to help bridge the gap between business/developers. The tools are only as good as the people using them. If the people don't really know what they're doing, the tools will only help them produce confused products faster than if they're doing it manually.

    Alex
  83. Best tools currently for RAD?[ Go to top ]

    Alex,
    I agree that your statement concerning requirements not changing but clarifying seems original and my verbage is right out chapter one of the RUP manual. I am however, a true believer in iterative, component-based development.
    For example, I am developing a software product for a start-up company, in a new industry, with no real subject-matter experts. This system will deploy on a new platform and will be implemented using the latest programming technology.
    The company business will be based on this system I am developing butI cannot start design and code until I solidify the requirements.
    I must produce a system that will allow the company to begin to conduct business, and for industry, market and system domain knowledge to grow. As this knowledge grows - the true requirements will begin to emerge. Hopefully we have designed our the product to accomidate these changes and haven't burned up all of our resources during start-up chasing information that just didn't exist.
  84. Best tools currently for RAD?[ Go to top ]

    I must produce a system that will allow the company to begin to conduct

    >business, and for industry, market and system domain knowledge to grow. As this
    >knowledge grows - the true requirements will begin to emerge. Hopefully we have
    >designed our the product to accomidate these changes and haven't burned up all
    >of our resources during start-up chasing information that just didn't exist.

    Mike,

    Your scenario is a very rare one indeed. I don't think we can generalize based on the constraints you've outlined above.

    Alex
  85. Business platform[ Go to top ]

    The lifetime of apps is WAY longer than 6-8 years.

    If you'd written Petstore 10 years ago, the best you could do was write CGI perl scripts. No matter how much extra effort you spent architecting for evolutionary reuse, today 10 years later all you'd have is an ugly pile. No one would want to consider your stuff. Windows 3.1 with 16 bit near pointers is about 10 years old. Many of the reusability snobs were writing OS/2 code back then, an operating system that doesn't exist now and that didn't last 10 years.

    When software methodology emerged in the late 1970s and stumbled through the 1980s and 1990s, there were methodology gurus that didn't know how to reduce time-to-market or initial-implementation defects. Those are quantifiable metrics that any charlatan would avoid. Instead they distracted their crowd with less important and less verifiable metrics -- things like reusability -- things that couldn't be disproven until they were paid and gone. A worthy expert expects judgement at the first release, since the the dot-com market doesn't give second chances. And we all know an unemployed developer or manager.
  86. Business platform[ Go to top ]

    What I'm wondering is what percentage of J2EE applications really need to be >distributed?


    No one today would have a computer with out a network card. However, here we have a suggestion that apps don't need/benefit from the network?
    How Ludacris!!
  87. Business platform[ Go to top ]

    What I'm wondering is what percentage of J2EE applications really need to be >distributed?

    >
    > No one today would have a computer with out a network card. However, here we have a suggestion that apps don't need/benefit from the network?
    > How Ludacris!!

    What I and the previous poster were referring to as 'distributed' are those apps where the J2EE components are distributed vs. colocated within the same server. It's assumed that the db is somewhere else but the question is how many J2EE apps truly need to have distributed J2EE components. If you can colocate the application then the incentive to throw in EJB is not very strong. And where things need to be distributed, isn't there a decent chance that web services will fit the bill?
  88. Business platform[ Go to top ]

    Bottom line -- we're back at square one. Only, this time we have a much, much more complex thing on our hands. So, everyone loses.

    >
    > So, how do we solve this conundrum? Tune in for the next installment, where I'll outline the way out of this misery.
    >
    > Alex

    You are soooo wrong. Computers are a commodity and the industry is mature. Any MBA knows that. We don't need further development. Every MBA knows that.
  89. Business platform[ Go to top ]

    DODO DODO wrote:
    > > Bottom line -- we're back at square one. Only, this time we have a much, much more complex thing on our hands. So, everyone loses.
    > >
    > > So, how do we solve this conundrum? Tune in for the next installment, where I'll outline the way out of this misery.
    > >
    > > Alex
    >
    > You are soooo wrong. Computers are a commodity and the industry is mature. Any MBA knows that. We don't need further development. Every MBA knows that.

    Hey DODO, be careful -- you may be on your way to extinction!
  90. Business platform[ Go to top ]

    What do you mean?>:)
  91. Business platform[ Go to top ]

    What do you mean?>:)


    I was just joking, making a fun related to the Dodo bird, and how it got extinct in the 19th century.
  92. Business platform[ Go to top ]

    I thought so. We both used sarcasm, in different directions.
  93. Business platform[ Go to top ]

    Alex B wrote:
    > There is very little doubt today that standard J2EE platform is a big honking failure. No matter how one puts it, it's unwieldy. For example, in the old days of mainframe computing, the machinery was so clunky that to try out any change to the application would take hours. The knowledge about the change had to propagate through many layers in the system, making it practically impossible to perform any iterative development work.
    >
    > Because of that, people have enthusiastically embraced Java, knowing that it will support the agile development model. But guess what? Today, with all the incredibly complex layers comprising J2EE, it again takes hours to propagate any minor changes in the system. The huge machinery has to really go through a lot of motions before all the obscure and convoluted descriptors and XML files get read, processed, all the Ant scripts executed, bla bla bla.
    >

    You are stating a lot of the drive for our vision of JBoss 4.0. Aspect Oriented Programming has the potential to solve a lot of the iterative development problems that you speak about above. Middleware, by nature, is cross-cutting across object boundaries. If we can truly encapsulate middleware as an aspect, then we free ourselves to focus on our application logic and we can apply middleware features as part of the iterative process.

    Bill

    > Bottom line -- we're back at square one. Only, this time we have a much, much more complex thing on our hands. So, everyone loses.
    >
    > So, how do we solve this conundrum? Tune in for the next installment, where I'll outline the way out of this misery.
    >
    > Alex
  94. The problem with the complexity of J2EE is to some extent the same problem that leads to all of those options in Microsoft Word that people swear no one uses. Each option was put there because somebody wanted it. It turns out that nobody uses more that 60% of the options but everyone uses a different 60%. Efforts to simplify J2EE by removing "unneeded" complexity won't work because that complexity is there because either it was needed by someone, or because the initial design choice made wasn't the best possible one but it has to be retained for backwards compatibility (it's always easier to design a new system from scratch if you don't have to support those pesky users of the existing one).

    I think a possible solution must lie in the area of Domain Specific Languages. If Java made it easy (as some other languages do) to develop languages specifically for expressing problems in a specific domain then many of these complexity problems could be solved by providing a language tuned to writing, for example, simple read mostly web sites, or even Hello World. This of course is not easy and requires allowing syntax extensions or replacements in Java as well as dealing with the problem of having a smooth transition from the DSL to Java when you need it. Building a new framework for each particular problem, using the same not very expressive language, is, imho, not as useful as building something that lets you easily construct languages and frameworks in which the problem can more easily be solved.
  95. These are the type of article Microsoft loves to see. For a programmer, complexity is someone else's code. I fail to see the complexity of J2EE. The article is bias towards persistence and pushing JDO. OR mapping in general is a problem not specific to J2EE. I think these article damage J2EE, which to me is just a large library to choose from. If you don't like Entity Beans don't use them, don't trash J2EE because of it. I do not see how Session Beans or MDB's are complex at all. I think the 11 million VB developers who were forced to learn an actual preogramming language are having trouble adapting and trying to push the market back in that direction. (XML/Web Services are not specific to J2EE either)
  96. Component-based Software Engineering[ Go to top ]

    One point everybody here is missing (include the author of the article) is that the aspect of the Component-based Software Engineering:
    - Web app for the server-sided presentation layer.
    - Java client (within the container) for the client-sided presentation layer.
    - EJB for the business layer.
    - Ressource Adapter for EIS

    It is important to standardize how such a component works within a container. Just like how each EXE file works within Windows OS:
    -> Operating System: Windows OS <=> J2EE container
    -> Application: Application (EXE files) <=> J2EE Application (EAR files)

    Without a standardization like J2EE it would be impossible to achive this idea. Don't forget the roles definition in J2EE. All of the readers here seem to think that there is one and only one role: "Developer".

    I'm not against all the lightweigt containers (PICO, ...) but IMO you should only use such a container to write an "operating system". If you want to write a "business application or domain oriented application" just use the J2EE container.

    Another point is that nowadays thanks to JOnAS J2EE container or JBoss J2EE container, you can at one side deliver your business application with those container as a client application and on the other side deploy your business application as server application without changing anything.

    In the article you also miss the third possibilty to manage the J2EE application complexity:
    1. Building another lighweight containers and frameworks just like PICO, Hibernate, etc. This has nothing to do with J2EE anymore. I see no problem with Hibernate, because you can integrate it into your J2EE container. Building another containers and component types is just another story. The adavantage of Windows is that you can write a Windows application and deploy it within one operating system easily. How can you reach this if you always need another container and component type? Again, J2EE container is just like an operating system...
    2. Building better tools just like BEA's Workshop and Sun's Rave. A wise development.
    3. Optimizing your development environment and your development process (this point is missing!). Structuring and componentizing your project can make the development of J2EE application a lot more easier. Mostly you *cannot reduce* the complexity of your application. You only *can manage* the complexity of your application. Use a good structured project is a half way to manage the complexity of your J2EE application!

    One point to add:
    Learn, learn and learn. Don't forget that "Long Live Learning" is one of the important part in our life nowadays. Nothing is complicated if you always want to learn. Do not mix the "complexity" and "complicated" term. J2EE is not *complicated* if you understand the idea behind it (component-based, transaction, distribution, deployment, etc). Your business application could be *complex* but you can manage the complexity by doing the points above (2 to 3 for J2EE application).

    At the end I think, please stick to your J2EE to build your business applications. At least one of the good thing in Java is not only Write Once Run Anywhere but also "Learn Once Use Everywhere". One time you understand how J2EE works it is very easy to write a good business application and you can understand how the other J2EE applications work.

    Cheers,
    Lofi.
    http://www.openuss.org
    http://ejosa.sourceforge.net
  97. Component-based Software Engineering[ Go to top ]

    Thanks for the sensible article. Try engineering as a problem-solving approach. That's the way most other non-computing technologies make progress. Even other non-IT areas of computing make progress by adopting engineering practices. Maybe it is time for most of the hackers in IT to return to school to get re-educated.

    Too many developers think that if they don't understand every area of J2EE then there is a problem with J2EE. J2EE is a collection of technologies; try specialising in one or two areas and accept that you are not a genius and will probably need to collaborate with specialists in other areas in order to develop reliable and robust systems.
  98. I like J2EE[ Go to top ]

    I have to say, I like J2EE because it offers so much options. People tend to think EJB is bad, but I feel that - apart from cmp entity beans - ejbs are a beautiful concept. Message driven beans and stateless session beans are just wonderful. Declarative transactions are great. Running the frontend (JSP/Servlet) in the same product/environment as the synchronous and asynchronous middle tier (J2EE, JMS, EJB) is an excellent choice. I like having a naming service and I like that there is a Mailsession object I just need to look up and use.

    Of course JDO or Hibernate are also nice and deserve a slot in J2EE. That said: Most enterprise environments rely heavily on stored procedures anyway because of speed and volume, so OR frameworks are by no means the silver bullet that some assume. Being able to generate Web Services directly from EJBs is great as well. I do think, J2EE, particulary EJBs need good tools to build effectively (like EJBGen etc.).

    On the other hand "lightweight containers" and inversion of control are nice. However don't be fooled to believe they are simple - I have seen people struggling to understand IoC systems much the same way they struggle with any technology that slightly leaves any straightforward processing model.

    On a slightly different note, while J2EE itself is great, I have seen "application frameworks" for J2EE that also cost $$$ that are extremely poorly designed and not fit for any purpose. The trouble to be stuck with an unfit application framework is far worse than struggling with the normal perils of J2EE.

    And I believe most features have a reason to be, even if I do not or cannot use them. I believe that declarative security features for Servlets and EJBs are a good idea, even though they (a) most of the time did not match my requirement and (b) most projects I have seen use crappy "MVC" patterns that totally bypass servlet security.
  99. Simple - Use Jini.

    .....most of our Java infrastructure connects up via Jini,
    we have distributed transactions between db's and CICS, 'service-oriented architecture', fault tolerance, remote events, resource leasing, scalability and load balancing, etc, etc
    Now looking towards provisioning and potentially grids....

    It works.
    And this is my point - use what works for you, if you can get a J2EE server that allows you swap it's capabilities around so that you get a lean server with only the J2EE techs that you need, then use it.

    Calum
  100. Why blame J2EE?[ Go to top ]

    Whats wrong with J2EE? The answer is nothing.

    J2EE is a technology stack - sort of a spectrum.

    When you paint your home, you dont choose all the colors in the rainbow.
    Choosing all the colors - JUST BECAUSE THEY ARE THERE only makes your house that much uglier. You cannot blame it on colors. It is your fault.

    If you choose the color that suits your home decor, why not choose only what is required from the J2EE trechnology spectrum?

    And of all the things, why blame it on J2EE ?

    If all that we want to do is Hello World, let us do it in Assembly language. Why Java, C++?

    If you are into serious enterprise development and want quick turn around time and at the same time not compromising scalability (etc....), come to J2EE.

    Sure, J2EE does not come easy. It needs some serious time of yours (although not as half as complex as it is being portrayed in this thread.) But so does anything in life (except writing Hello World).


    Take it easy,
    Srikanth Shenoy
  101. Why blame J2EE?[ Go to top ]

    Good point.

    I've been blaming it on a fascination with complexity. It seems to be more about developers using technology to say that they've used it, and then some of those same people turn around and talk about how "hard" and "complex" it is.

    Honest question, is anyone out there in Javaland able to even get work without some knowledge of J2EE anymore? I sure haven't seen many jobs and my current position is not possible without J2EE. On the other hand, what I actually need is a very small portion. EJB's would be overkill at this point.

    I think applications should be no more complex than what is necessary to accomplish their function.

    I don't find all aspects of J2EE useful or done well. However, what I actually need from it is usually quite good or sufficient.

    I think my question is, where's the real problem? Is it that J2EE is overly complex or is it the community's obsession to come up with obtuse solutions to simple problems?

    Nonetheless, Dave Thomas does make an excellent point in many ways. The question may not be "how do you write Hello World" but rather "Why are we using complex solutions to simple problems?"
  102. Why blame J2EE?[ Go to top ]

    "I think applications should be no more complex than what is necessary to accomplish their function."

    How many apps exist whose function NEVER changes?
    How many apps exist whose environment NEVER changes?
    How many apps exist whose dependencies NEVER change?
    How many apps exist whose number of users NEVER grows?
    How many apps exist whose function NEVER is Combined with other functions?
    How many apps exist that never need to interoperate with other apps?
    How many apps exist whose UI ALWAYS is best for EVERY user?

    Not even "Windows Calculator" meets these requirements.
    Therefore a "no more complex than it needs to be" app will automatically expose fatal limitations in any of these cases.

    Matt
  103. Why blame J2EE?[ Go to top ]

    So how is this an arguement that additional complexity is necessary?

    From what I gather, you are confusing "complexity" with "flexibility" or "extensibility". I submit that these are not all the same.

    As for some of your examples, I don't build apps that do anything beyond the requirements I'm given unless I come across something that I know will be a future need. Otherwise a lot of your scenarios would require developers to be fortune-tellers. I think planning for future functionality that we cannot predict is possibly how we ended up with the mess we have now.

    It's also been my experience that usually whatever is written in hopes of addressing a future need/problem is usually insufficient, doesn't meet requirements, or is outright obsolete by the time the future arrives.
  104. I wonder how many folks on this thread would argue against putting steering wheels in a car if you didn't have a requirement for the car to turn while moving?

    I wonder how many would think its OK to build a car that won't fit on the road?

    Anticipating change and adopting standards are key to advancing technology. EJB's and J2EE do both. The resulting "complexity" is innevitable (trucks are naturally more complex than ox carts.)

    Matt
  105. Again, you are confusing complexity with something else.

    A car doesn't function correctly if you cannot steer it. A train, on the other hand, doesn't need a steering wheel. Yet I know some people whose programming practices say that it should have one just in case someone might want to take it off the rails.

    I think a more appropriate example would be a CD player. You can get a car without one, or put one in later. Most people, knowing that they want one, will choose the former. On the other hand, some people may choose to save a little money or wait until they can get one that's better than the factory standard. Maybe they just don't want one. The great thing is, you can build the entire car without it. It's not a necessary function, and you can even leave space in there so that they can put in whatever they want. A CD player, an old tape deck, or maybe something else that might fit in the space.

    If you're writing an app with EJB's because you think it's going to be a distributed application in the next 2 years, you're wasting effort. Even 6 months might be pushing it. Then you get into short vs. long term costs. If you KNOW it will become a requirement and it is LIKELY that it will be cheaper to do it now versus later, then yes you do it.

    It's more about using a little common sense, not wasting effort on tasks that are uneccessary or of marginal usefulness. Frankly, I would be irritated if I busted my hump doing something that is replaced by something else or no longer meets the ever-changing requirements before it is ever used.

    As I said, no more complex than it needs to be. I'm not saying "Never use EJB's" or to keep it so simple that it becomes a maintenance nightmare. Don't plan for a future you can't predict.

    What's really hilarious is the original example and some of the blog posts. Talking about deploying .WAR files for "Hello World!" or using EJB's. It seems ludicrious and yet I know people, professionals no less, that think in exactly those terms. Does an app have to use EJB's to be considered 'J2EE'? If so, we have indeed lost our way.

    If something changes along the way, if something unpredicted comes up, if requirements change, dependencies, et al, then that is what enhancements and upgrades are for. If applications could remain static forever or we could create systems that lasted for years on end because we can give them all the possible features anyone will ever want, then no developer would last beyond one project.
  106. "...because we can give them all the possible features anyone will ever want, then no developer would last beyond one project"

    I think the important difference between the cd player example and the steering wheel example is the captured in your last sentence. The goal is exactly what you have stated: make the effort with which applications can be extended and enhanced so modest that it is no longer considered a "project" to do it -merely a "task".

    If I have to change the size of a car or add a steering wheel, I might as well start from scratch. Just adding a CD player should be "plug and play".

    I hope we don't have developer's selfish motivations to blame for this intentional short-sightedness that is so evident on this thread, otherwise ALL the IT jobs will sooon be in India!
    Matt
  107. I think my question is, where's the real problem? Is it that J2EE is overly complex or is it the community's obsession to come up with obtuse solutions to simple problems?


    Simple answer:

    Blame documents like Sun's J2EE blueprints, examples like Sun's PetStore, and naive faith that because they were trumpeting a standard, not a product, they wouldn't over-hype it.

    More complex (and accurate) answer:

    Once upon a time some smart people came up with J2EE standards, many of which were political compromises between vendors. They trumpeted how great their solutions were (as one does). Sun (and other vendors) wrote some blueprints and examples showing how to use these technologies, and they over-used all the whizzy complex gadgets (Entity EJBs in particular) to show how great they were. And app server vendors wrote 'reference' works telling you that you need EJBs, etc, because that's how app server vendors make money.

    And developers, delighting in the glory of Java, and naive in our faith in what Sun said, believed it. We tried to follow the Sun J2EE Blueprints, to build like PetShop, we tried to do what the vendor's examples on the web said we should. We told our clients we'd use these whizzy technologies, and they read the same gumph we did about how wonderful the technologies were, and the architects raptured over the architecture. People who'd never built a real system with these technologies wrote books about how to use them, because there was demand for the books and no-one had time to spend a year building a big, complex enterprise system with it before authoring a book on cutting edge technology. And then we built complex, overarchitected systems.


    But there may be a happy ending:

    Now "simplify Java development" is sun's catch-phrase. At Java One this year they announced the new Sun Blueprints, which include ideas like "you can use POJO". I think that's a watershed: people have gone past "use all the shiny whizzy toys" and are now settling down to "use appropriate technology, different projects have different needs"

    And maybe (if we're lucky) various spec leads are now saying "how can we empower developers to do things" instead of "how can we do things for developers".

    Sean
    PS: For those who read this site continuously, I'll start to sound like a broken record stuck repeating the same thing over and over (for the young: records are a quaint old analog technology) since I've said this 2 or 3 times on the server side over the last couple of years.
  108. PS: For those who read this site continuously, I'll start to sound like a

    >broken record stuck repeating the same thing over and over

    Sean,

    Repetition est mater studiorum. Please keep repeating these points, as they are of vital importance. Usually people need to hear something 20 to 30 times before they'd start paying slightest attention. Vendors know that, and are creating their own rumor mills, tirelessly repeating blatant lies, burning millions of dollars in the process. It's time we developers strike back, and create our own rumor mills too.

    The truth of the matter is that, like you've so eloquently pointed out, we're in the midst of the vendor war. Vendors must engage in this war, because that's the only way they make money. Fine and dandy for the vendors, but we have to ask ourselves the following question: what's in it for us? Why should we volonteer to work as Sun's or IBM's or Microsoft's foot soldiers? If I start wasting my time walking around proselytising and evangelizing particular vendor product, is that vendor going to send me a nice juicy paycheck at the end of the month? Not very likely, I'd say.

    So, why should I do the legwork for them, without even getting paid? What have they done for me lately?

    Alex
  109. Strong J2EE features[ Go to top ]

    There are a few J2EE features, that I've found are always quite useful.

    Transaction Management. JTA is such a simple API and its integration with the EJB Container makes managing transaction quite easy. JBoss's connection pooling is written on top of JCA, so this means that our connection pooling is tightly integrated with the TM if so desired. Add to this J2EE's ability to define transaction boundaries implicitly, and you have seemless, simple transaction management. This can greatly simplify code for even very simple JDBC based apps.

    End-to-end Security. Another great thing about J2EE is its end to end security. You can define secure URLs within your WARs and the Servlet container will make sure the correct login is made. These security credentials can then be passed on transparently and implicitly to the EJB tier and again checked against role-based security. Again, since JBoss connection pooling is built upon JCA, this implicit security propagation can be done all the way to the database layer. All seemlessly. You can do the same sort of thing with JMS. What's great about this is that you do not have to code in security for your initial iterations and instead snapshot it on to your application later on in the development process through configuration.

    Security and transaction management integration is a compelling enough reason to use a J2EE based application server.

    Bill
  110. JBoss 4.0 Roadmap[ Go to top ]

    I am posting our JBoss 4.0 Roadmap because I believe it is very complimentary to this thread:

    Future Directions

    Our long term strategy is based on the idea of Plain Old Java Objects (POJOs).
    Much of the direction of new open source and commercial projects is to ease the
    development process by allowing programmers to work with plain Java classes
    rather than complex APIs and specifications. Many times these open specifications
    intrude on the development process and sometimes are complete overkill in the overall
    application architecture. JBoss 4 introduces a POJO-based strategy that allows
    developers to focus on writing their business logic in pure, simple Java, and
    applying system level architecture later on in the iterative development process.
    Business logic gets encapsulated within simple, reusable object models, and system
    level middleware like caching, remoting, transactions, and persistence are integrated
    via aspects, not through modification of the base application code. This allows application
    developers a simpler approach to writing complex programs and allows them to have a
    common object model that can have middleware applied to it in different ways and at
    different times depending on the use of the software.

    The POJO kernel
    These components make up the core building blocks that allow us to bring middleware
    to plain old Java objects.

       
  111. MicroJBoss - our jmx microkernel that has been around since the 3.0 series tailored
       for POJO development. MicroJBoss gives us a lightweight component model. Allows us to
       declare configuration of core components, provides us with core features like component
       loading, hot deployment, and dependency management. It gives JBoss 4 a lightweight spine
       to load and configure JBoss and user services.
       


  112.    
  113. JBoss AOP. This is our Aspect-Oriented Programming framework. This tool gives us
       the ability to define and attach middleware services transparently and implicitly to
       POJOs (plain old Java objects).
       


  114.    
  115. JTA - transaction manager, a simple, but powerful API to provide transaction management
       for ACID behavior.
       


  116.    
  117. JBoss Remoting. An framework written to abstract out distributed communications.
       It is fully URL based and can provide seemless integration with a variety of protocols
       like SOAP, RMI, IIOP, or custom fast socket based communications.
       


  118.    
  119. JGroups. Our reliable group communication framework and basis for JBoss Clustering.
       


  120. Aspect-Oriented Middleware

    On top of our cores services, we are offering simplified middleware for plain Java objects
    that effectively provides J2EE a la carte.

       
  121. Persistence - Hibernate. Hibernate is the most popular Java Object/Relational Mapping solution.
       It is a powerful API for mapping plain Java objects to your relational tables. Hibernate is
       also one of the key players on the JDO 2 specification committee.

  122.    
  123. AOP remoting - Built on top of our core JBoss Remoting framework, these set of aspects
       allow developers to take any plain Java object and communicate to it over the network.
       No IDL definition phase like in CORBA. No precompilation like in RMI with rmic.
       Any POJO can be remotely accessed if so desired by any protocol offered by the JBoss
       Remoting framework.
       

  124.    
  125. AOP Clustering. Taking the best out of our JBoss Clustering project, this aspect
       expands on AOP Remoting to provide fault tolerance and load balancing to any remote POJOs.
       

  126.    
  127. Simple AOP Asynchronous Invocations. Allows you to easily tag a POJOs method to be *oneway*.
       That it is a fire-and-forget method that can be run in the background either with a Thread, or
       through a JMS queue.
       

  128.    
  129. AOP caching. Transparent transactional and replicated POJOs through our AOP Cache.
       This allows you to insert plain Java objects into a cache and these objects instantly
       become ACID and replicatable across a cluster.
       

  130.    
  131. JTA transaction demarcation. Apply transaction demarcation on any POJO. J2EE a la carte

  132.    
  133. Role-based security. Apply role-based security to any Java class within your application J2EE a la carte
  • JBoss 4.0 Roadmap[ Go to top ]

    Bill,

    Has the release schedule shifted or are you still on target for all these features in December -- i.e. are you going to skip DR3 and go direct to RC.

    -- Frank
  • Try Wakesoft[ Go to top ]

    I've tried the Wakesoft Architecture Platform and can say that it makes J2EE development straightforward and easy. Since it covers the whole J2EE stack, not just persistence or the presentation layer, it offers a more seamless integration than the products mentioned in this article.
  • Try Wakesoft[ Go to top ]

    I've tried the Wakesoft Architecture Platform and can say that it makes J2EE development straightforward and easy. Since it covers the whole J2EE stack, not just persistence or the presentation layer, it offers a more seamless integration than the products mentioned in this article.


    To clarify the scope of the Spring Framework, the lightweight container mentioned in the article: It is by no means just about presentation. Quite on the contrary, it is a full application framework, offering bean container, AOP framework, generic transaction management, DAO support for JDBC/Hibernate/JDO, generic web application support, and finally, a web MVC framework.

    Spring as middle tier backbone plus Hibernate as persistence tool is a popular combination. It easily competes with the Wakesoft Architecture Platform in terms of scope, and offers seamless integration between all involved components too - that's the major advantage of pre-built integration. We offer a similar level of support for JTA, and for view technologies like Velocity and Tiles.

    Spring's web MVC framework is just an option, albeit an elegant and powerful one. We have numerous users that choose their own combination like a Spring middle tier plus a Struts/WebWork/Tapestry web tier, or use Spring in standalone applications. We've even seen usage of Spring bean factories within applets.

    Juergen
    (Spring Framework developer)
  • Try Wakesoft[ Go to top ]

    We use Wakesoft here for a large scale project and I must admit it has made an enormous difference. It does take a bit of time to understand as it comes with bagloads of functionality that could be made use of. Think of it in terms of you building a house. It provides the structure, plumbling, electrical wirings and so on but you are responsible for painting, extensions etc. Your average developers will map use cases to Business Processes implemented in POJO's while the smarter ones can fine tune the architecture (for example, switching from an entity EJB based implementation to a DAO based implementation is simply a configuration file change). Incidentally, a few development cycles of our project were undertaken by an offshore team and the handover went without a hitch, thanks in major part to the architectural consistency provided by it (not to take away from the fact that the offshore team was a solid team too). Their support has been awesome too.
  • Although few might want to hear something from the Mainframe Alternate Universe (we ARE in the World&#8217;s Most Siloed Profession, aren&#8217;t we?) &#8211; I&#8217;ll risk it - maybe there is another way to approach the problem . . . . .

    In that old mainframe world, the role of the Business Application Developer (usually ye olde COBOL programmer) is very distinct from that of the Infrastructure Specialists that understand (set up and support) most of the technical architecture (operating system maintenance, transaction servers, database, storage management, and so on).

    Of course they all work together as a team, and (like anything else) the more the Developer knows about use of those infrastructure systems, the better. But they don&#8217;t have to know all about the INSIDES of these infrastructure systems. What this means is . .

    That the infrastructure can become as complex as needed &#8211; to the point of being a full-time job &#8211; and the Developer does not have to learn TWO (well, SEVERAL, really) full time jobs. The limitation of one person having to understand MANY full-time professions is not there, removing many of the limits to complexity of the system.

    And because the system itself CAN become much more complex (sophisticated?) without killing the Developer - this also can means that the system could do MORE for the Developer. For example (in the old mainframe world) there are some things that the Developer does NOT have to worry about if they follow basic guidelines:

    - Scalability is NOT an issue. Five users or five thousand &#8211; so what?
    - Transaction failover &#8211; review the topic for an hour or so &#8211; no biggie.
    - Running across mainframe clusters &#8211; with failover &#8211; pretty darned transparent to the coder.
    - Middle-tier caching &#8211; well, generally just not needed, difference in technologies.

    Yes, there is a lot of heavy lifting to implement the systems that allow this &#8211; but it&#8217;s mostly done by the Infrastructure Specialists. The Developers are generally off doing things of direct interest to the clients.

    Coming from the Old World, to me it sometime seems that the roles of Developer and Infrastructure Specialist have been so smushed together in the New that it places a terrible burden on the Developer, made even tougher by the rapid evolution of the newer technologies.

    Maybe those roles will ultimately have to be examined &#8211; maybe some specialization will be needed to allow progress to continue if things keep becoming more complex. (And that is a hard thing to think about if you really do like both the Technical and Business areas ((I do!)) &#8211; but there may come a time when choices might have to be made.)

    (And I can see how this comes about &#8211; because the tools and technology are cheap &#8211; many even free! &#8211; one person has an opportunity to TryToDoItAll . . )

    Disclaimer &#8211; I&#8217;m obviously a NewbieJustTryingToUnderstandItAll and am not really qualified to debate Java/J2EE in any depth at all, but that&#8217;s why I come here, to better get clues from ThoseWhoSureSeemToUnderstandItBetter.

    Best to all - gh
  • Visual basic cut and paste club[ Go to top ]

    The real problem is we have a lot of VB enthusiast flooding J2EE with their Brainbench certifications and cutting and pasting every line of code their pointer can hover over. That’s how it gets complex.
  • J2EE reminds me of unix[ Go to top ]

    Yes J2EE is complex, but as I remember unix was pretty overwhelming
    to. The main problem I see in J2EE complexity, is not the proprietary
    extensions from app server to app server, but the fact that the vendors
    spend all their effort there, and let the standard APIs fall by the
    wayside. Their tools will be flawless on the extension's and flaky
    for the standard APIs.
      There is a good article in the December issue of Software Developer
    called the flexible factory, basically stating that component software
    holds the only promise for increasing productivity and software quality.
    Another point is that it distinguishes between OO and component
    methodology.
      To me, EJBs are about as complicated as X-motif programming. You have
    a window manager in one a container in the other. Think a lot lot of folks
    are being led by a ring in their nose to whine too much here. Sticking
    with the standard APIs, to me, is the only way understand what is going
    on with your code. But the vendors are aggressive about lock-in and
    want you to fail here.
      EJBs don't make much sense for non-core business software, as there
    is more effort required to configure/deploy them. But the gain in using
    them is not so overly complex as it is being made out to be. Besides
    extracting your business logic from the system programming, like threads
    for concurrency (potentially problematic programming contructs are left to
    the container so they are not a concern to the "core" business logic), your
    core business logic can serve several different clients, so re-use of
    business components can be achieved across applications.
      I know threads are cool, JDBC calls can be a career in itself, but businesses
    don't want their programmers to be spending most of their time doing what can
    be offloaded to the container.
      So deployment descriptors will get less complex, entity beans more suitable
    for richer domain models.
      I was at a java .net interoperablity seminar. They said 2 things they likemost about J2EE, was the EJB container having business logic that can
    be used for many clients, and the O/R mapping, and plan to deliver both
    to .net next year.
  • The next language or paradigm?[ Go to top ]

    The article says "like C# or AOP".

    I fail to see how anybody can consider C# "the next language". If anything, it is a Java clone, more or less a few features, and very platform specific. You can't call that progress.

    But certainly paradigms that will take off are Service Oriented Archictures (SOA) and Document Oriented Architectures, based on Web Services and business process definition languages, of which BPEL is the prime candidate. You will still need Java, but more and more of the glue will be done in more declarative languages like BPEL rather than Java. This has the potential of increased application modularity, and lower barrier of entry for certain categories of developers.

    This is the approach we are pursuing with OXF (http://www.orbeon.com/oxf/).
  • Xdoclet save the day[ Go to top ]

    I don't know what is this article about. Spend some time with xdoclet and middlegen and 3/4 of work will disapear.
  • I perceive J2EE as the Java answer to major generic enterprise software problems
    that existed long before Java. One of them was previously addressed by classic
    TP Monitors (Tandem, CICS), another one was the distributed objects space (populated by CORBA ORBs), third one was the persistence model (occupied by RDBMS), forth one was MOM, etc. Due to breadth of the addressed problems, it’s not possible for one solution, J2EE, to be the best in all areas, but possible to introduce some sort of standard where a standard will have a big value.

    But unlike the past when big enterprise software problems were the focus of few highly skilled analysts and developers, J2EE exposed both problems and solutions
    to way larger developer audience with all implications. The platform doesn’t all areas of business computing but, I think, does cover a large portion of them.

    The entire universe of J2EE, obviously, is not and should not used in every
    case, and in every application. The question which technologies are relevant to
    in a given situation does take planning, thinking and evaluating possible
    options. It's all time and resource consuming, but that's life. Of course, we
    all will benefit from books something similar in depth and wisdom as K&R book
    (the one that is very close is "J2EE Design and Development" by Rod Johnson).

    But frustrated by the recent obsession with complexity in J2EE community. It’s impossible to come up with universal cure for every possible business scenario. But, let’s not forget that in many cases XP methodology has found a way to put ALM in control even with ever changing requirements. Take Unix, it has thousand of utilities that follow the simple philosophy "do one thing but do it right" [with exception of Emacs]. Yet the kernel orchestrates them so well that the entire OS scales in any direction.

    I liked rainbow analogy of Srikanth Shenoy and agree with Jeff Drost that using a standard to solve a complex business problem has value.

    I do enjoy the wide [wild?] variety of technologies comprising and joining J2EE – I learnt to value freedom of choice.

    And I enjoyed the article :) Thanks

    Valeri
  • J2EE is not a religion[ Go to top ]

    The entire universe of J2EE, obviously, is not and should not used in every

    >case, and in every application. The question which technologies are relevant
    > to in a given situation

    I think this is the key. What is indeed the simplest solution to a given problem should prevail (XP methodology). I see people dismissing those who complain about EJB as not understanding the technology. That is not the point. The point here is to avoid being too 'orthodox'.

    EJB (in particular stateless session beans) are perfectly adapted to some situations. In others, EJB as a whole is simply overkill and does not add any business value.

    Developers should simply avoid automatically applying the same technology to every situation and consequently fall into an anti-pattern (I believe it is called the 'Golden Hammer').
  • Let’s face it, most data-driven JSP development would be quite simple but for the complexities of interacting with the inherently— not object oriented— relational database. This complexity is manifest for the JSP developer as either complex snippets of Java code embedded within the JSP page (bad) or as an even more complex series of steps required to encapsulate the tables as JavaBeans. Typically, for simple to moderately complex web applications, most developers opt for the easy way out: embedded snippets or, slightly better, the JSP Standard Tag Library (JSTL) “sql” tag library.

    The open source tool <SQLTags:/> (http://www.sqltags.org) provides JSP developers with a new, radical approach to building those simple to moderately complex data-driven JSP web applications. The SQLTags Generator reverse- engineers a JDBC schema and converts it into a JSP tag library! Each “table tag” follows the JavaBean naming convensions, all column values and foreign keys are available to JSTL’s Expression Language (EL). Additionally, mundane tasks like assigning HTTP Request Parameters to columns; executing insert, update, and delete statements; parent-child nesting based on foreign keys; parent table lookups based on foreign keys; and paging of results are all standard, built-in features of SQLTags.

    In short, for those applications where EJB or Struts is overkill, but, interaction with JDBC is still necessary ... SQLTags is a solid solution.

    --Steve Olson
  • Four steps to creating a well-architected J2EE application using JAG - the Java Application Generator.

    1) Use the freely available PoseidonUML Community Edition to create a UML class diagram containing your entity and session beans, and the relations between them. (http://www.gentleware.com)

    2) Import the UML model in XMI format into JAG. Maybe configure your database connection details if you haven't included this information already in the UML.

    3) Let JAG generate the whole J2EE project for you.

    4) Build your generated application (as simple as typing 'ant'), deploy it to your JBoss app server, and enjoy!

    JAG is open source, it's reached stable version 3.0, and you can download it today at http://jag.sourceforge.net/

    J2EE application design just got a whole lot simpler!

    //Mike O'Connor
  • It's so nice that JAG automaticly generates a client-server application with end-to-end CRUD. It's sensible for a J2EE model compiler to emit a reasonable and working default application, something those pesky human architects don't always do in the early builds. How much money would a J2EE journeyman charge to hand code the same application from the same UML diagrams that this tool does for free? How long would it take him to debug and fix handiwork that does the same thing as what an MDA tool emits at the push of a button?

    I appreciate the CRUD metaphor, which is also known as REST -- so intuitive and allowing for still more generated presentation, perhaps direct manipulation with SVG or VRML. I'm encouraged that MDA is finding traction with J2EE. The better the tools, the less costly it is to build a custom application, with less defects, and the quicker it can be brought to market. I love passing savings on to consumers.
  • Hello J2EE World![ Go to top ]

    What the world needs is a reference collection of 'Hello J2EE World' configurations.

    Imagine having available a set of downloadable J2EE configurations touching upon variations of the most popular J2EE technologies with regards to vendors, persistance, frameworks ... the code, the web.xml, the ejb-jar.xml, the ant builds, the vendor parts abstracted out and separately downloadable etc... Once this incredibly popular open-source inititive takes off, vendors start contributing thoroughly-tested configurations themselves in ordert to gain a competitive edge :)

    I realize this could exponentially get out of control pretty quickly - the variations would become huge(and what a testing/maintenance headache), but a guy can dream can't he? It would be the ultimate way to get up and running in a hurry on your new project.

    ...now downloading HelloJ2EEWorld - Sun Reference Implementation
    ...now downloading HelloJ2EEWorld - WebSphere 5.0 with Struts and taglibs
    etc.

    If you wanted to get really ambitious, incorporate persistance - various frameworks and vendors.