Good design for delegates in a service oriented architecture

Question

My problem is quite complex to explain and my English is not excellent, so I hope you can understand my question.

In a service oriented architecture there are some modules that own data used by all the others applications end these modules expose the data via Remote Method Invocation and Web Services.

We the developers of the module have seen that the code that invokes these modules is repeated in all the other modules, so we decided to put in common the code and created a new module named Common Delegates. The responsabilities of this new module are:

• keep informations about the hostname, port and JNDI and/or web service names;
• instantiate and use the service locator;
• instantiate and call the stubs to the remote modules.

But the methods exposed by the Common Delegates modules use the same Request and Response classes that are defined in the called modules. This means that this module does not act as a layer of decoupling.

In some cases this module created problems of circular dependencies during maven builds.

Is it a good thing to split the Common Delegates module into many different Maven artifacts to avoid circular dependencies, one for the called module? For example if I need to call via RMI the module A, I will have to use the Module A delegate.

Is it a good thing to make this delegates to be also a decoupling layer, meaning that they will expose their own Request and Response beans and transform them into the beans used by the called methods?

Answer 1

so your problem is that the services will call each other, if i assume, that the services itself have no circular dependency, then you need to create 2 delegates for each service, one is a delegate to register the service, the other is a delegate to lookup a service.

where each delegate will extend an abstract delegate which holds the logic to register or lookup a service. and you need to separate your interface into an own jar.

then you have:

interface UserService{}

interface EmailService{}

class UserServiceImpl implements UserService{
 }

class EmailServiceImpl implements EmailService{
 use UserServiceLookup
 }

class abstract BindDelegate{}

class abstract LookupDelegate{}

class UserServinceBindDel extends BindDelegate{
 use UserServiceImpl
 }

class EmailServiceBindDel extends BindDelegate{
use EmailServiceImpl
 }

class UserServiceLookup extends LookupDelegate{
 use UserService
 }

class EmailServiceLookup extends LookupDelegate{
   use EmailService
 } 

in this case i also would rename BindDelegate just to Binder, and LookupDelegate just to Resolver or Lookup

but a better way would be to avoid this delegation, because as you see there is lots of code, so now you save some lines of code for resolving and binding, but you need to write always 2 new classes.

in such case that you need RMI, i would go for a generator. the generator will parse your code, a config while or something else, and out of this information he will generate the server, stubs and skeletons classes.

so you just need to write the generator once, and thats all. the duplication of code is done by generator. if you need to change it, just change the generator, run it and you have you changed code for all services.

if you dont want to write the generator by your self have a look at this

http://www.distributeme.org

there is a ready open source generator with lots of additional stuff for RMI and remote services.

if RMI is not needed, you can switch to REST Services as example, with REST, you can create one single delegator which will be able to call all other services, without having a circular dependency because he just makes a http call to another url, with another json string, the services are loose coupling.