Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Suggestions for providing service interfaces to POJO client applications  RSS feed

 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For POJO applications that need to use RMI, or other lightweight remoting technologies such as Spring HTTPInvoker, or Hessian for example...

I have several applications that expose these types of services via interfaces in their business layer. The applications provide the service implementations, and allow any client application to invoke the service remotely through its interface.

My question is: what is the best way to get the actual Java interface into the client code so that it can use it to invoke the service?

Should the service implementator .jar up interfaces for clients? Then have the client include the .jar in its build?

Or, should a version control system (like SVN) utilize "external" links to automatically import service interface code into it's own codebase?

Or, other?

What I'm worried about is needing to recompile many client applications when a service interface changes...

Any ideas?

I'd also like to hear any comments re: the flip side of the POJO coin (EJB).
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I'm worried about is needing to recompile many client applications when a service interface changes...

I really dont see any magic way to change the interface without changing the client code except in very restricted circumstances.

Exactly what sort of interface changes are you contemplating?

Bill
 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose this is the downside of using these technologies in an RPC fashion.

Maybe I should be focusing more on a MOM design using something like Lingo or Jencks?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No matter how you move a message around - RPC, XML-RPC, SOAP, JMS, etc etc
if the server changes the way a message is interpreted, the clients will need to know that.
Under restricted circumstances, where the service does not change the basic input parameters but adds new parameters having reasonable defaults, I suppose a client can continue using the service with the old parameters. Look at the way browsers are flexible about making use of request headers for example, or the way XML applications can ignore attributes that they dont understand.
A simple String with parameters formatted as properties or a XML-RPC Map could work.
Bill
 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you mentioned is actually what I'm contemplating.

For instance: instead of having the canonical method signature define the actual request, a simple Map of key-value strings could be passed to one method on the service and interpreted by the service. This would mimic the Service Activator + Command pattern for MDBs.

What do you think of something like that?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you think of something like that?

I think you are on the right track.
I have done something similar in a web server application generating practice exam questions. Passing only Maps instead of trying to keep up with changing message signatures means I can add new question types without having to modify existing classes.
Bill
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!