Strategy: Modeling Messaging Aspects of Connected Systems

Aquesta sessió ha estat presentada per dos senyors de Microsoft: Beat Schwegler i Arvindra Sehmi.

El títol fa referència al fet que les arquitectures que aquests 3 dies s'han explicat de totes les maneres (tant de bó!) possibles, ells les veuen sobre 5 "pillars" (com no): Missatgeria, interacció, "workflow", identitat i dades. Aqui suposadament se centraven en el primer pilar.
La idea fonamental és que per garantir la evolució dels sistemes s'han de poder evolucionar de la manera més independent possible. Segons ells, si ara creiem que per posar un "bus" al mig ja ho tenim garantit ens equivoquem. Només cal que mirem al passat, i si hem acabat tenint sistemes "spaghetti" a partir de suposades "bones arquitectures", d'aqui 15 anys tornarem a estar igual.

El truc per aconseguir-ho "de veritat" està en começar per extreure els serveis de les funcionalitats (capabilities) del negoci que estem intentant automatitzar. Aqui ens han presentat els "capability maps" d'una manera bastant terrorifica: han tret el CP d'un banc d'Austria i han dit que la mida real era 4x4, metres! Imagineu la de capsetes i connexions. Per descomptat, estava fet amb el Visio :-) Aquesta manera d'analitzar es veu que forma part d'una metodologia anomenada Motion. En realitat no cal implementar tot el mapa ni en amplada (es divideix en 4 àrees) ni en profunditat (et quedes a nivell de disseny, parlant en termes OOAD aplicats a nivell de negoci).

Per abreujar, podem dir que d'aqui surten els models per definir els missatges, les interfícies dels serveis. I que són els serveis ben fets a nivell abstracte: Address, Binding i Contract. I a més aquests aspectes han de poder evolucionar independentment.

I aquí s'han tret de la màniga el carmel que no podrem tastar de moment. Un afegit del Visual Studio per a crear serveis que et modela aquestes parts a partir dels blocs bàsics:
1) Els "schemas" de les dades o bé les classes equivalents.
2) El WSDL de les interfícies o les interficies en codi C# (per exemple) equivalents.
3) Els "adapters", per a ells la encapsulació de la implementació de la lògica de negoci, de manera que cridar-la, per exemple, des d'un WebMethod sigui un linia de codi.
4) La pròpia lògica de negoci.
5) El end-point concret per a un transport concret que es vulgui utilitzar.
El "carmel" et crea una solució amb projectes separats per a cadascun dels blocs i tel's lliga de manera que "només" has de posar-hi el codi concret. És una mena de "contract-first development" del que us vaig parlar en un mail, però amb més abast (i la insistencia d'ells de que pots partir del codi si vols).

Al final de tot, una sessió prou amena i un bon balanç teoria-pràctica, que a mi almenys em crea expectatives i dubtes de si la visió pràctica de SOA de Microsoft va pel mateix camí del que semblen anar molts d'altres. No seré jo qui vaticini qui s'equivoca, no... :-)