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ó?

• Increased risk (cada vegada depenem més de les TIC)
• Increased complexity (en això també va estar d'acord el senyor de la conferència Securing XML: Case Studies form the Insurance Industry)

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

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).

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!