Suplemento técnico del número 146 de NEWS/400
66 Agosto/Septiembre 2004
Llegan las aplicaciones distribuidas Desde la centralización del mainframe a la descentralización del ordenador personal hemos ido adaptándonos a los diferentes modelos informáticos de cada tecnología. Ahora con Internet y el e-business nos llegan las aplicaciones distribuidas y los Servicios Web. En el fondo, si queremos mantener al día nuestro nivel como profesionales, sólo se trata de un tema de formación permanente. Por Carlos Bell
E
l pasado 7 de abril, se celebró el 40 aniversario del mainframe: ese mismo día, en 1964, IBM anunció el lanzamiento del sistema S/360, una familia de ordenadores empresariales en la que había invertido más de 750 millones de dólares en ingeniería y 4.500 millones en equipamiento y fábricas. El éxito del sistema fue tal que, según comentó Álvaro Álvarez Santullano, máximo responsable de ventas de la división eServer zSeries de IBM para España y Portugal, “la compañía tuvo que contratar de inmediato a miles de trabajadores para producirlo y, en España, los clientes que lo adquirieron tuvieron que esperar hasta dos años para conseguir uno”. El S/360 de IBM fue el inicio de una serie de generaciones de procesadores que a lo largo de estos 40 años han marcado el punto más alto de la tecnología y capacidad de proceso de todos los sistemas de información empresarial. Aun hoy, los servidores eServer zSeries que existen en la actualidad, los z900, z800, z990 y z890, comparten lo último en tecnología y soportan la mayoría de los procesos informáticos que en todo el mundo se ejecutan en los centros de Proceso de Datos de las grandes corporaciones. Antes de continuar con el propósito de este artículo, comentemos brevemente la evolución de los distintos modelos informáticos adoptados en las empresas según la influencia del momento tecnológico que se estaba viviendo.
Centralización y descentralización
SUMARIO
En la década de los 60, mucho antes de que aparecieran los ordenadores personales, los mainframe regían el mundo de Proceso de Datos. La funcionalidad de las terminales que proporcionaban la interfaz de usuario era muy limitada y estaban basadas únicamente en protocolos de presentación tales como el 3270 o 5250 que determinaban cómo deberían mostrarse los caracteres en pantalla. Toda innovación se realizaba en el mainframe y algunas de estas innovaciones, en especial los procesos transaccionales y el desarrollo de lenguajes de programación de alto nivel, han beneficiado a la industria de manera significativa en la medida en que ésta ha avanzado. En las grandes corporaciones, los primeros “rebeldes” que consiguieron evadirse del férreo control del departamento de Proceso de Datos fueron los minis, desde
nes distribuidas
NÚMERO 66
HELP400 Suplemento Técnico 1
1 Llegan las aplicacio●
●6 .NET, una alternativa a J2EE
el S/3 de IBM o la saga de los S/3X, precursores del AS/400 y del actual eServer i5, pasando, entre otros, por los miniordenadores de Digital o HP y cuya proliferación, al ser adoptados mayoritariamente por las pymes como sistemas informáticos completos, marcó la década de los 70. En los 80 e inicios de los 90, el advenimiento del ordenador personal con su capacidad de ejecutar aplicaciones locales invirtió definitivamente el modelo tradicional. Gran parte de la innovación pasó del mainframe al PC cliente. El PC, principalmente bajo los sistemas operativos MS-DOS y Windows, se convirtió en un punto neurálgico para la industria del software, habilitando el desarrollo de valiosas aplicaciones del lado del cliente. En esta época se hablaba de un modelo cliente/servidor descentralizado, donde los minis y los mainframes en su función de servidores apenas actuaban como algo más que proveedores inteligentes para administrar y proporcionar archivos a las aplicaciones del cliente que los solicitara.
¿Se trata de un círculo vicioso? Una vez más, a partir de la segunda mitad de los 90, con la llegada de Internet, World Wide Web y el navegador o explorador Web la situación cambió, y nuevamente la balanza se inclinó hacia un modelo informático más centralizado. Internet revolucionó la forma en que los usuarios interactuaban con las aplicaciones y extendió de manera significativa el alcance del ordenador personal. Hace algo más de diez años, el número de aplicaciones que uno tenía a su disposición era más bien reducido. Ahora, con el navegador se puede escribir una URL y tener acceso a las aplicaciones y a la información en cualquier parte del mundo. Sin embargo, debido básicamente a las limitaciones del protocolo de presentación HTML, este modelo de Internet de primera generación no permite adaptar la información que reSuplemento Técnico de NEWS/400 cibe el cliente o realizar algún proceso local importante o inteliDirector General gente. Para el usuario, en general, Internet es muy parecido al Alberto C. Blanch Llangostera mundo de la televisión, donde el navegador proporciona una via.blanch@help400.com Director sión de la información disponible pero limita notablemente la caAntonio Montía pacidad de manipular, comentar o agregar valor a la información a.montia@help400.com recuperada. Coordinación Carlos Bell El modelo actual de interacción hombre-máquina se encuentra Jaime Gustavo Estany claramente limitado. Existe un mundo en el que se busca información y otro en el que se procesa la información que se recibe. Maquetación y Producción Complay, S.L. Como ejemplo inmediato, si trabajas con un PC, dale un vistazo a complay@retemail.es la barra de tareas en la parte inferior de tu pantalla. ProbableImpresión mente tengas, en un momento determinado, un par de ventanas Policrom, S.A. del navegador abiertas y un par o tres de otras aplicaciones en EDITA donde en realidad estás trabajando. Publicaciones HELP400, S.L. APTDO. DE CORREOS 8003 - 08080 Barcelona El navegador en sí es poco más que una versión gráfica de la Gran Vía C. Catalanes, 715, Entlo. 3ª pantalla 5250 y como tal ofrece poco para el proceso inteligente en 08013 - Barcelona el cliente. El poder de proceso se encuentra en el servidor que geTel. :93.231.00.49 Fax :93.231.03.09 E-mail: suplemento@help400.com nera una imagen basada en HTML de su información de salida. Web: http://www.help400.com Cada vez que se quiere hacer algo, nos vemos forzados a enviar Deposito legal: B-2757-90 I.S.S.N. 1133-8067 una nueva solicitud al servidor, pidiéndole realizar un procediSuscripción: Anual (10 números al año). España: 96 €. miento adicional. Con este modelo, en un mundo de dispositivos Se distribuye conjuntamente con el ejemplar de NEWS/ avanzados y poco costosos del lado del cliente, se están desperdi400, sin cargo para sus suscriptores. © Publicaciones HELP400, S.L. Se prohibe la reciado sus capacidades. producción total o parcial del contenido sin autorización previa y por escrito de la empresa editora, titular del Copyright. Todos los derechos reservados en cualquier idioma. De las ideas expuestas en los artículos firmados son responsables sus autores. Corresponde al lector el asegurar que las noticias, técnicas y procedimientos descritos son adecuados para su instalación. Publicaciones HELP400 S.L. no asume ninguna garantía ni implícita ni explicitamente. IBM y AS/400 son marcas registradas por International Business Machines.
2
HELP400 Suplemento Técnico
Interacción limitada Desde luego, el actual modelo centralizado basado en un navegador es interactivo, pero sólo aparentemente. Es muy difícil que Internet haga cosas automáticamente en beneficio del usuario. Por ejemplo, es muy fácil acceder a cualquier sitio Web, pero cuando se
requiere que los sitios Web interactuen entre sí para dar un servicio compuesto, es necesario añadir un costoso desarrollo a medida. En la actualidad, existen decenas de millones de sitios Web, pero todos son como islas y lograr que estos sitios interactuen y trabajen unos con otros es muy difícil. Hoy, uno de los dilemas con que se enfrentan los desarrolladores de aplicaciones para un servidor, es la necesidad de proporcionar soluciones que satisfagan a un amplio abanico de dispositivos cliente, con distintos formatos y resoluciones variables de pantalla. Además, la información presentada necesita personalizarse y, con frecuencia, combinarse desde múltiples fuentes de datos almacenados en diferentes servidores. Evidentemente, un modelo orientado a la terminal para el cliente o un modelo de compartición de archivos puro para el servidor, resulta insuficiente. La solución más adecuada requiere que se extraiga e intercambie información valiosa en ambas direcciones. El continuo incremento en capacidad de proceso de los servidores y clientes, así como el incremento y la disponibilidad de ancho de banda en un mercado liberalizado de telecomunicaciones, propicia un nuevo modelo informático, un modelo cuya arquitectura sea realmente “distribuida”. Utilizar Internet para distribuir poder de proceso donde tenga más sentido, junto con la gama de nuevos dispositivos inteligentes, permite crear aplicaciones más ambiciosas e interactivas y ofrece nuevas oportunidades de arquitecturas que se alejan y diferencian del clásico modelo cliente/servidor anterior.
usiness llega a la empresa El e-b e-business Las nuevas herramientas y estándares de desarrollo junto a nuevos modelos para construir la siguiente generación de aplicaciones basadas en Internet han permitido que la industria del software evolucione más allá de esta repetitiva estrategia de centralización/descentralización. De la mano de IBM nació un nuevo término: el e-business; un nuevo concepto y enfoque cuyo significado más simple y FIGURA 1 sencillo es el de utilizar (en la medida de lo posible) tecnologías de Internet para Las intranets corporativas y su mejorar y transformar los procesos clave de la empresa. propia presencia en Internet, Ultimamente, el término e-business está siendo aplicado de manera tan am- convergen en el e-bisiness plia que el rigor terminológico aconseja perfilar su contenido y contextualizar su empleo. No se Global Organization Electronic Market trata sólo de comercio electrónico and Integration Space (ventas online vía Internet) que es ▲ ▲ una parte del e-business, pero no ▲ ▲ su sinónimo. A nivel conceptual, Extranet (Convergence aparte del comercio electrónico, Connection) partiendo de la propia intranet de ▲ ▲ la empresa y de su presencia en Internet (Figura 1) el e-business aprovecha las nuevas tecnologías Customer WorkGroup Services para abarcar otros aspectos emCollaboration presariales como puedan ser el ▲ ▲ marketing y la publicidad, la gestión de la cadena de suministros, Broadcast Information las relaciones con el cliente, y la Medium Management gestión del conocimiento dentro de ▲ ▲ la empresa. Las experiencias ebusiness más completas se oriene-Mail & e-Mail & tan no sólo a los diferentes tipos WWW Browsing Data Posting de procesos enunciados sino también a su integración en una plataIntranets Internet forma compartida. En un esquema NÚMERO 66
HELP400 Suplemento Técnico 3
El modelo de Servicios Web que desde hace un cierto tiempo nos proponen los grandes actores de la industria informática, posibilita tal enfoque
general e-business integra de modo coherente, como un rompecabezas resuelto, diferentes componentes que representan la gestión de la cadena de valor ampliada de la empresa: SCM (Supply Chain Management), gestión de la cadena de suministros; ERP (Enterprise Resource Planning), planificación de los recursos de la empresa, orientado a la operativa interna; CRM (Customer Relationship Management), gestión de la relación con los consumidores; eCommerce, gestión comercial; BI (Business Intelligence), inteligencia corporativa, orientado a la mejora de los procesos de toma de decisiones. En pocos años el e-business ha evolucionado de un mero concepto intangible a una realidad innegable, y por una buena razón: tiene ventajas tanto para los consumidores como para las empresas. No solamente por sus valores primarios, es decir la disminución de costes, el crecimiento del beneficio, y el grado de satisfacción del cliente, sino también por la posibilidad de integrar otras tecnologías como telefonía celular, PDAs, etc., etc. La clave, como siempre, consiste en encontrar los medios para brindarle a un cliente cada vez más exigente lo que éste requiere, sin los gastos de las operaciones tradicionales. En definitiva: mayor rentabilidad a menor costo. ¿Demasiado bonito para ser verdad? Tal vez. En el libro “Alianza coopetitiva para la nueva economía” (Ed. McGraw-Hill, ISBN: 8448127986) su autor, Jon Imanol Azúa, nos dice: “La llamada Nueva Economía supone una permanente revolución en el mundo de las organizaciones. Un nuevo contexto en el que la Competitividad, entendida como resultado final de hacer mejor las cosas que los demás de una forma permanente, se explica en función de nuevas redes y/o alianzas coopetitivas (inmersas en el dificil equilibrio entre la competencia y la cooperación) a través de complejas interacciones entre empresas, gobiernos, industrias y nuevos espacios activos conocidos como Regiones Innovadoras.”...
¿Mito o realidad? El modelo de Servicios Web que desde hace un cierto tiempo nos proponen los grandes actores de la industria informática, posibilita tal enfoque. Los Servicios Web son componentes de software o “islas de funcionalidad” programáticamente accesibles desde la intranet o desde Internet que, utilizando protocolos abiertos, incluyendo el HTTP y XML para el transporte y representación de información variada y flexible, permiten crear aplicaciones distribuidas centradas en el usuario. Ya que la interacción entre un Servicio Web y su cliente se encuentra gobernada por estándares abiertos, cualquier dispositivo o plataforma que los soporte puede albergar o consumir estos servicios. El modelo de programación de Servicios Web es completamente independiente de la plataforma y se adapta de manera ideal a la naturaleza heterogénea de Internet. Teóricamente, utilizando los Servicios Web las posibilidades son ilimitadas. Los servidores que necesiten interactuar con otros servidores pueden hacerlo, los servidores pueden interactuar con los clientes y los clientes pueden interactuar entre sí. Por ejemplo, si te diriges a una sala de juntas y llevas en la mano un PDA y hay otras personas en la sala con dispositivos similares, deberías ser capaz de recuperar, proporcionar e intercambiar información con ellos. A este respecto, la solución requiere elementos de cliente-a-cliente, cliente-a-servidor y servidor-aservidor, construidos alrededor de un estándar único y utilizando las características y la inteligencia con la que estén dotados estos dispositivos.
2005: Comienza el espectáculo No sólo el número 5 va a ser uno de los grande protagonistas del próximo año (el procesador Power5, los IBM eServers i5 y p5 y el sistema operativo i5/OS, el Apple iMac G5, o incluso la celebración del 15º aniversario de nuestra revista) sino que también lo serán las dos grandes plataformas para el desarrollo e integración de aplicaciones “e-business”, es decir, J2EE definida por Sun Microsystems 4
HELP400 Suplemento Técnico
y .NET Framework, de Microsoft, de las que se tratará con mayor detalle en el siguiente artículo. La cuestión es saber si nosotros, como profesionales del entorno AS/400, también seremos protagonistas de este nuevo modelo informático de arquitectura distribuida o sólo meros espectadores. Citando a Phil Coulthard y George Farr, los evangelistas Java del laboratorio de IBM en Toronto (primer artículo de “El trayecto de RPG a J2EE”, publicado en el número 140 de NEWS/400): “Hoy en día, muchos departamentos de informática tienen varios equipos trabajando en distintas plataformas y tecnologías. Por ejemplo, además del equipo de desarrollo del iSeries suele haber otro equipo que se encarga de la presencia de la empresa en la web. La presencia en la web generalmente empieza como sencillas páginas estáticas creadas con tecnologías de Microsoft, Oracle o Sun por personal contratado con ese propósito, o subcontratado para ese proyecto. Inevitablemente, el sitio web evolucionará hasta precisar acceder a la lógica y a los datos del iSeries, iniciándose entonces una disputa por el territorio. El equipo de desarrollo de la web afirma que ellos pueden migrar sin dificultad a Windows o Solaris ese viejo código escrito en RPG y hacerse cargo de la gestión interna. Por otro lado, el equipo de desarrollo del iSeries sabe que se trata de una grave simplificación y un caso claro de optimismo extremo debido a la juventud de los promotores de la idea. Además, han oído que las posibilidades del iSeries son muchas más de las que están utilizando, incluyendo una excelente compatibilidad con aplicaciones escritas en Java y para la web. Se preguntan si no podría darse el caso contrario: ¿el iSeries podría hacerse cargo del trabajo que se realiza actualmente para la web en esas otras plataformas y con esas otras tecnologías?” Un poco más adelante añaden: “Hay otras razones, y puede que más poderosas, para que los programadores en RPG y Cobol hagan el esfuerzo de comprender las posibilidades de trabajar en la web que tiene su máquina favorita. Una razón es que hoy en día, la interfaz de usuario preferida para casi todas las aplicaciones (incluyendo las de uso interno) es un navegador web. Algunas aplicaciones aún se prestan a funcionar mejor mediante una interfaz de pantalla verde y algunas se adaptan mejor a un estilo de aplicación cliente/servidor. Sin embargo, la gran mayoría de aplicaciones se adaptan perfectamente a un navegador web, que es más persuasivo y moderno que una interfaz 5250 aunque tiene las mismas ventajas de una distribución sencilla. En el caso de aplicaciones que utilizan una interfaz de usuario gráfica cliente/ servidor, una nueva aplicación web necesita disponer de la misma lógica discreta de la empresa que la del iSeries. A menudo, esta lógica de la empresa puede reutilizarse para otra interfaz. De modo que incluso para las aplicaciones cliente/ servidor, se requiere un trabajo y unos conocimientos parecidos para ir desde dónde estamos hoy hasta donde hemos de llegar para crear esas nuevas aplicaciones.”
“Hoy en día, la interfaz de usuario preferida para casi todas las aplicaciones (incluyendo las de uso interno) es un navegador web.”
Es un tema de formación permenente Quienes reciben este Suplemento técnico (es decir, los suscriptores de la revista) saben que, al llegar estas fechas (Septiembre simboliza el inicio de un “nuevo curso”), cada año pretendemos profundizar algo más en un tema concreto: primero fue Java para programadores RPG, luego el SQL, hace dos años el estándar XML y las tecnologías a él asociadas, el pasado algo de Linux..., etc., etc. En nuestro entorno todo apunta a que la alternativa al desarrollo clásico de aplicaciones es J2EE a través de Websphere Application Server cuya versión “Express” se incluye gratuitamente en cada servidor i5 pero ¿qué ocurre si a uno Java se le atragantó desde el principio? ¿No hay ninguna otra alternativa? Si es tu caso, no te pierdas el siguiente artículo, incluido en este Suplemento. G
Carlos Bell es colaborador habitual de la revista ServerNEWS (antes NEWS/400) NÚMERO 66
HELP400 Suplemento Técnico 5
.NET, una alternativa a J2EE Según parece, el desarrollo e integración de aplicaciones distribuidas y Servicios Web será el modelo informático habitual en aquellas empresas que quieran mantener su competitividad. Existen dos alternativas: J2EE y .NET ¿Por cuál de ellas hemos de apostar si queremos mantenernos “al día” profesionalmente hablando? Tal vez en este artículo halles la respuesta. Por Carlos Bell
E
ste artículo va dirigido a todos aquellos que, como yo, están muy interesados en mantener actualizados sus conocimientos profesionales, pero que por causas del destino han realizado gran parte de su trabajo como desarrolladores en un entorno tan “clásico” como el del AS/400 (donde más del 80% de aplicaciones están escritas en RPG), apoyándose, y en más de una ocasión, en aplicaciones cliente/servidor que, del lado del cliente, han sido desarrolladas bajo Windows con el “humilde” VisualBasic. Como fiel reflejo del entorno al que se dirige, así lo han mostrado los artículos publicados en NEWS/400 (ahora ServerNEWS) donde, en un determinado periodo de tiempo (mediados de los años 90, del 94 al 97), las referencias prácticas a aplicaciones y utilidades RPG - VisualBasic son frecuentes. Cuando IBM dirigió su evangelización hacia Java, dejando atrás otros lenguajes OOP más estrictos y difíciles de adoptar en un entorno de aplicaciones empresariales, como puedan ser C++ y SmallTalck, en la redacción también seguimos, con más o menos fortuna, tal tendencia. Como he comentado en el artículo “Llegan las aplicaciones distribuidas”, a medida que la importancia de Internet ha ido creciendo y las empresas buscan integrar su información entre límites departamentales y empresariales, ha nacido un nuevo enfoque de desarrollo de soluciones basado en aplicaciones distribuidas y Servicios Web. Desde el punto de vista del consumidor, estos servicios son conceptualmente similares a los componentes habituales de VisualBasic, salvo que encapsulan sus propios datos y no forman parte, estrictamente hablando, de la aplicación sino que ésta los utiliza. Esas aplicaciones y servicios que necesitan integrarse pueden ser desarrollados en distintas plataformas, por distintos equipos, en diferentes programas y se pueden mantener y actualizar de una forma independiente. Ante la creciente demanda de soluciones distribuidas, en el mercado han surgidos dos plataformas o enfoques tecnológicamente distintos e incluso enfrentados. Una de ellas, la pionera, ofrece la visión de la empresa Sun Microsystems (creadora del lenguaje Java) y recibe el nombre genérico de J2EE (Java2 Enterprise Edition). La otra, más reciente, es la visión de Microsoft y recibe el nombre de Plataforma “dotNET” o, más concretamente, .NET Framework. En este punto, para clarificar conceptos, añadir que J2EE es, ante todo, un conjunto de especificaciones de Sun que definen un posible estándar “de facto” para el desarrollo de aplicaciones empresariales multicapa, no un producto. Son varios los vendedores que las implementan en sus productos. Entre otros, los más importantes son IBM WebSphere, BEA WebLogic, Oracle9iAS o Sun ONE. Sun también, pero aunque sea la propietaria de la definición J2EE, su presencia en el mercado, aun siendo importante, es relativamente menor. A su vez, cada una de estas implementaciones proporciona servicios de valor añadido a los originalmente propuestos en las especificaciones J2EE. 6
HELP400 Suplemento Técnico
Va más allá del alcance de este artículo y de mis actuales conocimientos comparar cada parte de la arquitectura J2EE con su equivalente en .NET de Microsoft. Por tanto, la comparación sólo será global para centrarnos con más detalle en la Plataforma .NET, por haber sido ésta la menos difundida entre los lectores de nuestro entorno.
Sobre la arquitectura J2EE
▼
▼
▼
▼
NÚMERO 66
▼
▼
Efectivamente, a lo largo de los últimos años en la revista NEWS/400 se han publicado numerosos artículos sobre Java y WebSphere. Entre ellos, mencionar el número 140 (de Enero de 2004) donde casi todo su contenido se centraba en WebSphere, la actual estrategia de desarrollo de IBM. Según los argumentos de Sun, “J2EE define un estándar para el desarrollo de aplicaciones empresariales multicapa. J2EE simplifica las aplicaciones empresariales basándolas en componentes modulares y estandarizados, proveyendo un completo conjunto de servicios a estos componentes, y manejando muchos de las funciones de la aplicación de forma automática, sin necesidad de una programación compleja”. Recordemos que las capas son simples agrupaciones lógicas de los componentes de software que conforman una aplicación o servicio. Ayudan a diferenciar entre los distintos tipos de tareas que realizan los componentes, facilitando el diseño de su reutilización en la solución. Cada capa lógica contiene un número de tipos de componentes discretos agrupados en subcapas, cada una de las cuales realiza el mismo tipo de tarea específica. Al identificar los tipos genéricos de componentes que existen en la mayoría de soluciones, se puede construir un mapa coherente de una aplicación o servicio y, a continuación, utilizar este mapa como plano técnico para el diseño. La figura 1 muestra una visión muy simplificada de las tres capas (presentación, lógica empresarial y acceso a datos) de una aplicación web distribuida con arquitectura J2EE y los diferentes componentes de sus especificaciones: acceso a base de datos (JDBC), utilización de directorios distribuidos (JNDI), acceso a métodos remotos (RMI/IIOP), funciones de correo electrónico (JavaMail), aplicaciones Web (JSP y Servlets), etc. Ni que decir tiene que la gran experiencia de IBM en escalabilidad de sistemas y en servidores transaccionales hace que cuando se plantea la evolución de los sistemas internos de la empresa (tipo 5250 o 3270...) hacia aplicaciones web, WebSphere Application Server sea una de las elecciones más acertadas. Y lo que es más significativo, Java es la elección estratégica de IBM para el desarrollo de FIGURA 1 nuevas aplicaciones. Así las cosas, tarde o temprano los lenguajes de programa- Arquitectura J2EE en una ción tradicionales pueden quedar relegados a un segundo plano. aplicación multicapa Añadir, finalmente, que a lo largo de más de 15 años, el “AS/400” ha demostraUsuarios WebSphere Application Server DB2 UDB do ser uno de los sistemas más fiables y Capa 1 Capa 2 Capa 1 Capa 3 seguros para todo tipo de aplicaciones emPresentación Lógica empresarial Presentación Acceso a datos (en el Servidor) (en el Servidor) (en el Cliente) (en el Servidor) presariales. Desde hace años, la implementación de Java bajo su sistema opeContainer EJB Container Web Navegador · JSP rativo ha convertido al hoy denominado · HTML puro · EJB · Servlet · Applet Java eServer i5 en uno de los servidores Java con mayor rendimiento del mercado. Java Desktop J2EE Server Core J2EE Server Core para el i5 es una combinación perfecta · Aplicación · JAF · JAF Java · Java Mail · Java Mail para el desarrollo de las aplicaciones em· JDBC · JDBC presariales más avanzadas y fiables. Java + Dispositivos · JNDI · JNDI pone la innovación, el eServer i5 la fiabi· JTA · JTA · J2EE Cliente · RMI/IIOP · RMI/IIOP lidad, y los desarrolladores pondremos el resto... Desde un planteamiento puramenFuente - http://www-106.ibm.com/developerworks/db2/library/techarticle/0209hutchison/images/... te teórico, es algo casi perfecto. HELP400 Suplemento Técnico 7
Sobre la arquitectura .NET A finales del 2000 Microsoft publicó los primeros documentos sobre la tecnología .NET, una estrategia de Microsoft que pretende homogeneizar y unificar sus APIs de programación en una sola que abstrae todo el sistema, simplificando el acceso a ella desde múltiples lenguajes, al mismo tiempo que sienta las bases de un rediseño estructural de Windows en favor de un modelo más uniforme de componentes orientados a objetos. Esta tecnología consta de dos partes: • NET Framework: un nuevo modelo de objetos COM+, un recompilador dinámico JIT (Just in time), un entorno de ejecución virtual y las propias APIs. • NET Services: Aplicaciones y librerías que pueden ser ejecutadas remotamente y utilizadas desde los programas. A un nivel muy elemental, .NET tiene bastantes similitudes con la tecnología Java: ambos compilan el código fuente a un código intermedio que, en el caso de Java se denomina Bytecode, y en .NET recibe el nombre de CIL (Common Intermediate Language). Para ejecutar este código intermedio es necesario un entorno que lo interprete para convertirlo al código de máquina del sistema donde se esté ejecutando. En ambos casos, para los que desde hace años trabajamos en el entorno “AS/400”, la idea nos resulta muy familiar: recordemos que el S/38, FIGURA 2 desde su concepción, contaba con un “Machine Interface” que independizaba claArquitectura de .NET Framework ramente el hardware del desarrollo del software, lo que permitió traspasar sus .NET Framework Architecture aplicaciones al AS/400 sin ningún tipo de modificación y que, posteriormente, perC# / C++ VBasic.NET JScript.NET Perl avRPG.NET Cobol... mitió a éste cambiar la tecnología de sus CLS (Common Language Specification) procesadores a tecnología RISC de 64 bits... ¡de un día para otro! Pero .NET va más allá de J2EE, su obASP.NET / Servicios Web XML Windows Forms jetivo no es sólo la independencia de la ADO.NET y XML compilación sino también la independencia del lenguaje de alto nivel que se utiliFCL (.Net Framework Class Library) ce. Como veremos, CIL ha sido diseñado para proporcionar todo lo necesario para la mayoría de los lenguajes actuales. El CLR (Common Language Runtime) que más aprovecha su potencia es C# (ce Sharp) un estándar diseñado por la proCLI (Common Language Infraestructure) pia Microsoft, pero nada impide que para formar parte de la plataforma .NET una Sistema Operativo empresa cree un compilador a código inFuente: Golem Project (Universidade da Coruña) termedio CIL para su lenguaje. La arquitectura .NET define las especificaciones de un lenguaje neutral denoFIGURA 3 minado CLI (Common Language InfrasPrincipales componentes de .NET y J2EE tructure) que es el alma y corazón de lo que Microsoft denomina como “.NET Característica .NET Java2 Enterprise Edition Framework” y que a su vez consta de un Acceso a bases de datos ADO.NET JDBC, SQL/J Código máquina “ejecutable” IL Java Bytecode CTS (Common Type System) con soporte Componentes .NET Managed Components EJB (Java Beans) a los suficientes tipos de datos para cuLibrerías desarrollo - API .NET Framework Java API brir las necesidades de cualquier lenguaje Integración Web ASP.NET Servlets, JSP actual; y unas especificaciones CLS Rercursos gráficos WinForms y WebForms Java Swing IDE progamación Visual Studio .NET Según fabricante (Common Language Specification) que Lenguajes C#, VBasic, etc... Java deben cumplir todos los lenguajes que Gestión mensajes MSMQ JMS pretendan beneficiarse de dicha interoRuntime CLR JRE perabilidad. Servicio de directorio ADSI JNDI Servicios Web SOAP, WDSL, UDDI SOAP, WDSL, UDDI Este CLI proporciona, por ejemplo, la Transacciones distribuidas MS-DTC JTS posibilidad de poder reutilizar clases 8
HELP400 Suplemento Técnico
programadas en un lenguaje de alto nivel como pueda ser C# desde Visual Basic.NET o desde cualquier otro lenguaje .NET de una forma muy sencilla. El lenguaje pasa a ser irrelevante, porque todas las clases son las mismas, y porque el entorno de desarrollo unificado (en el caso de Microsoft, Visual Studio .NET) brinda las mismas funcionalidades a todos. Evidentemente, nos hallamos ante una clara diferencia positiva con respecto a las especificaciones J2EE de Sun, donde es imprescindible aprender a programar con el lenguaje Java y en donde no es posible aprovechar el código o la experiencia adquirida en otros lenguajes, aunque éstos sean tan “tradicionales y humildes” como el Cobol o el RPG, para los que ya existen versiones comerciales “puntoNET”. La idea, con ser brillante, tampoco es tan novedosa en nuestro entorno. Al respecto, ¿qué podríamos decir del ILE (Integrated Language Environment), una solución similar incluida en el OS/400 hace años? En Marzo de 1995, en mi artículo “Por fin, ILE para todos” (NEWS/400, número 52) basado en un documento de Paul Conte titulado “Modular progamming and the AS/400 ILE”, explicaba sus fundamentos comparándolo con el modelo de programación original propio del AS/400 (OPM), escribiendo textualmente: “... el ILE no sólo facilita la utilización de lenguajes más modernos que hacen uso intensivo de llamadas a procedimientos o funciones, como puedan ser C++ o SmallTalk, sino también el desarrollo de aplicaciones y programas basados en varios lenguajes y en donde podemos explotar las mejores cualidades de cada uno de ellos, según nuestras necesidades y conocimientos.”
Profundizando un poco más Si bien en Internet existe una gran cantidad de información sobre el funcionamiento y lo que es el “.NET Framework” de Microsoft, antes de proseguir creo que es importante mencionar otros aspectos más “técnicos” que nos permitan entender qué podemos esperar de esta plataforma. Como pretende reflejar el esquema de la Figura 2, aparte del CLI ya comentado, la plataforma .NET está compuesta por otras dos partes fundamentales: Common Language Runtime (CLR). Es el entorno de ejecución que traduce el código intermedio CIL a código máquina y que, por tanto, permite ejecutar cualquier aplicación de la plataforma. La implementación del CLR de Microsoft incorpora tecnología JIT de forma que sólo se traducen a código máquina las partes necesarias y éstas se “recuerdan” por si vuelven a ser llamadas (por ejemplo, funciones) consiguiendo así un mayor rendimiento en la ejecución. En resumen, CLR actúa como: • • • • • • •
Un runtime para todos los lenguajes .NET Gestiona threads y memoria Recolector de basura (Garbage Collection) Fuerza la seguridad a nivel de código Elimina problemas de versiones de DLLs Podemos ejecutar simultáneamente varias versiones de una DLL Las aplicaciones pueden especificar la versión de la DLL que van a usar.
Framework Class Library (FCL). La librería de clases responsable de proporcionar una gran cantidad de servicios: Entrada/Salida; XML; ADO.NET, para el acceso a Bases de datos; ASP.NET, como soporte para las aplicaciones Web (incluyendo “Web Forms” para el interfase humano y “XML Web Services” para el interfase máquina); Windows.Forms, para el desarrollo de aplicaciones Windows tradicionales; sockets; colecciones; etc., etc. El FCL también presta parte de sus servicios a cualquier lenguaje que esté dentro de la plataforma .NET ya que éstos cumplen con CLI, minimizando así la incidencia de sus características propias. NÚMERO 66
HELP400 Suplemento Técnico 9
En la tabla de la Figura 3 se relacionan las principales características técnicas de .NET y de J2EE.
Hasta ahora he expuesto una visión global de la tecnología .NET y parte de sus posibles beneficios, pero lo realmente interesante viene a continuación. Se trata de un tema de percepciones y, por tanto, algo muy subjetivo. Al AS/400 siempre se le ha acusado de ser un “sistema propietario” de IBM, sin embargo, el eServer i5 actual es un servidor multiplataforma que puede trabajar, simultáneamente, con hasta cuatro sistemas operativos distintos (Windows con un xSeries integrado). Respecto a las arquitecturas .NET y J2EE nos ocurre algo similar. Nuestra percepción es la de que J2EE y su lenguaje Java son unos estándares de la industria, sin embargo su único propietario es Sun Microsystems y, aunque de facto puedan llegar a ser un estándar, se está a merced de sus decisiones e intereses al utilizarlos. Con la arquitectura .NET Framework y el lenguaje C# de Microsoft ocurre todo lo contrario: nuestra percepción nos indica que son propietarios y, no obstante, la realidad es que son estándares oficialmente reconocidos por la industria (en el caso de .NET, sólo las partes principales) y, por tanto, no están expuestos a variaciones interesadas de Microsoft. Tal vez sea poco conocido, pero así es. Microsoft presentó C# en junio de 2000, y en agosto del mismo año, junto con Hewlett-Packard e Intel, sometió las especificaciones del CLI y de C# al comité técnico de lenguajes de ECMA (European Computer Manufacturer's Association). Estos copatrocinadores, junto con otros miembros de ECMA, entre los que se incluyen IBM, Fujitsu Software y otros expertos, como Plum May, Monash University, ISE y Ximian, redefinieron estas especificaciones para su aprobación como estándar del ECMA. En diciembre de 2001, la asamblea general del ECMA aprobó la primera edición de los estándares C# y CLI como ECMA-334 y 335 respectivamente, aprobando también el informe técnico del CLR, ECMA-TR84, promoviendo su adopción por el ISO/IEC. En abril de 2003, Microsoft anunció satisfecha que el ISO/IEC (International Organization for Standarization / International Electrotechnical Comitee) haFIGURA 4 bían publicado conjuntamente los estándares internacionales para la programaRotor: esquema de la ción de Servicios Web. Entre estos estándares se incluyen C#, como lenguaje de impementación SSCLI de programación orientado a objetos, el CLI (Common Language Infraestructure), y Microsoft el informe técnico del CLR (Common Language Runtime), partes fundamenImplementación SSCLI tales de la plataforma .NET. (Más inVS.NET System.Web System.WinForms C# SessionState formación en la dirección http:// UI Component Model Desing Caching HtmlControls JScript msdn.microsoft.com/net/ecma/). Security WebControls VisualBasic
System.Drawing
Configuration
System.Web.Services
VC/MC++
Protocols Debugger
Discovery
Designers
SDK Tools
Description
Fuente: Golem Project (Universidade da Coruña)
10
ILDbDump SN ILDAsm
Sin duda Microsoft sometió sus propuestas a la estandarización oficial para obtener lo que podríamos denominar como una “certificación” de sus implementaciones, por lo que “.NET Framework” por definición ya es una arquitectura multiplataforma, lo que no implica que Microsoft esté obligada o interesada en transformar su propia implementación para que funcione en otra plataforma distinta a Windows. No obstante, con un giro inesperado en su larga historia contra el código libre y como muestra de un apoyo deci-
System.XML
SQL
XSLT
Desing
Adapters
XPath
Collections
IO
Security
Configuration
Net
ServiceProcess
Diagnostics
Reflection
Text
Remoting
Resources
Threading
Serialization
Serialization
System
Globalization
Runtime InteropServices
Common Language Runtime GC
App Domain Loader
JIT
MSIL
Common Type System
Class Loader
Platform Abstraction Layer (PAL)
Boot Loader Threads
Rotor: Shared Source CLI
Text
ADO
MetaInfo PEVerify
Printing
Imaging
System.Data (ADO.NET)
CorDBG ILAsm
Drawing2D
Networking Sync
HELP400 Suplemento Técnico
Timers
FileSystem
ECMA-335
ECMA-334
Sistemas estándar y sistemas propietarios
dido a su estrategia .NET, Microsoft, con la colaboración de Corel, puso en marcha el llamado “Programa de licencias de código fuente para implementaciones en C#/ JScript/CLI”. La infraestructura de lenguaje común (CLI) es el estándar establecido que describe la base de .NET Framework. El código compartido de la CLI (SSCLI) es el código fuente de una implementación válida de ECMA CLI y las características específicas del lenguaje C#. Como podemos ver en el gráfico de la Figura 4, el SSCLI incluso supera el estándar de ECMA (en verde) y ofrece un tiempo de ejecución, librerías de clases, compiladores de C# & JScript.NET, depuradores, herramientas, la capa de adaptación a la plataforma (PAL), un sistema de construcción portátil y una suite completa de pruebas. Según Microsoft, el SSCLI será de gran interés para los investigadores y el personal académico que quiera enseñar y conocer los conceptos de los modernos lenguajes de programación y para los desarrolladores de .NET interesados en el funcionamiento de tal tecnología. La implementación se construye y ejecuta en Windows XP, y los sistemas operativos FreeBSD y Mac OS X 10.2. Su lanzamiento se realizó bajo una licencia de “código compartido no comercial”. Según comentó en su día Craig Mundie, vicepresidente superior de estrategias avanzadas de Microsoft, “La implementación de fuente compartida de esos estándares demuestra la dedicación de Microsoft para con los estándares abiertos en .NET y proporcionará un ambiente nativo de programación de Servicios Web XML a través de distintos sistemas operativos.”. Todo un estímulo y un incentivo adicional para la activa comunidad de desarrolladores de código libre.
Propuestas .NET multiplataforma El hecho de que el “CLI” esté sujeto a estandarización genera dos impactos: el primero, como ya he comentado antes, es que cualquier otra empresa puede construir lenguajes de programación que lo utilicen en sus lenguajes (como ejemplos prácticos, “Delphi 8 para .NET” de Borland, “COBOL.NET” de Fujitsu, “AV RPG.NET” de ASNA, y así hasta más de 20); y el segundo, y tal vez con más impacto a corto plazo, es el de que cualquier otra empresa u organización interesada podría realizar su propia implementación. Aunque .NET es una iniciativa llevada a cabo por la empresa Microsoft, esto no impide que hayan sido creados otros desarrollos basados en sus mismos principios. Hoy en día, la comunidad Open Source está trabajando sobre dos proyectos que tienen como finalidad ofrecer una implementación libre y de código abierto sobre esta misma arquitectura. Y una de las garantías con la que cuenta la comunidad Open Source para que ambos proyectos prevalezcan y no sean relegados al no contar con el apoyo directo de Microsoft, es que los principales componentes de .NET se encuentran definidos como estándares. La idea que subyace en esta política no es precisamente la de competir, sino más bien la de complementarse para hacer frente a la arquitectura J2EE de Sun. Proyecto Mono. Aquí entra en juego la empresa Novell y su organización para proyectos OpenSource (Ximian), inmersa en la difícil tarea de realizar su propia implementación, pero en este caso en dos versiones, una para Windows y otra para Linux; lo que se conoce como “Proyecto Mono”, liderado desde el principio (2001) por Miguel de Icaza. La primera versión de Mono fue liberada en Julio de este año. Su importancia radica en la libertad que proporciona para escoger cualquier lenguaje de programación o combinación de ellos para desarrollar aplicaciones distribuidas y poder ejecutarlas en cualquiera de las plataformas en las que Mono se encuentra disponible, entre las que se incluyen Intel, AMD64, SPARC, StrongArm, Power5 y zSeries (S/390). Mono actualmente proporciona las herramientas suficientes para crear aplicaciones para Linux (diversas distribuciones), Solaris, Windows, Mac/OS, y mainframes de IBM. NÚMERO 66
HELP400 Suplemento Técnico 11
DotGNU. DotGNU es un proyecto llevado acabo por la fundación GNU, ofreciendo prácticamente las mismas funcionalidades que Mono, como: un compilador C# y un "Runtime" para .NET. Sin embargo, mientras ambos están basados en los mismos estándares de ECMA, dotGNU tiene un enfoque particular en lo que se refiere a Servicios Web (XML-RPC/SOAP) e integración con PHP.
Probar .NET Framework sin gastar un céntimo Aparte de otras consideraciones (infundadas, o no), existe la creencia de que se necesita mucho dinero para utilizarlo. Nada más lejos de la realidad. La versión .NET Framework SDK 1.1 en español se puede descargar gratuitamente desde Microsoft y puede utilizarse desde Windows 98 SE en adelante. Además, contiene el llamado “Microsoft SQL Server 2000 Desktop Engine” (MSDE) que posee muchas de las características de SQL Server aunque algo limitadas y sin herramientas visuales para su gestión. Ahora bien, VisualStudio.NET (VS.NET) sí sale algo caro, ¿verdad?, pero ¿por qué no probar con dos muy buenas herramientas, una de ellas OpenSource? Primero, disponemos de WebMatrix, un IDE pensado para el desarrollo de aplicaciones ASP.NET, que soporta muchas características de su hermano mayor (VS.NET) y hasta posee un mini Web Server integrado. Se puede bajar gratis desde http:/ /www.asp.net. Segundo, si necesitas realizar una aplicación WinForms, dispones de CSharpDevelop, un excelente IDE OpenSource (Figura 5), que tiene muy poco que envidiar al VS.NET de Microsoft. Puedes encontrarlo en h t t p : / / www.icsharpcode.net ¿Eres un “linuxero” convencido y no quieres utilizar M$ Windows para nada?, entonces ya sabrás dónde encontrar material y herramientas para Mono, dotGNU o FreeBSD.
La opinión de las grandes consultoras
FIGURA 5 CSharpDevelop, un excelente IDE Open Source
Para finalizar, añadir que si bien inicialmente los informes de los grandes analistas del mercado como IDC, Gartner, Giga Information Group o Forrester eran más bien desfavorables al futuro de la iniciativa .NET de Microsoft frente a la estrategia J2EE de Sun, hoy sus opiniones han cambiado. La mayoría coinciden al indicar que la batalla entre .NET y J2EE es global y que no habrá ni vencedores ni vencidos. Según su experta opinión, las grandes corporaciones seguirán utilizando J2EE en sus iniciativas e-business, y las pequeñas y medianas empresas se decantarán por .NET. Añadir que Forrester, en un reciente estudio titulado “The State Of Technology Adoption” en el que se entrevista a cerca de un millar de medianas y grandes empresas de EE.UU. se llega a la conclusión de que el 46% de las empresas consideran que su principal plataforma para el desarrollo propio de aplicaciones distribuidas es J2EE, mientras que el 56% se decantan por .NET. En general, es un documento interesante para todo aquel que quiera conocer la evolución del mercado TI a medio plazo. A través de Microsoft, está a su disposición en http:/ /www.microsoft.com/windowsserversystem/ forresterdotnet.mspx ●
Carlos Bell es colaborador habitual de la revista ServerNEWS (antes NEWS/400) 12
HELP400 Suplemento Técnico