API design and versioning using EJB

Question

I have an API that is EJB based (i.e. there are remote interfaces defined) that most of the clients use. As the client base grows there are issues with updates to the API and forcing clients to have to update to the latest version and interface definition.

I would like to possibly look at having a couple versions of the API deployed at a time (i.e. have multiple EAR files deployed with different versions of the API) to support not forcing the clients to update as frequently. I am not concerned about the actual deployment of this, but instead am looking for thoughts and experiences that others have on using EJB's as an API client.

• How do you support updating versions, are clients required to update?
• Does anyone run multiple versions in a production environment? Are there pro's cons?
• Any other experiences or thoughts on this approach, and having an EJB centric API?

Answer 1

It can be quite common to host multiple versions of an API (I'd only recommend having 2 at Max BTW). Typically you would host each API on a different shard/server/whatever and work with your clients to help them upgrade to the new API in an x time-frame.

An EJB centric API might suit your business needs now (which is fine) but there is an industry trend to move towards higher level (more abstract) API layers such as RESTful HTTP based APIs which can support a wider range of clients.

Answer 2

You can use the same EAR and just have different JNDI names for the different versions of your EJB. Then the old clients can still connect to the old EJB using the old client libs and new clients can connect to the new client libs. As Martijn pointed you don't want to have too many different versions floating around because that will greatly complicate support.

Answer 3

One way to do this is to add a Map<String, Object> addendum to all your EJB interfaces input and output before releasing it. For example:

Your interface:

interface UserService {
    GetUserResponse getUserResponse(GetUserRequest request);
    ...
}

Your method parameter and return object:

class GetUserResponse {
     ...
     public Map<String, Object> addendum;
}

class GetUserRequest {
    ...
    public Map<String, Object> addendum;
}

However, this is a double-edge sword.

While this will allow you to add to your implementation without changing the interface, it is very easily to fall into the trap of delaying the re-factoring of the interface.