BusinessDelegate and ServiceLocator Design Pattern

Hi guys,
I have a question about the BusinessDelegate Pattern.
I would like to know where the BusinessDelegate and the ServerLocator implementation must be done?
On the client or on the server side.
Let's suppose I have a simple java client which calls a method on a Remote EJB deployed on an EJB server on a different machine.
The BusinessDelegate and the ServerLocator implementation must be either bundled with the client jar or
in the client classpath.
Is it correct??
Otherwise, if they are on the server side (part of the EJB jar) the client will never succeed in calling the BusinessDelegate method because the JNDI Lookup is done on the server side and the client has no way to see the BusinessDelegate on the Remote server.
Is it correct??
Please, help me understand this pattern.
I see all the time on the Diagrams the BusinessDelegate and the ServerLocator on the server side.
Thank you very much.
iako73

Hi,
The business delegate's purpose is to abstract the business tier implementation from the client.
It is used in the web tier (or any presentation tier) to hide the business service behind an interface, reducing the coupling between application layers.
If the business tier is implemented as EJB's or any J2EE container service accessible through JNDI. The Business delegate implementation uses the Service locator pattern to abstract and hide all JNDI calls from the delegate.
Hence both patterns are applicable and used in the presentation tier.
See core J2EE patterns for full description : http://java.sun.com/blueprints/corej2eepatterns/Patterns/

Similar Messages

How to create plug and play design pattern on a environment

Hi All,
Help me to get a best design for my problem statement.
Problem Statement: I have to create a platform where I should be able to plug and play different components. explaining better with example
Example:
1. I have to create a platform for school
2. In this school platform we have to plug in multiple components like "Student", "Teacher", "Subjects", "ClassPeriods" etc.,
3. These components should be easily plug/unplug and play
4. Like, the component "ClassPeriods" want to purchase from Vendor 1 and plug it to "School" platform it should work.
5. Incase if we want to unplug the "ClassPeriod" component provided bfy Vendor 1 from "School" platform and want to plug the "ClassPeriod" from Vendor 2. then the Design should support without any extra effort.
Suggest me the best design pattern for the problem
This design pattern is for ASP.Net
Thanks,
S.Kannan

Sounds like you're looking at 'Composition'. As a background, and possible solution, take a look at MEF;
http://mef.codeplex.com/
http://pauliom.wordpress.com

JavaBean Models, Command Bean and J2EE Design Pattern

Hello,
I have read the available "How To", Using EJBs in Web Dynpro Applications where the author mentions that one should use a Command Bean (according to J2EE Design Patterns) so that one can invoke business methods in a Session Bean from our Web Dynpro Application. Well, although, I have read some available articles in the internet about J2EE design patterns, I still have some questions about command beans and its usage in Web Dynpro applications.
I have developed a WD App which uses EJBs to read data from the DB.
Let's suppose I only have two tables: BOOKS and AUTHORS.
Lets also suppose I have to Entity Beans (one for each table) and a Session Bean with two methods: Book[] getAllBooks() and Author[] getAllAuthors();
I also have a Command Bean which I imported in my WD App.
My questions are:
How should I design my Command Bean?
Can I have only one Command Bean with two methods each calling one of the methods of the Session Bean?
Or instead should I design two Command Beans, one for each call?
In the last case do the methods must be named <b>execute</b> or can I name them whatever I want?
Furthermore, how should I store the data in my command bean? In instance variables?
If so, can I use array of a class representing a record in the database table (for instance, classes Book and Author) or do I have to store the data in a generic collection (such as ArrayList for instance)?
I ask this last question because if I try to store the data in an array when I am importing the Command Bean as a JavaBean model I always get an error.
One last question: Can the Command Bean execute method directly return the data or should I always store the data in an instance variable an then get it using getter methods?
I know this questions are more about J2EE Design Patterns and JavaBeans specification than they are about Web Dynpro but I also have doubts about the rules that the command bean must obey in order to accomplish a successful JavaBean model import in WD.
Some guidance or tips would be highly appreciated.
King Regards

I have the same problem.
Does anyone know the solution?
Thanks
Davide

Difference between n-layer software architecture and MVVM design pattern?

hello everyone,
I am not clear with this concepts of Software architecture pattern and design pattern.
I am developing an wpf application using MVVM. Now, my question is, does MVVM come under n-layered architecture?
or n-layer architecture and MVVM both are different?
Regards,
Rakesh.N
Rakesh murthy

"
Now my question is, i want to process the data which i get from database. where should i write that processing logic after getting the data from database? in model classes? or in view model classes?
The model is however the data comes from wherever it comes from.
If there is any processing after you get it then that would be in the viewmodel.
The viewmodel adapts your data to the view.
If it needs any adapting then the viewmodel does that, not the model.
EG here
protected async override void GetData()
ThrobberVisible = Visibility.Visible;
ObservableCollection<CustomerVM> _customers = new ObservableCollection<CustomerVM>();
var customers = await (from c in db.Customers
orderby c.CustomerName
select c).ToListAsync();
foreach (Customer cust in customers)
_customers.Add(new CustomerVM { IsNew = false, TheEntity = cust });
Customers = _customers;
RaisePropertyChanged("Customers");
ThrobberVisible = Visibility.Collapsed;
That logic is in a viewmodel.
in this context , in which layer the viewmodel and model classes are put under in n-tier architecture?
They're in two of the n layers/tiers.
Or they're in one.
Depending on how someone decides to classify a layer or a tier.
There is no absolute definition.
Why would you care?
Hope that helps.
Technet articles: Uneventful MVVM;
All my Technet Articles

BusinessDelegate and Value Object Patterns

I have just embarked on the facinating world of J2EE. My questions are very simple:
Why would I use a BusinessDelegate pattern? What is it and why have this extra tier?
Finally, why would I use a Value Object? What are they? How would I use them in practice?
As you can see I am a total novice and would appreciate expert advice. Thanks in advance.

Why would I use a BusinessDelegate pattern? What is it
and why have this extra tier?Well, there are always some extra "plumbing" work involved when calling business services, especially if they are located in remotely hosted EJBs. You need to create your JNDI-context, perform a lookup, do narrow()-operations etc. etc.
Now this is implementation-specific stuff, that your presentation tier doesn't really need. No, it's only concerned about sending some values to the business-logic tier, and retrieving the results and acting upon them (usually formatting and displaying them to the end-user at some way).
If you wouldn't have BusinessDelegate as an extra insulation layer between your presentation and business tiers, you'd end up cluttering your presentation code with unnecesessary implementation-specific stuff. When you have a BusinessDelegate, you can isolate all the dirty work into it, make it configurable somehow, and just call it from your Servlets/JSPs/Applets whatever.
So instead of this:
InitialContext ctx = new InitialContext();
Object home = ctx.lookup( "com.company.myproject.ejb.FirstBusinessBean" );
FirstBusinessBeanHome narrowedHome = (FirstBusinessBeanHome)PortableRemoteObject.narrow( home, FirstBusinessBeanHome.class );
FirstBusinessBean remote = home.create();
// Only now you get down to the real business.
String[] initialValues = remote.readInitialValues();
// And so on.
// Some stuff like try..catch suppressed for readability.You can do something simple as this:
EJBDelegate myDelegate = EJBDelegate.getInstance( MyBeans.FIRST_BUSINESS_BEAN );
String[] initialValues = myDelegate.readInitialValues();
Finally, why would I use a Value Object? What are
they? How would I use them in practice?A value object is an object whose sole purpose is to represent a value (or a bunch of values). In the previous example, if you needed to get a list of persons from you database, and one person is represented as one entity bean, at first you'd probably end up getting a collection of PersonEntityBean's remote interfaces as a result of some ejbFindBy()-query method.
Now if you are running on a true distributed enviroment, when you iterate through this collection, displaying the persons ie. on a JSP page, every getFirstName(), getLastName(), getTitle() etc. call could potentially be a remote method call, adding a tremendous amount of extra overhead. This of course depends entirely upon your app servers implementation.
But if you replace your Remote interfaces with a simple Value object, for example PersonVO, it could be as simple as this:
public class PersonVO
    String firstName, lastName, title;
    public PersonVO( String firstName, String lastName, String title )
        this.firstName = firstName;
        this.lastName = lastName;
        this.title = title;
   public void getFirstName() { return this.firstName; }
   public void getLastName() { return this.lastName; }
   public void getTitle() { return this.title; }
}Instead of a collection of remote interfaces, you return these from your business method, and use them for displaying in your presentation logic. Simple, clean and fast.
Oh, and notice that the VO is immutable. This is a done on purpose.
Another point where a VO is really helpful that if you have ie. two different tables in your DB, represented by two different Entity Beans (Person and PhoneNumber for example), which have a relation at the database. With a VO, you can package data from multiple entities into a single object, instead of having to deal with a multitude of different entities and their remote interfaces.
I could go on for hours about this, but I guess I'll have to do some productive work as well. Anyway, these patterns are tried and tested, any believe me, they make the job a lot easier when properly implemented.
.P.

UML and Java Design Patters

I am new to UML and Java Design Patterns
Please suggest some good books for UML and Java Design Patterns.
Venu

I am new to UML and Java Design
Patterns
Please suggest some good books for UML and Java
Design Patterns.
VenuThere are only a few of them:
http://www.amazon.com/gp/product/0596007124/ref=pd_bxgy_text_b/102-9140088-0344105?%5Fencoding=UTF8
http://www.amazon.com/gp/product/0130935387/ref=pd_sbs_b_3/102-9140088-0344105?%5Fencoding=UTF8&v=glance&n=283155
http://www.amazon.com/gp/product/0471227293/ref=pd_sim_b_5/102-9140088-0344105?%5Fencoding=UTF8&v=glance&n=283155
http://www.amazon.com/gp/product/0201485397/102-9140088-0344105?v=glance&n=283155

Need a Effective Design Pattern for Different Validation methods ???

Hi All,
I am having different validation methods with separate functions. I like to know the Best and Effective Design Pattern to do this.
for example
validateUserId()
validatePassword()
validateAuthentication()
validateSession()
validateConnection()
.... etc......
Can anybody help me to solve this?
Thanks,
J.Kathir

Hi there - is this the kind of thing you wanted?.
This structure has served me well. There is quite a lot to it and lots you need to infer but you should be able to work it out!
It works for EJB & swing etc (I believe)..
It doesn't use exceptions to return validation messages.
It doesn't use lots of little objects. The code is very explicit & pretty simple.
public class PersonValidator
Person myData;
public PersonValidator() {
//personId will be 0 and we are in nsert mode
myData = new Person();
public PersonValidator(long personId) {
//personId will have a value and we are in update mode
myData = PersonDb.getPerson(personId);
// =================================Single field validation
// =================================For swing apps to call - not over network.
// =================================Use validateData method
public String validateDateOfBirth(String dataOfBirthStr) {
String msg = "";
msg = validateDateStr(dataOfBirthStr);
if (!msg.equals("")) return msg;
public String validateSurname(String surname) {
String msg = "";
if (surname.equals("")) return "surname must be entered";
//=============================================Cross Validation
public List crossValidateAndSave(boolean saveData) {
String msg = "";
List valerrs = new ArrayList();
if (surname.equals("Collins") && dateOfBirth.compareTo("???")) {
List.add("Candidate is lying about their age. Please enter a realistic Date of birth");
if (valerrs.size() == 0) {
if (saveData()) {
personDb.saveData(myData);
// =========================To validate across the netwrok this lets you
// pass all the data in 1 go & receive multiple messages in reply.
// AN EJB can delegate to this code or this code could be in the EJB.
// @param stopAtFirstMessage flag allow efficiency if app ccan't handle multiple validation
// erros at a time.
// @param saveData flag allows validation without saving - allows for confirm message.
// @param EditPersonGuiData - What the user types in. Numeric data & dates can be
// in Strings. Using struts this could be the formBean.
public List validateData(EditPersonGuiData inputData, boolean stopAtFirstMessage, boolean saveData) {
String msg = "";
List valerrs = new ArrayList();
msg = validateDateOfBirth(inputData.dateOfBirth);
if (!msg.equals("")) valerrs.add(msg);
if (stopAtFirstMessage) return valerrs;
valerrs = crossValidateAndSave()
return valerrs;
}

What Design Pattern - Change Language functionality

On my application, I will have a series of buttons to choose
a language. When the user chooses a language, all control labels,
pop-up messages and others will change at the chosen language.
I would like to do this from an OOP point of view and use
Design Patterns. Which one would you recommend to use?
My guess is the Strategy Pattern. Am I right?
Thanks for any comment or link.

The Strategy Pattern is used to swap algorithms dynamically.
Based on user input a decision can be made to run a (set of)
function(s). This behaviour is encapsulated in seperate objects.
You just want to swap data at runtime. Or maybe set some
behaviour regarding specific functions in languages like the way
currencies are handled, measurements and the like. The latter would
be implemented as Interpreter Pattern.
When it's merely data that needs to changed/loaded at
runtime, than it's more like a change of the Model in the MVC
design pattern, using an Observer to notify all registered
'listeners' and using a Command to get the thing going.

Business delegate and Session facade design patterns

Does any one tell me, what is the difference between business delegate and session facade design patterns.

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

Best architecture and design pattern to use

I am currently designing a moderately sized LabView application and cannot decide on the best architecture/design pattern or combinations thereof to implement.
The program basically polls an instrument connected to a serial port continuously at a 2-10Hz rate. When operator clicks a button to start a run, the polled data is then filtered, has math functions performed on the data, writes collected data to files, and produces reltime graphs and calculates point-by-point statistics. At the completion of a run, some additional data files are written. I pretty much know how to accomplish all these tasks.
What is also required is main-vi front panel interaction by the operator to access a database (via a C# dll with .Net) to query for specifications to apply in order to determine pass/fail status. Setup conditions also need to be changed from time to time by the operator and applied to the data in real time (ie- a measurement offset). I have prototyped the database portion successfully thus far.
For the main vi, I started off using the Top Level Application Using Events design pattern (Event structure within a while loop). Copious use of bundled clusters and shift registers keep the database data updated. I cannot figure out how to have the top level vi concurrently poll the serial device as outlined above. The Event structure is only active when defined control values change, and use of a timeout is no help since it prevent data from being collected while the user is accessing the database. All database and setup parameters must be applied to the data as it comes in from the serial port. Error trapping/recovery is a must.
I believe what I need is two parallel processes running under my main vi (one for database and setup, the other for polling and data processing/display, but what would be the preferred choice here?
Revert back to a polled loop in lieu of Events, use notifiers, occurrences, user-defined events, Producer-consumer loops?
It�s been about 3 years since I have had an application on this level (which used a state machine architecture), and a lot has changed in LabView (using 7.1 Prof Devel). I am currently having a mental block while trying to digest a lot of features I have never used before.
Suggestions Welcome!
Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

I suggest a (3) state machine(s) architecture. The first is the user interface. Your main VI is a good start. Another state machine handles the instrument I/O (your serial polling). The third handles all data processing. The three loops run independently. Each has a wait to allow LV's scheduler to share CPU time among the loops. I like queues or functional globals for inter-loop communications.
This allows a lot of flexibility. Each portion can be tested alone. Each can have different timing and priority.
Spend some time thinking about what needs to be done and plan the structure carefully before you do any coding (except for little test programs to try new ideas).
I also like Conway and Watts "A Software Engineering Approach to LabVIEW", published
by Prentice Hall.
Lynn

Design Pattern and ABAP Objects

Hello Friends,
I would like to know, if ABAP Objects can be used to do pattern oriented programming ?
For example GANG of four has provided almost more then 30 design pattern ( MVC, singelton, Obserable, FACADE,,,etc) can we implement patterns using ABAP ??
Many thanks
Haider Syed

Hi,
Take a look at the following site:
http://patternshare.org/
It has all the basic patterns from the GOF and a lot more. I can recommend the ones from Martin Fowler but be sure you start with the ones from the GOF.
All patterns are described by using UML so it's very easy to translate them into ABAP OO code.
Regarding your other question. For the observer pattern I used an interface which the SAP had already created if_cm_observer and created my own abstract observable class. The observable class is nearly a 100% copy of the java.util. one
regards
Thomas

RE: design patterns involving EJBs and JDO

Is the idea that you specify in some config file (xml?) the methods of
your session bean, whether its stateful or stateless, the default bean
transaction semantics, etc, then say "go" and it generates the home and
remote interfaces and the skeletal session bean class?
-----Original Message-----
From: Eric Lindauer [mailto:[email protected]]
Sent: Monday, June 25, 2001 8:26 AM
To: JDO-ListServ
Subject: Re: design patterns involving EJBs and JDO
I don't think it's publicly available yet, I used to work there and was
helping out a little with testing. I'll tell you in advance, it really
works well. Much like the JDO implementation, the process of turning
things into SesisonBeans is very transparent to the developer. I guess
TT is going to make it available in another week or two, as time
permits.
----- Original Message -----
From: Matthew <mailto:[email protected]> Adams
To: '[email protected]' <mailto:'[email protected]'>
Sent: Monday, June 25, 2001 11:18 AM
Subject: RE: design patterns involving EJBs and JDO
IMHO, JDO replaces entity beans, but you'll have to decide for yourself.
My recommendation would be to use session beans exclusively.
Where do you get TechTrader's "SessionBean Creator"? What are its
features? How do you use it?
-----Original Message-----
From: Eric Lindauer [mailto:[email protected]]
Sent: Monday, June 25, 2001 8:12 AM
To: JDO-ListServ
Subject: design patterns involving EJBs and JDO
Hi,
I was just wondering, if you are using JDO for persistence, does it
matter whether you wrap your objects with proxy EntityBeans or
SessionBeans? I am currently demoing TechTrader's SessionBean creator,
which makes means that for me creating SessionBeans is much easier than
creating EntityBeans. I am currently using stateful SessionBeans to
wrap the JDO objects, simply dropping them when the bean is passivated
and refinding them ( they'll already be in the cache ) when the bean is
activated.
My main advantage in doing it this way is SessionBeans are so much
easier to create. Do you see any problems looming, or any other
advantages to this decision?
Thanks in advance.
Eric

I don't think it's publicly available yet, I used to work there and was
helping out a little with testing. I'll tell you in advance, it really
works well. Much like the JDO implementation, the process of turning
things into SesisonBeans is very transparent to the developer. I guess
TT is going to make it available in another week or two, as time
permits.
----- Original Message -----_
From: Matthew <mailto:[email protected]> Adams_
To: '[email protected]' <mailto:'[email protected]'>
Sent: Monday, June 25, 2001 11:18 AM
Subject: RE: design patterns involving EJBs and JDO
IMHO, JDO replaces entity beans, but you'll have to decide for yourself.
My recommendation would be to use session beans exclusively.
Where do you get TechTrader's "SessionBean Creator"? What are its
features? How do you use it?
-----Original Message-----
From: Eric Lindauer [mailto:[email protected]]
Sent: Monday, June 25, 2001 8:12 AM
To: JDO-ListServ
Subject: design patterns involving EJBs and JDO
Hi,
I was just wondering, if you are using JDO for persistence, does it
matter whether you wrap your objects with proxy EntityBeans or
SessionBeans? I am currently demoing TechTrader's SessionBean creator,
which makes means that for me creating SessionBeans is much easier than
creating EntityBeans. I am currently using stateful SessionBeans to
wrap the JDO objects, simply dropping them when the bean is passivated
and refinding them ( they'll already be in the cache ) when the bean is
activated._
My main advantage in doing it this way is SessionBeans are so much
easier to create. Do you see any problems looming, or any other
advantages to this decision?
Thanks in advance.
Eric_

Design Patterns: 'Program to an interface, not an impl.' and Factory Method

Design Patterns: 'Program to an interface, not an implementation' and Factory Method.
Hi All,
I've 4 questions. And 1M thanks for your precious input.
1. OOAD steps:
Requirement-->Use Cases-->Analysis Classes-->Sequence Diagrams-->CRC-->other UML diagrams if needed--> Domain/Business Classes.
If we follow the rule 'Program to an interface, not an implementation',
would that imply NECESSARILY we should have another set of Interface Classes for our Domain Classes? i.e Interface_ClassX for ClassX_Impl.
2. If the point 1 is a MUST because of the rule 'Program to an interface, not an implementation',
ie we should have an Interface classe for every one Domain classe,
would that NECESSARILY imply we should have as many Factory Methods as they are Domain Classes to abstract the creation process?
Interface_ClassX X= Factory.GetClassX() ( return new ClassX_Impl)
Interface_ClassY Y= Factory.GetClassY() ( return new ClassY_Impl)
Interface_ClassZ Z= Factory.GetClassZ() ( return new ClassZ_Impl)
3. On the point 2, the underlying principle used is Factory Methods.
Now on the surface, what are other possible business and/or technical naming for such Factory Methods? I mean should we call it a kind of Business Facade?
4. Is the point 1 and point 2 considered to be the best practices?

So the question here is whether we can predict having
more than one possible implementations which required
option c. Is this a dilema? I guess it's hard to
predict the future.Right. Hopefully it's fairly obvious while designing things and
deciding what objects are needed.
Now, if the Presentation Tier, says JSP, needs that
ClassNormal object. Would we still keep that line of
code a.
OR would we introduce an intermediate object to free
JSP from the direct creational aspect using new
keyword like the choice b. that you reject.
The point here is to reduce the direct coupling aspect
between the Presentation Tier and Business Tier. So
what would that intermediate object be?In that case, you have to ask yourself if there is a valid
need for reducing the coupling. If you simply make an intermediate
object, what keeps you from making an intermediate object to your
new intermediate object, ad infinitum.
That intermediate object could be a Facade pattern, or simply
an abstraction. We actually did that here, we began a massive
java project, and we abstracted away from Swing J-classes and created
our own "wrappers" that simply extended all the J-classes and we had
all our programmers develop using our wrappers instead of the Swing
classes. That allowed us to add some custom code, some temporary bug fixes, etc. Some of our classes were nothing more than "EPPasswordField extends JPasswordField" with nothing overridden. It does allow us a place to hook in and adjust or fix things if needed though.

EJB and Design Patterns

Hi all,
Which design patterns could be applied in coding EJB? I don't know if my question is clear enough, but what I really want to know is which design patterns I could use with EJB and how could I use them this way? (Some example situation)
Regards,
Filipe Fedalto

i think it depends of what u intend to do..
e.g. i think (maybe i'm wrong, any relevant replies are welcome!) that u could use a stateless session bean to implement some facade, delegating entities creation to some non-bean classes? or why not a stateful session bean to implement a factory (when entities creation depend on client preferences)?

Get instance method and design pattern

Hi All,
1. I New to abap objects and i read the help and some stuff from the forum,
l like to now more about design pattern in abap objects,
2. I saw in some abap class the use of method of GET_INSTANCE i think it's from factory pattern , what is the pros. and cons to use this method ,when i should consider to use it ?
Thanks in Advance
Nina

Hello Nina
A very good introduction into design patterns is the book "Head First: Design Patterns". Here you will find many good reasons why and when to use the factory pattern.
You should use the factory pattern when
- you want to prevent "direct" instantiation (i.e. using a public CONSTRUCTOR method) by the developer
- you want to hide the complexity of instantiation from the user of the class
- the instantiation creates an implementation of an interface and you want to keep control of which implementing class is returned
Regards
Uwe

BusinessDelegate and ServiceLocator Design Pattern

Similar Messages

Maybe you are looking for