Progettazione dell'API e versioning tramite EJB

0

Ho un'API basata su EJB (ovvero, sono definite interfacce remote) utilizzata dalla maggior parte dei client. Man mano che la base del cliente cresce, ci sono problemi con gli aggiornamenti dell'API e impone ai client di aggiornare la versione e la definizione dell'interfaccia più recenti.

Mi piacerebbe probabilmente avere un paio di versioni dell'API distribuite alla volta (cioè avere più file EAR distribuiti con versioni diverse dell'API) per supportare non forzare i client ad aggiornarsi con frequenza. Non sono preoccupato per l'effettiva implementazione di questo, ma sono alla ricerca di pensieri ed esperienze che altri hanno sull'utilizzo di EJB come client API.

  • Come supporti l'aggiornamento delle versioni, i client devono aggiornare?
  • Qualcuno esegue più versioni in un ambiente di produzione? Ci sono dei pro?
  • Qualche altra esperienza o idea su questo approccio e con un'API EJB centrica?
posta broschb 26.04.2012 - 06:04
fonte

3 risposte

3

Può essere abbastanza comune ospitare più versioni di un'API (io raccomanderei solo di avere 2 a Max BTW). In genere, ogni API verrà ospitato su un frammento / server / qualsiasi e lavorerà con i tuoi client per aiutarli ad eseguire l'aggiornamento alla nuova API in un intervallo di tempo x.

Un'API EJB centric può soddisfare le tue esigenze di business ora (che va bene) ma esiste una tendenza del settore per passare a livelli API più avanzati (più astratti) come API basate su HTTP RESTful in grado di supportare una gamma più ampia di client.

    
risposta data 26.04.2012 - 11:10
fonte
1

Puoi utilizzare lo stesso EAR e avere solo nomi JNDI diversi per le diverse versioni del tuo EJB. Quindi i vecchi client possono ancora connettersi al vecchio EJB usando le vecchie librerie client ei nuovi client possono connettersi alle nuove librerie client. Come ha sottolineato Martijn, non vuoi avere troppe versioni diverse in giro perché ciò complicherà notevolmente il supporto.

    
risposta data 06.05.2012 - 17:27
fonte
0

Un modo per farlo è aggiungere un'aggiunta di Map<String, Object> a tutte le tue interfacce EJB in ingresso e in uscita prima di rilasciarla. Ad esempio:

La tua interfaccia:

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

Parametro del metodo e oggetto restituito:

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

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

Tuttavia, questa è una spada a doppio taglio.

Anche se questo ti consentirà di aggiungere all'implementazione senza modificare l'interfaccia, è molto facile cadere nella trappola di ritardare il ri-factoring dell'interfaccia.

    
risposta data 27.06.2013 - 20:15
fonte

Leggi altre domande sui tag