Quelle est la meilleure pratique lors de la conception de services Web SOA WCF?

Question

Compte tenu d'un contrat d'exploitation tel que:

[OperationContract]
void Operation(string param1, string param2, int param3);

Ceci pourrait être redessiné pour:

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

Une chose qui me plaît dans MessageContract est que je contrôle un peu plus explicitement le format du message SOAP.

De même, je pourrais écrire à peu près le même code, mais utiliser un DataContract:

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

Une des choses qui me plaisent dans DataContract est que je peux définir IsRequired, Order et Name.

Aujourd'hui, je m'attends à ce que le seul consommateur soit un client WCF. Cependant, je veux d'abord concevoir un contrat et adhérer autant que possible aux pratiques en matière de SOA. Plutôt que de laisser la WCF dicter mon SOAP, WSDL et XSD, je veux que XML définisse la couche WCF, mais utilisez WCF pour générer ceci afin de ne pas ajouter de traitement de message personnalisé à WCF. Je souhaite suivre les conventions les plus courantes de la SOA XML, qui sont probablement toutes les balises commençant en minuscules - ai-je raison? Et je veux être aussi tolérant que possible envers les versions.

Est-il judicieux de toujours créer des messages de demande et de réponse comme celui-ci? Lequel des trois formats fait la promotion des meilleures pratiques SOA? Devrais-je aller plus loin et définir à la fois un DataContract et un MessageContract dans lesquels MessageContract ne contient que le DataContract? Ou ne devrais-je jamais utiliser DataContracts que si j'expose réellement un nouveau type (c.-à-d. Ne crée pas de types de message en tant que conteneurs)?

Je connais un ensemble chargé de questions, mais j'essaie d'aller au fond des choses et je ne suis pas certain que la séparation des questions fournisse un contexte suffisant pour obtenir la réponse que je cherche.

Answer 1

XML a généralement tendance à être camelCased. WSDL et XML Les schémas utilisent camelCasing pour les éléments et les attributs, par exemple, vérifiez la syntaxe et schéma .

Pourquoi SOAP a été défini différemment, je ne le sais pas, mais il utilise PascalCasing pour les éléments et camelCasing pour les attributs, vérifiez ici .

De même, la plupart des spécifications WS * (peut-être toutes) utilisent PascalCasing pour les éléments et les attributs, voir ici . XML Schema ignore les conventions des types qu’il définit pour XML.

Thomas Erl écrit de nombreux ouvrages importants sur SOA , y compris" Architecture orientée services ". Dans les chapitres 13 et 15 , il fournit un certain nombre d'exemples du code XML des différentes parties de transactions types. Il définit les types et les membres d'objet dans XML Schema à l'aide de PascalCasing qui correspond bien aux modèles normaux de C # pour la dénomination de classe et de propriété. Ainsi, les valeurs par défaut WCF correspondent déjà étroitement aux normes.

En ce qui concerne la dénomination réelle des messages, certaines conventions utilisent camelCasing et d'autres utilisent PascalCasing. Je préfère par conséquent répondre aux besoins de la langue principale, qui dans le cas WCF est PascalCasing. Et les valeurs par défaut WCF correspondent à quelques exemples de la manière dont le message de requête et de réponse doit être écrit, Quelques exemples ici .

Donc, la seule question en suspens est maintenant la question fondamentale de savoir combien de normaliser l'utilisation de OperationContract , DataContract et / ou MessageContract .

Définir DataContract uniquement lorsque vous avez un type complexe (au sens de XSD ) est logique, et j'ai tendance à penser que YAGNI (vous n'en aurez pas besoin), comme l'a souligné Terry, est choix correct, mais Erl semble suggérer une version beaucoup plus intensive en processus, donc je ne suis toujours pas sûr de la meilleure approche à utiliser comme choix par défaut (la partie principale de la question).

Answer 2

C’est toujours une bonne pratique de ne pas avoir plusieurs paramètres dans un contrat d’opération, mais de toujours avoir un type qui englobe tous les paramètres requis. Cela aidera à long terme. Vos clients existants ne casseront pas lorsque vous ajouterez un nouveau paramètre facultatif.

Je travaille dans une équipe d'intégration métier où nous nous intégrons avec d'autres entreprises assez régulièrement (AT & amp; T, Cox, Exxon ...) et je n'ai jamais vu d'appel à un service Web prenant plus d'un paramètre.

Answer 3

Je pense que cela dépend honnêtement du scénario. Si vous échangez simplement des types simples [i.e. string], OperationContract est certainement acceptable.

Vous devez utiliser MessageContract lorsque vous souhaitez modifier le format du message et DataContract doit être exploité lorsque vous souhaitez exprimer un type complexe, tel qu'une adresse.

Answer 4

YAGNI vient à l'esprit ici.

Je dis de ne pas trop le faire pour ne pas trop regarder vers l’avenir. La WCF est déjà bien adaptée à la SOA. Je dis, en général, respectez les valeurs par défaut et faites attention au couplage jusqu'à ce que vous ayez un besoin spécifique de faire quelque chose de élaboré.