Discussions

News: Article: Pragmatic Design

Bookmark and Share Get thread feed

  1. Article: Pragmatic Design (17 messages)

    This article, by Frank Teti, is targeted for Enterprise Architects, who are involved with establishing enterprise-wide standards and guidelines. The article discusses using a decision matrix for selecting a particular design pattern or framework only when it was appropriate for a particular processing style with distinct non-functional requirements, such as performance, protocol independence, etc.
    Reply to this

    Threaded Messages (17)

  2. The summary says it all[ Go to top ]

    ... As far as runtime performance, only through a combination of application server clustering and application construct performance tuning can Java expect to approach the runtime performance of C++...
    Sure, no way to approach the runtime performance of C++ without clustering. I think I'll just save the 10 minutes that I would spend on reading this article.
    Reply to this Reply to original

  3. Re: The summary says it all[ Go to top ]

    Ok What I don't understand is, why people are comparing two architecturally different languages? C++ V/S Java/J2EE? Is there are difference between a compiled and interpreted languages?
    Reply to this Reply to original

  4. Re: The summary says it all[ Go to top ]

    Ok What I don't understand is, why people are comparing two architecturally different languages? C++ V/S Java/J2EE? Is there are difference between a compiled and interpreted languages?
    Neither of the languages you mention are interpreted (both are compiled) and J2EE is not a language. Having read the article (where do I apply to get those moments of my life back?) I agree with the general opinion expressed here that the article is worthless.
    Reply to this Reply to original

  5. About performance[ Go to top ]

    ... As far as runtime performance, only through a combination of application server clustering and application construct performance tuning can Java expect to approach the runtime performance of C++...


    Sure, no way to approach the runtime performance of C++ without clustering.

    I think I'll just save the 10 minutes that I would spend on reading this article.
    There is a big difference between system performance and single thread/processes performance. In many cases organizations are more interested in a wholistic view of performance. End-to-end performance. The time it takes to execute concurrent business transactions. This is why in many cases, it is less relevant to compare single program performance between Java and C++. In heavy transaction processing environements the metrics that are important are latency and scalability. Latency - what is avg/max elapsed time of a single business transaction, end to end. Scalability - how many business transactions can run concurrently. In these cases, the system architecture is what matters.
    Reply to this Reply to original

  6. Re: Article: Pragmatic Design[ Go to top ]

    Is performance really the issue? Seems many companies would love to replace COBOL with more-flexible Java systems except for the cost and effort it would take to entirely replace a legacy system. I need to read the article to see which types of COBOL applications require pedal-to-the-metal speed over stability and correctness.
    Reply to this Reply to original

  7. What does this have to do with COBAL?[ Go to top ]

    Where does COBAL enter into this discussion other than a brief mention in the beginning. It also appears the author may want to re-evaluate EJBs given the current generation application servers are using technology similar to Hibernate, if not Hibernate.
    Many organizations that support application servers that include EJB containers (i.e. WebSphere, WebLogic) view EJB as a complex, heavy-weight solution and do not rely on them.
    This was true many years ago, but not so any more.
    These organizations prefer using more light-weight frameworks like Spring (i.e. Prototype, Singleton or Session) beans in conjunction with Hibernate.
    Again, same story here. Spring has gathered a lot of attention and provided a nice framework for POJO style development, but I'm not sure this argument still holds true. Noah Campbell http://www.noahcampbell.info
    Reply to this Reply to original

  8. Re: What does this have to do with COBAL?[ Go to top ]

    It is hard to figure out what the author's real point is. The article is a bit all over the map and is in bad need of editing for clarity, spelling, and content. There are some basic writing 101 errors here: * Why bring up COBOL in your introductory (most important) sentence and then drop it? * Figure out who your audience is and target everything you write to them. * If you are going to publish, and you want to be taken seriously, find an editor. Especially, if English is not your first language. e.g. I'm not sure if you really meant "ubiquitous clients" * Why doesn't your summary match your content or your introductory paragraph? The final point of the article seems to be that you have to pick different application patterns and architecture to match the kind of system you are building. In short there is no one size fits all approach. This makes be think the target audience is beginner level designers. I did like the chart showing how you might pick different application technologies and patterns based on the type of application you are developing. I'm not sure I agree with everything the chart states but it shows some thought. The title made me think it was going to be one of the high-quality publishings from the pragmatic press. The title is overly-generic both on the article and the TSS posting.
    Reply to this Reply to original

  9. Re: What does this have to do with COBAL?[ Go to top ]

    Sorry, this is a marketing paper mistakenly written by a half-trained engineer. :-)
    Reply to this Reply to original

  10. Re: What does this have to do with COBOL?[ Go to top ]

    Many organizations that support application servers that include EJB containers (i.e. WebSphere, WebLogic) view EJB as a complex, heavy-weight solution and do not rely on them.

    This was true many years ago, but not so any more.
    Ummm, I've developed EJBs on WebSphere, and I can tell you that they are a pain. Especially in a collaborative, continuous integration scenario. The auto-generated stubs can easily get out of sync by just adding a simple method. I tell people that if they want to speed up a project now and in the future to avoid EJBs on WAS 5 and 6. EJBs work fine in WebSphere, but they don't seem worth the effort to develop and maintain.
    Reply to this Reply to original

  11. Tangent: Continuous Build and EJB can learn to love one another![ Go to top ]

    Ummm, I've developed EJBs on WebSphere, and I can tell you that they are a pain. Especially in a collaborative, continuous integration scenario. The auto-generated stubs can easily get out of sync by just adding a simple method.
    Why would you be committing auto-generated stubs into a continues integration system? Wouldn't the build system generate the final output for you? I don't have experience with WebSphere, but I've heard similar stories of woe.
    I tell people that if they want to speed up a project now and in the future to avoid EJBs on WAS 5 and 6.
    Works for me...I work for BEA :)
    EJBs work fine in WebSphere, but they don't seem worth the effort to develop and maintain.
    EJB's do require additional effort to develop and maintain, but I'll punt and say in the hands of an experience team, this is non-issue. EJB3 is expected to remove this burden and liberate the developer. My point is that the old adage of EJBs being hard/difficult/slow is not true given JavaEE landscape. Noah Campbell http://www.noahcampbell.info
    Reply to this Reply to original

  12. Re: What does this have to do with COBAL?[ Go to top ]

    Where does COBAL enter into this discussion other than a brief mention in the beginning. It also appears the author may want to re-evaluate EJBs given the current generation application servers are using technology similar to Hibernate, if not Hibernate.
    Many organizations that support application servers that include EJB containers (i.e. WebSphere, WebLogic) view EJB as a complex, heavy-weight solution and do not rely on them.

    This was true many years ago, but not so any more.
    You think EJB has become more popular lately? I think people are increasingly more sour on EJB. EJB 3 may pull it out of its tailspin but I think you are living in a fantasy world with this comment. What evidence do you have that this is the case?
    These organizations prefer using more light-weight frameworks like Spring (i.e. Prototype, Singleton or Session) beans in conjunction with Hibernate.

    Again, same story here. Spring has gathered a lot of attention and provided a nice framework for POJO style development, but I'm not sure this argument still holds true.
    Again based on what? Spring is more popular now than it was a year ago. What changed? I have seen any trends indicating a reversal. I think WebLogic is a great product but I think you need to accept that EJB has gotten really bad reputation and it's future is in question. Java is at risk of becoming a legacy platform. What makes you think people are flocking back to EJB? Are you selling a lot more licenses? I hope for your sake that BEA isn't putting all it's chips on EJB because everything I see suggests movement away from it.
    Reply to this Reply to original

  13. Don't bother reading.[ Go to top ]

    Who approved this article for publishing? What a waste of time.
    Reply to this Reply to original

  14. 6 years too late[ Go to top ]

    Hi, I think both Frank & yourself (Nuno) should do a bit more research and expand your bibliography - see Business Component Factory : A Comprehensive Overview of Component-Based Development for the Enterprise, by Peter Herzum & Oliver Sims (book website - http://www.componentfactory.org/). Ignore the specifics about Java - specially since java is not a replacement for COBOL, and the IT landscape for solutions has changed dramatically -. As of patterns the article focuses on the basic ones - see Enterprise Integration Patterns (book website - http://www.enterpriseintegrationpatterns.com/) and also Patterns of Enterprise Application Architecture. It is interesting, but lacks innovation, has no references and shows a very limited view on the enterprise application landscape. Cheers, Josh
    Reply to this Reply to original

  15. Re: Article: Pragmatic Design[ Go to top ]

    I think it's time for dinner..
    Reply to this Reply to original

  16. Re: Article: Pragmatic Design[ Go to top ]

    Looks like a number of copy&paste from various sources. I hope none will print the "article": it would be an unacceptable waste of paper. For now, it is only an unuseful waste of bandwidth and some disc sectors somewhere. Guido
    Reply to this Reply to original

  17. Re: Article: Pragmatic Design[ Go to top ]

    http://myjavaserver.com/~sudhirnimavat/
    Reply to this Reply to original

  18. Re: Article: Pragmatic Design[ Go to top ]

    http://myjavaserver.com/~sudhirnimavat/
    ok, are you saying your sweet home designed very pragmatically?
    Reply to this Reply to original