aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes ServiceLocator in ClassDiagram of Big Smokes Cigar Shop applicaiton Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "ServiceLocator in ClassDiagram of Big Smokes Cigar Shop applicaiton" Watch "ServiceLocator in ClassDiagram of Big Smokes Cigar Shop applicaiton" New topic
Author

ServiceLocator in ClassDiagram of Big Smokes Cigar Shop applicaiton

Suresh Gopalakrishnan
Greenhorn

Joined: Aug 08, 2006
Posts: 25
Hello all,

I am currently working on the assignment, and just wondering whether I need to include the some Design Pattern classes in the class diagram ?
For example, I can include the ServiceLocator class, but I am little hesitant since it might clutter the diagram.

Thanks in advance.
Rumen Krastev
Greenhorn

Joined: Dec 22, 2008
Posts: 15
Suresh Gopal wrote:Hello all,

I am currently working on the assignment, and just wondering whether I need to include the some Design Pattern classes in the class diagram ?
For example, I can include the ServiceLocator class, but I am little hesitant since it might clutter the diagram.

Thanks in advance.

It's explicitly mentioned in Sun's site that you should include important design patterns in your class & component diagram. IMHO service locator is useless in JEE5, since injection (@EJB) removes the need of JNDI lookup, which is the main purpose of service locator.
mimi mang
Ranch Hand

Joined: Dec 02, 2009
Posts: 36
ServiceLocator is still useful for those POJO objects that are not managed objects for example Business Objects, DAO/EAOs etc. Even in web tier, I don't prefer to use Dependency Injection with annotation. because it can't logically seperate ejbs from web tier managed beans especially when you need 2 kind of presentation tier such as web client and swing client.

The problem is it really make the diagram messy. not sure if we need draw every dependency line to it...
Rumen Krastev
Greenhorn

Joined: Dec 22, 2008
Posts: 15
mimi mang wrote:ServiceLocator is still useful for those POJO objects that are not managed objects for example Business Objects, DAO/EAOs etc. Even in web tier, I don't prefer to use Dependency Injection with annotation. because it can't logically seperate ejbs from web tier managed beans especially when you need 2 kind of presentation tier such as web client and swing client.

The problem is it really make the diagram messy. not sure if we need draw every dependency line to it...


I agree, this pattern could be still useful in some special cases, but DI is essential new feature in EJB3 and behind the scene it's doing much more than just lookup (think about @PersistentContext) like CMT and CMP, therefore I always would recommend using it. About the clear separation of concerns, you can still wrap the injection in more decoupled way if you prefer, but let's remember that annotations came in JEE5 to solve some very typical issue - the bunch of boilerplate code. I would say ServiceLocator is one good example for that and when you see the new DI (JSR-299) is even further improved in JEE6, you'll see that new style of design.
About the pattern existence in class diagram, yes it could become more complex, but it might me necessary since you also would include it in sequence diagram and component diagram to show how exactly your design provide good maintainability and extensibility
mimi mang
Ranch Hand

Joined: Dec 02, 2009
Posts: 36
Good points! What I want to do is web tier will use Service Locator to locate the service provided by business tier. As for business tier itself, I prefer to use DI as long as it is available. But seems only those session beans and MDBs can use it. For example, if I use EAO/DAO pattern, I have to get the JPA entity manager by ServiceLocator. Otherwide I have to rely on the caller to pass in it to EAO because EAO is a POJO unless you use session bean as the EAO.
Rumen Krastev
Greenhorn

Joined: Dec 22, 2008
Posts: 15
mimi mang wrote:Good points! What I want to do is web tier will use Service Locator to locate the service provided by business tier. As for business tier itself, I prefer to use DI as long as it is available. But seems only those session beans and MDBs can use it. For example, if I use EAO/DAO pattern, I have to get the JPA entity manager by ServiceLocator. Otherwide I have to rely on the caller to pass in it to EAO because EAO is a POJO unless you use session bean as the EAO.

I agree completely, when we add Business Delegate and Session Facade, we've the complete picture.
J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
I agree completely, when we add Business Delegate and Session Facade, we've the complete picture.


Why do you need a Business Delegate with POJO EJBs?


SCJP, SCWCD, SCBCD, SCEA 5
Rumen Krastev
Greenhorn

Joined: Dec 22, 2008
Posts: 15
J J Wright wrote:
I agree completely, when we add Business Delegate and Session Facade, we've the complete picture.


Why do you need a Business Delegate with POJO EJBs?

Correct me if I''m wrong, but Business Delegate helps the presentation tier to decouple from the interface (usually session facade) in business layer, doesn't matter what technology is used in business tier (POJO or not). That means Session Facade and Business Delegate are like twins but stays in the opposite tiers. See the picture in http://www.corej2eepatterns.com/Patterns2ndEd/ and will understand what I mean (even Business Delegate and Service Locator are in purple, which is strange for me).
Bigwood Liu
Ranch Hand

Joined: Feb 26, 2003
Posts: 240
From "Real World Java EE Patterns", Adam Bien:

•The majority of all EJB 2.1 exceptions were checked. The EJB client had to catch, or at least know, the exceptions and became polluted with the EJB 2.1 API. The separation between business logic and infrastructural code was not given. Business Delegate fixed this issue. With EJB 3.0 all checked exceptions are optional—the business interface is identical to the external Business Delegate interface.
•Business Delegate used Service Locator to fetch the home interface and created the local or remote interface internally. EJB-related exceptions were converted to neutral system exceptions. In EJB 3.0, home interfaces became optional; the business interfaces can be fetched directly from JNDI.
•Business Delegates were used to decouple the business logic from the presentation as well. This is no longer necessary, because business interfaces can be directly injected into most of the presentation components.
 
Consider Paul's rocket mass heater.
 
subject: ServiceLocator in ClassDiagram of Big Smokes Cigar Shop applicaiton