Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question
did you mean you let say you have a user and an email server, both services can be accessed trough RMI and as Webservice ? and for this two Services, you created a Delegate Module ? or you created two Delegate Modules ? and if its one, this Delegate have only on Method (makeRequest) or have a union of methods from both User and Email Service ? – fmt.Println.MKO Mar 5 '13 at 10:48
@fmt.Println.MKO now there is just one Delegate Module. In the future there could be two delegate modules. There are many methods for every service. To follow your example, you could have addUser(), findUser(), updateUser(), etc. And also sendMail(), sendBulkMails(), sendMailAndSms(). – Vitalij Zadneprovskij Mar 5 '13 at 11:57
so you have service module user, and a service module email, and you have a delegate module for this two services which other services will call ? and this delegate exposes the same requests and responses as the two services itself ? and you just created this delegate to avoid writing the same code for RMI connection twice ? and the userservice can call the email service and email service can call user service, and both are using the delegate module todo that, is that right so far ? – fmt.Println.MKO Mar 5 '13 at 14:40
@fmt.Println.MKO yes, you are right so far. – Vitalij Zadneprovskij Mar 5 '13 at 15:07

1 Answer 1

up vote 1 down vote accepted

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

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.