• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do we need to show BD & Service Locator in Sequence Diagrams?

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I put Business Delegates for all services, My Seq. diagram is becoming big and readability is lost.

Can I avoid putting BD and just attach notes saying 'Business Delegate and Service Locator is used to get the Sevice'?

SCEAs, Can you please share your suggestions.

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

Originally posted by Johnty Rhodes:
If I put Business Delegates for all services, My Seq. diagram is becoming big ...


You probabely have N business Sequence diagrams? All using the same 1 BD&SL classes?
In such N:1 cases consider to construct 1 additional technical Sequence diagram (not the comon business sd I talked about in a previous post) in which you show
- the one interface of all the clients with a note "can be any of ..."
- the client-side Business Delegate used by all clients
- the client-side Service Locator
- the Session Facade and / or ...
- ... the business / workflow Session EJB (or the one interface of multiple Session EJBs) ...
- ... and / or business handlers ...
- ... with a note "can be any of ..."
- the server-side Business Delegate(s)
- the server-side Service Locator(s)
- server-side proxies, DAOs, etc. like for payment, external systems etc.
- and whatever you think is worth to be shown in between.

You need not and should not show these technical details in each business SD. But in my opinion you should show them in one. Maybe using ref, or even (without ref) as a technical overall view in parallel to what your business SDs show.


Originally posted by Johnty Rhodes:
Can I avoid putting BD and just attach notes saying 'Business Delegate and Service Locator is used to get the Sevice'?


The next idea could be to just show one client and one server-side do-what-I-mean component and providing the logic in notes instead of in sd messages - in extreme.
I think that is not a good idea, and hopefully it would cost points, because SCEA exam is not just a Business Architect exam but an "Enterprise Architect for J2EE Technology" exam, even if later some will specialize as Business Architect, some for security, some as Technical Architects, some more for Servlet techniques, some more for GUI techniques, etc. .

Thomas
[ July 01, 2006: Message edited by: Thomas Taeger ]
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

- the one interface of all the clients with a note "can be any of ..."
- the client-side Business Delegate used by all clients



If there are N services, then there will be N business delegates.
Service Locator will be only one.

Please let me know whether my understanding is correct.

If yes, then in Tech SD also, we will end up putting all business delegates
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How do we define "Service"?
- Pretty sure not each usecase-level business operation.
- Maybe a largest-most remote business method callable in one single server turn-around.
- Maybe even more coarse grained, like "everything concerning to ordering", i.e. preselecting and selecting and sending an order and getting a confirmation and ...?
Do you know an exact definition of the term "Service"?
Or what is yours?


Originally posted by Johnty Rhodes:
If there are N services, ...


I assume you talk about business services here.


Originally posted by Johnty Rhodes:
... then there will be N business delegates.


Our vision of a Business Delegate differs.
For me a Business Delegate usually comes in pair with a Session Facade. Because Session Facades conceptually are coarse grained, in my thinking the Business Delegate is coarse grained too. There for decoupling reasons may be two Session Facades, e.g. one for miles (should be argued ...) and one for the rest, or just one Session Facade for all. So for my thinking in "pairs" there might be two or one Business Delegate in the client.

Before answering the rest I should wait for your definition of "Service".

Thomas
[ July 01, 2006: Message edited by: Thomas Taeger ]
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Service is Business Service.

For example, in an application for a Company A, there can be following services
1. EmployeeService - For Maintenance (add/view/modify/delete)
2. OrderService - add/view/modify/delete/process
3. SalesService - add/view/modify/delete
4. BenefitsService
5. ProductService


So for all these service, I will have BusinessDelegates.

From http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

Use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architectur


BusinessDelegate pattern is not for providing coarse grained service...i think it is the fuction of Facade.
[ July 01, 2006: Message edited by: Johnty Rhodes ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for providing your examples of 5 services. Each of your services provides more than one operation.

Originally posted by Johnty Rhodes:
BusinessDelegate pattern is not for providing coarse grained service...i think it is the fuction of Facade.


It is not for, ok. But what I want to show is: Business Delegate does best decouple if you apply it in a coarse grained way.


The cited description of a Business Delegate
- mentions the technical lookup, ok
- but leaves undecided how this hiding of the underlying implementation details is designed (and later implemented).


Originally posted by Johnty Rhodes:
So for all these service, I will have BusinessDelegates.


... or as you said before "If there are N services, then there will be N business delegates." So you would provide 5 Business Delegates here.

I agree that this is one way to apply the Business Delegate pattern correctly. But is it the best way or even the most adjacent / natural / usefull one?:

In big projects having a client developer team and a server developer team the Business Delegate is designed and coded by the server team and passed as a .jar to the client team. This is the praxis of decoupling here! The client team needs not and can not care about what methods should be provided by the Business Delegate. The server team does that because they best know how to minimize server turn-arounds. The client team just adds the jar and calls the methods of the Business Delegate provided by the server team (though running in the client).

If the server team has to decide
a) which operations to provide in which Business Delegate and
b) how many Business Delegates to provide,
then they most naturally think in what they provide in the Session Facade(s) and provide the same in the Business Delegate(s). That is where my "thinking in pairs of Business Delegate and Session Facade" comes from. It is just practical.

I even would say that Sun's description of a Business Delegate should also mention this practical pairing of Business Delegate and Session Facade as a strategy of the Business Delegate pattern.
P.S.: The "Delegate Proxy Strategy" (Core J2EE Patterns, p. 253) is most similar: "In this strategy, a Business Delegate provides proxy function to pass the client methods to the session bean it is encapsulating".

And for the assignment this pairing makes life easier. Business Delegate and Session Facade implement the same business interface! So in Sequence diagrams
- you can show this interface where the Business Delegate is needed and
- you can show this interface where the Session Facade is needed and
- you never need to worry that Business Delegate and Session Facade could get out of sync with each other.

Thomas
[ July 01, 2006: Message edited by: Thomas Taeger ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic