Proxy Pattern

Hi all,
I've been reading about the Proxy Pattern and it seems like just normal encapsulation to me or do I misunderstand it?
To me, Proxy looks like using a "middleman" class to delegate requests to the actual class so that the implementation of the actual class is hidden from the user.
Another benefit of this proxy pattern is that can delay the creation of an object from the actual class until you need it.
That is what I understand from what I read about it, but do you know some scenarios where you would use the proxy pattern?
Is it for example useful to separate the GUI from the actual code?
grtz

The Business Delegate design pattern is a version of the Proxy pattern.
A Presentation-tier Business Delegate delegates method calls to the Business tier.
The code on the Presentation tier only contains references to the business delegate. There are no class/code level dependencies between the business model implementation and the code on the Presentation tier.

Similar Messages

[svn:fx-trunk] 11250: Fixing proxy pattern bug in VideoPlayer.

Revision: 11250
Author:   [email protected]
Date:     2009-10-28 17:07:19 -0700 (Wed, 28 Oct 2009)
Log Message:
Fixing proxy pattern bug in VideoPlayer. I tried to save a few extra bytes by not keeping around an extra object, but I made a mistake with this code. It seems better just to follow the typical pattern and not worry about this extra savings, which probably cost more in code-size anyways.
Also changing VideoPlayer.thumbnailSource to mx_internal, rather than public. In VideoElement it's mx_internal, and that's what it should be here too.
QE notes: -
Doc notes: -
Bugs: SDK-23665
Reviewer: Deepa
Tests run: checkintests, mustella VideoPlayer
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23665
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/VideoPlayer.as

Difference between Proxy pattern and Business Delegate pattern

Hi All,
Can any one please tell me what is the difference between Proxy pattern and Business Delegate pattern.
Thanks in advance.
Basak

The books they were first reported in, and the expressed intent, I guess. Arguably, the Business Delegate pattern is a special case Proxy, with more specific details about what resource is being proxied

Generic Proxy pattern - help needed.

Greetings!
Lately i have been working on some design architecture to work on possible ways of designing message flows in OSB.
I found one excellent solution called Generic Proxy pattern at: http://javamaster.wordpress.com/tag/osb/ .
This pattern consists of four proxy services.
Actually Generic Proxy pattern and proxy service are different. You can read more about pattern at : http://game-engineering.blogspot.com/2010/03/adapter-pattern-vs-proxy-pattern.html
My problem is interesting and very straight forward.
1. I have one proxy service which is created on client side WSDL.
2. I have one business service created on legacy system WSDL.
Now, if i want to implement this Generic Proxy pattern, I need to create two more proxy services in between my existing proxy service & existing business service.
On what basis should these two proxy services should be created?
Options in OSB to create a proxy service are : WSDL Web Service / Messaging Service / Any SOAP Service / Any XML Service / Business Service / Proxy Service
If anybody has worked in this pattern, please help.
Any inputs from everyone are welcome.
Thanks and Regards,
Swapnil Kharwadkar.

The generic proxy service will be of type "messaging service" with input/output type as text/XML.

Wrapper/Proxy pattern

Hi,
We�re in the process of updating one of our APIs, which contains lots of interfaces (backed by heavyweight implementations - the java.sql package is a good comparison). I want to help vendors to wrap our existing implementations so that they can add extra functionality without having to re-implement all the backend workings by providing a "wrappers" package, which simply passes (unwrapped) arguments to the underlying implementations, and wraps returned heavyweights coming back up, allowing the vendors to add small amounts of functionality where needed.
// interfaces, could be heavyweight or wrappers..
interface Foo {
    Bar getBar(Hee theHee);
interface Bar {
   Foo getFoo();
// wrappers
class FooWrapper implements Foo {
     private final Foo myWrapped;
     public FooWrapper(Foo theWrapped) {
          this.myWrapped = theWrapped;
     public Bar getBar(Hee theHee) {
          return new BarWrapper(this.myWrapped.getBar(theHee));
class BarWrapper implements Bar {
     private final Bar myWrapped;
     public BarWrapper(Bar theWrapped) {
          this.myWrapped = theWrapped;
     public Foo getFoo() {
          return new FooWrapper(this.myWrapped.getFoo());
}The first issue I had with this was the calling new XxxWrapper is patently bum, as it means that the methods have to be overridden anyway to stop the "default" XxxWrappers from being returned. This, in my opinion, is easily solved by using a WrapperFactory, which can be passed in during construction of the wrapper, and called where needed to allow the user to supply there own wrapper implementations.
The second issue involves "unwrapping" which I am unsure as to the best way forward. In the, as yet undisclosed, "Hee" we should really have unwrapped it before passing it to the underlying Foo, otherwise it will still be the wrapped version of the Hee, (assuming) HeeWrapper. This is where the questions arise.
-What happens if it's not a HeeWrapper? My Initial thoughts are throw an exception, as, assuming it's come from our provider/factory, it should have been wrapped by us before the user could have gotten hold of it. Unless of course the WrapperFactory isn't returning HeeWrappers for some reason?
-What�s the best way to unwrap it? Again, initially I thought of adding an unwrapXxx to the WrapperFactory and let the user deal with it, though this seems to add too many methods. I also thought about WrapperFactory.unwrap(Object) letting the provider unwrap it generically and then casting the results? I avoided adding a Hee.unwrap() method in case it could lead to mistakenly unwrapping other providers (who are also using the wrappers package) implementations, though this may be a bit anal, but I�m sure I could abuse it (and therefore others no doubt could), so I want to avoid it.
-What happens if the Hee originates from the underlying implementation, say via an event? Delegate the wrapping of that Hee to the factory again? Should the default factory cache the results to allow the same wrapper to be returned each time, or just create a new one?
Has anyone done anything like this, or have any obvious solutions that I've missed, or just some preference?

So what you want to do with wrappers is beyond me.
Why do you not want to use abstract classes? What problem do you think is going unsolved in that case?I might be misunderstanding the problem but it's been while since prefer "composition to extension" became a mantra.
Suppose you have a type Foo. And you have behaviors Up and Down you wish to implement:
UpFoo
DownFoo
But wait, what if up and down aren't mutually exclusive (OK I could have chosen better names here.)
UpDownFoo
Great. Now here come Charm and Strange. So let's add:
CharmFoo
StrangeFoo
Now the combos:
UpCharmFoo
DownCharmFoo
UpStrangeFoo
DownStrangeFoo
UpDownCharmFoo
UpDownStrangeFoo
CharmStrangeFoo
UpCharmStrangeFoo
DownCharmStrangeFoo
UpDownCharmStrangeFoo
Whew. That was a lot of classes to write. I hope I didn't miss any. Uh oh, here come Top and Bottom...
I'm not going to type these out. Suffice it to say that this is an unsustainable approach. A good example of this approach is the Collections class which provides A synchronized wrapper and a unmodifiable wrapper so that we don't end up with all the permutations with all the map implementations.
This is usually called the Decorator pattern and it has been considered before. It's in the GoF.

Proxy design pattern

Hey,
I have jar that run in different enviroments (client,server,partners).
In my jar i have some method that in case they called the action that executed is depend on the implementor.
For example let say that i have method "updateXXX(long id,String name){
Notify.notify(...)
if this called in the client than it need to lookup to this service and send the class name, method name and the method parameters to the service.
if it run in the server than it need to run XXX with the same parameters (this infrastrcture need to server some method with different parameters).
Is the proxy design patterns is the solution for this?
I thought to demand from each imlementor that want to use those kind of methods to implement a plugin with a given class name and in notify to load this class with class.forName, what are you say about this soultion?
any other ideas will be more than welcome.

The proxy pattern could help here, but isn't the simplest solution. You just want to define an interface that has those updateXXX methods declared on it, and have several classes implement those methods, such as one which executes some code in the same process, or one that does so over RMI, that sort of thing. Write your calling code against that interface, and configure at runtime which class they'll be calling
interface Updater {
    void updateXXX(Object params);
class LocalUpdater implements Updater {
     public void updateXXX(Object params) {
       // code to do work here
class RemoteUpdater implements Updater {
public void updateXXX(Object params) {
       // code to do remote work here
class Client {
   Updater myUpdater;
   Client(Updater updater) { // constructor takes an instance of something which implements Updater
       myUpdater = updater;
    void doSomething() {
       myUpdater.updateXXX("params"); // see how this class is decoupled from your Updater implementations
}How you inject your concrete dependencies is up to you.

Proxy design pattern help

Hi,
Could please clarify my below doubts on proxy design pattern?
There are several cases where a Proxy can be useful:
*1. If the object is on a remote machine and loading it over the network may*
be slow, especially during peak network load periods.
so In this case how do we get the object which is in remote? By copying the jar files from the server to client
is that right?So we will get the object which is in the remote.
*2. If the object has limited access rights, the proxy can validate the access*
permissions for that user.
This how do we do?
Thanks
Bhanu

Hi Paratheosis ,
I almost got the point. But what I have heard about proxy pattern is, we use proxy to reduce the traffic between
client and server. In this case whenever we need any method on the server side we call isnt?..how trafic is being reduced here? Or is it storing somewhere client when we first time access the Object in Server side? for example
In Servicemanager getEmployeedetails.. So in client do we store the ServiceManager object so that next time we can access the that ServiceManager object in the client side.. Is it in this way? I dont think because any updation on the ServiceManager will not be able to get in the client side? I totally confused the implements for proxy.. :(
Thanks
Bhanu.

Design patterns in log4j

hi
i have a question that was asked to me
what pattern does log4j appender(consoleappender,rollingfileappender etc) implement?
candidates can be dao, facade etc....
can somebody xplain what pattern does it use and how
techy

actually this question was given in an exam and the
answer that the teacher gave was proxy pattern.Actually, if you think about it, only the individuals that programmed the log4j code know what design patterns they actually used.
As an outsider, just because an application "looks" like a pattern might have been used, does not mean it was actually used to design the application.
Futhermore, just because an application's functionality may fit in well with how one envisions the pattern's possible implementation, this too, does automatically equate or represent the fact that the pattern(s) were used.
This is a poor question to have on an exam, especailly if the individuals taking the exam were not the ones that worked on log4j. If the exam was given to log4j programmers, then it is a reasonable question.
To ask this question to assess knowledge/experience with log4j or object-oriented design patterns is a bad decision, in my opinion.
Only close and detailed inspection of the log4j source code will reveal what design patterns were actually used. Again, to question someone on this is inappropriate, unless it is for the log4j development team, in my opinion.
i m not able to understand how it applies proxy
pattern?I understand your confusion.

Pattern b/w Remote interface & Container implementation class

Which pattern is followed by EJB Remote interface & Container implementation class of that interface?Is there anyting mentioned in specs?
This questoin was asked to me by many people.I think it is Command design pattern as it hides away all the details of actual business implementation.but at same time I doubt if it is Facade?
Anyone who knows about this?
Thanx in advance
Sidhu

Rarely is software represent a single pattern, it typically represents multiple patterns.
Which pattern is followed by EJB Remote interfaceThe remote interface is an example of a facade pattern. This presents a public interface which is an abstraction of the real interface.
Container implementation class of that interface? The implementation is an example of what I think of as a double proxy pattern. That is acting as two distinct proxies. The first being the the remote callingof EJB standard functions via the Skelton implementation. I.E. The underlying EJB/RMI interface. The Second being a application level proxying of the business logic seen in most RL implementation.
The use of an UID ID beans is an example of a memento.
I think it is Command design pattern as it hides away all the
details of actual business implementation.Not directly, though an AppServer programmer may use the Command Pattern to resolve the remote connections. The User Application Programmer may also use this pattern. The key element of Command Pattern is the Invoker executing an concrete class via abstraction or interface of a polymorphic class. You can think of this as a specialisation of the
Martin

Business delegate pattern doubt

Hi,
One of the reasons for going for Business delegate pattern is because the business components is vulnerable to changes.
Suppose if the business component has a method
getAccountInfo( int Accountnumber)
The business delegate pattern may have a method
getAccountInfoFromBusiness(Accountnumber int)
return businesscomponent.getAccountInfo(Accountnumber);
and the presentation tier components will have code containing invoking to getAccountInfoFromBusiness method.
Now suppose if business component method signature changes then the signature of business delegate class will also change. This turn in requires changes to presentation tier components. I really dont understand why business delegate pattern is needed.

Hi,
One of the reasons for going for Business delegate
pattern is because the business components is
vulnerable to changes.Abstraction is your first tool to reduce a projects exposure to change.
Secondly filling you code with getter and setters is a bad idea, it's procedural not OO, Objects should express themselves.
So instead of :
Suppose if the business component has a method
getAccountInfo( int Accountnumber)consider
     Account account = getAccount( AccountID accountID ) ;          // or
     Account account = findAccount( AccountName accountName ) ;
     ... AccountInfo = account.toString( FULL ) ;          // or
     ... AccountSummary = account.toString( SUMMARY ) ;     // or
     ... AccountBalance = account.balance() ;This abstracts the Account's identification, from an int, makes your code robust to change, and more flexible, and easier to understand.
The business delegate pattern may have a methodThis is not good, the naming is particularly specific and relies on assumptions about the architecture, it looks like a a global function, yet should be a method of businesscomponent, which is also badly named.
getAccountInfoFromBusiness(Accountnumber int)
          return businesscomponent.getAccountInfo(Accountnumber);
}Instead consider the following. I've used abstraction to hide the implementation details, and the relations model real life, and I can handle my objects polymorphically.
     class Account { ... }
     class DayBook {
          Hashtable accounts ;
          public Account getAccount( AccountID accountID )
               accounts.get( AccountID accountID )
     class MyApp
          DayBook salesDayBook = new DayBook() ;
          DayBook purchaseDayBook = new DayBook() ;
          Account account = salesDayBook.getAccount( theAccID ) ;
          Account account = purchaseDayBook.getAccount( theAccID ) ;
          }Here DayBook is a collection of Accounts, I've two instances, one for my sales one for my purchases.
and the presentation tier components will have code
containing invoking to getAccountInfoFromBusiness
method.
Now suppose if business component method signature
changes then the signature of business delegate class
will also change. This turn in requires changes to
presentation tier components. I really dont understand
why business delegate pattern is needed.The Business Delegate is not really a pattern as such, it is an appliction of the Proxy pattern abstracted into Business language/terminology.

Design Pattern Discussion

I am now reading on a surogate pattern, I am not sure as to what is the difference between a Proxy pattern and a state pattern.
I currently reading the Thinking in Patterns by Bruce Eckel I really have probelm in understanding the Surrogate pattern design. I need concrete examples, is there any other sites or articles I can refer to or perhaps read.
Please give me some light and direction on this thank you

What's the Surrogate pattern? is it another name for
Proxy?Eckel uses the term "Surrogate" as a "category" containing Proxy and State.

Dynamic routing in OSB

Environment: OSB 10.3.1
To avoid manual configuring all published services one-by-one (eg. alter logging), I'd like to implement a generic proxy pattern in OSB. Assume that I have business services at /bs1, /bs2, etc, proxy services at /ps1, /ps2, etc.
What I'd like to achieve is to publish proxy services which routes to the generic proxy first and then reroute to the original proxy service. For this I published eg. /pps1, /pps2, etc all with an Insert action which saves $inbound/ctx:transport/ctx:uri to . in $header and then route to the genericproxy proxy service.
Generic proxy starts by executing common logic in the pipeline (log, etc), then should fetch the original routing information from the header and use dynamic routing to direct the message to the right proxy service (/ps1, /ps2, etc).
Now the questions:
1. is this the right approach to solve the problem of generic configuration of multiple published services in OSB?
2. appearently the uri itself is not enough for dynamic routing - what else do I need to save from the original message?
3. can I construct a <ctx:route><ctx:service..><ctx:operation..> construct with only Insert actions? I'd need a concrete example here accomplishing this.
Thanks.

Well you have to add Route Node to your proxy pipeline and inside it add a Dynamic Routing action.
If you select the Dynamic Routing action you'll see in the Properties view something like:
Service: <Expression>
Here is where you have to define the <ctx:route> element. You can basically paste the text here.
You could also create an XQuery transformation (so you can reuse it later) and invoke it here (with the XQuery Resources tab). But if you're not very familiar with XQuery I'd advise to start with the first option just to see it working.
At first you could also omit the {$proxy} variable and statically specify the service you want to route to. Or you could use an Assign action to define the $proxy (or any name you want to give it) variable. And then once that's working see if you can get the service path from the headers.
Hope that helps

Thread safe architecture problem

I am developing a app that is utilizing a proxy pattern to "wrap" instances of a few classes. The consumer of the proxy then does not need an instance of the inner class and the inner class is shared among all of the proxy consumers. However, I need the ability for the underlying class to be changed as needed ( reloaded through a ClassLoader to be more precise ). The problem is that I am trying to move this into a multi-threaded environment and am running into a few problems. I know that synchronization could solve my problems, but that will adversely affect the performance because only one thread will be able to execute the code any give time given that all of the proxies use the same underlying class. The reason that the proxies all wrap the same class is to eliminate constantly creating instances to handle the processing. (they are referenced from jars at runtime and use reflection to instantiate them)
Does any one have any suggestions on how to better structure this?

There are probably better ways, but one simple way would be to use a ReadWriteLock. In the proxy: aquire the read lock upon invocations to the underlying "real" instance. When you want to switch implementations, aquire the write lock (will wait for all readers to finish, and then prevent any readers from executing while you swap in your new state).
This way, if your old implementation needs to be "shut down", you can be sure that no one is relying on it when you do so. On the other hand, it doesn't prevent concurrent usage of the underlying instance when it's in service.
See java.util.concurrent.locks.ReadWriteLock (java 1.5) or doug leas util.concurrent for java versions before that

How to hide this method?

I want to use Protection Proxy Pattern,but I feel nervous about my
real method,how can i hide it(such as set it friendly or protected)?
you can see this code:
interface Safe{
     public String getSecret();
class RealSafe implements Safe{
     public String getSecret(){
          return new String("You can get the secret");
class ProtectionProxy implements Safe{
     private String password=null;
     public ProtectionProxy(String temp){
          password=temp;
     public String getSecret(){
          if(password.equals("I have the rights")){
               RealSafe realobj=new RealSafe();
               return realobj.getSecret();
          else{
               return new String("Illegal password,You can't get the secret");
How to hide the getSecret() in class RealSafe with the precondition of using Protection Proxy Pattern???????
How can i do? i need your help,please!

You can't prevent a malicious developer constructing an instance of RealSafe. They could always decompile your application and make changes to it if they wanted anyway!
The ProtectionProxy is really just a convenience for users of your API. It provides "reasonable" security through a means of determining whether the current user has access to the data. It does not provide a means of determining whether the current developer has access to it!
Your proxy lays down the rules for accessing the class being proxied. This works when the client application plays by the rules (as most applications do).
So all you need to do is make sure that developers who play by the rules can't construct an instance of RealSafe:
public class SafeFactory
public static Safe getSafe(...)
    Safe safe = new RealSafe(...);
    return new ProtectionProxy(safe);
class RealSafe implements Safe
RealSafe(...)
class ProtectedSafe implements Safe
private Safe safe;
ProtectedSafe(Safe safe)
    this.safe = safe;
}Thus the only way for a developer to get hold of an instance of Safe is to use SafeFactory.getSafe which always returns a ProtectedSafe.
Make sure you don't mistake this sort of pattern for robust security, though. It simply allows your client application to catch "UnauthorizedExceptions" and react accordingly. As pointed out in this thread there're various ways of getting at the data that's hiding inside a Proxy. If you're really concerned about preventing someone viewing your data unless they are authorised you need to either encrypt it or only load it (and not cache it) when their credentials have been provided.
Hope this helps.

Best practise - Domain model design

Hello forum,
we're writing an application divided into three sub projects where one of the sub projects will be realized using J2EE and the other two sub projects are stand alone fat client applications realized using Swing. So that's the background...
And now the questions:
After doing some research on J2EE best practise topics I found the TransferObject-Pattern (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html) which we certainly want to apply to the J2EE sub project and to one of the standalone client applications also. To avoid code duplications I like the "Entity Inherits Transfer Object Strategy" approach outlined in the document referenced above. But why does the entity bean inherit from the transfer object class and not vice versa? In my opinion the tranfer object adds additional functionality (coarse grained getData()-method) to the class and isn't it a design goal in OO languages that the class that extends a base class has more functionality than the base class?
For the standalone application we want to use a similar approach and the first idea is to desgin the entitys and let the TO classes extend these entitys.
When I get it right the basic idea behind all of these design schemes is the "Proxy pattern" but when I design it using the previously mentioned way (Entity <-- EntityTO) I will have a very mighty prox beeing able to execute all operations the base class is able to execute.
Any tips and comments welcome!
Thanks in advance!
Henning

Hello Kaj,
at first - thanks for your fast response and sorry for coming back to this topic so late.
After reading a bit more on patterns in general what about avoiding inheritance
completely and using the proxy pattern instead (As explained eg.
http://www.javaworld.com/javaworld/jw-02-2002/jw-0222-designpatterns.html here) - so moving the design to a "has a" relationship rather than an "is a" relationship.
In the previous post you said that the client shouldn't be aware that there are entity beans and therefore the mentioned implementation was chosen - But if I implement it vice versa (Entity is base class, TO extends entity) and do not expose any of the methods of the entity bean I would achieve the same effect, or not? Clients are only able to work with the TOs.
I have some headaches implementing it in SUN's recommended way because of the Serialization support necessary within the TOs. Implemented in SUN's way the Entity bean would also have serialization support which isn't necessary because they're persisted using Hibernate.
Thanks in advance
Henning

Proxy Pattern

Similar Messages

Maybe you are looking for