Using EJBs in Web Dynpro Applications

[Former Member]

SAP published a document entitled <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1f5f3366-0401-0010-d6b0-e85a49e93a5c">Using EJBs in Web Dynpro Applications</a> in which they advocate creating a Data Access Command Bean to be imported into the Web Dynpro project as a Web Dynpro Model. My contention is that such an artifact is counterproductive and totally useless – PROVIDED OUR EJB PROJECT FOLLOWS INDUSTRY STANDARD J2EE BEST PRACTICES.

SAP prides itself on building systems that are open to and integrate with existing standards and best practices. In the J2EE world, this means, among other things, being aware of the patterns movement and the numerous J2EE related patterns that have been provided by the J2EE community. <a href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html">Sun's Core J2EE Patterns</a> are a good place to start to look around for some inspiration on the subject. Also a good reference is the excellent <a href="http://www.theserverside.com/tt/books/wiley/EJBDesignPatterns/">EJB Design Patterns</a> book by Floyd Marinescu.

Sins of omission, I believe, are at the source of the tutorial’s misguided advice. Had the authors been aware of the <a href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html">Business Delegate</a> pattern, and had they implemented it on the J2EE side of their example application (as I believe should be the case on pretty much any J2EE project), they would almost certainly have realized that their Data Access Command Bean component had become totally redundant.

Since the J2EE example supplied by the tutorial totally ignores the Business Delegate pattern, the Web Dynpro client is forced to interact with the Session EJB directly. This is not considered good J2EE design as it requires some rather inelegant lookup logic in the client code :

 
//looks up the session bean and creates the Home interface 
try 
{ 
  InitialContext ctx = new InitialContext(); 
  home = (BonusCalculatorLocalHome)ctx.lookup("localejbs/MySessionBean"); 
  theCalculator = home.create(); 
} 
catch (Exception namingException) 
{ 
  namingException.printStackTrace(); 
} 

Functional, yes, but a bit complex with all this lookup code, the JNDI names to be used, the different connection mechanisms to be used depending on if the EJB is local or remote, etc… These facts alone justify the need for some sort of abstraction layer to shield the main application from these implementation details. This is how, on page 9, the authors of the tutorial articulate their justification for introducing their Data Access Command Bean :

<blockquote>

"...we require an access layer (intermediate layer) consisting of JavaBeans that encapsulate access to the back-end system. This kind of intermediate layer, therefore, forms a high-level component that lies between the business logic and a Web Dynpro application that serves as an EJB client.

It also serves to hide all low-level aspects of the application such as data acquisition logic or details regarding the storage of persistent data and to decouple them from the EJB layer."

</blockquote>

This is how the <a href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html">Core J2EE Patterns Catalog</a> present the motivations for introducing the <a href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html">Business Delegate</a> pattern :

<ul>

<li/>Presentation-tier clients need access to business services

<li/>Different clients, such as devices, Web clients, and thick clients, need access to business service.

<li/>It is desirable to minimize coupling between presentation-tier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access

</ul>

Strangely similar, wouldn’t you agree ? Sort of gives you a hint that one of these components might be superfluous - not a good idea to have two components in the same application that both have the same role & responsibilities...

In a well designed J2EE application, the use of Business Delegates is strongly encouraged. This encapsulates and isolates in one place the logic and mechanisms of communicating with the back-end… for the benefit of ALL potential clients – not just one particular Web Dynpro application. What one must realize, however, is that once this standard EJB access mecanism in set in place, the rational for building and deploying the Data Access Command Bean becomes moot ! Let me illustrate by referring to the actual code that is supplied by the tutorial... on page 26, we are instructed to code the following in the relevant event handler :

 
/** declared validating event handler */ 
public void onActionSubmit(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent) 
{ 
  //@@begin onActionSubmit(ServerEvent) 
  wdContext.currentMyCommandBeanElement().modelObject().execute(); 
  //@@end 
} 

The code to the execute method of the CommandBean can be found on page 14 :

 
public void execute() 
{ 
  // Calls the calculateBonus method of the session bean 
  // which calculates and returns the bonus 
  try { 
     this.bonusAmount = theCalculator.calculateBonus(multiplier); 
  } catch (Exception e) { 
     e.printStackTrace(); 
     return; 
  } 

  // Calls the storeData method which tries to store the calculated bonus 
  // and the corresponding Social Security Number in the entity bean. 
  try { 
     this.message = theCalculator.storeData(this.getBonusAmount(), 
                                            this.getSsn()); 
  } catch (Exception e1) { 
     e1.printStackTrace(); 
  } 
} 

Now here is how I would code the event handler by using the business delegate:

 
/** declared validating event handler */ 
public void onActionSubmit(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent ) 
{ 
  //@@begin onActionSubmit(ServerEvent) 
  try 
  { 
     // get reference to business delegate 
     BonusCalculationBizDelegate delegate = new BonusCalculationBizDelegate(); 

     // fetch value of multiplier as entered by user 
     double multiplier = wdContext().nodeMyModel().getMultiplier(); 

     // call the calculateBonus method of the business delegate 
     // which calls the calculateBonus method of the session bean 
     // which calculates and returns the bonus 
     double bonusAmount = delegate.calculateBonus(multiplier); 

     // call the storeData method which tries to store the calculated bonus 
     // and the corresponding Social Security Number in the entity bean. 
     String ssn = wdContext().nodeMyModel().getSSN(); 
     this.message = delegate.storeData(bonusAmount, ssn); 
  } 
  catch(Exception e) 
  { 
     e.printStackTrace(); 
  } 
  //@@end 
} 

Notice that there is no Command Bean to be found anywhere in the code ! Notice also that NO FUNCTIONALITY WHATSOEVER has been taken away. The code is no less flexible than before, and certainly no less maintainable (it’s arguably MORE maintainable…)

In the process, we’ve rendered obsolete the following tasks:

<ul>

<li/>creation of the Command Bean

<li/>creation of the Command Bean properties

<li/>creation of the Command Beans getter/setter methods

<li/>creation of the java DC that houses the Command Bean

<li/>creation of the java DC api public part

<li/>creation of the java DC assembly public part

<li/>creation of a Used DC association between the Web Dynpro DC and the Java DC api public part

<li/>creation of a Used DC association between the Web Dynpro DC and the Java DC assembly public part

<li/>possibly also creation of a use relationship between the Web Dynpro DC and Java DC compartments

</ul>

Though I concede that one could, in principle, argue that the choice of using either a Command Bean or a Business Delegate to communicate with the EJB Session is a trivial one, and more a matter of personal taste, I have seen several projects where BOTH patterns are present in the design ! And that is not a matter of personal taste, but arguably wasteful and inefficient engineering practices, as I think I have just demonstrated.

Now, one may ask, if the Command Bean goes away, what are we to use as the basis for our Web Dynpro Model ? We do need some java-based data structure on which to bind elements of our Web Dynpro Context, right ? My answer to that is to use another well-known J2EE pattern; namely the <a href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html">Data Transfer Object</a> (also simply known as the Transfer Object and/or Value Object).

These serializable classes are used by J2EE applications precisely to encapsulate business data in a manner that can be marshaled across processes and application tiers. Why not push that concept to the limit and extend the DTO’s realm right into the heart of Web Dynpro Context ? I think you’ll find that most presentation screens will contain presentation elements that mirror very closely the business data that it needs to manipulate – the very stuff that DTO classes are made of ! Why go through the manual steps of creating properties and associated getters and setters on some superfluous Command Bean (as has been recommended on pages 12 and 13 of the tutorial) when that work has already been done in the DTOs ? Perfect opportunity for reuse !

I myself have been able to import DTOs directly into my Web Dynpro application by means of the Java Beans Model Import Wizard. The resulting Model was quite useful in helping me define perfectly appropriate Web Dynpro Context structures for the needs of my application. Still, it is probably preferable to create a ModelBean (as opposed to a CommandBean) to import as a Web Dynpro Model. In the simplest case (and the most common, I believe), you can merely declare a ModelBean class that extends the required DTO :

 
package com.yourcompany.yourproject.wdp.modelbean; 

public class MyModelBean extends MyBusinessDataDTO 
{ 
} 

This simple class can be created directly in the package structure of your Web Dynpro application – thereby avoiding the need to create yet another stand-alone DC to pollute the global namespace. This ModelBean class does the job… but more importantly in the context of this discussion, it does so WITHOUT the need to create any CommandBean. We're able to reduce the amount of manual coding by reusing the work that’s already been done and made available by our well-designed EJB application.

I guess my ultimate question to the experts, in general (and to SAP in particular, since they’re the ones who are pushing this Command Bean proposition) would go something like this : Taking into account that a well designed J2EE application should provide your Web Dynpro application with a suitable Business Delegate and domain-specific Data Transfer Objects, does SAP still stand behind its recommendation of going through the elaborate process of building a separate and distinct Data Access Command Bean to serve as a Web Dynpro Model ? If so, why ? To what advantage ? As compared to, let’s say, replacing it with the already available Business Delegates and DTOs ?

[former_member185086]

Hello Romeo

Reason is the way you have posted the Qestion.Please follow the standard of the forum, It should be Precise and clean.

I am sure then you will get immediate responce.

Best Regards

Satish Kumar

[ankur_garg5]

Hi Romeo,

You would be disappointed, this reply ain't anywhere nearby to what you are talking about...

I wanted to mail you, but you have not mentioned your email in your profile.

I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.

Anyways the ball is still in your court

As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...

Bye

Ankur

[Former Member]

I posted that question over a month and a half ago. Not only didn't I get any answer, I didn't get the slightest response... not a peep. no one seems to know.

I did some thinking and exploring since then. I think I've come up with my own answer... sort of... not the answer to "What are the advantages of using a CommandBean as a WDP Model ?"... I don't believe there <i>are</i> any convincing arguments to support that assertion... at least, none I've heard or read thus far...

I did come up with some ideas, though, on what are the advantages of using a javabean Web Dynpro Model. For those of you that the might be interested by this subject matter, I posted a small to try and explain my viewpoint.

Regards to all

... points are still available on this one...