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.