• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Do we need DAO to access webservice from SLSB?

 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

In Cade & Sheil example in the 3rd sequence Diagram "Email Server" has been added and "sendMessage" is called on the "Email Server". Should it there be EmailDAO instead of external system? "

Because we are referencing webservice into session bean by @WebServiceRef annotation, hence I dont think there is any scope of introducing DAO, but then any external datasource should be accessed using DAO. Right?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Probably I am not clear with my query, hence rephrasing the question...

Do we need DAO in between, when we access External System from Stateless session bean by using @WebServiceRef annotation?

I tried to search answer of this by using Google, but could not get needed information. Any help on this is much appreciated!

Thanks!
 
Sharma Ashutosh
Bartender
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For accessing an external system which is exposed via Webservices - you need a WS client at your end. This WS client will get control from your service facade or service layer.

Presentation Tier Components--> Service Facade -->WS client -->External WS
This will provide layer of abstraction also.
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ashutosh for the reply!

That WS client can be an SLSB with @WebServiceRef annotation, right?

My flow will be like this

JSP -> Controller -> Business Delegate -> SLSB containing business logic -> SLSB as WS client (@WebServiceRef annotation) -> External system (ex:- Inventory System)

Anyone who see problem in this design, please reply.
 
Krzysztof Koziol
Ranch Hand
Posts: 133
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the role of Business Delegate in the presented flow?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmm.. Good question

I am not able to identify any particular code that should be part of Business Delegate, but it is standard practice to invoke any SLSB from presentation tier through Business Delegate, Right?

So Business Delegate will only contain method call to invoke SLSB containing business logic. Please inform if anything is wrong with this approach.

 
Zm Mohammed
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are two SLSB necessary in your flow? My design has only one SLSB which is acting as WS client.
 
Nilessh Ganu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant Desai wrote:hmm.. Good question

I am not able to identify any particular code that should be part of Business Delegate, but it is standard practice to invoke any SLSB from presentation tier through Business Delegate, Right?

So Business Delegate will only contain method call to invoke SLSB containing business logic. Please inform if anything is wrong with this approach.



Earlier, I had thought off a proxy SLSB to access a WS Client SLSB(post). I was thinking of hiding/separating the WS Client from the business logic that consumes the data from WS. Share your thoughts on it.

As mentioned by Ashutosh, a service facade class can be good enough. But will it be scalable if it's going to be hit by several threads simultaneously?
 
Nilessh Ganu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant,
Any comments on service facade usage ?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nilesh,

I dont see any scalability issue if we use "sessionfacade", which is a type of service facade. Becasue it is a session bean anyway. so its scalability will be managed by EJB container.

Details are available at http://www.corej2eepatterns.com/Patterns2ndEd/ServiceFacade.htm

Hi Mohammed,
Having only one SLSB which is acting as WS client is fine, but then where will you put your business logic?
I have considered two SLSBs because one SLSB will have business logic and part of Business tier, where as secong SLSB will act as WS client and will be part of Integration Tier (Separation of concerns).

And any way calling method of WS client SLSB from Business tier SLSB will not sacrifice scalability also, and is perfectly ok.

Please reply if any one see any issue with this design. Thanks!


 
Nilessh Ganu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant Desai wrote:Hi Nilesh,

I dont see any scalability issue if we use "sessionfacade", which is a type of service facade. Becasue it is a session bean anyway. so its scalability will be managed by EJB container.

Details are available at http://www.corej2eepatterns.com/Patterns2ndEd/ServiceFacade.htm

Hi Mohammed,
Having only one SLSB which is acting as WS client is fine, but then where will you put your business logic?
I have considered two SLSBs because one SLSB will have business logic and part of Business tier, where as secong SLSB will act as WS client and will be part of Integration Tier (Separation of concerns).

And any way calling method of WS client SLSB from Business tier SLSB will not sacrifice scalability also, and is perfectly ok.

Please reply if any one see any issue with this design. Thanks!



Gurkant, did you went ahead with the 2 SLSB approach ?

SLSB1 in business tier(session facade) >> SLSB2 in integration layer(WS client) >> WS(External system)

Since SLSB2 will be injected in SLSB1, don't the combination(SLSB1 + SLSB2) look like a proxy pattern with SLSB1 acting as a proxy to real subject(SLSB2)?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nilessh,

Yes, I am still considering this approach.

But in Cade's book they have not shown "WS client" in any of the diagrams. Hence I am planning to adopt same approach and I will not display "SLSB2 in integration layer(WS client)" in any of my diagrams.

"SLSB2 in integration layer(WS client)" will act as a proxy class to access Webservice through JAX-WS API (SOAP Message).
But rather than acting only as proxy to SLSB2, SLSB1 in business tier will also contain actual business logic.

Please reply if anyone see any issue with this approach.
 
Saket Mittal
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant Desai wrote:Hi Nilessh,

Yes, I am still considering this approach.

But in Cade's book they have not shown "WS client" in any of the diagrams. Hence I am planning to adopt same approach and I will not display "SLSB2 in integration layer(WS client)" in any of my diagrams.

"SLSB2 in integration layer(WS client)" will act as a proxy class to access Webservice through JAX-WS API (SOAP Message).
But rather than acting only as proxy to SLSB2, SLSB1 in business tier will also contain actual business logic.

Please reply if anyone see any issue with this approach.


Hi Gurukant,

what benefit will an SLSB2 will bring as a webservice client when compared to a POJO client ?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Saket,
Implementing WS-Client as SLSB will improve scalability because its instance will then be maintained by container.
 
Nilessh Ganu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant Desai wrote:Hi Saket,
Implementing WS-Client as SLSB will improve scalability because its instance will then be maintained by container.


I am also in dilemma to use SLSB or a POJO.

SLSB has advantages:

1. SLSB2 will have simplicity with @WebServiceRef, no plumbing code to webservice.
2. Probably more scalability with SLSB pools/container-managed?
3. We can inject SLSB2 directly into SLSB1, if you want to keep the business logic separate from 'webservice integration code'.

Considering above it looks SLSB1(business) + SLSB2(WS integration) should be used ?
 
Gurukant Desai
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Nilessh for highlighting other benefits of using SLSB as WS-Client!

Saket, Please check below mentioned thread for more information.
http://www.coderanch.com/t/542955/java-Architect-SCEA/certification/Who-didn-SLSB-DAO
 
Saket Mittal
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurukant Desai wrote:Thanks Nilessh for highlighting other benefits of using SLSB as WS-Client!

Saket, Please check below mentioned thread for more information.
http://www.coderanch.com/t/542955/java-Architect-SCEA/certification/Who-didn-SLSB-DAO


Thanks Nilesh and Gurukant,

#1 and #3 sound good but I am not too sure that SSB1+SLSB2 would add scalability ( in fact I am thinking it could be less scalable because now the container has to do more work by managing an additional resource).

If this a design pattern ? can you please point me to the documentation if you have any ?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic