local vs. remote - separate interfaces for client?

[Nina Binde]

My business and remote layers consists of the following:

Interface ContractorService specifies methods like book,serach,etc.
Interface RemoteContractorService extends Remote and has the same methods as ContractorService, but each method throws RemoteException in addition to any other exceptions (DataAccessException, SecurityException, etc.)

Class ContractorAdapter implements ContractorService. This is the local version.
Class RemoteContractorServiceImpl implements RemoteContractorService and creates an internal ContractorAdapter.

For example, in RemoteContractorServiceImpl, I would have methods like:

public void book(ContractorRecord contractorRec, Customer cust)
        throws  DataAccessException, SecurityException,    
        RemoteException {              
    contractorAdapter.book(contractorRec, cust);
}

How do I create a GUIController (similar to the one in Andrew's book) without returning two different interfaces (local and remote) to the client?
I am thinking I would have to create another layer above the remote and the business ?But have no clue how...
Any ideas on this appreciated. Thanks

[Javier Corral]

I think you could write

Interface RemoteContractorService extends Remote, ContractorService {....

then any class that implements RemoteContractorService is-A ContractorService as well.

I hope it helps you.

[Nina Binde]

Thanks Javier. The solution you mentioned would not work as is for my case since my ContractorService class does not throw RemoteException.
Instead, what I did was let the ContractorService methods all throw IOException which is a superclass of RemoteException. From there on, I could extend RemoteContractorService from ContractorService.
Initially, I had thought of this, but did not want IOException to be in my business layer. But, now looks like this is the only way I can achieve it.
Thanks again..

[Gabriel Vargas]

Hi Nina,

I do as Javier, but in your implementation ContractorAdapter you could implement all your methods of ContractorService without throw IOException. I think if i want to use local and remote services in my implementation, this must be compatible with both and this means than that interface must throw RemoteException or a more generic exception IOException and this makes implementation compatible with the desire functionality.

I hope it helps you.

[rinke hoekstra]

Hi Nina,

I did the following:

First, I created a business layer, which has a Service interface with two methods, book and search. It has one implementing class, ServiceImpl, which catches the runtimeExceptions and rethrows them again as the original IOExceptions. This has two advantages: IOExceptions are more appropriate, as they are severe exceptions, so they should be checked. But the real advantage is in the network approach.

The network approach is as follows:
I have a RemoteService interface, which extends the Service interface. The RemoteService interface needs nothing more than the Service interface, so it is completely empty. The RemoteExceptions which I need to declare for each method are a subtype of IOExceptions, so there is no need to explicitly put the RemoteExceptions in my throws clause, as all Service methods already have a IOException.

The RemoteServiceImpl class is the only implementing class, and it (of course) again has only the book and the search method, which implementations are very simple: they just call ServiceImpl.book and ServiceImpl.search.


Now how this all works together:

The application is started via the ApplicationRunner class, which main method calls a class which is called ServiceProvider.

ServiceProvider cannot be instantiated (only one default private constructor), and it has one static public method called initiateService, which takes the application mode (an enum) and a connecting string as params, and returns an instance of Service.

If applicationMode is standalone, then it just returns an instance of ServiceImpl.

If applicationMode is client, then the method returns a proxy of RemoteServiceImpl via connecting the rmi server.

If applicationMode is server, then the server is started via the rmi registry. In that case, it returns null.

So there is one single call to ServiceProvider.initiateService from the main method, which returns the correct version of a Service (networked or non networked), or starts the server, depending on the application mode.


This approach is very simple, and thanks to the trick of catching and rethrowing as IOExceptions, my network package is just no more than about 10 lines of code.

In all cases, a Service is returned; if it is local, it is of class ServiceImpl, and if it works via rmi, it is a proxy of RemoteServiceImpl.

[Liviu Carausu]

Originally posted by Nina Binde:
Thanks Javier. The solution you mentioned would not work as is for my case since my ContractorService class does not throw RemoteException.
Instead, what I did was let the ContractorService methods all throw IOException which is a superclass of RemoteException. From there on, I could extend RemoteContractorService from ContractorService.
Initially, I had thought of this, but did not want IOException to be in my business layer. But, now looks like this is the only way I can achieve it.
Thanks again..

Hi Nina,
I also find not nice to have IOException in my business layer. I throw for my business layer a not checked BusinessException where I encapsulate all the exceptions from the database layer.
I see no problem in having the RemoteContractorService not extending the ContractorService. At the client I can have an adapter for the RemoteContractorService that will implement ContractorService and will encapsulate the RemoteExceptions thrown by the RemoteInterface into BusinessExceptions.
In this way the client will have to handle only with unchecked BusinessExceptions. Which is trendy ...
Just my 2 cents..

[rinke hoekstra]

Originally posted by Liviu Carausu:

I also find not nice to have IOException in my business layer....

I see more people writing this. Maybe I have some blind spot for this, but could you please explain why not? Because I cannot see a problem at all with it.

Thanks, Rinke

[Nina Binde]

Thanks for your replies.
Liviu, donno if throwing unchecked Business exceptions to the client sounds right cos clients need to necessarily catch these kind of exceptions. You are trying to tell the client that it is ok to not have to deal with this.

Rinke, In my case, I also have SecurityException in my DB layer along with
IOExceptions. If these exceptions are propagated as is, I think it
would reveal implementation details to the client. I wouldn't want
my UI to deal with IOException and many others. Just one exception
that it can take and display in a dialog box would suffice for our kind of client. What do oyu think?

[rinke hoekstra]

Originally posted by Nina Binde:

Rinke, In my case, I also have SecurityException in my DB layer along with
IOExceptions. If these exceptions are propagated as is, I think it
would reveal implementation details to the client. I wouldn't want
my UI to deal with IOException and many others. Just one exception
that it can take and display in a dialog box would suffice for our kind of client. What do oyu think?

hm hm hm. But these exceptions are real exceptions, in the sense that they can happen. If you want to handle these exceptions in an appropriate way (amongst which is: informing the user what went wrong, when necessary), then it is handy to be able to distinguish between different types of exceptions. If Sun though it good to have only one-fits-all type of exception, then they wouldn't have subclassed the Exception class, I would think.

So, to my idea, having the business layer methods throwing only one exception type is only valid if all exceptions are always handled in exactly the same way by any gui which may be using the business layer. That would not only be your own gui, but but also future extensions or versions of the gui.

Personally, my business layer is throwing several different exception types, and all of them will have to be caught by the gui.

[Liviu Carausu]

Originally posted by rinke hoekstra:


I see more people writing this. Maybe I have some blind spot for this, but could you please explain why not? Because I cannot see a problem at all with it.

Thanks, Rinke

Hi Rinke,

Somehow it looks to me that IOException is more like a low level exception that belongs to the base layers.

And we can distinguish between different types of exceptions by wrapping the original exception in the exception that we are throwing from the upper layer. There are a lot of exceptions that can be thrown by the low layer, RecordNotFoundException, SecurityException, DuplicateKeyException , IOException, InterruptedException,UnsupportedEncodingException ....

I read somewhere that is recommended to throw exceptions appropriate to the abstraction (I think it was Joshua Bloch's book Effective Java) , meaning that the current layer must catch exceptions from the lower layer and pack them into its own meaningful exceptions.

The only thing that it does not look very natural to me is throwing IOException from the business layer. I know that this is the workaround for masking the RemoteException from the Remote interface and having the Remote interface implementing the local one. But, on the other hand, if the remote interface does not implement the local one, we must only write an adapter at the client side that will allow the client to use the same interface.

I think this handling it is a matter of taste and I do not think that is very important.

Best regards,

Liviu
[ August 22, 2007: Message edited by: Liviu Carausu ]

[rinke hoekstra]

Originally posted by Liviu Carausu:

Somehow it looks to me that IOException is more like a low level exception that belongs to the base layers.

And we can distinguish between different types of exceptions by wrapping the original exception in the exception that we are throwing from the upper layer. There are a lot of exceptions that can be thrown by the low layer, RecordNotFoundException, SecurityException, DuplicateKeyException , IOException, InterruptedException,UnsupportedEncodingException ....

I read somewhere that is recommended to throw exceptions appropriate to the abstraction (I think it was Joshua Bloch's book Effective Java) , meaning that the current layer must catch exceptions from the lower layer and pack them into its own meaningful exceptions.

The only thing that it does not look very natural to me is throwing IOException from the business layer. I know that this is the workaround for masking the RemoteException from the Remote interface and having the Remote interface implementing the local one. But, on the other hand, if the remote interface does not implement the local one, we must only write an adapter at the client side that will allow the client to use the same interface.

I think this handling it is a matter of taste and I do not think that is very important.

Best regards,

Liviu

[ August 22, 2007: Message edited by: Liviu Carausu ]

Hi Liviu,

thanks for your explanative reaction. I must say I fully agree with your last sentence :-).

Of course, I'm packing Exceptions together and pass them according to the abstraction level of the layer. To my idea, IOException means just "could not connect to the database for any reason", which is an informative and very typical type of Exception, so I don't see a problem of passing it to the gui layer. But that is of course a matter of taste.

Rinke

[Liviu Carausu]

Hi Rinke,

I think you are right, IOException is general enough to be thrown at any layer.

Regards,

Liviu