La capa de coneixement

En els sistemes d'avui en dia, quan parlem del seu desenvolupament, el seu disseny o la seva arquitectura, en algun moment o altre, sempre apareix el terme capa.

"desenvolupament de 3 capes, de 5 capes , de n-capes,...."

Sempre apareix la capa de visualització (pantalles per interactuar amb el sistema), la capa de negoci (processament de les dades rebudes pel sistema) i la de dades (persistir aquella informació que ha de durar en el temps), és un resum. També hauríem de parlar de la capa de seguretat que apareix involuntàriament ,o no, en tota la resta. Però, independentment del número de capes i a l'igual que la de seguretat, al meu entendre, crec que hi ha una capa més amagada i de la qual mai se’n parla, poder perquè no cal parlar-ne, poder perquè no hi ha temps per pensar-hi, poder perquè la inversió econòmica no ho ha previst o poder perquè no hi em parat a pensar més del que es mereix.

Quan parlem de coneixement, parlem de saber, de saber alguna cosa, de saber fer alguna cosa, de saber com ..., etc, en definitiva, "saber", sabiduria, intel·ligència?, uhmm, raonem-ho una mica més.

Crec que puc afirmar que al voltat dels sistemes d'informació hi ha molt coneixement, i dins, n'hi ha?..., també, però menys del que hi podria haver.

En qualsevol programari informàtic triat a l'atzar, podem trobar un mínim de coneixement, com pot ser, el manual d’instal·lació, la documentació tècnica, i el coneixement que ens dóna el sistema, uns logs i uns events (rarament), dels quals poques vegades se’n treu profit, quan realment són indicadors de que el sistema està viu.

Bé doncs, la idea que jo vull expressar és la de poder absorbir el coneixement al màxim de manera bidireccional, o sigui, utilitzar el coneixement del professional per alimentar al sistema, i utilitzar el coneixement del sistema per ajudar en tot moment al professional a fer la seva feina el millor possible i augmentar així la productivitat i la eficiència, així com millorar-ne els resultats.

I com podem fer-ho:

• 
  
  Utilitzar al màxim el llenguatge natural i les parts de la semàntica que el formen. Utilitzar noms per identificar objectes i verbs per identificar accions sobre els objectes. adjectius per representar propietats, adverbis per representar estats, situacions, aspectes, etc. També cal identificar dominis d'aplicació. "Enregistrar persona" en un domini mèdic-assistècial suposa enregistrar un pacient, en canvi en un domini de compres online, suposa enregistrar un client.
  
  
  
• 
  
  Mantenir un glossari domini-nom-verb i associar-li una documentació o protocol que utilitzarem per informar on calgui del que s'està fent quan és produeixi l'acció.
  
  
  
• 
  
  La documentació o protocol associat/da a cada relació domini-nom-verb, realment ja la tenim, però no en podem fer res, no la fem servir, perquè no ens hem preocupat d’enregistrar-la. Aquest protocols estan en els professionals que degut a la seva experiència, saben com es fan algunes coses que altres no saben. Això suposa que si no podem absorbir d'alguna manera aquest coneixement, quan aquesta persona marxi pel motiu que sigui, s'emportarà amb ella aquest coneixement tant valuós.
  
  
  
• 
  
  I per tant, l' empresa és la primera interessada en no perdre aquest coneixement. I que pot fer, doncs molt fàcil, incentivar l'aportació de coneixement als sistemes d'informació de l'empresa.
  
  
  
• 
  
  El sistemes d'informació han d'oferir mecanismes per enregistrar aquesta informació de manera que sigui aprofitable pel programari i els usuaris que en facin ús. Per dir-ho de manera senzilla, el sistema ha de se capaç de dri-li a l'usuari que està enregistrant un pacient i no un client.
  
  
  
• 
  
  També podem utilitzar aquests protocols per informar al nous usuaris de com es fa alguna cosa (procés de negoci). El sistema hauria de ser capaç de posar-lo en el punt de partida i ajudar-lo fins al final de tot el procés. El sistema hauria de ser capaç de contestar a "Com es fa un alta hospitalària" o "Com es programa un preoperatori" o ....
  
  
  
• 
  
  Per altre banda el sistema es va informant, l'usuari "x", a l'hora "y" a "enregistrat un pacient". Però en aquest procés d'enregistrament, s'han fet moltes coses, s'han introduït dades per part de l'usuari (que podríem analitzar, imaginem-nos un informe d'alta per un diagnòstic en concret, crec que valdria la pena analitzar el contingut dotant al sistema de coneixement sobre aquest tipus de diagnòstic i reutilitzar-lo si cal, en futurs diagnòstics semblants), s'han procesat  i finalment s'han guardat.
  
  
  
• 
  
  Sempre que s'estigui executant un procés, utilitzaria el gerundi del verb que identifica la acció sobre el nom o objecte. Per exemple "guardant" i un cop acabat el participi, "guardat". En ambdós casos dispararia un event que informés al gestor d'events i aquest decidís si s'ha de fer alguna cosa.
  
  
  
• 
  
  Per altre banda dins el sistema, s'han de capturar tots els errors i tractar-los amb cura. Les excepcions haurien d'informar-se ràpidament, per tal de solventar-les. Quan es produeix un error l'usuari ha d'estar informat de manera entenedora i el tècnic de manera explícita. Això es coneixement també.
  
  
  

Quines aportacions podem trobar en les noves tecnologies que ens ajudin a gestionar coneixement dins les nostres aplicacions? Moltes.

En molts IDE's actuals podem trobar ajudes per crear documentació tècnica, facilitar el disseny de processos, facilitar la integració entre processos i serveis, facilitar la definició d'entitats, de models, ajudar a la programació, a picar codi, mostrant les possibilitats al programador a partir de la variable on es troba (intellisense, bona paraula quan parlem de coneixement), etc, etc, etc. Tot això s' ha pogut incloure dins els IDE's gràcies a fer un estudi de com fan les coses els professionals, com estaria bé que les facin, i analitzant això i moltes més dades, poder facilitar la feina al desenvolupador, per fer la seva feina el millor possible i augmentar així la productivitat i la eficiència, així com millorar-ne els resultats. Em sembla que això ja ho havia dit abans.

Dins el món Microsoft, puc dir que realment ja treballen en aquest sentit, aportant millores constants que em molts casos faciliten en gran mesura el desenvolupament, i el desenvolupament de la capa de coneixement. En el seu IDE actual en producció ja es poden definir processos mitjançant Workflows, definir Serveis amb workflows, definir models d'entitats a partir de models relacionals, definir serveis de dades, crear diagrames de seqüències, de classes, etc. Amb el VS2010 que vindrà les coses encara són més senzilles i entenedores.

Dins les tecnologies .NET que Microsoft aporta mitjançant el seu framework gratuït, podem trobar dins de cada capa millores que ajuden a la gestió del coneixement.

Si comencem en la capa de dades, està clà, "S' HAN ACABAT LES SENTÈNCIES SQL DINS D' UNA APLICACIÓ". Avui en dia em d'anar més enllà del model relacional, i de consultes SQL dins les aplicacions, em d’ apostar pel model d'entitats, models post relacionals. N' hi ha un munt, NHibernate és poder el més famós, però jo em quedo de moment amb el que porta el mateix framework, de moment no necessito res més. I que ens aporta? coneixement. Amb un model d'entitats, si parteix d'un model E/R ben definit i amb les relacions entre taules ben establertes, obtenim un model d'entitats (classes) que ens aporten coneixement en tot moment del model que representen, mitjançant les seves propietats escalars i de navegació. Aquestes últimes ens informen cap a on podem anar a partir d'una instància qualsevol. Si a més projectem el context que formen aquest conjunt d'identitats a través d'un Servei de dades (DataService), podem accedir a un model de dades, des de qualsevol punt de la xarxa (fora de la intranet, saltant firewalls, amb HTTP o HTTPS), i a més a més, un model que ens aporta coneixement de com aquestes dades estan relacionades, i el més important que encara no ho he dit, en temps d' execució i consultable amb LINQ. "El sistema es capaç de d'informar-nos de que emmagatzema, com ho fa i com està relacionada tota la informació". I moltes més avantatges (mirar documentació a MSDN).

Si continuem en la línea lògica, ens trobem en la part de processos de negoci. Aquesta part ha d'estar desenvolupada amb Workflows. Aquest per si sols ja aporten coneixement, si estan ben implementats, ens donen una representació gràfica de flux del procés, encapsulen porcions de codi en activitats, augmentant en gran mesura la reutilització de codi, la flexibilitat dels processos i el coneixement dels usuaris. Es poden representar amb estructures XML, el que suposa que son portables , transferibles, serializables, fàcils de transmetre entre sistemes, fàcils de modificar, bé aconsello el seu estudi.

Alguns del processos de negoci seran projectats a través de serveis. Els serveis en .NET són igual a WCF. La gràcia d'aquesta tecnologia no l'explicaré, perquè és obvia si et documentes prou. Però respecte al coneixement també comença a aportar coses molt interessants, com poden ser el descobriment de serveis, la recerca de serveis a partir de certs criteris, serveis que anuncien la seva disponibilitat, realment molt interessant, només cal pensar que un client ja no s'ha de connectar a un servei que respon a una URL, sinó a un servei que respón a un criteri de recerca, això és coneixement, els sistemes saben que busquen però no saben on està, però els serveis que poden respondre a dites necessitats saben respondre a aquestes sol·licituds, ....... no calen més explicacions, imaginació i prou.

Si arribem a les capes de presentació, trobem components Web 2.0 que ajuden a captar coneixement dels professionals, però es tasca dels dissenyadors d'interfícies i els desenvolupadors, el fet d'aportar o incorporar components intel·ligents que siguin capaços de captar que vol fer un usuari i ajudar-lo i informar-lo si cal, de que està fent i que suposarà fer allò i com ho ha de fer. El sistema prèviament ha estat informat per algún professional qualificat amb el coneixement necessari per realitzar la tasca suposada, i per tant em estat capaços de captar el coneixement, i reutilitzar-lo.

"Bé com podem veure es un tema apassionant en el qual sens dubte i tenen cabuda algoritmes utilitzats en Sistemes Experts i Intel·ligència artificial. No és una tonteria, el futur del sistemes d'informació passa per convertir-se en sistemes de coneixement, el professionals han de conèixer el negoci, els sistemes també, i crec que en un futur la presa de decisions ha de ser compartida entre el professional i el sistema."

Nucli d'un model d'identitat

Està clà que, dins un sistema on és gestionen dades assistencials, dades de confidencialitat alta, és del tot necessàri saber en cada moment qui hi està accedint, perque, i quines accions s'efectuen sobre elles. Tot això cal aplicar-ho a diferents nivells del sistema (visió vertical) i per tant cal definir bé quines entitats i relacions entre aquestes formen part del gestor d 'identitats de mencionat sistema. Ha de ser flexible, per poder-se adaptar als requisits actuals i futurs, per diferents tipus d'autentificació, assignació d'usuaris als serveis, delegacions d'autoritat, etc, etc, etc.

Entitats bàsiques en el model de la identitat

Els següents termes descriuen les entitats que representen la identitat bàsica:

• Usuari (demandant) - l'individu a ser identificat, autenticat i autoritzat a utilitzar certs serveis.
• Identitat - representa i identifica a un usuari en el sistema de gestió d'identitat. Un usuari pot triar
  mantenir diverses identitats separades, en general que representen diferents rols o grups de serveis que romandre separats.
• Credencials - la informació o altres elements que són verificables d'afirmar una identitat. Poden ser moltes les credencials associats amb la mateixa identitat. Els exemples típics són, un identificador d'usuari i contrasenya, un certificat digital, etc.
• Servei - És una agrupació lògica de funcionalitat de negoci que ofereix un proveïdor de serveis, amb regles coherents d'autorització i accés dels usuaris. Una "agència de salut" poden oferir diversos serveis diferents, i les normes d'accés i els nivells d'autenticació requerit pot ser diferent per a cada un. Alternativament, l'agrupació de la funcionalitat de negoci de diverses agències com un servei únic és possible sempre que aquestes siguin compatibles i hi ha una participació clara i la responsabilitat assignada pel servei afegit.
• Inscripció - el vincle d'identitat per a un servei particular, amb el servei corresponent context específic de atributs (identificadors). Una inscripció vàlida i activa dóna dret al propietari (o degudament autoritzat representant) per accedir al servei en el marc definit pels identificadors.
• Identificadors - Informació sobre els atributs adjunts a una inscripció, que identifiquen i proporcionen el context per a la relació d'una identitat amb el servei respectiu. Exemples d'aquests identificadors són un impost ciutadà de referència, un nombre d'assegurança nacional, un nombre d'assegurança social, un identificador de registre d'empreses, un valor que afegeix el número de registre d'impostos, un identificador d'impostos a la propietat, un identificador de proveïdor de serveis públics, o un número de compte.
  
• Grup - representa un conjunt d'usuaris que comparteixen la mateixa matrícula/identitat, en general com a representants d'una organització.
• Rol - una àmplia categoria d'identitat utilitzada per definir o limitar l'accés als serveis apropiats per a tots els els usuaris dins d'aquesta identitat. El conjunt típic de funcions inclou:
  
• individual (ciutadà, pacient, el metge, consumidor, client, etc) - presenta els clients per als serveis de la salut.
  
• Organització (grup) - representa les organitzacions (empreses), on diversos individus en un grup de poden compartir la mateixa matrícula/identitat i actuar en nom de l'organització.
  
• intermediari (agent, delegat) - permanent o temporal, nomenat representant d'una persona o organització autoritzada a actuar en el seu nom en el context del servei especificat.
  
• de la salut - les persones i els sistemes de representació dels organismes de salut i autorització per accedir a serveis específics.

El model d'identitat

La figura il.lustra les relacions entre les entitats esmentades en el model d'identitat. Tingueu en compte que:

• Un usuari pot tenir diverses credencials.
• Cada un dels mapes de credencials de la Identitat, i la mateixa identitat que podrà ser utilitzada per diversos accessos en diferents "verificadors de poders/permisos".
• Cada un dels vincles d'identitat té un paper únic de participació, que determina el subconjunt de serveis a disposició d'aquesta identitat.
• Múltiples identitats es podesn enllaçar a un grup.
• Un grup pot ser amo d'inscripcions múltiples per als diferents serveis.
• Cada un dels mapes d'inscripció pertany a un únic servei.
• Cada inscripció a un servei s'ha associat a identificadors exclusius al context de la relació entre el propietari de la inscripció i el Servei.
  

Deu temes clau en els sistemes sanitaris

• Com crear registres de salut d'un pacient.
• Com construir la història clínica d'un pacient a partir de la informació emmagatzemada en múltiples i diversos sistemes d ' informació.
• Com gestionar la identitat i les autoritzacions d'accés.
• Com identificar un pacient (o un professional de la salut) de manera única i fiable.
• Com combinar els diferents sistemes que puguin existir.
• Com interconnectar diferents sistemes i com fer-los interactuar.
• Com comunicar-se amb sistemes remots.
• Com seguir utilitzant sistemes heretats.
• Com aconseguir que tot això sigui flexible i àgil.
• Com aconseguir un alt rendiment i escabilitat per garantir el futur.
  

Dades

No cal dir que en tot sistema d' informació, les dades són el més important de tot. Els SI serveixen bàsicament per crear, modificar, cercar, transformar, facilitar.... DADES.

En un Hospital, evidentment és manipulen dades, un gran volum de dades, expressades en diferents formats, text, imatges, video, etc. Aquestes, han estat generades a partir de diferents entorns (aplicacions) que juntes i d'una manera distribuida interacctuen entre elles.

Recordem però que volem implementar un sistema nou, que doni resposta a tot el que fa referencia a l'assitència mèdica. Aquest sistema treballarà en dades del propi sistema i dades originaries d'altres sistemes.

Imaginem un sistema del més normal. Les dades d'aquest segurament estaràn enmagatzemades en una BD. I, l'accés a elles en última instància segurament es farà en SQL.

Molt bé doncs, abans de pensar quina solució oferir a aquesta part tant important (Data Acces Layer) la capa d'accés a dades, cal fer un esforç i marcar-se uns objectius, que si es pot més tard es dissenyerant per una futura implementació.

Que volem aconseguir, quins objectius volem assolir en aquest projecte pel que fa a l'accés a dades?

• Transparència d’origen de dades: El lloc on estiguin allotjades ha de ser indiferents respecta al seu accés. Això no vol dir que qualsevol lloc és bo.
• Model d'entitats únic, independent de la BD: Això vol dir que sigui quina sigui la BD el model d'entitats (mapejos a objectes, més o menys) ha de seguir el mateix patró.
• Facilitar la lectura de dades relacionades en diferents BD: Cercar dades d'un origen a partir de dades tretes d'un altre.
• Veure les dades com si fossin totes d’un mateix context: Totes les dades han de formar un context de dades únic (Conjunt de contextos).
• Augmentar la productivitat en els desenvolupament de capes de procés (Bussiness Layer)
• Facilita-ne, si cal, l' accés remot (Serveis de dades).
• Evitar cadenes SQL dins el codi de les aplicacions (no es una tonteria).

Recordo que plantajem la solució en .Net.

Si mirem que ens ofereix aquesta tecnologia sobre accésos a dades i models d'entitas ens trobem que els de Microsoft estàn fent feina.

ADO.Net Entity Data Model

• System.Data


• System.Data.Entity

El mateix nom es defineix com a una possible solució al que volem. Un model de dades accessible sense SQL (també si pot accedir amb SQL). I, com si accedeix?, amb LINQ.

LINQ: Increíble, incríble, increíble.

Però, no tot es bonic. Amb SQL Server funciona a la perfecció, amb origens XML també, amb coleccions carregades a memòria també, però amb les altres bases de dades (Intersystems Cache, Oracle, MySQL, etc) dependrà dels seus fabricants, o, de la nostre imaginació. Només cal implementar una llibreria que transformi expressions LINQ a sentancies SQL amb la sintaxi de la BD corresponent.(linQToSQL)

I que aconseguim ?

• Tenir uns contextes de dades accesibles des de LINQ
• Desde LINQ podem tractar diferents contextes de dades com si fossin un de sol.
• Podem interrogar dades d’un contexte a partir de dades d’un altre, de manera fàcil i transparent.
• Projectar les dades a través de serveis de dades (ADO Data Services).
• Definir un cotext de dades (virtual) que actui com a proxy de tots els cotextes existents, al qual li demanarem les dades des de capes superiors (BL).

Una simple aproximació de disseny. Comencem a veure la llum?

Gestor d' identitats: solució inicial pel sistema

Bé, continuant amb les identitats, i després d'un periode de recerca, i pensant en la infraestructura de servidors i la tecnologia de desenvolupament "Microsoft", fem-li una ullada a les següents imatges

En un moment en que està de moda la col.laboració, el cloud computing i el SAAS (Software As A Service) i mirant el contexte en el que ens movem (HCCC, SIRE, ICAM, RCA, Factura Electronica) crec que hem de pensar en la col.laboració entre serveis de diferents entitats o coorporacions sanitaries de manera que s' aprofiti al màxim la feina feta. Per fer això s'han de complir uns requsits de seguretat que cal aplicar als diferents serveis exposats i unes politiques de col.laboració pactades entre els diferents participants.

Es de suposar que no tots els desenvolupadors coneixen tecniques de seguretat aplicades a la autentificació i autorització d'usuaris (identitat). Els desenvolupadors s'han de dedicar al negoci de la empresa i deixar els temes de seguretat als que en saben. O sigui, en termes desenvolupament, diriem que separem la lògica de seguretat de la lògica de negoci. Quan això només ha de funcionar dins la intranet, el problema es bastant senzill tant de desenvolupar com d'aplicar algún model existent (forms, windows,etc). Ara bé quan els límits sobrepassen la intranet, estem parlant de sistemes que confien els uns amb els altres. Per donar solució a això podem fer dues coses:

1. Donar usuaris i passwords a tots els usuaris externs (empresa forana) per tal de que puguin entrar a les nostres aplicacions




2. Dir-li al nostre sistema d'identitas(usuaris) que confii amb el sistema d'identitats de la empresa forana(amb tots o un grup de membres d'aquest)

Això és el que s'anomena federar sistemes (per dir-li d'alguna manera) i actualment es pot aconseguir amb Active Directory Federation Services, dins les tecnologies de microsoft.
Però com es de suposar això ha d'evolucionar, de manera que la seva tecnologia de desenvolupament, Microsoft .Net pugui aqprofitar el màxim aquesta visió de col.laboració en les seves tecnologies presentades als usuaris (un usuari pot ser una persona, una empresa o una aplicació) Asp.Net, WCF (Serveis), Winforms, SilverLigth, WPF, etc. I si, actualment es troba en la seva Beta 2, es diu Microsoft Code Name Geneva i disposa de bastante informació per començar-hi a treballar. Finalment serà anomenat Windows Identity Foundation i es distribuirà amb les noves versions de Windows 2008 (anira inclós en el producte).
Es basa amb estandars de seguretat i xifratge, soporta tarjes de identitats, pot generar assertions SAML, etc.

En aquests moments hi estic treballant.

Gestor d' identitats: Autentificació, autorització, pas de credencials entre aplicacions

La meva intenció no és explicar que és un gestor de identitats, però si deixar cla de la necessitat de disposar-ne d'un.
En el sistema a desenvolupar, aquesta feina serà delegada al servidor/s que allotgin el Servei de Active Directory.
Com tots sabem, l' AD és capaç d'enmagatzemar identitats d'usuari, maquinari, grups, unitats organitzatives, dominis, etc.

Per si no ho havia esmentat abans, utilitzarem sistemes microsoft tant en servidors com en clients, dins un domini d'AD. Per tant, els usuaris es validaran quan iniciin una sessió. Però, el usuari validat a la sessió a vegades no és nominal, sino que representa un lloc de treball on l'ordinador es utilitzat per diferents usuaris no concurrents alhora. Per tant, quan iniciien una aplicació del sistema, tots els usuaris s'han de tornar a loginar, per ser nominals, identificats en el programari per poder autoritzar les funcionalitats a les quals tenen accés.
I si no hi ha un sistema centralitzat per autentificar i autoritzar usuaris desde les aplicacions, cada cop que obrin una de les aplicacions que formen part del sistema senzer, els usuaris han de realitzar el procés d'autentificació. I si està centralitzat amb un AD, però les aplicacions no saben pasar-se credencials les unes a les altres, quan es criden entre elles, cal fer el procés d' autentificació. I si la crida entre aplicacions és entre aplicacions de tecnologies diferents, la cosa comença a complicar-se.
Bé, el que porti uns anys en el món de dels sistemes distribuits (en molts sistemes) suposo que ja ha entés el que vull dir.

La ideia, o proposta per solucionar aquest problemes, és dissenyar un sistema SSO (Single Sing-on) amb algunes particularitats pròpies, que un cop hagi validat un usuari, es puguin fer crides entre aplicacions de tecnologies diferents (ASP.Net, WinForms), allotjades en servidors diferents o subdominis diferents.

I això és possible? Si ho és, i ho farem.

Interoperabilitat: Integració, Serveis, Processos, Events, Transformacions de dades, Operacions i Adaptadors (connectors).

Es evident de que quan parlem d'un gran sistema distribuit, els diferents membres que el formen ha de ser capaços de comunicar-se entre ells.
Quan s'estableix una comunicació, aquesta pot donar-se de manera sincronitzada o no. Sigui com sugui aquesta, el receptor, sempre rep la petició asincronament, ja que no sap en quin moment arriba.

Dit això, quan parlem de integrar dos sistemes, el que volem dir exactament, es que d'alguna manera s'intercanviin infromació entre ells. Ara bé, quan són tres, quatre, o més els que s'han de intercanviar informació, la cosa comença a complicar-se, si volem que tot funcioni correctament. I per tant hem de buscar una solució el més transparet pel nostre sistema.

Situem-nos. EL sistema que volem desenvolupar és una part de tots els sistemes que formen el sistema d'informació complert. S' ens dubte, és el més important, i per tant les acciones o esdeveniments que es produeixin en ell afecten a la resta. Imagime-nos que un pacient modifica la seva ubicació, d'urgències pasa a radiologia. Aquesta acció ha d' avisar al sistema que gestiona la radiologia de que aquest pacient es dirigeix cap allà perque se li realitzi alguna prova, o de que a un pacient se li ha realitzat un nou informe i aquest s'ha de publicar a la HCCC (Historia clínica compartida de Catalunya), d'aguna manera o altre ho haurem de comunicar.

Quan pasa qualsevol esdeveniment al sistema, com els abans esmentats, cal que aquest sigui el sufientment intel.ligent per a saber-los gestionar. Aquesta gestió o intel.ligècia, és la que determina una bona interoperabiltat entre els sistemes. És el que en el món del programador coneixement com a events, accions i esdeveniments que es van produin dins el sistema i els quals em de capturar.

"I com diu un company, en C.R, el sistema serà complert quan aquest sigui capaç de gestionar qualsevol event empresarial i ....".

Evidentment, i més coses que ara no venen al cas.

Arquitectura conduida per events.

Tornant al principi, i per tal d'aconseguir una bona interoperabilitat entre els sistemes, ja hem vist que cal gestionar events, però això no es tot. Un cop capturat el event, cal comunicar-lo. Un cop comunicat, cal processar-lo, potser aplicar alguna transformació de dades i fer-lo arribar al seu destinatari o destinataris (sistemes receptors). O també podem rebre, quina gràcia si nos fos així, i seguir el mateix procés.

Com a solució a tot això, s'ha optat a comprar una eina especialitzada per fer aquestes coses (EAI). La millor opció actualment al mercat és Ensemble de Intersystems. La arquitectura de desenvolupament d'aquesta eina és molt senzilla i potent. Es basa en serveis (de negoci) que escolten i quan els hi arriba algún missatge, engeguen el procés (de negoci, workflow) que aten al missatge, en ell es fan les operacions i transformacions de dades necessàries, i mitjançant operacions, comunica els resultats als sistemes destinataris. Per aconseguir cominar-se amb els sistemes receptors, aixì com per rebre missatges d'aquest, disposa d'una serie de d'adaptadors (odbc, web services, fitxer, http, ftp, etc) que faciliten aquesta part. Per altre banda, i molt important dins el món de la sanitat, ajuda de manera extrema la utilització de missatgeria HL7 fins versió 2.6.

"Com podem observar en el dibuix, un sistema envia un missatge a través d'un adaptador a un servei d' ensemble, aquest egenga un procés que el tractarà, i aquest invocarà les operacions necesàries, fins que un cop finalitzi, a traves d'una operació/ns i un adaptador/s anirà comunicant el resultat al o els sistemes receptors. S'ha de tenir en compte, que tot el que passa per Ensemble queda enregistrat, cosa que ajuda molt en el moment de buscar incidències, errors, o simplement, fer el seguiment d 'un missatge (tracert). No es propaganda, és una bona eina. Demaneu opinió.".

Si parlem d'un sistema conduit per events (event driven), haurem de pensar en fer un gestió d'aquest. Això em fa pensar amb la necessitat d'un servei més dins del sistema, un manejador d'events (event manager), el qual s'encarregarà de tractar tots els events que es produeixin en el sistema, engegant o fent les accions oportunes.

"Una aplicació, invoca un servei del HIS per realitzar alguna operació. El Servei atent la petició i invoca el fluxe de treball que la processarà. Si cal aquest utilitzararé la capa de dades per per operacions de presistència (CRUD). Un cop acabat el procés, si cal es comunicarà al Manejador d'events, de l'event que ha passat dins el sistema, i també, si cal retornarà resposta al client (Aplicació). El manejador, és el que decideix si cal comunicar aquest tipus d'event al EAi perque informi a la resta de sistemes. Si la resta de sistemes actuen igual podem tenir una interoperabilitat entre tots molt bona".

Seguint aquest patró aconseguim una escabilitat del sistema molt gran. A més li donem transparència, ja que podem arribar a desconeixer que hi ha darrera del EAI. Assegurem reutilització de codi, ja que la gestió d'un event pot comunicar a varis sistemes la seva resolució, o sigui que si afegim sistemes, pot ser que al nostre sistema no hi haguem de fer res, ja que la informació que necessita pot ser que ja estigui disponible dins el EAI pels events exitents. La integració quedaria reduida a una operació més dins el EAI que faria arribar el missatge al nou sistema.

Servidors: On seran els Serveis i Com.

Pensant en una arquitectura orientada a serveis, aquest han d'estar allotjats en algún servidor o servidors. Es clar que parlem d'una arquitectura totalment distribuida i per tant cal tenir una infraestructura mínima per tal de poder-la posar en funcionament.

En tota "xarxa" informàtica de cert pes, com pot ser la d'una corporació sanitària, hi ha uns elements que han d'existir per tal de facilitar-ne l'us a les diferentes aplicacions que si publiquin.


Fem-ne una enumeració:
· Servidor d' administració: Aquest servidor serà l'encarregat de controlar mitjançant un Directori Actiu, les polítiques de seguretat, l'administració de comptes d'usuari i de maquinari. Per altre banda també pot oferir serveis de DHCP i DNS.
· Servidor de Correu: Servidor que allotjara un Microsoft Exchange 2007. Aquest sistema ens garantitza missatgeria estandard (mail), missatgeria instantània, missatgeria de veu, control de presencia, etc. És una eina bastant moderna, molt millor a les antigues versions i amb una arquitectura modular molt aconseguida.
· Servidor de Fitxers: Per allotjar fitxers personals o de grups de traball. Per facilitar-ne l'accés, hi montarem un servidor WebDav.
· Servidor d' impressores: Per poder controlar les cues d 'impressió d'una forma centralitzada.
· Servidor Proxy: Aquest servidor controlarà l'ús i els accesos a informació disponible a internet.
· Un tallafocs (firewall): Aquest servidor controlarà els accesos externs als servidors de la corporació.
Evidentment que amb això no n'hi ha prou, però si suficient per tenir una xarxa mínimament controlada i segura.

Per altre banda cal allotjar les aplicacions, les bases de dades, i les integracions amb aplicacions de tercers. I també disposar d'un sistema d'enmagatzament centralitzat i redundat.

Deixant de moment de banda els servidors, pensem en la topologia de xarxa. Depenent del volum d'estacions clients, cal pensar en una xarxa de classe B o varies de classe C. Amb una classe B (en cas que es necessiti), no cal pensar en sistemes de ruteig, però si en que un error de xarxa afecte a tota la xarxa. En una segmentació de xarxa amb subxarxes de classe C, cal fer un manteniment de rutes, i a vegades també suposa la duplicació d'algún dels serveis d'administració esmentats anterioement. I quan la xarxa està present en diferents edificis físics, la cosa és complica una mica més. Bé és un tema que alhora de posar-si cal discutir extensament.


Un altre punt molt important és pensar en com redundemt tot això. El sistema sencer ha d'estas disponible les 24 hores del dia, els 7 dies de la setmana i els 365(366) dies de l'any. En el cas dels sistemes d'enmagatzament, poden pensar en un sistema SAN, amb RAIDS i un accés fiberchannel o iSCSI (més barat i igualment d'efectiu). En el cas dels servidors, podem pensar en clusters, però la experiència em diu que hi ha solucions molt millors. I la xarxa, es pot redundar amb uns cores centrals (que es redundin entre ells amb spanning tree) així com disposar de switches redundats amb la mateixa tecnica en les arees més crítiques.

La Virtualització, com a solució a la redundància de servidors i a la alta disponibilitat dels serveis.

La virtualització crec que és una bona solució a la redundància de servidors i per tant garantir la disponabilitat de tots els serveis disponibles a la nostre xarxa. Hi ha varis sistemes capaços de donar serveis de virtualització de servidors, però si volem dissenyar un sistema segur, avui en dia només hi ha un nom, que és VMWARE, en les seves versions ESX.

Que ens pot oferir un sistema basat en VMWARE?
· Alta disponibilitat.
· Posibilitat d 'escalar els servidors, augmentant memòria i CPU
· Posibilitat de fer manteniment de servidors fisics (host VMWARE, sense parar) gracies al VMOTION i STORAGE VMOTION.
· Posibilitat de controlar carregues de treball en els Host i dotar a aquest de la intel.ligencia necessària perque actui davant moments crítics.
· Facilitat d'administració i visualització de marcadors indicatius (contadors).
· Facilitat de instalació de nous servidors (plantilles).
· Facilitat alhora de fer copies de seguretat de servidors.
· Facilitat alhora de fer test d'actualitzacions.
· Posibilitat d'allotjar servidors amb sistemes operatius diversos.
· Posibilitat de montar xarxes virtuals entre servidors.

Bé les ventatges són moltes, però cal montar una infraestructura basada en virtualització valorada segons les necessitats del sistema que ha d'allotjar. No és la meva intenció explicar res més tecnic, ja que VMWARE posa a la disposició dels usuaris molta informació de com montar un sistema de servidors virtualitzats. Ara bé hi ha unes cosetes que si que cal tenir en compte.

1. CPU: La cpu dels host de vmware ha d'estar preparada per virtualització (AMD anava per endevant).
2. RAM: Molta RAM, molt important.
3. HDD: El disc dur només ha d'allotjar el propi VMWARE ESX dels Host, ja que els servidors els intal.larem en espais de la SAN projectats cap els servidors del VMWARE.
4. Xarxa: Aqui si que hem d'anar en cura. Hem posar unes bones tarxes de xarxa i un número com a minim de 6.
5. Controladores de disc: Encar que no ho sembli es la art més crítica de la virtualització. Cal que siguin bones i sobretot amb Cache d'escriptura habilitada.

De totes maneres el millor quan pensem en virtualitzar és documentar-se i si és necessàri posar-se en mans d'un expert.(blog de Josep Ros)

Una bona solució, és un cluster ESX basat en 3 blades 4core amb 32GB de ram cada un de IBM amb el seu enclosure redundat en alimentació elèctrica, fons d'alimentació i xarxes (els blades de IBM tenen una distribució interna més bona que milloren la refrigeració d'aquest, envers altres marques).

I finalmet, per garantir la seguretat dels servidors d'aplicacions, serveis i bases de dades, cal pensar en una xarxa només per aquest, en el cas de que només si accedeixi des d'un altre servidor. Els servidors visibles des dels clients, han de tenir accés a aquesta xarxa de serveis i bases de dades i a la xarxa dels clients. Però, per exemple, els servidors de bases de dades, no haurien d' estar dins el mateix segment de xarxa que les estacions clients.
El més important alhora de donar d'alta un nou servei/servidor a la xarxa, cal pensar qui hi tindrà accés per tal de poder-lo ubicar de la millor manera i alhora evitar accesos indeguts (a vegades no es fa i després es configuren restriccions per software, innecessàries amb una bona distribució i ubicació de xarxa).


Pel que fa als servidors d'aplicacions i serveis, aquest seran també virtualitzats, amb Windows 2K3 i 2008. Com que la distribució de qualsevol aplicació es farà a través d'un entorn basat en Web, tots disposaran del IIS 6 o 7, i els frameworks 2.0, 3.0 i 3.5 disponibles en aques moment.

Cal pensaren balancejos de càrrega, reverse proxies, i WAF (Web Application Firewalls).

I per acabar, no em d'oblidar els serveis oferts des d' aplicatius de tercers, un PACS, un servidor de Laboratori, HCCC de Catalunya, la recepte electronica, la facturació del CatSalut, la facturació de ICS, el ICAM, el RCA, o sigui, qualsevol servei amb qui ens hem de comunicar, interoperar o integrar, digue-li com volgueu, a la intranet, al nus sanitari o a internet.

Per aconseguir una transparencia entre aquest sistemes i el propi a desenvolupar, apareix la necessitat d'utilitzar un EAI, però evolucionat, que doni la possibilitat d'afegir negoci a les integracions, que suporti HL7 i que sigui fiable, ràpid, doni tracebilitat de missatges i suporti estandars. La millor opció trobada ha estat Ensemble de Intersystems, un EAI evolucionat a posibilitat de Workflows i amb una arquitectura molt senzilla i moderna, basada en serveis de negoci, processos de negoci i operacions de negoci, amb suport HL7 fins versió 2.6. L' únic inconvenient per qui no coneixi Intersystems, es que porta el seu propi llenguatge de programació, orientat a objectes i amb suport d'herencia múltiple.

WCF (Windows Communication Foundation)

Windows Communication Foundation (WCF) de Microsoft és el model de programació unificat per a la construcció d'aplicacions orientades a serveis. Permet als desenvolupadors construir la seguretat, la fiabilitat, i la transacció a través de solucions que integrin les plataformes i interoperar amb les inversions existents.

Fonaments de WCF
Windows Communication Foundation (WCF) és un conjunt d'APIs per a la creació de sistemes que s'envien missatges, entre els serveis i els clients dels serveis. La mateixa infraestructura i API s'utilitzen per crear aplicacions que es comuniquen amb altres aplicacions en el mateix equip o en una màquina que resideix en una altre empresa i s'accedeix a través d'Internet.

Missatges i extrems (Messaging and Endpoints)
WCF es basa en el concepte de comunicació basat en missatges, i tot el que pot ser modelat com un missatge (per exemple, una petició HTTP o un missatge de MSMQ) poden ser representats de manera uniforme en el model de programació. Això permet una API unificada a través de diferents mecanismes de transport.
El model distingeix entre clients, que són aplicacions que inicien la comunicació, i serveis, que són aplicacions que esperan als clients per comunicar-se amb ells i respondre a aquesta comunicació.
Els missatges s'envien entre extrems.
S’han d’establir criteris, valorar i definir tota la informació necessària per a l'intercanvi de missatges.
Un servei exposa una sol licitud o més punts finals (així com a zero o més paràmetres d'infraestructura), i el client genera un punt final que és compatible amb un dels criteris de valoració del servei. Descriu un punt final que es basa en la manera en que els missatges han de ser enviats o intercanviats. Un servei pot exposar la informació com a metadades que els clients puguin utilitzar per generar clients (proxys) i contractes per tal de poder establir la comunicació amb les piles (conjunt de canals) del servei.

Protocols de comunicació

Un element de la comunicació és el protocol de transport que viatjara per la pila (canal). Es poden crear més mecanismes de transport utilitzant extensions del WCF.

Un altre element necessari en la pila de comunicació és la codificació que s'especifica de quina manera cada missatge està formatat. WCF proporciona les següents codificacions:

Codificació de text, una codificació interoperable.
Mecanisme de transmissió del missatge d'Optimització (MTOM) de codificació, que és una forma interoperable, eficient per a l'enviament de dades binaries no estructurades d'un servei.
Codificació binària per a la transferència eficient.

Es poden generar més mecanismes de codificació (per exemple, una codificació de compressió) fent ús dels punts d'extensió del model d ‘operacions de WCF.

Patrons missatge

WCF admet diversos models de missatgeria, incloent sol licitud-resposta, en un sol sentit, i la comunicació dúplex. Les diferents modalitats de transport donen suport a les diferents modalitats de missatges i, per tant l'API de WCF en temps d’execució afageix seguretat i fiabilitat en l’intercanvi de missatges.

Termes WCF

Altres conceptes i termes utilitzats en la documentació de WCF Són els següents.

Missatge

Un missatge és una unitat autònoma de dades que podrà constar de diverses parts, inclòs un cos i les capçaleres.

A service is a construct that exposes one or more endpoints, with each endpoint exposing one or more service operations.Un servei és una construcció que exposa un o diversos paràmetres, amb una exposició de cada punt final i operacions de servei.

Un punt final és una construcció en la que viatgen els missatges enviats o rebuts (o ambdós). Es compon d'un lloc (una adreça) que defineix on es poden enviar missatges, l'especificació d'un mecanisme de comunicació (vinculant) que es descriu com s'han d'enviar els missatges, i una definició d'un conjunt de missatges que poden ser enviats o rebuts (o ambdós) en aquest lloc (un contracte de serveis) que descriu el que es pot enviar el missatge.
Un servei de WCF s'exposa al món com una col lecció de punts finals (canals).

Aplicació de punt final

Un punt final exposat per la sol licitud i que correspon a un contracte de serveis executats per l'aplicació.

Infraestructura de punt final.

Un punt final que s'exposa a través de la infraestructura per facilitar la funcionalitat que es requereix o és facilitada pel servei que no es refereixi a un contracte de serveis.

Per exemple, un servei pot tenir un punt final que proporciona la infraestructura d'informació de metadades.

Adreça

Una adreça específica el lloc on es reben missatges. S'especifica com un Uniform Resource Identifier (URI). La part de l'esquema de noms URI és el mecanisme de transport a utilitzar per arribar a l' adreça, com ara HTTP i TCP. La jerarquia de la URI conté una ubicación única i el format depèn del mètode de transport. El punt final de l' adreça li permet crear adreces úniques per a cada punt final en un servei, o, en determinades condicions, es pot compartir una adreça en els extrems.

L'exemple següent mostra una adreça mitjançant el protocol net.tcp amb un port no predeterminat:

net.tcp://server.domain.com:8000/DalDBIService/Service.svc

Element vinculant

Un element vinculant representa una part de la unió, com ara el transport, una codificació, una implementació d'una infraestructura a nivell de protocol (com WS-ReliableMessaging), o qualsevol altre component de la comunicació pila.

Controladors de Funcionament

Un controlador és un component que controla diversos aspectes de temps d'execució d'un servei, un punt final, una operació, o un client. Els controladors s'agrupen d'acord a l'àmbit d'aplicació: controladors comuns afecten tots els punts finals a nivell general, el servei només afecta els controladors relacionats amb els aspectes de serveis, al punt final només afecten els controladors relacionats amb les propietats de punt final, i el funcionament a nivell de conductes afecten a les diferents operacions. Per exemple, un controlador és la regulació, que especifica com reacciona quan un un excés de missatges amenacen amb desbordar la seva capacitat de manipulació. Un controlador variable, d'altra banda, els controls només els aspectes relatius a les variables, com ara com i on trobar una credencial de seguretat.

Enllaços proporcionats pel sistema

WCF inclou diferents sistemes d'enllaços. Es tracta de col leccions d'elements vinculants que estan optimitzats per a situacions específiques. Per exemple, el WSHttpBinding està dissenyat per a la interoperabilitat amb els serveis que implementen diferents especificacions WS-*. Aquests enllaços predefinits estalvien temps presentant únicament les opcions que poden ser correctament aplicades a la situació específica. Si un predefinit vinculant no compleix els seus requisits, es pot crear el seu propi vinculant.

Configuració versus codificació

El control d'una sol licitud es pot fer ja sigui a través de la codificació, a través de la configuració, o mitjançant una combinació d'ambdós. La configuració té l'avantatge de permetre que algú que no sigui el promotor (per exemple, un administrador de xarxa) pugui configurar els paràmetres de servei de client i sense haver de recompilar el codi escrit. Configuració no només li permet establir els valors com les adreces de punt final, sinó que també permet un major control per la qual cosa li permet afegir punts finals, fixacions, i comportaments. Codificació permet als desenvolupadors mantenir un control estricte sobre tots els components del servei o client, i qualsevol ajustament realitzat a través de la configuració pot ser inspeccionat i, si cal anul lat des del codi.

Explotació del servei

Un servei és un procediment d'operació que es defineix en una part de codi que implementa la funcionalitat per a una operació. Aquesta operació està exposada als clients com els mètodes d'un client WCF. El mètode pot tornar un valor, i pot tenir un nombre opcional d'arguments, o no tenen arguments, i tornar sense resposta. Per exemple, una operació que funciona com un simple "Hola" es pot utilitzar com una notificació de la presència d'un client i començar una sèrie d'operacions.

Contracte de servei

El contracte de serveis utilitza múltiples llaços junts en les operacions relacionades amb una sola unitat funcional. El contracte pot definir els ajustos de nivell de servei, tals com l'espai de noms del servei, el corresponent contracte de devolució de trucada, i altres ajustaments. En la majoria dels casos, el contracte es defineix per la creació d'una interfície de programació en l'idioma de la seva elecció i l'aplicació de la ServiceContractAttribute atribuit a l’ interfície. El codi de servei real es el resultat d’ aplicar la interfície.

Un contracte d'operació es defineix el tipus de retorn i paràmetres d'una operació. En crear una interfície que defineix el contracte de serveis, que significa un contracte d'operació mitjançant l'aplicació dels OperationContractAttribute atribuir a cada mètode de definició, que és part del contracte. Les operacions poden ser modelades tenint un sol missatge, o tenint un conjunt de tipus de missatges. En aquest últim cas, el sistema determinarà el format dels missatges que han d'intercanviar per l'operació.

Un missatge contracte descriu el format d'un missatge. Per exemple, declarar els elements que han d'anar a les capçaleres i al cos, quin nivell de seguretat s'ha d'aplicar als elements del missatge, i així successivament.

Culpa contracte(Excepció)

Un contracte de culpa es pot associar amb un servei d'operació per indicar els errors que es poden retornar a la persona que truca (client). Una operació pot tenir zero o més defectes associats a ella.. Aquests errors (transmesos en SOAP) es basa en les fallides com les excepcions en el model de programació.

Contracte de dades

Els tipus de dades que utilitza un servei, haurà de ser descrita a les metadades per tal que puguin interoperar amb altres per al servei. Les descripcions dels tipus de dades són coneguts com les dades del contracte, i els tipus es poden utilitzar en qualsevol part d'un missatge, per exemple, com a paràmetres o tipus de retorn. Si el servei és senzill utilitzant només els tipus, no hi ha necessitat d'utilitzar les dades explícitament els contractes.

Allotjament

Un servei ha d'estar allotjat en algun procés. Un host és una aplicació que controla la vida útil del servei. Els serveis poden ser acollits o auto-administrats per un procés d'acollida existent.

Auto-servei allotjat

Un auto-és un servei allotjat que s'executa dins d'un procés de sol licitud, que el desenvolupador ha creat. (Classe ServiceHost)

Procés d'acollida

Un procés d'acollida és una aplicació que està dissenyat per acollir els serveis. Aquests inclouen Internet Information Services (IIS), Serveis d'activació de Windows (WAS), i serveis de Windows. En aquests escenaris amfitrió, l'amfitrió controla la vida del servei. Per exemple, si utilitza IIS, pot crear un directori virtual que conté el servei de muntatge i arxiu de configuració. Quan es rep un missatge, IIS inicia el servei i controla la seva vida.

Instàncies

Un servei té un model d'instància. Hi ha tres models d'instàncies: "únic", en què un sol objecte servei CLR atent tots els clients, "per trucada", en la qual un nou objecte CLR es crea per tractar a cada client de trucada, i "en cada període de sessions", en què un conjunt CLR d'objectes es creen, un per a cada període de sessions. L'elecció d'un model d'instància depèn dels requisits de l'aplicació i el patró d'ús d'espera del servei.

Aplicació client

Una aplicació client és un programa que els intercanvis de missatges amb un o més extrems. L'aplicació client comença per la creació d'una instància d'un client de WCF i els mètodes, funcions i propietats que pot invocar del servei WCF. És important assenyalar que una única aplicació pot ser tant un client i un servei.

Canal

Un canal és una aplicació concreta d'un element vinculant. La unió representa la configuració, i el canal està associat amb l'aplicació de la configuració. Per tant, la configuració defineix un canal associat a cada element vinculant. El conjunt de canals defineixen la pila de canals que es poden utilizar per invocar el servei (canal pila).

WCF client

Un client de WCF és una aplicació client que exposa a la construcció de les operacions dels serveis com els mètodes (al. NET Framework, llenguatge de programació de la seva preferència, tals com Visual Basic o Visual C #). Qualsevol aplicació pot acollir un (o més) WCF client, inclosa una sol licitud que allotja un servei. Per tant, és possible crear un servei que inclou el conjunt operacions dels clients altres serveis.

Un client de WCF pot ser generat automàticament utilitzant l'eina d'utilitat ServiceModel metadades (Svcutil.exe) i apuntant en funcionament un servei que publica metadades.

Metadades

Les metadades d'un servei ens descriuen les característiques del servei que una entitat externa a d'entendre per comunicar-se amb el servei. Les metadades poden ser consumits per la utilitat de les metadades ServiceModel Tool (Svcutil.exe) per generar un client de WCF i que acompanya a la configuració d'una aplicació client pot utilitzar per interactuar amb el servei.

Les metadades exposades pel servei inclou l'esquema XML de documents, que defineixen les dades del contracte del servei, i els documents WSDL, que descriuen els mètodes del servei.

Quan està activada, les metadades del servei es generen automàticament pel conjunt d'operacions pel servei d'inspecció i els seus criteris de valoració. Per publicar les metadades d'un servei, s’ha d’especificar explícitament en el comportament del servei.

Seguretat

WCF inclou la seguretat a la confidencialitat (xifrat de missatges per prevenir escoltes), integritat (els mitjans per a la detecció de la manipulació amb el missatge), l'autenticació (els mitjans per a la validació dels servidors i clients), i l'autorització (el control d'accés als recursos). Aquestes funcions són proporcionades per qualsevol dels mecanismes de seguretat existents, com TLS sobre HTTP (també conegut com HTTPS), o mitjançant l'aplicació d'una o més dels diversos WS-* especificacions de seguretat.

Per la seguretat del transport

Seguretat poden ser proporcionades per un dels tres modes: mode de transport, el mode de missatge de seguretat, i el transport amb el mode de missatge credencial. El mode de seguretat de transport s'especifica que la confidencialitat, integritat, autenticació i són proporcionades pels mecanismes de la capa de transport (per exemple, HTTPS). Quan s'utilitzi un transport com HTTPS, d'aquesta manera té l'avantatge de ser eficient en el seu acompliment, i siguin ben compreses per la seva prevalença a Internet. El desavantatge és que aquest tipus de seguretat s'aplica per separat en cada tram en la ruta de comunicació, fent de la comunicació sensibles a un atac “d’ home al mig”.

Per la seguretat en el missatge

Missatge Especifica el mode de seguretat que la seguretat és proporcionada per l'aplicació d'una o més de les especificacions de seguretat, tals com l'especificació anomenada "de seguretat de Serveis Web: SOAP Message Security" (disponible a http://go.microsoft.com/fwlink/?LinkId = 94684). Cada missatge conté els mecanismes necessaris per garantir la seguretat durant el seu trànsit, i de permetre que els receptors per detectar la manipulació i per a desxifrar els missatges. En aquest sentit, la seguretat es encapsulada dins de cada missatge, d'extrem a extrem a través de múltiples salts. Perquè la informació de seguretat es converteix en part del missatge, també és possible incloure diversos tipus de credencials amb el missatge (es refereix a les reclamacions). Aquest enfocament també té l'avantatge de permetre que el missatge pot viatjar de forma segura a través de qualsevol transport, inclouent salts entre origen i de destí. El desavantatge d'aquest enfocament és la complexitat dels mecanismes de xifrat, i les implicacions que porta la seva correcta execució.

Transport amb el mode de missatge de credencial de seguretat

Aquest mode utilitza la capa de transport per proporcionar confidencialitat, autenticació i integritat dels missatges, mentre que cadascun dels missatges pot contenir múltiples credencials (reclamacions) requerida pels receptors del missatge.

EAI i ESB no són el mateix

Bé en el dia d'avui es del tot ben clar que ens movent inmersos en un munt de procesos informàtics que es parlen entre ells enviant-se missatges a través de la xarxa. Es per això que va neixer la necesitat de adatar aquestes comunicacions entre processos i no només això sino traduir els missatges que generava un de manera que l'entengués l'altre. Quan la necessitat era un a un no passava res, però quan la necessitat d'entendres era amb varis processos de diferents sistemes, la cosa comensava a fer-se feixuga. Va ser llavors quan va neixer el que van anomenar EAI (Enterprise Application Integration), una eina que en pricipi servia per fer transformacions de dades d'una estructura a una altre, facilitat la comunicació entre dos sistemes que necessitenssin infomació l'un de l'altre. Incicialment els EAI eren eines centrelitzades en un servidor, que només transformaven dades. Van anar evolucionan i més endavant van incorporar negoci en la integració, cosa que feia que fos un element més actiu i present dins la empresa, ja que no només s'el tenia en compte alhora de transformar dades, sino també alhora de tractar-les. Ara bé, amb el naixament de l' arquitectura orientada a serveis (SOA), van sorgir la necessitat d'agrupar aquests, els serveis, els quals serveixen per fer la comunicació entre diferents clients i els diferents sistemes. Com que aquest es basen en estandards la teoria diu que els serveis son accessibles des de diferents tecnologies, i com que ha darrera d'un servei hi pot haver negoci, els fan elements claus en la infraestructura de qualsevol sistema empresarial. Aleshores quan comencen ha haver molts serveis neix la necesitat de gestinar-los, i es quan neixen els ESB (Enterprise Service Bus). Aquest el que fan es allotjar serveis. La gracia està en que poden funcionar de manera distribuida i federada entre diferents servidors. Un cosa bàsica es que es basen amb estandards, cosa que pot semblar molt bona, però no ens oblidem mai d'una cosa quan parlem d'estandars, i es que sempre estan acotats.

Arquitectura Orientada a serveis en .NET.

Windows Communication Foundation (WCF) de Microsoft és el model de programació unificat per a la construcció d'aplicacions orientades a serveis. Permet als desenvolupadors construir la seguretat, la fiabilitat, i la transacció a través de solucions que integrin les plataformes i interoperar amb les inversions existents.


Per desenvolupar amb aquest model cal partir del Farmework 3.0 de Microsoft. Una de les avatnatges més grans es que separa totalmet la capa de comunicació de la resta del negoci que implementa el servei. Fins a tal punt que modificar aquesta capa o canviar-la o afegir-ne una de nova es tant simple com escriure en el fitxer de configuració algunes comandes, i ni tant sols cal tornar a compilar el servei. Es poden especificar tant protocols estandars, com protocols no tant estandars com poden ser pipes o ques MSQM. També porta associats a la comunicació sistemes de validació, autorització i xifratge de missatges.

Per altre banda assegura que els missatges intercanviats entre client i servidor siguin coneguts per ambdós de manera específica (DataContracts, DataMembers) així com les operacions o funcinalitats ofertades pel Servei (OperationContract).


Per altre banda hem de pensar en quin mode de configuració usarem en cada cas. Si pensem una mica podem dir que quan més amunt estigui el servei, més estándard i quan més avall menys. Que vull dir amb això, doncs que els serveis que només siguin consumits per altres serveis (del nucli del sistema) cal que siguin efectius i farem servir protocols de baix nivell (tcp/ip, pipes si estan allotjats en el mateix servidor o ques). Si són serveis usats per aplicacions utilitzarem (http, SOAP, xml).


No cal remarcar que aquesta arquitectura aporta al sistema un radi de interoperatibilitat complert, el que vull dir amb això es que qualsevol servei es pot convertir en estándar (SOAP, Http, XML) modificant un fitxer de configuració (2 minuts), i canviar-ne el comportament en qualsevol moment.

Arquitectura

El sistema que aquí es proposa està basat en una arquitectura orientada a serveis (SOA). Aquest tipus d’arquitectures segueixen una serie de premises, les quals les fan que actualment siguin les millors per aplicar en grans sistemes d’ informació.

Com a concepte defineix serveis per donar suport a les necessitats del negoci. Està demostrat que aquest tipus d’arquitectura facilita la escabilitat i reutilització de codi, la modularitat de les solucions i el desenvolupament de components, així com la interoperabilitat entre sistemes, ja siguin aquests de tercers. En un model basat en serveis web fins i tot s’estanderitza tant que facilita la interoperabilitat entre sistemes basats en tecnologies totalment diferents.

Podem definir el serveis com a funcions sense estat, que no tenen dependencia de cap altre servei, això no vol dir que no l'utilitzin, es poden orquestrar (sequenciar amb altres serveis) afegint la lògica necessària i mai portan un UI (user interface). Això si, faciliten una interfície de comunicació al consumidor (sempre i quan desenvolupem aquesta arquitectura amb eines d 'ultima generació, actuals)

Per tal de desenvolupar serveis, el més important es mentalitzar-se en aquesta arquitectura. Desenvolupar serveis comuns que seran secuenciats per clients. Quan es parla de SOA bàsicament parlem de protocols coneguts a Internet, i quan la gent (desenvolupadors) en parla ho fa referint-se a serveis web. SOA no és igual a Serveis Web. El concepte es més ampli. Els protocols més comuns i coneguts són HTTP, XML, SOAP, WSDL, UDDI, però això no vol dir que siguin requisit de l’arquitectura, ni que siguin els únics. Una cosa és la arquitectura SOA i una altre els protocols de comunicació.

Desenvolupar sistemes d'informació amb aquesta arquitectura porta els seus avantatges:

• Millorar els temps en els canvis de procesos (facils de modificar)
• Facilitar la adaptació a models de negoci de tercers.
• Facilitar la colaboració amb procesos de negoci de tercers (altres proveidors)
• Facilitar el desenvolupament en capes.
• Facilitar la integració i la interoperabilitat amb tecnologies diferents.

Existeixen diferents tecnologies de desenvolupament, que faciliten, unes més que altres, el disseny SOA. Empreses com IBM, BEA, SUN o Oracle oferten eines de desenvolupament SOA. Ara bé Microsoft també, a partir de Framework 3.0 amb VS2005. Però amb el VS2008 i el Farmework 3.5, crec que podem anar bé, molt bé. De fet s' estan posant les piles, que ja era hora, pel que fa a entorns de desenvolupament competitius. Recordem que fins fa poc tenien VB6 i C++, quan la tecnologia Java (gratuita i amb IDE's gratuits com Eclipse o Netbeans) ja oferia tecnologia JSP, servlets, Struts, etc, ja oferia la posibilitat de crear Web Services (Axis) i utilitzar tecnologia AJAX en entorns "web" amb DWR (Direct Web Remoting) que començaven a tenir bona acceptació. Com a curiositat dir que GMAIL utilitza DWR com a framework AJAX. Bé dit això, repeteixo, VS2008 i Framework 3.5 són una molt bona opció per desenvolupar SOA, sobretot amb el WCF (Windows Comunication Foundation) i WWF (Windows WorkFlow Foundation). I si ens mirem el que vindrà aviat amb el Framework 4.0, no hi ha dubtes.

Un cop tinguem els serveis, aquest s'hauran de catalogar i allotjar. Per allotjar serveis s' utilitza el que anomenem un ESB (Enterprise Service Bus). Resumint podriem dir que es una "Aplicació" o s'allotgen els serveis, i aquesta facilita el descobriment d'aquest i la comunicació amb ells als clients. Podriem dir que és una evolució del EAI, però no, no són ben bé el mateix.

Ara bé, jo desestimo la opció d'un ESB en aquest moments, mirant el futur del .NET i els SO de Microsoft (Win Server 2008 + II7 + Oslo + Dublin + WAS + PowerShell + ...) crec que amb aquesta linia ens ho donaran fet.

Els serveis els podem catalogar en quatre grups:
Serveis de Negoci
Serveis que formen part del nucli de la empresa i el negoci, normalment identificats per usuaris no tecnics i casos d’ús o escenaris d’aquest. Estan molt lligats amb els verbs CRUD (create, read, update, delete). Un posible exemple seria (CrearClient….). Solen estan desenvolupats amb estandards (Web Services). Solen ser consumits per aplicacions que interactuen amb l’usuari, ja que com he dit complimenten els seus escenaris.
Serveis d’ Empresa
Serveis identificats pels membres del departament Sistemes d’Informació. Solen ser producte de la sequenciació de varis serveis (orquestració), o sigui serveis que fan servir altres serveis per donar una resposta. CalcularPressupost, ProcessarCuaPeticions, etc
Serveis d’ Aplicació
Serveis que no formen part del nucli però hi poden acabar. Són serveis especifics de la Aplicació en questió i es solen identificar amb aquesta. Un exemple actual seria GuardarAdreça de les agendes de la Empresa.
Serveis d’ Infraestructura
Serveis de suport a tots nivells. Logging, auditoria, seguretat. Solen ser identificats per desenvolupadors i gent de sistemes. Exemple EnviaMissatgeLog

I per acabar aquesta part només dir que com a possibles consumidors de serveis podem tenir:

• Aplicacions
• Serveis (altres serveis)
• Dipositius: TAC, ECODOPPLERS, ELECTROS, CONTROLS DE PRESENCIA, PDA...., DOMOTICA,......,ALARMES, SENSORS, .....

Veien aquesta diversitat, crec que SOA es una molt bona opció.

Antecedents

El sistema a desenvolupar està inmers en un cotext sanitari. O sigui, per entendrens, es tracte de desenvolupar un sistema complert per ajudar als professionals de la sanitat (metges, infermers, auxiliars d’ infermeria, administratius,etc) a donar la millor assitència sanitaria possible al pacient.

Per qui no coneix aquest món, com a negoci (mirat sempre des del punt de vista dels sistemes d’ informació) és bastant, o millor dit, molt complexe. Si a això hi afegim el dinamisme que implica el coneixement dels professionals que fan servir aquest sistemes (metges, infermeres, professionals de la sanitat), així com al dinamisme del entorn sanitari, encara ho complica més. Per entendrens millor, només hem de pensar en que la medicina a igual que els sitemes d’ información està sempre en constant evolució. Si això li afegim la importància de les dades que es mouen (dades referents a la salut de les persones) i la confidencialitat que aquestes requereixen, encara es complica més.

Si a aquest sistema, podriem dir assistencial, li afegim la resta (no assitencials), recursos humans, contabilitat, facturació (pública i privada), compres, magatzems, cuina, bugaderia, magatzems, etc, encara es complica més. I per tant, estem davant d’un sistema distribuit, els membres del qual han de poder interoperar entre ells. I si a més a més alguns d’aquest sistemes són propietaris, amb tecnologies totalment diferents, encara es complica més.

També hem de pensar que actualment, el negoci no està parat. Això vol dir que existeix un sistema, que en algún moment s’haurà de migrar, augmentant encara més el grau de complexitat. I si es tot tant complexe, com es que decidim apostar per aquest canvi? Doncs perque el sistema actual està caducat, cal fer una reingenieria del sistema total. Funcionalment el considerem bastant complert (valorant solucions de mercat), però el metode en que es va desenvolupar ja no dona per més. Fer-lo creixe cada cop costa més. Es tra d’un sistema totalmente monolitic, les dades del qual estan enmagatzemades de forma jerárquica, amb manca de documentación, cosa que puposa perdua de coneixement del sistema. A tot això cal sumar, pocs professionals al mercat per poder-lo gestionar, i poca productivitat per part del departameent SI.

“Els diplodocus eren dinosàuris molt grans, això feia que fossin lents, molt lents. Davant dels problemes que els hi poguessin sortir, reaccionavem lentament, i a vegades massa tard. Els velociraptors en canvi eren ràpids, àgils, intel.ligents, treballaven en grup, es sabien comunicar, i si tenien algún problema el resolient ràpidament”.

“Hem d’aconseguir un sistema format per un grup o família de velociraptors, que es comuniquin, colaborin i es relacionin entre ells, idependentment del metode de desenvolupament i la tecnoligia que facin servir”

I per acabar aquest punt, com a professional dels sistemes d’informació, i amb uns anys d’experiècia demostrats, m’agradaria apuntar un detall. El món sanitari és un món que va lligat directament amb la evolució del coneixement i les noves tecnologies. Catalunya com a país aposta per la formació professional dels seus habitants, de manera encertada, i mira als països més desenvolupats per poder trobar models aplicables al creixement en materies de coneixement i formació. El més curiós de tot es que quan has lluitat per la teva formació, durament, arribes al món laboral i resulta que no serveix per res, el titol no es contempla dins el conveni al que pertanys. El que vull dir es que és molt trist que un llicenciat o enginyer o tècnic informatic, que desenvolupa tasques de analisi, disseny, desenvolupament de tecnologies de sistemes d’informació, o sigui que fa la feina que sap fer i per la qual a invertit molt temps de formació, no sigui reconegut com a tal. Amb detalls com aquests, els països acaben sent anomenats, països desenvolupats. Suposo que altres col.lectius es troben en el mateix cas. Així va tot.

Presentació

Aquest blog ha estat creat amb la intenció de escriure informació basada en el coneixement que vaig assolint d' aquesta arquitectura.En un moment, en que em trobo inmers en un gran projecte (de grans dimensions) del qual se m'ha encarregat el disseny de l'arquitectura del sistema i de les aplicacions (o serveis) que el formaran, crec que aquesta es una manera de deixar escrita la meva experiència.