Tuesday, November 15, 2005

Strategy: Governance, Security, and Management in a Service-Oriented World

Paul Lipton, de Computer Associates va fer un recull de suggeriments i experiències en aquesta conferència dedicada als aspectes més crítics de l’Arquitectura de Sistemes Orientats a Servei (SOA) com poden ser la seva governabilitat, la seguretat i els seu control general. Consells i perills en un món on no sempre depenem de nosaltres mateixos.

Va començar descrivint el context que ens trobem a l’hora de implementar, o mantenir un sistema SOA:
- Els sistemes son multi-plataforma i heterogenis.
- El desenvolupament d’aplicacions, la instal·lació i la comunicació del sistema amb el seu entorn.
- Tot i això, la seguretat i el control del sistema encara és força plataforma-cèntric, tot i que, de vegades, es desitjable mirar les coses amb més perspectiva per tal de obtenir millors resultats.

Tot seguit va definir les característiques que descriuen la governabilitat d’un sistema:
- Evita desviacions dels objectius marcats.
- Fa èmfasi en el desenvolupament d’actius.
- Ha de ser aprovable, escalable i global.
- I per últim, un aspecte crític: Visibilitat i Control en temps real.

Poc després va descriure un error comú que es dona quan treballem amb SOA. Com es fàcil habilitar politiques de Seguretat, ens hem d’assegurar que l’àmbit d’aquestes polítiques és el correcte. Ficarem un exemple per tal de que quedi clar el concepte: El govern d’Àustria ha de poder controlar el seu exèrcit però no pas l’exèrcit europeu.
A continuació va parlar dels riscos de negoci, es a dir, els lligats a àmbits funcionals, al context del negoci, aquells que et poden enviar a la presó si els incompleixes, així que pareu atenció:
- En companyies heterogènies assegurar-se de que totes les parts coneixen les seves obligacions.
- Context de privacitat de dades: Atents a la legislació vigent sobre protecció de dades.
- La qualitat del servei ha de mantenir-se tal i com es va estipular.

Per tal d’assegurar l’èxit de la implantació d’un Sistema haurem d’afrontar una sèrie de desafiaments:
- Ingent increment de la complexitat.
- Gestió dels fluxos d’events.
- Problemes de diagnòstic de crisis.

Aquest últim punt pot ser especialment costós i reactiu si l’hem de fer mitjançant una visió centrada exclusivament en una versió del sistema. L’última que va funcionar abans de l’error, per exemple.
Tenint en compte que SOA és un nou paradigma que pot comprendre diversos dominis, hem de pensar que, en moltes ocasions, no depenem només de les nostres infraestructures i que, justament per això, podem tenir problemes deguts a terceres persones.
Per aquesta raó, conèixer qui ha causar l’error no és suficient, necessitem de una polítiques unificades i d’un veritable Anàlisi que analitzi les causes profundes dels errors. El qui és important, però més important es el què i el perquè.
En aquest punt, en Paul Lipton va establir un nou Standard per aquest nou paradigma heterogeni. Aquest Standard rep el nom d’ OASIS WSDM (Web Services Distributed Management) i el seu sistema de control rep el nom de Muws (Management using Web Services).

En que consisteix Muws? Doncs conté una sèrie de capacitats de control (Identificadors, controls d’estat, mètriques, configuració, relacions, etc) obtenint capacitats de control en un entorn canviant.
A mes, simplifiquem el sistema atès son WebServices els que governen WebServices i millor integració de control i funcional en un flux d’informació bidireccional.
El punt a on volen arribar és aquell on els processos siguin suficientment intel·ligents, smart processes, per tal que puguin saber si tenen prou recursos per ser llençats, es a dir, com si els processos de negoci poguessin ‘parlar’ amb els processos de control.
Però per aconseguir això una fita imprescindible és tenir Standard oberts per tal de garantir la interoperabilitat.I en aquest punt varem tenir que deixar la ponència per qüestions de Timing.
Una mena de coitus interruptus però que tot i això va resultar d’allò més reveladora en el sentit de veure el canvi de pensament Mainframe-centralista cap a Sistemes Distribuïts i els problemes i reptes que aquests ens provoquen.

Friday, November 11, 2005

Strategy: Policy Driven Architecture: The new contract model for SOA

En aquesta conferència ens ha explicat perquè i com s’ha de separar la part de polítiques i la part de negoci en una arquitectura SOA.

La part de política consisteix en definir temes com la seguretat, l’eficiència, la disponibilitat, els permisos, ... i ha de ser controlada per un “Policy enforcement Point” que asseguri que s’executen les regles establertes per cada Web service.

D’aquesta manera els desenvolupadors es poden centrar en dissenyar els requeriments de negoci.

Tot això necessita de l’arquitectura anomenada “Service Bus” que es podria definir com un entorn on cada node pot consumir i publicar serveis. Cada node disposa d’un “Policy enforcement Point” que assegura que es compleixen les polítiques definides en els contractes per cada crida a un servei.

Best practices: Realtime Enterprise Architecture: How SOA can use and benefit from active EA Models

Encara que era una conferencia de Best Practices, ha estat molt teòrica. Ha sigut una vista per sobre de com aplicar models de coneixement a EA. El model explicat ha estat el de les ontologies:

- Model d’informació en temps real (és consultable com si fos una base de dades)
- Permet definir rols, activitats, sistemes, recursos, ...
- Basat en estandards:
· XML
· RDF
· OWL
- Defineix una arquitectura semàntica d’empresa que permet respondre preguntes com:
· Qui està utilitant què
· Quins sistemes estaran afectats per..
· Quina tecnologia suporta aquest servei
· ...

A mi personalment m’ha semblat una conferència massa teòrica i molt utòpica. El model presentat és real i funciona però és molt difícil d’implantar a les empreses reals (almenys per ara...)

Wednesday, November 09, 2005

Strategy: Enterprise Application Management and SOA

Conferència presentada per Martin Milani, de Intersperse. Tant l'empresa d'aquest bon senyor com l'empresa que ell presideix, van de la gestió de sistemes SOA que ja estan en producció.

En primer lloc definim el problema: Què ha canviat al món dels sistemes d'informació?

En canvi, el que no ha canviat són les necessitats de gestió dels sistemes d'informació:

  • Fault management
  • Configuration management
  • Accounting management
  • Performance management
  • Security management

La resposta: La gestió centrada en les aplicacions ("App-centric management"). Els sistemes i les eines de gestió de la xarxa antics estaven dissenyats per monitoritzar el sistema operatiu i els components de xarxa, no les aplicacions! En canvi, l'interès principal (el què més l'interessa a l'usuari, no necessàriament la font dels problemes) són les aplicacions!

Dins el raonament d'aquesta resposta, en destaco tres conceptes principals que es van exposar a la conferència:

  • Intrumentació de les aplicacions ("App. instrumentation"): Cal intrumentar les aplicacions per a monitoritzar el seu comportament en producció. Aquesta instrumentació ha de començar en la fase de disseny de les aplicacions, abans que s'iniciï el desenvolupament.
  • Empresa en temps real ("Real-time enterprise"): L'empresa avui dia necessita eines de gestió (desatesa) en temps real, no persones que monitoritzin contínuament els sistemes.
  • Enterprise Management Bus (EMB): Filosofia que defineix un "sistema nerviós" central de l'empresa per a la gestió dels sistemes. L'objectiu és centralitzar la informació de gestió (esdeveniments, alertes) i respondre de forma unificada a la seva gestió (sistemes que de forma desatesa prenen les accions correctores per a què les aplicacions puguin seguir funcionant correctament).

Best Practices: Securing XML: Case Studies from the Insurance Industry

Aquesta conferència va ser presentada per Tony Palmer, de l'empresa Vordel, una companyia dedicada a proporcionar serveis de seguretat per a sistemes XML i SOA, per tant amb coneixements sobre el tema. Entre els seus clients hi té Telefonica i la Seguretat Social.

Les assegurances han esdevingut ja una commodity. Avui dia no hi ha massa diferències entre el què ofereix una companyia i una altra. Per tant el benefici del sector es centra en el volum de contractació. Això significa que les asseguradores tenen un alt interès en proporcionar mecanismes que facilitin aquesta contractació. El mecanisme per exel·lència són els serveis SOA.

El sector de les assegurances és un clar exemple de necessitat de SOA, però podem saber quan hi ha necessitats d'aquest tipus de serveis mitjançant els següents Símptomes de SOA:
  • Leverage existing assets
  • Infrastructure is a commodity
  • Faster time to market
  • Reduce cost
  • Mitigate risk
  • Continuous business process improvement
  • Process-centric architecture

Altre cop parlant del sector de les assegurances, el sr. Palmer va remarcar la Naturalesa del serveis en aquest cas d'estudi:

  • Sensitivity, per la naturalesa del sector
  • Service levels, degut a què la naturalesa dels beneficis del negoci és en el volum. En aquest apartat, cal tenir en compte els aspectes de: Service degradation, Denial of service, Billing capability

Una altra de les coses que van aparèixer a la conferència va ser l'estratègia a l'hora de posar-se en el món SOA. Com passa sovint, les coses van diferent si vénen de dalt (quan una empresa decideix implantar SOAP/WSDL/UDDI de manera institucional) de quan vénen de baix (els desenvolupadors implanten serveis web per aprofitar les seves avantatges). Així, el sr. Palmer advocava per definir els Web Services com simplement un conjunt d'aplicacions utilitzant XML, fent així referència que l'important és la seva aplicació i utilització. Fins i tot es van introduir "nous conceptes" per a definir aquest darrer cas, com són la tecnologia POX ("Plain Old XML") i la programació JBOWS ("Just a Bunch of Web Services").

Finalment, la presentació va adreçar els principals reptes de la seguretat en el món dels serveis web: la complexitat, l'accés no autoritzat i les amenaces a nivell XML ("XML-level threats").

En quant a la complexitat, el consell és el de desplegar els mecanismes de seguretat com a part de la implantació de SOA, i no esperar a fer-ho al final. Els serveis de seguretat que cal tenir en compte són:

  • Signing Services (OASIS DSS)
  • Encryption Services
  • Security token generation and translation services (SAML, WS-Trust)
  • Centralized SMS access

En quant a les amenaces a nivell XML, es van destacar les següents:

  • SQL injection
  • XPath injection
  • Unexpected attachments
  • Malformed XML
  • XML Denial Of Service
  • Over-relianse on WSDL

Strategy: An Architectural Reference Model for the Enterprise Applications – A Case Study

El ponent d'aquesta sessió ha estat Mark Collins-Cope Technical Director de l'empresa ratio group.

Bàsicament s'ha exposat una arquitectura SOA que no té cap novetat ni és cap birgueria, bàsicament és un popurri de coses que tothom coneix. L'interessant ha estat l'enfoc pràctic de l'exposició ja que en cada aspecte de l'arquitectura ha posat casos de com portar-ho a terme.Aquesta arquitectura és utilitzada en projectes reals en l'empresa on l'home treballa i és fruït de l'evolució durant 20 anys de la seva carrera professional. Els objectius amb els quals s'ha concebut són els següents:

  • Factoring: significa reduir el número de línies a picar en nous projectes(és a dir reutilització de codi), també aconsella utilitzar refactoring per millorar i evolucionar el codi existent. L'avantatge d'això és la reducció de bugs en nous productes ja que aquests es desenvoluparan sobre mitjançant codi,llibreries, etc. ja testejades.
  • Intelligibility: significa organitzar el codi d'una manera racional i clara de cara tan a facilitar el manteniment i evolució del producte, com a reduïr el cost d’introduir gent nova.
    Separation: la clàssica separació de conceptes(UI, lògica i infraestructura). Els beneficis d'això ja són coneguts per tothom.
  • Stability: l'arquitectura defineix una sèrie de capes, l'objectiu és que les capes inferiors(més genèriques, reutilitzables) siguin el màxim d'estables possible per donar robustesa a cada nou producte.
  • Testability: implementar un projecte pensant des del principi en el test, utilitzar unit testing.


Un cop exposats els objectius l'home ha mostrat les capes de l'arquitectura i les regles que cal seguir per utilitzar-la amb resultats satisfactoris.


Capes

  • Interface: dins d'aquesta capa hi han d'anar tots els components que fan d'interfície del sistema cap a actors externs, ja siguin interfícies gràfiques com interfícies amb altres sistemes(Host, SAP, etc.)
  • Application: En aquesta capa és on hi ha els serveis que implementen la lògica de negoci.
  • Domain: capa que conté elements genèrics com per exemple un component de gestió de comptes, han de ser genèrics pq l'objectiu és reaprofitar aquests elements en altres projectes. De cara a adaptar cada component a cada nou projecte el ponent recomana definir outerfaces que siguin implementades a la capa d'aplicació.
  • Infraestructure: capa on es troben el components genèrics a nivell tecnològic com poden ser llibreries de persistència o classes d'accés a dades.
  • Platform: aquí és on entren els components externs com per exemple windows forms, jdbc, etc.

Regles:

  • les dependències sempre han de ser d'un component d'una capa superior a un component d'una capa inferior
  • sempre s'ha d'intentar moure els components a capes inferior ja que així probablement seran més genèrics i per tant reaprofitables en projectes posteriors
  • mai un component ha de contenir elements de més d'una capa

Segons el propi ponent la eina bàsica per portar a terme aquesta arquitectura és una pissarra on es dibuixen 5 línies horitzontals que defineixen les capes, allà es dibuixen els components a desenvolupar o reutilitzar i a saco a programar ;-)

En resum i com ja he dit l'arquitectura no planteja cap novetat, però ha estat interessant com s'ha exemplificat la seva aplicació

Tuesday, November 08, 2005

Strategy: How the ESB delivers on the value of SOA


Aquesta sessió ha estat a càrrec del senyor Dave Chappel de Sonic Software.

Si en algun dels missatges d'aquest bloc llegiu que les conferències són avorrides no en feu cas. Es veu que a banda de la passió pel software, la passió per l'arquitectura també existeix ;-) i provoca més estralls.

Després d'una introducció on ha explicat perquè les solucions basades en brokers EAI i servidors d'aplicacions no són prou bones i perquè els WS són bons, però no son més que una part de la solució per aconseguir una arquitectura amb totes les característiques que no repetiré jo un altre cop aquí, ha passat a presentar què es això de l'Enterprise Service Bus.
Per evitar-vos el ridicul de que us vegin algun dia intentant parar-ne un pel carrer, intentaré transmetre la seva definició:
Un ESB es una infrastructura software destinada a actuar com a eix d'una arquitectura SOA, capaç de mediar, controlar i connectar aplicacions i serveis en entorns altament distribuits i diversos.
Així doncs, Carles, pot ser un producte i ja s'ha encarregat el senyor Chappel de recordar-nos que Sonic en té un.

A banda de la independencia i acoblament feble ens ha insistit força en la facilitat de configuració i distribució dels serveis que dóna als encarregats del sistemes sobre tot si pensem a nivell de grans empreses d'àmbit supranacional - o potser hauria de dir "supraestatal" :-)

A continuació se li ha acudit posar un exemple de com és de fàcil d'escalar un servei com podria ser una transformació de dades amb XSLT amb una infrastructura tipus ESB en comparació a una infrastructura tipus EAI, el Biztalk sense anar més lluny. I, a efectes pràctics, aquí s'ha acabat la conferència, almenys tal com la devia tenir prevista el ponent.

Resulta que hi havia 2 senyors de Microsoft. El primer, després de sentir l'exemple no s'ha pogut estar d'intervenir per dir que les afirmacions del ponent no eren certes. De la discussió posterior s'extreu que BT si que suporta l'escenari (tot i que suposo que implicaria un cluster, més llicències de BT i no sé si alguna sé si alguna més). Quan ja semblava que es posaven més o menys d'acord, el segon ha intervingut per dir que l'exemple era poc realista i que les transformacions XSLT formen part del propi Windows i que el framework de .NET ja les porta, que no cal complicar-se la tant, vaja. Al final el ponent ha optat per seguir la exposició (amb una altra cara, per cert)

El que ha vingut després ha estat una explicació dels detalls de com és un ESB i com suporta escenaris de workflow molt fàcilment i només tocant la configuració.

En resum, detalls de safareig a part, la sessió ha estat d'un nivell molt respectable i el ponent semblava tenir bastant per la mà el tema inclús a nivell d'implementació. Llàstima que fos la darrera del dia perquè a aquelles hores el cap començava a dir prou.

Strategy: The Mobile Enterprise Challenge

Aquesta sessió ha estat presentada pel senyor Mika Litinen de Nokia.

Aquesta sessió no estava prevista. Es veu que ha sortit de la banqueta sense escalfar per substituir la sessió titular i, per dir-ho educadament, no ha triumfat.
De la sessió he pogut treure 4 coses:
1) Nokia dóna serveis de mobilitat a les empreses que van des dels terminals (ara treuren 3 nous models molt macos destinats a l'empresa plens de característiques) fins a la consultoria, passant per les aplicacions i els connectors amb sistemes de correu i tot el que faci falta.
2) Nokia creu que el mercat està(rà) en la mobilització d'aplicacions, la convergència entre dades i veu mòbil i la convergéncia entre telefonia fixa i telefonia mòbil.
3) Venen el Nokia Bussines Center com a "push e-mail solution" que es el que es porta ara vista l'actitud de les operadores al respecte.
4) El Nokia Bussines Center es capaç de còrrer (poc suposo) sobre un servidor amb Linux Red Hat amb 1 KByte de memòria!!.

Evidentment la 4) ha estat un lapsus molt comprensible i totalment disculpable del conferenciant, però ha estat la única cosa divertida de la sessió i volia dir-ne alguna cosa positiva :-)

Strategy: Modeling Messaging Aspects of Connected Systems


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

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

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

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

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

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

Keynote: Changing the Rules of Systems Architecture

Arvindra Sehmi, de Microsoft ha proposat en aquesta ponència una redefinició del procés de creació de Sistemes.

Part 1: Introducció

El principal objectiu del seu parlament ha estat fer decréixer els costos de manteniment, que segons els seus càlculs pugen fins al 70% del temps de desenvolupament, per poder dedicar el temps a altres aspectes que pugin donar un valor afegit al nostre treball.

De fet, el paradigma ideal contemplaria baixar aquests costos tot i que la complexitat pugés. Més encara, si aconseguim fer decréixer aquests costos inherents a qualsevol procés de creació de Sistemes, podrem reduir els seus costos globals i, fins i tot, la seva complexitat. Tot això respectant els principis bàsics que tota arquitectura de Sistemes ha de tenir en consideració: Transparència, Consistència, Predictibilitat, Disponibilitat, Seguretat i Suportabilitat.

Un altre punt crític que va destacar a l’hora de desenvolupar un Sistema és aconseguir una bona interacció amb el seu entorn:
  • Amb el repositori de Dades: Continuïtat, Tractament de contingències, Recuperació de dades, etc.
  • Amb l’entorn de l’Organització: Cohesió amb els processos operacionals
  • Amb l’entorn de Control:
    o Instrumentació i Monitorització (Què està passant?)
    o TroubleShooting i Root Causes (Com solucionar-ho?)
  • Entorn de Previsió: Establir estratègies planificades de modificacions de l’arquitectura.


Retornant als objectius desitjables, Arvindra Sehmi donava molta importància a incrementar el número d’hores dedicades al disseny en lloc de passar-les per alt per després dedicar molt més temps en el desenvolupament de les solucions i el seu manteniment.

També hi va destacar tres rols i va destacar la importància de la seva intercomunicació:
- Desenvolupador d’Aplicacions: Qui desenvolupa l’arquitectura.
- Professional de les Tecnologies d’informació Qui fixa els punts fonamentals i les limitacions.
- Usuari format: Usuari que té uns coneixements prou sòlids com per poder retroalimentar els altres dos rols.


Part 2: Alternativa de Microsoft


Un cop arribats a aquest punt, la conferència es va centrar en l’exposició de la alternativa que Microsoft té per liderar aquesta revolució tecnològica garantint els requeriments anteriorment citats. Una revolució que tindrà lloc en els següents 2-3-4 anys i que té un cicle de vida estimat de 15-20 anys de vida útil.

El concepte que es va desenvolupar va ser el de DSI (Dynamic Systems Initiative) que consta de tres eixos principals: Coneixement, Model i Cicle de Vida.


Què necessita DSI?
- Una manera genèrica de modelar el coneixement.
- Una manera genèrica de comunicació amb el Sistema.


Aquestes necessitats es satisfan mitjançant un nou model anomenat SDM (System Definition Model) que formarà part del nou Visual Studio 2005 que permetrà garantir:
- Control d’Activitat, mitjançant Microsoft Operation Manager.
- Configuració i canvi, mitjançant Microsoft Systems Management Server.
- Simulació i Planificació, mitjançant Microsoft System Center Capacity Manager.

Un dels principals objectius que te SDM és cercar una manera de reutilitzar processos simplificant així tot el procés de creació/modificació/manteniment d’Arquitectura de Sistemes.

Tot i així, des de Microsoft volen tocar de peus a terra establint dos conceptes contraposats: L’Oughtness, o com les coses haurien de ser i l’Isness, o com aquestes mateixes coses acaben sent. SDM vol reduir l’espai entre aquests dos conceptes, essent el paradigma utòpic de DSI el de l’existència de sistemes auto-dirigits i auto-mantinguts. Aquest paradigma utòpic rep el nom al·legòric de Nirvana.


Finalment, ens van fer cinc cèntims de la fulla de Ruta que Microsoft té per als següents anys:
2005: Windows Server 2005 R2.
2006: Computer Cluster Solution i WinFx
2007: Longhorn Server

Part 3: Demo

Una demostració, feta per Beat Schwegler Sbilordo de Microsoft, mitjançant Visual Studio 2005 de les diferents capacitats que el sistema DSI pot oferir, com creació i reutilització de Sistemes, establiment de llindars entre el Front-End i el Back-End d’un Sistema i les diferents formes d’interrelació dels mateixos.

Best Practices: Stories from the Field: Adoption of SOA and Web Services

La conferencia va consistir en exposar les aventatges de SOA a molt alt nivell.
No va aportar res més enllà dels conceptes més bàsics de SOA.
Resumeixo el contingut de l'exposició:

Fonaments de SOA
---------------------------
- Exposició del Patró de disseny "Bus de serveis". El model es el de components que ofereixen Serveis exposant-los en un "Bus de Serveis" i muntar les Aplicacions com a consumidors d'aquests serveis.
- El Bus de Serveis es la infraestructura dels Web Services: Standards, SOA, WSDL, UDDI

Disseny SOA
----------------
Diseny centrat en serveis més que en aplicacions
Serveis desacoplats

Beneficis de SOA
----------------------
La compartició de serveis comuns redueix errors i redundancia i augmenta la reutilització.
Facilita les capacitats d'auditar i fer logs d'activitats.
Reforça l'aplicació de polítiques corporatives.
Un cop tenim els serveis permet desenvolupar noves aplicacions en menys temps.
Facilita la col.laboració amb Partners. Integració de Sistemes.

Tecnologies actualment disponibles:
---------------------------------------------
WSSecurity
WSDL
UDDI
WSRP
XPath, XSLT, XML Schema

Tecnologies encara no disponibles:
--------------------------------------------
WSManagement
WSBEPL (Orchestration)
WSReliability
WSTransaction, WSCoordination
WSPolicy

Situació actual
-------------------
S'estan utilitzant Serveis en la seva expresió més sencilla
Serveis punt a punt i sense gestió.

Evolució prevista
----------------------
Segons el ponent disposarem de "Secure, Reliable Transacted SOA" al 2008
(Ens ho creiem? S'admeten opinions i apostes)

Un comentari
-----------------
Una frase que em va agradar del ponent va ser "Els serveis haurien de tenir la mateixa consideració que les dades". Per tant hauriem de començar a tenir "Administradors de serveis" tal com tenim "Administradors de bases de dades".

Monday, November 07, 2005

Best Practices: .NET/J2EE interoperability

Laurence Moroney de Mainsoft, ha sigut l'encarregat de comentar alguns aspectes de com integrar J2EE i .NET... que s'ha acavat convertint en una demostració del producte de Mainsoft que ells anomenen Unified Platform.
Inicialment ens ha enumerat les diferents possibilitats d'integració .NET/J2EE:
  1. Web Services: Efectivament funciona, però afegeixen overhead, augmenten la complexitat de mantenir els diferents servidors implicats i també converteixen l'interoperabilitat en un paradigma de request/response força lent... a més a més si s'involucren tipus de dades complexos la cosa es complica: ja sabem com va això dels estàndards en informàtica ;)
  2. EAI: Utilitzar un EAI és una opció. Augmenta la complexitat de mantenir els servidors, ja que a més dels servidors J2EE i .NET hem de mantenir i configurar el EAI
  3. Missatgeria: Vé a ser el mateix que el punt anterior.
Arribat en aquest punt a on sembla que no hi ha cap solució que permeti interoperar J2EE i .NET de forma fàcil, és quan ens ha presentat el Unified Platform de Mainsoft.
La idea és unificar .NET i J2EE en una sola plataforma (J2EE) de forma transparent, i que la gent de .NET pugui seguit utilitzant els seus coneixements, habilitats i productes (VS.NET).
El producte de Mainsoft, bàsicament, és un compilador de MSIL a bytecode: Agafa codi MSIL de .NET i el compila a bytecode per a ser executat en una JVM. D'aquesta manera qualsevol aplicació .NET pot executar-se com si fos una aplicació java.
La idea de Mainsoft és doncs aquesta: Permetre l'execució d'aplicacions .NET sota servidors J2EE. L'aplicació .NET és compilada a bytecode, es genera una aplicació 100% J2EE que és la que s'executa (sota un websphere, un weblogic o un jboss). A més a més el procés està 100% integrat amb VS.NET (no cal explicitament realitzar cap acció extra per tal de convertir el codi MSIL a bytecode) i permet fins i tot depurar amb VS.NET! O sigui que la gent que programa en .NET no ha de canviar cap dels seus costums.
Ok, d'acord, algú pot objectar que no n'hi ha prou convertint el codi MSIL a bytecode: tot i que el rol que juguen MSIL i bytecode a cada plataforma és el mateix, el framework de classes que hi ha per sota no te res a veure en .NET i en J2EE. Resumint: ens cal tenir un .NET Framework "convertit" a J2EE o un .NET Framework natiu en la plataforma escollida... Segons m'ha semblat entendre Mainsoft ha escollit la primera opció: utilitzant el seu propi compilador de MSIL a bytecode, han compilat les llibreries de classes de Mono a J2EE, i aquestes llibreries convertides son les que s'inclouen en el seu producte (de fet Mainsoft és un dels principals patrocinadors del projecte Mono i participa activament en el seu desenvolupament). Convertint Mono a J2EE s'asseguren que poden donar suport a qualsevol plataforma (igual que J2EE).
Aspectes claus de l'eina:
  • 100% integrada amb VS.NET: Es pot depurar amb VS.NET la part .NET de l'aplicació que s'està executant sota un contenidor J2EE.
  • Permet l'ús directe de classes java i/o EJBs desde VS.NET: Apareixen dues opcions extres a VS.NET (add java reference i add EJB reference) que automàticament generen els proxies en .NET per a invocar directament una classe Java.
  • Permet la creació de EJBs en .NET, a través d'Enterprise Services, però és una opció que tot i que és possible no la recomanen.
  • No suporta, de moment, aplicacions winforms (winforms no estan suportats actualment en Mono).
  • Suport per a .NET 2.0 es preveu en mig any (m'ha semblat entendre).
Més info sobre l'eina es pot trobar a http://www.mainsoft.com/solutions/whitepapers/vmw4j2ee_tech_wp.pdf

Resumint: La presentació era totalment comercial, però no es pot negar que l'eina sembla a priori força potent...

Workshop: Developing and Enforcing Security Policies

La presentació ha sigut a càrrec de l'empresa Parasoft, i ha constat de tres parts: una introducció, una segona part més tècnica i una demo final.
Part 1: Introducció
En la introducció, se'ns ha comentat que la seguretat en les aplicacions és clau: segons Gartner un 75% dels atacs de hackers a sistemes son existosos gràcies a forats en les aplicacions. De res serveixen inverisons millonaries en SO segurs, firewalls i configuracions de servidors si després les aplicacions tenen forats de seguretat. Per tant, la seguretat no s'ha de comprobar a posteriori, si no que ja s'ha de tenir present des de temps de disseny. També es va destacar que el cost de comprobar la seguretat és molt costós i que per a que sigui factible les proves s'han d'automatitzar.
Part 2: Conferencia en sí
La segona part de la conferència, va durar unes dues hores i escaix i es van fer un repàs de les principals causes d'error en aplicacions (sobretot aplicacions web, ja que aquestes son, per raons òbvies, les més fàcilment atacables). Així la llista dels 10 errors de seguretat més comuns seria:
  1. Entrades d'usuari no validades. Clau perquè permet XSS, injecció i buffer overflow
  2. Autorització mal implementada
  3. Autenticació trencada (cookies manipulades,...)
  4. XSS
  5. Buffer overflows (especialment en CGIs fets en C/C++ o Perl).
  6. Injecció
  7. Excepcions tractades erroneament
  8. Criptografia massa dèbil.
  9. Atacs DoS
  10. Servidors mal configurats

A destacar que les 8 primeres raons son bàsicament de desenvolupament. DoS ocupa la novena plaça i és un tema molt complicat de defensar-se contra ella, i finalment servidors mal configurats tot just és la 10a causa d'errors de seguretat. Conclusió: Sistemes pot ser culpable d'un error de seguretat, però desenvolupadors tenen segurament més part de culpa.

També va mencionar altres tipus d'errors inherents a Web Services (generalment manipulacions malèvoles dels missatges SOAP, o WSDL "massa" explícit), però no es va donar cap exemple concret en aquest punt.

Finalment va fer un resum de quines àrees havia de cobrir tota política de seguretat d'un desenvolupament, però sense entrar en detall.

Part 3: Demos

Un parell de demos de les aplicacions de Parasoft, per poder veure com ajuden a automatitzar el testing de seguretat. Per una banda JTest, que bàsicament realitza anàlisis estàtics sobre el codi font per buscar "bad practices" a nivell de seguretat i presenta un report. L'eina és Java i s'integra al 100% amb eclipse. Sembla que tenen una eina per a C/C++ que fa el mateix, però no he trovat cap eina equivalent per a .NET.

La segona eina era WebKing que buscava errors de seguretat en una aplicació web: a partir de la gravació d'una navegació per un site web, es generaven un conjunt de test-cases i l'eina buscava els clàssics errors: SQL injection, broken session, unvalidated user input, ... A la demo no va quedar gens clar com configurar l'eina per a que detecti els diversos tipus d'errors (no sembla fàcil).

Conclusions: La segona part de la conferencia va ser força interessant, però vaig trovar a faltar una mica de profunditat tècnica. En general tota la presentació va ser un pel massa comercial pel meu gust (la part final de les demostracions no aclarava res, més enllà de que ells ofereixen eines per a automatitzar tests de seguretat).

Sunday, November 06, 2005

Workshop: Principles and Tools for SOA Governance

El rol de l'arquitecte:

  • L'arqutecte és el rol que uneix [Desenvolupament] --- Arq --- [Negoci]

SDA (Software Development Asset)

  • És software, models, codi, etc. + metadades associades: atributs, versions, etc.
  • Distribució dels SDAs:
    [Application specificic Layer] 85%-100% ==> No adequat per reutilitzar
    [Domain dependant (negoci)] 20%-85% ==> Actius de gran valor
    [Domain independant layer (login per exemple)] 0%-20% ==> Actius de poc valor (implementats ja en .NET Enterprise Solution Patterns).

SOA (Service Oriented Architecture):

  • SOA utilitza SDAs
  • Granularitat de SOA?
    No ha de ser massa global (app layer). Exemple: Fer_Tancament_Anual.
    No ha de ser massa granular (domain layer). Exemple: crides a RPC.
    Per tant:
    El valor de SOA està al domain dependant.
    Per tant SOA no significa que haguem d'implementar totes les funcions orientades a servei.
  • SOA no és exclusivament Web Services, pot haver-hi altres tecnologies (per exemple message based).
  • Per especificar SOA utilitzarem, preferentement: Diagrames de classe, Casos d'ús, Diagrames d'activitat.
    Per gestionar SOA crearem models:
    Performance Reference Model.
    Service Components RM.
    Biz RM
    Data Access RM
    Technological RM
  • El model inclourà una base de dades de SDA (SDA metadata library), que permeti:
    Guardar les definicions d'SDA i les metadades associades:
    Artifacts: work products, code, schemas, models, executables, etc.
    Classifiers: keywords, development efford, owner, language, etc.
    Relationships to other assets: Dependencies, prerrequisites, other assets versions
    Cercar-les
    Gestionar polítiques d'ús

Best practice 1: Sigueu pragmàtics quan definiu models/defincions de serveis

  • Orientació bottom-up (des dels serveis més bàsics): masa específic, acabaríem creant massa serveis específics que serien codi spaguetti
  • Orientació up-down (tot definit abans de fer res): caurem en la paràlisi per anàlisi
  • Cal seguir un model en espiral on:
    Top-down: ens ajuda a prioritzar el que és més important pel negoci
    Bottom-up: ho subtituirem en la mesura que poguem per Software Patterns ja existents.
  • Es recomana crear un equip d'arquitectes d'SDA en matriu a l'empresa:
    Cada equip té un responsable d'SDA
    Les seves responsabilitats són: identificar candidats, revisar proposats, publicar aprovats i recomanar futurs.

Best practice 2: Reviseu els serveis al llarg del clicle de construcció

  • Cal crear "checkpoints" per alinar espectitatives entre els diferents actors implicats.
  • Compte amb crear un procés poc complert (insuficient) o massa burocràtic (lent, impràctic o senzillament no se segueix). Equilibri a "just enough process".

Best practice 3: Gestioneu els serveis com si fossin productes

  • Cal crear un release cycle ben definit
  • S'ha de fer releases backward compatible
  • Cal fer una presa de requeriments amb els clients actuals i potencials + Defect tracking
  • Ha d'existir un rol de product manager, que alínia: [Developers] --- Product Manager --- [Biz]
  • Cal fer versionatge
  • Cal orientar-ho a gestió d'SDA (en desenvolupament, production, retired, obsolete).
  • Recomanació: Branch as long as you can (http://www.perforce.com/perforce/bestpractices.html)

Best practice 4: Distribuïu mitjançant una gestió d'actius en una base de dades

  • Cal utilitzar una eina ja que:
  • Les spreadsheets i webs estàtiques queden obsoletes
  • "Call the architect" crea un coll d'ampolla
  • UDDI no és adequat per als desenvolupadors

Best practice 5: Traceu qui utilitza els components

  • A nivell de projecte i rol dins el projecte.

Eines recomanades:

  • Rational Architect (?) i Java Session Bean Modeler (?) per les especificacions
  • Logidex per gestionar els SDAs.
  • Tot i que crec que no ho he reflexat, la presentació va tenir un petit to comercial.

Ha començat l'EAS 2005

Avui ha començat l'Enterprise Architect Summit 2005, que en aquesta edició es celebra a Barcelona. Enguany hi desembarquem els companys de Raona, i intentarem en aquest blog anar-hi resumint què s'hi dóna.

Avui com a primer dia de l'EAS, la cosa comença suau. Hi ha dos workshops previstos, "Developing and Enforcing Security Policies" i "Principles and Tools for SOA Governance". Veurem què s'hi explica, ho podreu llegir aquí.

Estigueu al lloro!