Coder la question architecturale

Question

Je suis après quelques conseils sur la façon d'aborder le codage d'un problème, je ne veux pas entrer directement dans le codage sans y penser car je dois être aussi générique et personnalisable que possible,

Le scénario est que j'ai un service Web qui agit comme une passerelle vers les services en aval, dans le but d'authentifier et d'autoriser le message SOAP destiné aux services descendants, ce qui allège fondamentalement le service en aval de le faire eux-mêmes. Chaque message SOAP a une variété de mécanismes WS-Security différents généralement attachés WS-UsernameToken, WS-Timestamp, et une signature XML du corps du message. Mon problème est que je veux trouver une bonne façon extensible de valider tous ces mécanismes de sécurité, je ne sais pas comment faire pour l'apprécier.

Je pensais que d'avoir une classe de contrôleur qui est réactiver les et contrôle le flux de validation c.-à-

ISecurityController controller = SecurityControllerFacotry.getInstance(); 
boolean proceed = controller.Validate(soapMessage); 

en utilisant très peu comme un modèle de conception de modèle qui ditates le flux de la logique à savoir

public Boolean Validate(Message soapMessage) 
{ 
    return ValidateAuthentication(soapMessage) && ValidateTimeStamp(soapMessage) && ValidateSignture(soapMessage); 
} 

Serait-ce la meilleure approche du problème?

Aussi serait-il préférable de mettre chacune de ces méthodes de validation dans une classe qui a implémenté une interface commune? Alors qu'une classe pourrait être instanciée et récupéré d'une sorte d'usine de validation à savoir

IValidationMechanism val = ValidationFactory.getValidationType(ValidationFactory.UsernameToken); 
boolean result = val.Validate(soapMessage); 

Cela me donnerait un aspect facilement extensible.

Serait-ce une solution évidente ou quelqu'un peut-il penser à d'autres façons de le faire?

Je suis interset dans les modèles de conception et de bons principes de oo donc je voudrais descendre une route en les utilisant si possible.

Merci à l'avance

Jon

EDIT: Le service est essentiellement un service de sécurité de la passerelle qui soulage la charge de l'authentification et l'autorisation des services qui sont assis derrière elle. Le service de sécurité peut être considéré comme un intermédiaire invoqué implicitement sur le chemin de message SOAP qui valide les mécanismes de sécurité dans le message SOAP et, en fonction du résultat de la validation, transmet le message au service aval approprié en interrogeant les en-têtes WS. Bien que le service n'est pas vraiment la question, il est plus sur la façon de mettre en œuvre la procédure de validation.

Answer 1

Je peux penser à un autre moyen de valider votre message SOAP par rapport à différentes validations. Vous utilisez un modèle de visiteur.

Pour cela, vous aurez un emballage simple autour du message SOAP que vous obtenez. Votre contrôleur de sécurité contiendra la liste des Validatiors que vous injecterez fondamentalement.

 SecurityController{ 
     List<IValidator> validators; 

     //Validate the message 
     void validate(MySOAPMessage soapMessage){ 
     forEach(Validator validator: validators){ 
     soapMessage.isValid(validator) 
      } 
     } 
    } 

Vos Valideurs ressembleront à quelque chose comme ça.

UserNameValidator implements IValidator{ 
public void validate(MySOAPMessage message){ 
// Validate and put error if any 
} 

}

Vous ne avez pas besoin et l'usine inutile ici pour les validateurs .. si vous voulez vouloir ajouter/supprimer validateurs du contrôleur vous injectez juste/un Injecter de la liste.

Answer 2

Je pense que votre intuition est bonne; aller avec l'approche de l'interface unique. Autrement dit, cachez vos implémentations de validation derrière une seule interface de validation; Cela vous permet d'étendre vos implémentations de validation plus tard sans modifier le code appelant.

Et oui, l'idée de mettre la validation dans sa propre classe est une bonne idée; vous pourriez envisager d'avoir une classe de base commune, si vous avez des éléments de validation communs (par exemple, nom d'utilisateur peut être un élément de validation commun, même si chaque schéma de validation différent peut l'encoder différemment: un en tant qu'élément, un autre en tant que attribut, etc.). Je pense que les classes de validation sont un mappage plus approprié pour le niveau de complexité dont vous parlez de toute façon, par opposition aux méthodes de validation; Je soupçonne que le type de validation que vous faites nécessite des groupes de méthodes (c'est-à-dire des classes).

Answer 3

Le printemps a un paquet de validation générique qui gère ce type de processus bien à mon humble avis.

Leur ressemble

public interface Validator { 
    public boolean supports(Class<?> clazz); 
    public void validate(Object o, Errors errors); 
} 

Accordé, ils utilisent un Errors pour retourner les questions param de validation dans, ce qui pourrait ou pourrait ne pas convenir à votre objectif.