• 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

BigSmoke inventory - Adapter or Facard?

 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Dear Ranchers,

BigSmoke has an existing inventory system which is assumed to be intact as per my design proposed for their system enhancement. So I decided to use an Adapter to interface with inventory system as that would abstract inventory. Is this a right approch? What do you guys think.

warm regards
-Sandeep
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Abstraction through interfaces is always an optimal design. It sounds good to me!

-Cameron McKenzie
 
Sandeep Krish
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Cameron.
Do you think a business delegate is an overkill between the Adapter and Front controller? That is how i designed and the reason was to take care of exception and to abstract out the business method further. Adapter handling the business method exception dosen't look so good for me.

Have a good day
-Sandeep
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I always use a business delegate.

-Cameron McKenzie
 
Sandeep Krish
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you again.

-Sandeep
 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I always use a business delegate.



Why? In EJB 3.0 the business interface is precisely that - the business interface. It doesn't throw checked infrastructure-related exceptions like EJB 2.1. In EJB 3.0, the business delegate and the EJB interface end up being identical, in which case there's no value in introducing a new layer. How does business delegate fit in with frameworks like Seam / WebBeans?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

That is how I designed and the reason was to take care of exception...



What exceptions are you taking care of? Business (i.e. application) exceptions should be propagated to the client, otherwise there's no point in throwing them. The original intent of Business Delegate was to handle infrastructure related checked exceptions like RemoteException, FinderException, or CreateException. As I mentioned in my previous response, these exceptions don't exist in EJB 3.0.

... and to abstract out the business method further



Why? If you need to further abstract the interface of a boundary class, surely there's something wrong with the original interface. It sounds to me like you're mixing up Business Delegate with Service Facade.

Adapter handling the business method exception doesn't look so good for me.



That depends on where you want to introduce failover. I don't think Business Delegate was ever intended for that purpose. Proxy - yes, Business Delegate - no.
 
Sandeep Krish
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What exceptions are you taking care of? Business (i.e. application) exceptions should be propagated to the client, otherwise there's no point in throwing them. The original intent of Business Delegate was to handle infrastructure related checked exceptions like RemoteException, FinderException, or CreateException. As I mentioned in my previous response, these exceptions don't exist in EJB 3.0.



I am so used to EJB2.0 and did not remember the new feature available in EJB3! But still business delegate holds good due to following reasongs
1. 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.
2. Clients may need to implement caching mechanisms for business service information.
3. It is desirable to reduce network traffic between client and business services.

Why? If you need to further abstract the interface of a boundary class, surely there's something wrong with the original interface. It sounds to me like you're mixing up Business Delegate with Service Facade.


I too felt that there is something wrong the original interface and that is the very reason I posted this message! Service Facard is new for me so need to study that first before making any comments.

That depends on where you want to introduce failover. I don't think Business Delegate was ever intended for that purpose. Proxy - yes, Business Delegate - no.


I agree that BusinessDelegate is not intended for this purpose but since I decided to use it, I felt the extra functionality would beef up the Business Delegate.

Regards
-Sandeep
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Dependency injection solves this problem.

2. Clients may need to implement caching mechanisms for business service information.
3. It is desirable to reduce network traffic between client and business services.



Remote clients.

I too felt that there is something wrong the original interface and that is the very reason I posted this message!



If you feel the interface is wrong then you need to go back and clearly define the boundary classes in the business tier. I don't see Business Delegate as the way to fix a poorly designed service.

Good luck
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Really good points by Jonathan and Sandeep.

Indeed, with EJB3, many of the tried and true design patterns have much less significance than they did in the past.

I actually put together a thread on Which Design Patterns are Not Needed in JEE5. It's an interesting discussion.

-Cameron McKenzie
 
Sandeep Krish
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Cameron and Jonathan! I am revisiting design.
 
this llama doesn't want your drama, he just wants this tiny ad for his mama
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