• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Greetings - J2EE Design Patterns Applied

 
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,
My name is John Carnell and I am doing this week's book promotion, J2EE Design Patterns Applied (Wrox Press), on the JavaRanch.
I was pretty excited when Wrox approached me on helping with their J2EE Design Patterns Book. Design patterns are always one of my favorite subjects and I find they are incredibly useful when trying to conceptualize and design any application.
The J2EE Design Patterns Applied book really tries to avoid being a patterns "catalog" and instead focuses on showing how J2EE Design Patterns can be used in real world experience. It a small well-focused book that consists of only 8 chapters. (Yes, I have heard the criticism that
Wrox authors are paid by the pound :,>
Personall, I have a pretty broad development experience background and I have worked with a lot of development languages tools (C,C++,Java, Delphi). What I have found is that often times the success of a project is tied to its design rather than the tools that were used to implement it.
If anyone has any particular questions about J2EE Design Patterns and their application, I would love to listen. (Or if you want to talk about anything else, I am always game :>
However, I will pose this question to you guys? I pose this question to every group I talk to:
While the J2EE Design Patterns were originally
conceived to solve problems encountered
with J2EE application development, is the use
of the term "J2EE" patterns misleading. Is it
not more appropriate to call these patterns
Distributed Application Design Patterns? Its
been my experience that most, if not all of the
J2EE Design Patterns solve problems related to
distributed and component based application
development.
Could not most of the core J2EE patterns be
applied to an environment like .NET?
By putting the focus purely on the J2EE
environment, do we limit ourselves to new
new patterns that can be used and identified?
I would like to hear everyone's thought on this. Design Patterns are supposed to be technology
independent? How does this fit with a topic like
"J2EE" Design Patterns?
I look forward to hearing from everyone.
Thanks,
John Carnell
 
sharp shooter, and author
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi John,
A warm JavaRanch welcome to you - it's great to see a fellow Wrox author stopping by at the ranch to help out.
I hope you have a great week...
Cheers
Simon, Bartender of "J2EE and EJB" forum
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Simon,
Thanks! I am really excited about being on the JavaRanch. I just wanted to provide a little bit more information about the J2EE Design Patterns Applied book.
1> The ISBN for the book is ISBN: 1861005288.
2> My profile says I am the author of the book.
I am actually one of the co-authors. The other
authors on the team were Craig Berry, Matjaz
Zuric, Meeraj Moidoo Kunnumpurath, Nadia Nashi
and Sasha Romanosky.
Thank,
John Carnell
 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello James,
i wonder whether J2EE patterns evolved while using J2EE or some people sat and thought about having some patterns and released them ?

clarify
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Manas,
Personally I believe the core J2EE Design Patterns are an evolution and refinement of many of the Design Patterns in the original GOF Design Patterns book.
For instance, the ServiceLocator pattern is very similiar in behavior to a factory pattern. You use the ServiceLocator pattern to abstract away the process in which an object/resource is created.
The SessionFacade pattern is essentially a Facade Pattern that hides the complexities of creating and manipulating EJBs.
I do not think J2EE Design patterns just sprang out of existince. Rather the original patterns authors (Crupi, Malks, Alur) probably looked at common patterns and extrapolated (???I think I spelled write. Thank god for editors :,> how they could use these patterns in their projects.
Thanks,
John
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
I have two questions:
a) In the chapter on persistence patterns,
do you cover other persistence frameworks
like JDO, OODB versus CMP/BMP ?
b) I am interested to hear about your
comments on PAGING. Other than SUN's
page-by-page iterator pattern; what
other would you recommend ?
See also this discussion for reference.
Pho
 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I remember six years ago working at a company that was transitioning from PowerBuilder to Forte', and they were trying to figure out how to use it to build multi-tier applications. The manuals described Forte's very rich API for distributed computing, but we didn't have a clue how to use it properly! If only we had had your book then!
But now that people have learned from experience and compiled the lessons learned, I fear that it's all for naught -- that we're heading back towards the mainframe paradigm.
I mean, think about it. PCs became popular because their GUIs were much nicer than terminal green-screens. We went to client-server so that other-than-personal applications could have GUIs, and then to 3+ tier computing so that client-server could scale. Now, with thin clients running little more than a web browser and all the business logic running on servers, why distribute anything? It's like building terminal applications, but instead of using CICS to control terminal, we're controlling HTML terminals.
What are your thoughts on this?
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pho,
Let me answer the first part of your question and I will get to the second part of the question later.
The data persistence framework chapter really tries to be data access technology agnostic. The examples in the book use JDBC and session EJBs to implement database access. I wrote the data peristence chapter and I chose JDBC because just about everyone has some basic understanding of JDBC.
Now, one of the core dataaccess patterns I talk about is the Data Access Object (DAO) pattern. The DAO pattern abstracts the underlying data access technology used to retrieve and manipulate data away from the applications that consume it.
This way the systems architects have a lot of flexibility in what Data Access technology they use. For instance, at my current client, we started life using a JDBC-based solution. JDBC was quick and easy to use and the development team I was mentoring was very new to Java.
However, as the demands of the application grew, we found that we were spending a lot of our time writing SQL code. Because we had implemented our data access tier using the DAO and Value Object patterns (both of which are discussed in the Chapter) we were able to re-write our persistence framework to use Object-Relational Bridge (http://jakarta.apache.org/ojb). All of the applications using the framework never had a clue that we did this.
To make a long story short, the emphasis in the chapter is on the logical design of a data access tier and not on the physical implementation of the tier. Two of the core principals I always try to go for when implementing a framework:
1> Keep it simple.
2> Focus on the reuse of the class interfaces
and not the code. Code always changes,
but if you define your interfaces properly
you can easily maintain and extend an
application.
I hope that answered your question.
Thanks,
John Carnell
P.S.
I just did a talk on building a data persistence
framework at one of the local user groups.
I would be happy to send you the slides.
Let me know if you would like them.
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
VERY pleased to see a discussion on patterns. I am a Java and C# programmer who strongly believes patterns apply to any OO language. I am certainly applying many of the patterns I have learned to the .NET environment.
John, I have not YET read your book but tend to like a lot of the Wrox books. How do you recommend developers learn patterns? I have heard a lot of good discussion, one of the best ideas being learn the name of the pattern and when to use it...then refer back to code examples and the details of the pattern later. Any thoughts?
One more great recommendation. Design Patterns Explained, by Alan Shalloway is a great book and much easier to start with than GoF. In the interest of full disclosure, I do some work with Alan but can genuinely recommend his book as big help in understanding patterns (as a companion to John's of course!).
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Frank,
Your point is well-taken about us moving back to almost a "mainframe" type approach to developing applications.
I think one of the key differences though is that computing power is such that more and more people are turning to loosel-coupled "clusters" of machines to handle processing rather then one large mainframe or server.
As software architects this poses a challenge because we need to layer our applications so that they can reside on one server or multiple servers.
A common "trap" architects fall into is that a 3-tier architecture is a physical partitioning of an an application across three or more distinct servers.
In reality, a three tier architecture is a logical splitting. We should be designing our applications so that they are cleanly split between the presentation, business and data logic tiers, but more importantly we do not expose the underlying implementation details.
That is one of the most common problems I see with a lot of J2EE applications I have worked on. People build a multi-tier application, but then expose implementation details to other tiers. For instance, what if you have critical piece of business logic that is encapsulated in an EJB. This EJB is re-used across multiple applications.
At some point, you decide that this logic should be a web service. If you have exposed in your business tier that you are invoking an EJB, you need to go back to every touch point in your application and change it if you want to use it as a web-service. J2EE Design Patterns like the ServiceLocator, SessionFacade, DataAccessObject and ValueObjects, are powerful tools for abstracting away the underlying implementation details of system. Abstraction gives you the ability to change.
Sorry I got up on my pulpit and started preaching :,>
Thanks,
John Carnell
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi John,
My company currently uses J2SE, so I don't know much about J2EE. Will reading your book teach me a little about J2EE?
Thanx,
Daniel
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
-------------------------------------------------
While the J2EE Design Patterns were originally
conceived to solve problems encountered
with J2EE application development, is the use
of the term "J2EE" patterns misleading. Is it
not more appropriate to call these patterns
Distributed Application Design Patterns? Its
been my experience that most, if not all of the
J2EE Design Patterns solve problems related to
distributed and component based application
development.
-------------------------------------------------
"J2EE" may be misleading because the patterns are not specific to just J2EE applications, but I did find it helpful to have a moniker I could identify with when starting out. I think comercially it was very clever because it allowed a branding of various products, and a link directly to Java. Having started out with "Design Patterns" (Gof4), it was helpful to see the patterns applied to Java solutions.

-------------------------------------------------
Could not most of the core J2EE patterns be
applied to an environment like .NET?
By putting the focus purely on the J2EE
environment, do we limit ourselves to new
new patterns that can be used and identified?
I would like to hear everyone's thought on this. Design Patterns are supposed to be technology
independent? How does this fit with a topic like
"J2EE" Design Patterns?
--------------------------------------------------
I think this is directly related to the "line in the sand" drawn long ago that separated Microsoft and Sun idealogically. My thought is that naming a pattern and putting it in a catalogue is secondary to recognizing a pattern and being able to intuitively apply it. The naming seems to help communication in some respects, and there you definitely have a point. My experience has been that when I complete a design and we begin to develop, the pattern name references in the documentation may mean something, to maybe half of the developers coding it. If we happen to get another project together, the references mean more. It's really developmental in nature. I am sure the patterns could be used with .Net regardles of the name, programmers with only a Microsoft background may not be familiar with them at first, but then the opposite would also be true with the C# developers with a Java background. Until we all play in the same sand box long enough, these gaps will exist. Economic necessity will eventually drive some change in this area, but I hope it favors the Java side of the house since that is where I hang my hat.
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ed and MC,
I think its going to be an interesting year for the .NET programmers out there. As .NET matures they are going to be facing many of the same problems that Java and J2EE developers have encountered.
I think you are going to see a huge explosion of interest from the .NET community in design patterns. I think many of the J2EE Design Patterns currently being used are going to be readily applicable to the .NET world.
MC, I think you are dead on though with your comment about the whole "line in the sand" between Microsoft and Sun. Both the J2EE and .NET development environments are geared towards solving the same problems just with different technologies. It would make sense then that the same design patterns are the same.
Ed - I do think Alan's book is a good book. I teach a distributed Java programming class at a local technical college and one of my student's brought a copy in. I looked through and it easy a very nicely laid out and well-written book :,>
Thanks,
John Carnell
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Daniel,
This book is not a tutorial on J2EE. It already assume you have a working knowlege of J2EE and you want to step from the mechanics of J2EE and focus on the appropriate use of the J2EE technology.
Personally one of my favorite tutorials on J2EE (even though it does cover everything like JSPs and Servlets) is Ed Roman's "Mastering Enterprise JavaBeans"
Thanks,
John Carnell
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,
Some one in another post asked to me list the table of contents for the book and the patterns covered. If anyone is interested, I have included them below.
Thanks,
John Carnell
----------------------------
Hi Greg,
Below is a brief table of contents. I will contact my editor and ask him to put a more comprehensive
table of contents. Here it is:
Chapter 1: Design Patterns Applied to J2EE
This chapter is just a brief introduction to design patterns and how they can be used to solve problems.
Chapter 2: Patterns Applied to the Web Tier
The patterns covered in this chapter include:
Front Controller Pattern
Intercepting Filter Pattern
Composite View Pattern
View Helper Pattern
Service-to-Worker Pattern
Dispatcher View Pattern
Chapter 3: Patterns Applied to a Persistence
Framework
The patterns covered in this chapter include:
Data Access Object Pattern
Value Object Pattern
Service Locator Pattern
In addition, the following data access strategies are discussed:
Primary Key Generation
Concurrent Management
Transaction Management
Performance Strategies
Migration Strategies
Chapter 4: Patterns Applied to Improve
Performance and Scalability
The patterns covered include:
ServiceLocator Pattern
Value Object Pattern
Session Facade Pattern
Message Facade Pattern
Business Delegate Pattern
Chapter 5: Patterns Applied to Manage Security
The patterns covered include:
Single-Access Point Pattern
CheckPoint Pattern
Role Pattern

Chapter 6: Patterns Applied to Enable Enterprise
Integration
The patterns covered include:
Integration Broker Pattern
Integration Wrapper Pattern
Component Pattern
Integration Mediator Pattern
Virtual Component Pattern
Data Mapping Pattern
Process Automator Pattern
Chapter 7: Patterns Applied to Enable
Reusability, Maintainability and
Extensibility
The patterns covered include:

Facade Pattern
Abstract Factory Pattern
Builder Pattern
Template Method Pattern
As for the second part of your question, the book does go into some of the differences between the EJB 1.1 and EJB 2.0 specification. Particularly in Chapter 3. In that Chapter we go through a short history of why the Data Access Object Patterns and Value Object patterns came into play. We also discuss why that even with the introduction of the Local interface in the EJB 2.0 spec, these data access patterns are relevant. I hope that answers your question.
 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
Welcome to the ranch!
Janet
 
M.C. Horn
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
My situation with my current client has been rather unique. On my arrival they had implemented a Servlet/JSP application which utilized the DAO pattern for the persistance layer, and used the SessionFacade pattern in their services layer. At first I was impressed until I realized the amount of code that would have to be written each time we accessed a new table. The client had decided against an EJB solution, but apparently the original architect wanted to implement the J2EE patterns regardless. Have you ever ran into this ?
I basically simplified things quite a bit by loading the schemas from the database using DataBaseMetaData, and wrote a little dynamic persistence api that utilizes metadata to dynamically build Statements and PreparedStatements and utilized a business layer to access the database via JDBC. This eliminated both the Services and DAO layer. In this case this seemed to be a simpler solution since the client was not interested in being really distributed. They basically use MQ as the distributed "hub". I think it is very important that everyone understands what a true "distributed application" is, in regard to remote access. The client just wanted a web application to access the database via the simplest means, and instead got a muti-tiered seven headed monster. Sure, it will never handle massive numbers of users, but that wasn't in the requirements. What do you think ? Was this a mis-use of the patterns ?
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi MC,
The problem you describe is a pretty common one. On any medium-to-large Java project writing SQL code can be a huge undertaking. It can become even more cumbersome when implementing a data persistence tier using the DAO pattern.
The Data Access Patterns while a lot of work to implement really help with the long-term maintainability of the code.
Have you ever thought of using an object-relational mapping tool. A tool like that lets you map your Java objects to SQL code generated by the OR tool. There is an excellent open-source tool called OJB (http://jakarta.apache.org/ojb) that we have used in combination with the DAO patterns and we have signficantly reduced the amount of work involved with implementing a DAO.
Thanks,
John
Thanks,
John
 
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
Regarding the questions you posed to the group...


While the J2EE Design Patterns were originally
conceived to solve problems encountered
with J2EE application development, is the use
of the term "J2EE" patterns misleading. Is it
not more appropriate to call these patterns
Distributed Application Design Patterns? Its
been my experience that most, if not all of the
J2EE Design Patterns solve problems related to
distributed and component based application
development.
Could not most of the core J2EE patterns be
applied to an environment like .NET?
By putting the focus purely on the J2EE
environment, do we limit ourselves to new
new patterns that can be used and identified?
I would like to hear everyone's thought on this. Design Patterns are supposed to be technology
independent? How does this fit with a topic like
"J2EE" Design Patterns?


I think you bring up an excellent point. Patterns by their very nature should be applicable to most tool sets (albeit object oriented ones are more easily adapted...).
I believe the more diverse your experience the easier these concepts become. I think the issue is that it's difficult for developers with less experience to abstract the concepts which is why it's nice to provide them with concrete examples in a language/tool they are familiar.
Once they really understand the pattern, use it and get exposed to other platforms they SHOULD be able to translate most of them into other toolsets.
So I think there is room for technology agnostic and technology specific patterns books. The key is the reader. An experienced developer/architect should be able to extract the information from both.
I do, however (...given a recent foray into the .NET world), see the opportunity for books to help developers who must stradle the .NET/J2EE divide by working with both toolsets draw crisp parallels between the technologies so that they can be more effective and so groups working in both arenas can have more meaningful discussions. Patterns in general help that, but it would be nice if more people were more familar/conversant in the parallel services, capabilities and structures that exist in each. Having worked with VB.NET and helped teach OOD/OOP to hard core VB Programmers I've come to realize that the two camps are much closer than some people might think.
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here, Here
Byron. Excellent post :>
Thanks,
John Carnell
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Byron,
I own copies of the books you mentioned. I consider them an essential part of my collection. The main difficulty I had with those two books is that they are excellent books, but they are too formal and at times a very difficult read.
For instance, most people who read the GOF the first time walk away "kinda" understanding what design patterns are, but often times feel overwhelmed with the information presented. Same with the Core J2EE Patterns boo. Dont get my wrong, I am not critizing the content of the books just the delivery :,>.
The J2EE Design Patterns Applied book really tried to take a hands on approach and focus on how to use patterns to solve problems.
We attempted to lay the material out so that the reader could pick any one chapter and be able to walk away with enough information to be useful for their projects. I hope that answers your inquiry.
Thanks,
John Carnell
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
I agree with this statement...


In reality, a three tier architecture is a logical splitting. We should be designing our applications so that they are cleanly split between the presentation, business and data logic tiers, but more importantly we do not expose the underlying implementation details.


I am frequently suprised at how many developers do not practice design and coding practices that strive for strong cohesion and loose coupling.
I think one of the most powerful patterns relating to the reuse of the business tier is the business delegate. I know some people see this as overhead, but I appreciate the clean separate it creates and the simplicity with which it can be used my different presentation layers if implemented properly.
Regards,
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
I know what you mean about the Gof4. I don't think I would have got as much out of it had I read it early in my career. I've been in IT for 15 years and have designed/implemented on every platform from mainframe to wireless.
I didn't pick up the Gof4 until I had been programming in Java for about a year (...I've been doing java for around 5 years now), I was immeadiately struck by how many of these "magical" patterns I had already used. I was also excited to see so many of them reflected in the package/class structure of Java.
It wasn't until I started studying for the SCEA that I really pushed myself to undertand (in principle) the entire catalog. Reading the Gof4 is like a very rich dinner, you can't possibly consume it in one sitting.
Cheers,
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Byron,
I like the analogy of rich dinner. I have heard the comment over and over again about how people did not realize that they have been doing the certain design patterns in their own code.
There is nothing magical about design patterns. They formalize and capture in a distinct vocabulary about the best practices found in the industry.
Along time ago, I used to do some VB programming and use to freak out the VB developers when I would start implementing design patterns in VB. Some of my co-workers were just amazed when I implemented a Model-View-Controller framework using a single ASP page, COM components, XML and XSLT :,>
Thanks,
John Carnell
 
Author
Posts: 350
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you feel that newer version of J2EE related specifications effect the use of patterns, i.e., as the containers become more advanced some of the benefits of a pattern gets rolled into the container, thus the pattern in question becomes less relevant?
Have you used tools like Together Control Center, and XDoclet to auto generate the creation of patterns based on javadoc like meta data? If so, how do you feel this will encourage/impact the use of patterns?
[ October 01, 2002: Message edited by: Rick Hightower ]
 
Rick Hightower
Author
Posts: 350
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I almost forgot... Congrats on your new book!
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I'm new to patterns in general, does it make sense, and is it doable, to jump into learning J2EE patterns? I do happen to be involved currently in a J2EE project so I would like to learn J2EE patterns if possible. It sounds from an earlier posting that the J2EE patterns build on some of more basic patterns and that understanding of these basic patterns may be a prerequisite. Thoughts?
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rick,
Thanks for the kind words. I picked up a copy of your book when I started using Cactus on one of my projects. It was extremely useful. :,>
Some of the J2EE Design Patterns were developed in response to the problems inherent in the earlier releases of the spec (i.e. remote interfaces for database access). However, I do think that even with the release of new EJB specs, the define J2EE patterns are still extremely useful because they help enforce separation of concerns and abstraction.
The DAO pattern for instance is still a useful pattern for abstracting away physical details of the datasource you are using and the data access method you are using to get data. Thats one reason why I stand by my statement that J2EE patterns is a bit of a misnomer. I really think
many of the J2EE patterns solve problems that are encountered in all web application development efforts.
Thanks,
John
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Allan,
I would say you could still start learning about J2EE Design Patterns. With my original comments, I was trying to make the point that the learning the GOF patterns will help provide a content and history to what you see in the J2EE patterns.
The J2EE patterns evolved from the original GOF patterns.
I hope that answered your question.
Thanks,
John Carnell
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,


Along time ago, I used to do some VB programming and use to freak out the VB developers when I would start implementing design patterns in VB. Some of my co-workers were just amazed when I implemented a Model-View-Controller framework using a single ASP page, COM components, XML and XSLT :,>


I know what you mean. I've had similar experiences to what you've described. It's like the way the two groups work is fundamentatlly different. It doesn't have to be, but something about the toolsets and the way they are learned (formally or informally) tend to create this differnce. This will go away as .NET takes hold. I was amazed to find out how many of the Microsoft developers at my company had little or no OO experience. It was a trivial task for me to get started programming in VB.NET. Sure there were some syntactic differences, but they were minor. It the being aware of the constructs, concepts and how they are used that form the chasm that many of these "old time" VB programmer must leap. It's funny becuase they don't really get the benefit of abstraction yet. I had one guy complain because he "felt" like he was writing alot more code than he used to. In reality, he probably was although I would suggest that much of it was his own fumbling as he digested the concepts. What he doesn't realize is how much less code, testing he'll need to write as things change in the future. My favorite saying is, "A level of abstraction solves every problem in computer science".
Regards,
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi John,
First of all Congrats!!! for your book J2EE Design Patterns Applied ... and Wish you all the very best..
You are absolutely right that the success of a project is tied to its design rather than the tools that were used to implement it.
I agree with your point of view that there should not be constraint of technology considering the Design Patterns,it should be technology independent.
Now comming back to J2EE there are Patterns which we can only use for J2EE enironment where we have Entity Beans which is not there in .NET technology.I think since Byron mentioned that both are parallel streams so there will be lots of evloutions by specifically using these patterns in J2EE and .NET.
I think there is a nice discussion going out here as Byron mentioned about
frequently using of strong cohesion and loose coupling,that is very crucial in efficiently designing an application and checking on the dependencies between the layers.
I also strongly believe in Responsibility driven design, like assigning responsibilities to the objects using GRASP which is also not very commonly practiced.
I would like be very keen on the third and Fourth topics of your table of content Patterns Applied to a Persistence and Patterns Applied to Improve
Performance and Scalability.
Since I am doing a project having performance and one of the crucial factors.So I would like to have a point of view from you on this.
1 . It is said that when you design you application you shold not consider about performance else it leads to bad design.
2 . Also on the Persistence part have you covered JDO...
3 . Regards to persistence caching and concurrency are one of the major issues actually I have to decide whether to go with Entity beans or not since it degrades the performance.

Thanks and Best Regards
Malay
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Authors,
If we are using entity bean / Stateful session bean , if the ejb passivation is called, it should automatically destroy the the entity instance ..( By removing the particular instance in finalize block) If it has been done in EJB 2.0 , then it will be easy for Java world itself. Instead if the exception happens, even though passivate method is called internally the resources used by the bean are not released. We have to explicitly to do this ??
Is it the problem with EJB design patterns made by experts or Sun Spec fault ??
 
John Carnell
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Malay,
Thanks for the kind words on my book. Sorry I have been unresponsive. Its been a hectic morning. I will get those powerpoint slides out to you , but probably not until tonight :,>
Anyways I will take a stab at your questions:
1 . It is said that when you design you application you shold not consider about performance else it leads to bad design.
Like any advice you have to take it with a grain of salt. What the advice is getting at is that you should be optimizing every single aspect of your application for performance because it will ultimately it will lead to bad design.
However, you do still have to look for areas of easy optimization. For instance, if you have a small set of read-only data that is heavily used, does it not make sense to read it once into a cache and therefore avoid unnecessary database roundtrips?
2 . Also on the Persistence part have you covered JDO...
The persistence chapter deals with patterns that wrapper the data access technology. Using these patterns makes your application unaware of how data is being retrieved. My examples uses stateless EJBS with JDBC, but it would be a trivial matter to rip the guts out of the code and use JDBC.

3 . Regarding to persistence caching and concurrency are one of the major issues actually I have to decide whether to go with Entity beans or not since it degrades the performance.
I have traditionally stayed away from entity beans. I usually have used commerical object-relational mapping tools like TopLink or OJB. I have found that entity EJB work best when they are used in heavy volume environments where EJB clustering really makes up for the overhead imposed by entity EJBs.
I hope I answered your question. Drop me a line if you want to chat more.
Thanks,
John
 
That new kid is a freak. Show him this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic