Web Services

Informe de Proyecto de grado Estudio e implementación de Web Services

1INTRODUCCIÓN ..................................................................................................................................................................4

1.1EL PROYECTO.......................................................................................................................................................................4

1.2OBJETIVO..............................................................................................................................................................................4

1.3ORGANIZACIÓN DEL INFORME ................................................................................................................................................4

2WEB SERVICES....................................................................................................................................................................6

2.1 INTRODUCCIÓN.....................................................................................................................................................................6

2.1.1RPC............................................................................................................................................................................6

2.1.2Comparando protocolos XML.................................................................................................................................6

2.2EVOLUCIÓN DE LOS WEB SERVICES........................................................................................................................................8

2.2.1Historia de la computación distribuida..................................................................................................................8

2.2.2Conectando Aplicaciones en la Web.......................................................................................................................8

2.3ARQUITECTURA DE LOS WS...................................................................................................................................................9

2.3.1Invocación ..............................................................................................................................................................10

2.3.2Descripción ............................................................................................................................................................11

2.3.3Discovery.................................................................................................................................................................12

2.4WSDL : WEB SERVICES DEFINITION LANGUAGE.................................................................................................................13

2.5UDDI : UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION.........................................................................................13

2.6OTRAS TECNOLOGÍAS RELACIONADAS....................................................................................................................................13

2.7IMPLEMENTACIONES Y HERRAMIENTAS..................................................................................................................................14

2.7.1Microsoft SOAP Toolkit 2.0...................................................................................................................................14

2.7.2IBM Web Services Toolkit......................................................................................................................................15

2.7.3 Otras implementaciones de SOAP.......................................................................................................................16

3SOAP : SIMPLE OBJECT ACCESS PROTOCOL......................................................................................................16

3.1INTRODUCCIÓN....................................................................................................................................................................16

3.2SOAP Y WEB SERVICES.....................................................................................................................................................16

3.2.1SOAP Message Exchange Model..........................................................................................................................16

3.2.2SOAP y HTTP.........................................................................................................................................................18

3.2.3SOAP Message .......................................................................................................................................................18

3.3TRANSPORTE.......................................................................................................................................................................19

3.3.1Separación de mensaje y transporte.....................................................................................................................19

3.3.2HTTP.......................................................................................................................................................................20

3.3.3SOAPAction Header...............................................................................................................................................21

3.3.4Status Code..............................................................................................................................................................21

4CASOS DE APLICACIÓN................................................................................................................................................22

4.1INTRODUCCIÓN....................................................................................................................................................................22

4.2PRESENTACIÓN DEL PROBLEMA.............................................................................................................................................22

4.2.1Transacciones.........................................................................................................................................................22

1


4.2.2Publicación de Cursores........................................................................................................................................23

4.2.3Perfil del producto .................................................................................................................................................23

4.2.4XForms ...................................................................................................................................................................24

4.2.5Plataforma y herramientas ...................................................................................................................................25

5DISEÑO.................................................................................................................................................................................26

5.1TRANSACCIONES..................................................................................................................................................................26

5.1.1Firma Digital..........................................................................................................................................................26

5.1.2SSL ..........................................................................................................................................................................27

5.1.3Manejo de tickets....................................................................................................................................................27

5.2CURSORES..........................................................................................................................................................................27

5.2.1Manejo de sesiones por parte del servidor...........................................................................................................28

5.2.2Benchmarks.............................................................................................................................................................28

6PROTOTIPO........................................................................................................................................................................29

6.1ESTUDIO DE PLATAFORMA....................................................................................................................................................29

6.2MODELO DE TRABAJO DE APACHE SOAP SOBRE TOMCAT.....................................................................................................29

6.3MECANISMO DE MANTENIMIENTO DE SESIONES (WEB SERVICES STATEFUL)..............................................................................32

6.4 TRANSACCIONES.................................................................................................................................................................33

6.4.1Soporte de comunicación sobre SSL.....................................................................................................................33

6.4.2Soporte de firma Digital.........................................................................................................................................35

6.4.3Secuencia de Ejecución de Transacciones...........................................................................................................41

6.4.4Tratamiento de Errores..........................................................................................................................................46

6.4.5Objetos de Intercambio (ValueObjects)................................................................................................................46

6.5 CURSORES.........................................................................................................................................................................47

6.5.1Cursor Abstracto....................................................................................................................................................47

6.5.2Implementación Básica de un Cursor...................................................................................................................48

6.5.3Implementación de un Cursor con Caché...........................................................................................................49

6.5.4Publicación de un Cursor como Web Service......................................................................................................51

6.5.5Implementación de un Cliente...............................................................................................................................54

6.5.6RMI..........................................................................................................................................................................55

6.5.7Objetos de Intercambio (ValueObjects)................................................................................................................56

7BENCHMARKS ...................................................................................................................................................................57

7.1TRANSACCIONES..................................................................................................................................................................57

7.1.1Objetivo...................................................................................................................................................................57

7.1.2Escenario.................................................................................................................................................................57

7.1.3Ejecución y Presentación de los resultados.........................................................................................................57

7.2CURSORES..........................................................................................................................................................................58

7.2.1Objetivo...................................................................................................................................................................58

2


7.2.2Escenario.................................................................................................................................................................59

7.2.3Ejecución ................................................................................................................................................................59

7.2.4Presentación de los Resultados.............................................................................................................................60

8CONCLUSIONES................................................................................................................................................................63

8.1SOBRE LA TECNOLOGÍA .......................................................................................................................................................63

8.2SOBRE LA APLICACIÓN A ESTOS CASOS...................................................................................................................................63

8.2.1Transacciones.........................................................................................................................................................63

8.2.2Cursores..................................................................................................................................................................64

8.3SOBRE LA ALTERNATIVA UTILIZADA .......................................................................................................................................68

8.4SOBRE EL FUTURO ..............................................................................................................................................................69

8.5POSIBLES EXTENSIONES AL PROYECTO....................................................................................................................................69

3


1 Introducción

1.1 El ProyectoRecientemente,ha surgido el conceptode WebServices(WS), y los expertosconsideranque el

mismocambiarála formade programarlas aplicacionesorientadasa Internety la conduciráhaciaunaarquitecturaorientadaa servicios.Esteproyectosebasaenel estudiodeestatecnologíay suaplicacióna casos concretos, demostrando su viabilidad a través de la implementación de un prototipo.

1.2 ObjetivoEl objetivodeesteproyectoesevaluarel estadodel artedela tecnologíadeWebServicesy probar

su aplicación a casos concretos.

En unaprimerainstanciaseestudióéstatecnología,los protocolosy especificacionesasociadas,yse realizó una evaluación de algunas implementaciones y herramientas disponibles.

Los casosde aplicaciónseeligieronde forma quefueranrepresentativosde los problemastípicosquepuedenintentarresolverseconWebServices.En particularsetrabajóenel marcotecnológicodelproducto EDF de la empresaIdeaSoft [1], brindando la infraestructuranecesariapara realizartransacciones y manejar cursores.

El caso de aplicación para las transaccionesconsiste en estudiar la viabilidad de realizartransaccionescomercialesmedianteWeb Services.Como un objetivo de esteproyectosepresentaelimplementarestafuncionalidad,resolviendoproblemastalescomo:asegurarla confidencialidadde latransacción, evitar el repudio, etc.

Otro problema que puede atacarse utilizando Web Services es el de recorrer catálogos o coleccionesde datos.Paraello, se estudióel conceptode cursorgenérico,accedidomedianteWeb Services.Unobjetivodeesteproyectoesprobarsuviabilidad,medirsudesempeñofrentea otrasalternativasy fijaruna frontera para la utilidad de ésta tecnología.

1.3 Organización del Informe El informe se organizade la siguientemanera:primero se da una detalladadescripciónde la

tecnología,su arquitectura,sus componentes,ventajasy desventajas.Luego, se presentael marcotecnológicoy funcionalde IdeaSoft,a continuaciónseexponela implementacióndel prototipoy losbenchmarksrealizadosy por último, seenumeranlasconclusionesrecogidasdurantela realizacióndelproyecto.

En él capitulo titulado WebServicesseproporcionaunabaseteórica,un raccontode la evolucióntecnológicaquecondujoal surgimientodeWS y unainformacióngeneraldela arquitecturadelos WS.Más adelantesehaceunadescripciónde los conceptosWSDL y UDDI y de cómoéstostrabajanenconjunto.

En el capítulo SOAP, se da una descripciónbásicadel protocolo,de su aplicaciónen los WebServices,desu sintaxis,de la representacióndelos datos,y de la formadetransporteentreun puntoyotro.

En el capítulo denominadoCaso de Aplicación se describenlos diferentescontextosen que se

4


realizaesteproyectoy los requerimientosdadosparala ejecuciónde transaccionesy el manejodecursores usando Web Services.

En el capítuloDiseño, sepresentala solucióna los requerimientosdel proyecto,haciendohincapiéenlos requisitosdeseguridadquetraeaparejados(firma digital, SSL,etc.)y en lasconsideracionesdeperformance.

En el capítuloPrototipo, se describeel entornode desarrollodel proyecto,qué herramientasseusaron como software de base para realizarlo y las clases implementadas.

Porúltimo sepublicanmedicionesparalos distintosentornosdeejecución,comparandotiemposderespuestasde mensajesfirmados y no firmados y los benchmarkde los Web Servicescontra laarquitectura RMI.

Finalmente,en el último capítulo,se arriba a las conclusionessobreel proyecto junto con lascaracterísticas que presenta esta tecnología.

5


2 Web Services

2.1 IntroducciónUn WebServices(WS) esunaaplicaciónquepuedeserdescripta,publicada,localizada,e invocada

a través de una red, generalmente Internet.

Los WS sona los efectosdel consumidorcomponentesqueseencuentrandentrodeunacajanegra,quepuedenserutilizadossin preocuparsede comofueron implementados,y seraccedidosutilizandoXML (SOAP), generalmente sobre HTTP.

La arquitecturabásicadel modelodeWS describeun consumidor,un proveedory ocasionalmenteun corredor(broker)y relacionadoscon estosagentesestálas operacionesde publish(publicar),find(encontrar) y bind (enlazar).

Los requerimientos a la hora de desarrollar o consumir un WS son:

- una forma estándar de representar los datos: XML

- un formato común y extensible de mensaje: SOAP

- un lenguaje común y extensible para describir los servicios: WSDL (basado en XML).

- una forma de descubrir los servicios en Internet: UDDI (basado en XML).

Una vastaáreade uso de XML viene dadapor la necesidadde interoperabilidad,permitiendoa lasaplicacionescomunicarseunascon otrasde unaforma estándar.En efectoXML seha vuelto la piezacomún y de mejor entendimiento de la comunidad de diseñadores de software.

De aquí en adelantenos referiremosa la comunicaciónCliente - Servidor.El procesoservidor,delrequerimientocliente,generalmenteretornaráun valor comoresultadodesuproceso.El clienteenestecaso es la función o método que hace la llamada, el cual requiere ejecutar algún proceso en el servidor.

2.1.1 RPC

RPCpermitea los desarrolladoresdesoftwarehacerfuncioneso llamadasa métodosa travésdela red,lo cualpermiterudimentariasaplicacionesdistribuidassobrela red. Esun mecanismoa nivel decapade aplicación,quecomunicaunaaplicacióncon otra. La llamadade RPCesidénticaa la sintaxisdeuna función local.

La función toma la forma de interacciónCliente - Servidor.RPC actúacon el mismo espírituJavaRMI, pero se diferencia en que:

- no haycontextodeobjeto.Funcionesremotassonllamadasa travésde la red comounaAPI remota.RMI logra esto naturalmente

- requiere un seteo para el retorno de una llamada en ambos servidores

- el cliente y el servidor pueden ser implementados con independencia de lenguajes de programación

2.1.2 Comparando protocolos XML

6


2.1.2.1 XMLRPC

- Liviano, rápido y fácil para la implementaciónde invocacionesremotasde funcionalidadatravés de HTTP tunneling

- HTTP tunneling es integrante de este protocolo

- Operaciones sin conexión no están actualmente disponibles

- Las especificaciones son muy fáciles de entender

- Es muy fácil de programar, fue la meta del diseño original

- El trafico del protocoloesleíbley entendible,y un operadorpodrádescifrarel tráfico noencriptado

- Una conexión debe abrirse para cada nuevo canal, no es posible multiplexar canales

- Solamente un servidor sirviendo a un cliente, no soporta descentralización

- Es una instancia de protocolo fija, no tiene la habilidad de pasarse a otros protocolos

- No existe una seguridad de autentificación especificada

- Request y response son ambos documentos XML

2.1.2.2 SOAP

- Es el protocolo clave para la nueva infraestructura de interacción entre aplicaciones

- Soporta HTTP tunneling, como un transport binding

- Soporta manejo de RPC

- Soporta operaciones de desconexión

- No es fácil entenderlas especificaciones,es un complejoesquemade codificación,binding paraprotocolos y otras para HTTP que no están especificadas

- No es muy fácil de programar en el actual estado de desarrollo

- No se necesita de una especificación para descifrar el trafico no encriptado

- El generar protocolos eficientes no fue un criterio de diseño

- Multi-channels y multiplexing no están actualmente soportadas

- Se menciona la posibilidad de multi-agent, procesing path, sin embargo no están lasespecificaciones en la versión 1.1

- La habilidad de host a otros protocolos no se aplica directamente

- Seguridady autentificaciónno estándirectamenteespecificadas,perosi sonflexibles a la horadeimplementar.

- Envelope, request y response son documentos XML.

7


2.2 Evolución de los Web Services.El conceptocentraldeWeb Services:computaciónorientadaa los servicios,quedeterminanun nuevoparadigmadeprocesosdecreacióndeaplicacionesaltamentedistribuidas.Sonaplicacionesmodulares,queseautodescriben,puedenserpublicadas,localizadas,e invocadasdesdecualquierlugardela WEBo dentro de una Intranet.

El modelode WS potenciael desarrollode aplicacionesdistribuidas.Por ejemplouna compañíadealquiler de cochespuedeasociarsu sistemade reservason-line con el sistemade aerolíneasy loshoteles.De tal maneraque un viajero puedeal mismo tiempo haceruna reservade un vuelo, unahabitación de hotel y un coche de alquiler.

2.2.1 Historia de la computación distribuida.

Estaevolucióntecnológicay de una búsquedade solucionesa la computacióndistribuida no es unproblema reciente.

En los 1980 los protocolosde comunicaciónno eraobjetode interésde los desarrolladores.Realizaraplicaciones que dentro de una misma máquina se comunicaran entre sí, era suficiente.

En los 1990 alcanzaronpopularidadobjetoscomo COM (ComponetObject Model) introducidoporMicrosoft y CORBA (CommonObject RequestBroker Architecture)introducidopor OMG (ObjectManagement Group).

En general,COM y CORBA son modelos para escribir y encapsularcódigo binario. Estos soncomponentesque puedenser fácilmente llamadosdesdecualquier aplicaciónque soporteCOM oCORBA. Sin embargoestosmodelosno sonfácilmenteinteroperables,de tal maneraqueCOM puedesolamente llamar a COM, y lo mismo ocurre con CORBA.

Conectarunamaquinaa otrasetransformóenunaprioridadcuandolasredeslocalessegeneralizaron.Fue entoncesque OMG estableció IIOP (Internet Inter-ORB Protocol) como el protocolo decomunicaciónparaCORBA. Microsoft creoDCOM (DistributedCOM). MastardeSunMicrosystemslanzo al mercado RMI (Remote Method Invocation).

Conestosprotocolossepuedenllamarcomponentesqueseencuentrenenotrascomputadorasa travésde la red. Estasllamadasse realizanbajo la forma de RPC (RemoteProcedureCall). Es necesarioaclarar que estos protocolos no son interoperables.

La soluciónestadisponibleparatenercomunicaciónaplicacióna aplicacióndesdecualquiermáquinaacualquierotrasin importarel sistemaoperativo,entornodelenguajes,modelosdeobjetosdistribuidos,y usandolos estándaresde Internet.Esto es un buencandidatoparaun protocolode comunicaciónuniversal.

2.2.2 Conectando Aplicaciones en la Web

Los WebServicesmanejanla interoperabilidadmedianteel protocoloestándardeXML. La necesidadde pensar en el Web site como en una función.

Web Services son aplicaciones modulares que se autodescriben,que pueden ser publicadas,localizadase invocadaso usadasdesdecualquier parte en la Webo dentro de cualquier red local,basadas en los estándares abiertos de Internet.

8


Ellos combinanlos mejoresaspectosdelos componentesdeprogramación,y programaciónWeb,y sonun paqueteen la forma de módulos,quepuedenserreutilizados,sin preocuparnosacercade cómoelservicio esta implementado,o aún en que lenguaje,sistemaoperativo,o modelosde componentesfueronusadosparacrearlos,asícomoel consumidory desdesupuntodevistaesuna“caja negra”.Sonaccesibles vía los protocolos de Internet como HTTP y SMTP, y basados en XML.

XML y SOAP son la base tecnológica de la arquitectura de los Web Services.

SOAP (Simple Object AccessProtocol) es un protocolo de mensajesentre computadoras.SOAPespecifica el formato de mensaje que accede e invoca a los objetos, mas que un objeto en particular.

En Mayo del2000,sedaa conocerSOAP,por W3C[2]. Lasempresasquesejuntaronparapresentarala W3C lasespecificacionesdel protocolofueron: Ariba Inc., CommerceOneInc., CompaqComputerCorp, DevelopMentor Inc, Hewlett-PackardCo., IBM Corp., IONA TechnologiesPLC, LotusDevelopmentCorp.,Microsoft Corp.,SAP AG, y UserlandSoftwareInc.. Estoesun buensignode laindustriaparaaceptare implementarestándaresbasadosen protocolointeroperables.Actualmenteesteprotocolo esta siendo desarrollado por el XML Protocol Working Group de la W3C, en la versión 1.2.

2.3 Arquitectura de los WSHay 3 conceptos básicos que son : descubrir, describir e invocar.

Desdeel punto de vista del consumidor,tendrá primero que encontrarloo descubrirlo.Luego elconsumidortendráqueaprenderacercadel WebServiceo sudescripción.Finalmentepodríadisponero tener la necesidad de invocarlo, suministrando los elementos de entrada y recibiendo los elementos desalida del mismo.

Estosconceptoscontienenel protocolo SOAP con varias extensiones.El Messagebuilding block,situadoen el topede la capade transporte,el cual consistede un protocolode transporte,talescomoHTTP y SMTP.

SOAP

XML

Att

ach

men

ts

Ro

uti

ng

/In

term

edia

ries

Rel

iab

le M

essa

gin

g

Sec

uri

ty

Co

nte

xt/P

riva

cy

Tra

nsa

ctio

ns

Qo

S

Message / Wire

( I nvocation)

WSDL

Structure XML

Process Flow

and Pattern Description

(Workflow, Orchestration)

RDF (meta data)

Description

Semantic Web

UDDI

I nspection

Discovery

Estemarcono esmuy restrictivoa la tecnologíaquepuedeserusadaparaimplementarWS, y no

9


limita a los desarrolladoresa un producto particular de un vendedor.Significa que puede serimplementadocon varias tecnologías,tal como Java en Linux o Visual Basic y Vicual C++ enWindows.

Esto se amolda a las situacionesde las empresas,si por ejemplo solo se quiere crear unacomunicaciónde aplicacióna aplicación,solo alcanzacon usarSOAP,sin la necesidadde los otroscomponentes,y WS Frameworkpuedenser implementadosen cualquierlenguajede programación.Algunos proveedores :

HP y e-Speak ,

IBM Dynamic e-Business,

Microsoft .NET Platform and Framework,

Sun Microsystems and Sun ONE

Desdeel proveedor,la primerainteracciónesconel bloquedeInvocación,y luegoconlos bloquesde Describir y Descubrir.

2.3.1 Invocación

Aquí SOAP,esel componenteclaveparala arquitectura.Es un protocolode formatode mensajeextensible y se puede colocar en el tope de los protocolos de HTTP y SMTP.

2.3.1.1 SOAP

SoportandoSOAP, los Web site, puedenaccederprogramáticamentea otras computadoras,sinnecesidad de intervención humana y anexarlo como servicio en sus propias aplicaciones.

XML es usadopara definir el formato del mensaje,envelope,mecanismosde RPC, y HTTP ySMTP definen los mecanismos de transporte para los mensajes.

SOAP es un protocolo simple. Con pocaslíneasde código, un parseadorXML, y un servidorHTTP, sepuedetenerun SOAPobjectrequestbroker(ORB). Un ORB esun servicioqueasisteen lainvocación objetos, manejando el tiempo de vida, realizando pooling, manejando performance y demás.

SOAPesextensible,por el usode XML. Ningún otro protocologarantizaquepuedaseusadoentodas las situaciones,todas las veces.También estableceun framework para enviar mensajesoconducir comunicaciones del tipo RPC.

SOAP trabajacon la infraestructurade Internet.No hay que hacerconfiguracionesespecialesenrouters, firewall, proxy servers,para que SOAP trabaje. UsandoHTTP se vuelve muy fácil dedesarrollar, saltando los aspectos de seguridad.

Variosproveedoresy organizacioneshansoportadola implementacióndeSOAP.W3C hadefinidoa SOAP como una especificación,y ningunaorganizacióno un simple proveedortendráel controlsobreSOAP,por lo tantose ha convertidoen otro estándar de Internet,talescomoHTML, XML,HTTP y SMTP (ver [2],[3]).

SOAPno reemplazaa CORBA, DCOM o RMI. No tieneun modelode objetosperohabilitaa lasaplicaciones al uso de varios modelos de objetos y lenguajes.

10


2.3.1.2 SOAP Message

Los mensajesson fundamentalmenteen una dirección, desdeun “emisor” (cliente) hacia un“receptor” (servidor), y las comunicacionesson del tipo request/response.Todos los mensajessondocumentosXML consupropioesquema,queincluyesuspropiosnamespaces,elementos,y atributos.SOAP define 2 namespaces: envelope, encoding. No puede tener DTD asociados.

SOAP message consiste de 3 secciones: envelope, header y body.

- envelope : elemento raíz del mensaje.

- header: información de identificación del contenido.

- body: es el contenido del mensaje.

(para una información completa ver Apéndice - SOAP Message)

Extensionesal protocolo,puedenserhechasadicionandomódulosde funcionalidad.Esteenfoquepermitea los desarrolladoresusarlos módulosy funcionalidadqueellosnecesitan,sin la necesidaddetener que implementar la totalidad de estos. En pocas palabras el protocolo puede ser extensible.

Algunas de las extensiones que pueden ser deseables en los proveedores :

- Attachments- La posibilidadde incluir un documentono XML, o archivobinario.La posibilidaddeenviardocumentosdefax, legales,imágenesdemedicina,dibujosdeingeniería,o cualquierotrotipo de imágenes, codificadas en Base64

- Routing/Intermediaries– Relacionadasal proceso de rutear mensajesSOAP a través deintermediarios.Estoofrecela posibilidaddeagregarvariosWS y ofrecerloscomopartedenuestropaquete.Estoesunamanerade hacera los WS escalables,a travésdel direccionamiento,inclusohacia múltiples servidores

- Reliable Messaging– ¿Cuandoun servidor envía un mensaje,cuanto tiempo esperapor larespuesta? ¿Que puede pasar si dos o más veces el mismo mensaje es enviado?

- Security – Dar un marco de seguridada la comunicación.Algunos de los aspectospodríanseraplicarSSL,firma digital, etc.XML Signaturenosayudaa responder:quienenvíael mensaje,si elmensaje fue alterado en la ruta. (ver detalles en Apendice - XML Signature).

- Quality of Services– QoSesunamedidaquepuedesercomparadacon el númeroo calificacióndadaa los ASPo ISP,quemidela calidaddel servicio,un conceptosimilar puedemanejarseparaalos Web Services.

- Context/Privacy- Referenciaa guardarel contextoy privacidad,del entornode los usuarios.(Platform for Privacy and Preferences (P3P)).

- TransactionSupport– Permitir que un grupo de operacioneso accionesse comportencomo sifueran una simple unidad (o todo falla o todo es un éxito).

2.3.2 Descripción

La descripciónde un WS, es la descripciónde los mensajesque se puedenaceptary generar,

11


fundamentalmenterealizadapor el WSDL (WebServicesDescriptionLanguage),el cualdefineciertosXML Schemas y namespaces.

La definición de la estructuracomienzacon un XML Schema,que provee una maneradeespecificartiposdedatos,desdelo mássimplecomointegero string,a lo máscomplejocomoarrays,yotrosdefinidospor el usuario.El siguientenivel es la descripcióndel servicioen formatoXML, quedescribe los servicios de red.

La actual especificacioncontiene bindings a SOAP, HTTP, y MIME. (a la fecha no estacompletamente especificado por la W3C, ver Apendice - WSDL)

2.3.3 Discovery

Una vez conocida la forma de invocar un WS y su descripción, se necesita una manera de permitir aotros encontrarlo. UDDI (Universal Description, Discovery and Integration) describe como unproveedorpuedeanunciarla existenciadeun WS. Un consumidorpuedeencontrarla existenciade unWS, a través de categoría.s

El siguiente paso es ver los detalles, tales como descripción, proceso, contrato.

Web Service Requester

UDDI Service

Web Service Provider

Socio de negociosu otro sistema 2

Servlets JAXR

Documento WSDL

1

PUBLI SH

FI ND

BI ND

firewall

3 4

SOAP Request

SO

AP

Req

ues

t

SO

AP

Req

ues

t

SOAP Request

RecuperarDef inición en

WSDL

Regist rar Web Service(en t iempo de

desarrol lo)

I nvocar Web Service

Encont rar Web Service

Conceptos publish – find – bind en los Web Services

12


2.4 WSDL : Web Services Definition LanguageWSDL es usadopara describir serviciosWeb por parte de las empresas,de tal forma que los

clientespuedanaccedera ellos y utilizarlos. Proveeinformaciónde los distintosmétodosqueel WSbrinda, muestra como accederlos y el formato que deben tener los mensajes.

WSDL esun formatoXML quedescribelos serviciosde red comoun conjuntode endpointsqueprocesanmensajescontenedoresde informaciónorientadatantoa documentoscomoa procedimientos.Lasoperacionesy los mensajessedescribendeformaabstractay despuésseenlazana un protocolodered y a un formato de mensajeconcretopara definir un endpointde red. Los endpointsconcretosrelacionadossecombinanen endpointsabstractos(servicios).WSDL esextensible,lo quepermiteladescripcióndeendpointsderedy susmensajes,independientementedelos formatosdelos mensajesoprotocolos de red utilizados para comunicarse.

Estaversióndel lenguajeWSDL esun primerpasoqueno incluyeun frameworkparadescribirlasreglasde composicióny organizaciónde los endpoints.Un frameworkcompletoque describatalesreglasdebeincluir mediosparacomponerserviciosy mediosparaexpresarel comportamientode losservicios,esdecir, reglasde ordenaciónparaenviar y recibir mensajes.La composiciónde serviciosdebeser de escriturasegurapero tambiéndebepermitir pasarreferencias,siendolas referenciasdelservicio intercambiadasy enlazadasen tiempo de ejecución.Este último factor es clave para lanegociaciónde enlacesen tiempo de ejecucióny la capturadel comportamientode servicios dereferencia y de intermediarios.

Los autoresde la especificaciónWSDL deseanpublicar versionesrevisadasde WSDL y/odocumentosadicionalesque incluyan un framework paracomponerserviciosy un framework paradescribir el comportamiento de los servicios.

Para una especificación completa de WSDL ver Apéndice - WSDL.

2.5 UDDI : Universal Description, Discovery and IntegrationUDDI es un proyectopropuestopor Ariba, Microsoft e IBM. Es un estándarpara registrary

descubrir los WS. La idea es una registración en el registro de empresas UDDI, un servicio centralizadoy replicadoa distintos nodosen forma regular,quedandodisponibleparaser descubiertapor otrasempresas.

Para una especificación completa de UDDI ver Apéndice - UDDI.

Para una especificación del funcionamiento de WSDL con UDDI ver Apéndice – WSDL y UDDI.

2.6 Otras tecnologías relacionadas

2.6.0.1 EbXML

Es una iniciativa establecidapor UN/CEFACT (United NationsCenterfor TradeFacilitation andElectronic Business) y OASIS (Organitatio for the Advancement of Structured Information Standards).

EbXML antecedea UDDI. La razónparaebXML fue desarrollarespecificacionesXML paraelintercambiocomercialy crearun simplemercadoelectrónicodondelasempresasdecualquiertamañoy ubicación geográficapodrían encontrary conducir negociosa través de mensajesbasadosendocumentos XML.

13


Para más información ver www.ebXML.org

2.6.0.2 JAXR

JARX o JavaAPI for XML Registries,proveeunaAPI paraaccedera XML basadosen registrosdistribuidos.Estarespaldadapor Suny fue originalmenteparaaccedera ebXML, y forma partede laAPI JAXM (Java API for XML Messaging), el cual define una API para mensajes basados en XML.

Para más información ver java.sun.com/xml/xml_jarx.html o jcp.org/jsr/detail/093.jsp

2.6.0.3 DSML

Directory ServicesMarkup Language,es un marco para describir la estructuray contenidodeinformación de servicio de directorio.

Estainformaciónesrepresentadaen un documentoXML y defineun esquemaenel cual establecedirectoriospara publicar información que puedeser compartidavía un protocolo estándar(HTTP,SMTP)

Para más información ver www.dsml.org

2.7 Implementaciones y Herramientas.Pesea ser una tecnologíaemergente,existen actualmenteun variado y crecientenúmero de

implementacionesy herramientasdisponibles.A continuación,se enumeranalgunasde las masimportantes y sus principales características.

2.7.1 Microsoft SOAP Toolkit 2.0

La apuestadeMicrosoft a estatecnologíahaquedadoclaraal presentarsunuevaplataforma.NET,la cual soporta fuertemente XML y SOAP.

El Microsoft SOAP Toolkit 2.0 consiste actualmente de tres APIs COM, divididas en:

- Alto nivel: objetos que simplifican el RPC SOAP a través de proxies y stubs, basadosprofundamente en el meta data de XML. Utiliza la API de bajo nivel para hacer este trabajo.

- Bajo nivel: objetosqueaccedendirectamenteal transportey la estructuradel mensajeSOAP,sinbasarse en el meta data de XML.

- SMO (SimpleMessagingObject):objetosquevuelvenfácil deusarmensajesSOAPquecontienenXML, en lugar de tener el overhead del RPC

Adicionalmentea las APIs, hay numerosasherramientasy utilidades que proveen una grancomodidad para el desarrollo, como por ejemplo:

- WSDL Generator: un wizard para generar el meta data XML derivado de un objeto COM, el cual esusado frecuentemente junto con la API de alto nivel.

- WSDL and WSML API : una API adicional para la lectura y escritura de meta data XML

- MSSOAPT: un utilitario para debuggear y tracear el progreso de los request y response del SOAP

14


La plataforma.NET proveeun servidorde Web Services,basadoen el InternetInformationServeryASP.NET

2.7.2 IBM Web Services Toolkit

El IBM WebServicesToolKit (WSTK) esun kit dedesarrollodesoftwarequeincluyeun run-time,demosy ejemplosparaayudarenel diseñoy ejecucióndeaplicacionesbasadasenWebServicesque puedenautomáticamenteencontrarseunasa otrasy colaboraren transaccionesde negociossinprogramaciónadicionalo intervenciónhumana.Proveeejemplossimplesde Web Services,así comodemostracionesdecómopuedentrabajarjuntaslastecnologíasemergentesestándar,talescomoSOAP,WSDL y UDDI.

WSTK exhibela tecnologíaemergenteenWebServicesy esunabuenaforma decomprenderuna de las especificacionesmas recientementeanunciadaspor IBM. Sin embargo,un entornodedesarrollode alto nivel paraWeb Servicesexiste: IBM's WebSphere Studio Application Developerpermitela creación,construcción,testeo,publicacióny discoveringde aplicacionesbasadasen WebServices que soportan UDDI, SOAP, WSDL, y XML.

A modo de comentariode la utilización de éstaherramientase ha comprobadoque algunascaracterísticasbásicassonlimitadas.Por ejemplo,la generaciónde archivosWSDL sólo esposiblea

15


partir de Java Beans.

Por mas información sobre WSTK., ver [4].

2.7.3 Otras implementaciones de SOAP

Si bienno fueronevaluadasparaésteproyecto,existenactualmenteimplementacionesdeSOAPpara Perl, C++, Phyton y PHP. Por mas información, ver [5], [6], [7] y [8].

3 SOAP : Simple Object Access Protocol

3.1 IntroducciónSOAPestadescriptoenunanotaa la W3C.,presentadopor Microsoft, IBM, y UserLandSoftware

el 8 de Mayo de 2000. La nota describe la versión 1.1 del protocolo.

La idea detrásde SOAP es la mismaque RPC.Tambiéndefineun protocoloparallamadasamétodos remotos, sin embargo SOAP incluye :

- SOAPespecificainformaciónadicionalincluidaenel documentoXML, quedescribeel contenidoy como podría ser procesada.

- no se asocia fuertemente con HTTP

- define la especificación de algunas estructuras en XML, tales como arrays.

- el modelo es descentralizado, esto significa que puede ser procesado por varios intermediarios

- tiene características especificas para operaciones clásicas de RPC con parámetros in/out, etc.

3.2 SOAP y Web ServicesSOAPnoesel únicoprotocoloparael usodeWS.Estospuedenserusadosa travésdeXML-RPC,

operandosimplementesobreHTTP GET, sin quepor ello tenganmenoscomponentes.PeroSOAPhasidoaceptadopor proveedoresy desarrolladoresindependientescomoun estándar,el cualesmejoradotodo el tiempo. La primera versión fue liberadaen 1999 y fue un resultadode desarrolladoresdeMicrosoft, DevelopMentory UserLand.SOAP1.1 fue liberadael 8 deMayo del 2000,comounaNotepor la W3C, con la contribución de IBM y Lotus.

Para ver una completa lista de implementaciones ver [9]

3.2.1 SOAP Message Exchange Model

Define un modelo para el intercambio de mensajes, en el cual intervienen los siguientes conceptos :

3.2.1.1 XML Documentos como Mensajes

El conceptofundamentales el uso de documentosXML como mensajes,tal como en el casodeSOAP.Estoproveevariasventajas.Puedesercompuestosy leídospor desarrolladoresconeditoresde

16


textos, hacer el proceso de depuración más simple, y trabaja en las mayoría de las plataformas.

3.2.1.2 Emisor y Receptor

En el intercambiodemensajeshaydospartesinvolucradas:emisory receptor.Estaoperacióneslaconstrucción básica de bloques de SOAP y es la unidad mas pequeña de trabajo.

Los requerimientosmáscomunessonel intercambiodemensajesenparesrequest/response.Esteesel métodoSOAPusadoconHTTP y/o RPC,el intercambiobásicoone-way.Requerimientoscomplejosde intercambio se componen construyendo cadenas de mensajes.

3.2.1.3 Message Chains

El intercambiode mensajespuedeserrealizadocomounacadenade entidadeslógicasquepuedenprocesarlos mensajes.Esteconceptode unaentidadlógica querealizaalgúnprocesode un mensajeSOAPesreferidacomoun endpoint, el cual actúacomoreceptorde mensajes.La responsabilidaddeun endpointesexaminarun mensajey removerla partequefue direccionadahaciaeseendpointparaproceso.Un endpoint puedenfuncionar tanto como receptoro emisor, pasandomensajesa otrosreceptores (intermediarios).

3.2.1.4 Endpoints en Funcionamiento

Pensandoel SOAPen términosde endpoints,ayudaa comprenderla flexibilidad de los mensajesSOAP.Todoslos enpointsdebendemanejarmensajesenciertamanera,no importaqueruta tomaunmensajeo comomuchosendpointspuedeprocesarlos.Hay 3 pasosqueun endpointdebetomarparaconformar la especificación:

1) Examina el mensaje, para ver si contiene cualquier información direccionada hacia el.

2) Determinarcualesdelaspartesdireccionadashaciaesteendpointsonobligatorias.Si el endpointpuede manejarla o rechazarla.

3) Si esteendpointesun intermediario,entonceselimina todaslaspartesidentificadasenel primerpaso antes de enviar el mensaje al siguiente endpoint.

3.2.1.5 Diseño Modular

SOAP esabiertoy extensible.Esto significa quetodoslos siguientesescenariossonaceptadosypermitidos por la especificación de SOAP :

- Un aplicacióndesktopcomponeun mensajeSOAPquerequiereunacantidadde stocky lo envíacomo el body de un HTTP POST. Un WS recibeel POST, procesael mensajey retornaunmensaje SOAP en el HTTP response.

- Un procesoen el servercomponeun mensajeSOAP, que describeun eventodel sistemay lodifunde a otro servidor en la red.

- Un desarrolladordesoftware,queenvíaun mensajecomoun e-mail attachment(parecidoa serunmensaje en one-way)

17


SOAP soportatan diferentesescenariosgraciasa un diseñomodular.Las especificaciones,deprincipio a fin, sondejadasabiertasparafuturasextensionesdel protocolo.SOAPesextensibleen lassiguientes áreas:

Message Syntax – el formato tiene un área aparte para extensiones que sean adicionadas

Data – SOAPpuedecontenercualquiertipo dedatos.Proveeunmétodoparaserializacióndedatos,pero las aplicaciones pueden definir sus propias reglas.

Transport – No definecomosontransportadoslos mensajesduranteel intercambio.SOAPmuestracomo podríanser intercambiadossobreHTTP, pero cualquierprotocoloo métodopuedesustituir aHTTP.

Purpose – SOAPnodefinequeeslo quehaydentrodelmensaje.Hay unadiferenciaentrelos datosy su propósito o finalidad.

3.2.2 SOAP y HTTP

SOAP especificael binding sobreHTTP, básicamenteun tunneling, segúnel modelo request-response.El HTTP tunneling se refiere a un wrapper del protocolo de comunicaciónHTTP. Lahabilidadde crear protocolosque se colocanen el tope del protocolo estándarHTTP se hacemasimportantequenunca.La mayoríade las redescomercialesoptimizanel trafico del protocoloHTTP,permitiendocualquierprotocoloconbaseenHTTP. Estoa suvez potenciala seguridadde lasredesatravésdelos firewall, los cualespermitenHTTP tunneling.De otramaneraseintroduciríanpotencialesriesgos al tener que habilitar otros puertos en los firewalls.

- el Content-Type del header de HTTP debe especificar “application/soap”

- HTTP POST es solamente para el tipo request

- SOAPAction en el HTTP header es requerida para indicar el intento de request

- un requestSOAPexitosoesindicadoporun responseconstatusHTTP y codigo2nnsiendonn unnúmero entre 00 y 99

- unerroresrespondidoconel codigodestatus500y el mensajeInternalServerError,conteniendoel Fault element.

3.2.3 SOAP Message

Un mensaje SOAP consiste de un documento XML. El elemento raíz es siempre el <Envelope>.

18


El elemento<Envelope>puedecontenerunelementoopcional<Header>,el cualdebeserel primerhijo inmediato.El elemento<Header>puedetenermúltiples headerentries.Anticipa el caminodelmensaje SOAP como valor agregado a lo largo del proceso.

El elemento<Body> le sigueal <Header>y es obligatorio.Es el contenidodel mensaje,con lonecesarioparaconsumirel servicio.Puedecontenersuspropioselementoshijos, llamadobodyentries.Cadaunodeestosesindependientementecodificado,y especificadoenun atributoencodingStylequeindica su uso.

SOAP definesolo un tipo de body entries,llamado<Fault>,que ocurresolo una vez dentrodel<Body> y se utiliza para indicar errores o excepciones.

Todo esto se basaen un modelo de mensajesrequest/responsecomo una forma de invocar unmétodoy pasarleparámetros.El potencialdeestoeshacerlosobreInternetusandoHTTP pararealizarla comunicación entre aplicaciones.

Paramasdetallesacercade comosonlos componentesEnvelope,Body y Headerir al Apéndice -SOAP Message

3.3 TransporteHastaahorasedetallóel contenidodel paqueteSOAP,a continuaciónsedescribirácomoseenvía

un mensaje desde el emisor al receptor. Este mecanismo se llama transporte.

3.3.1 Separación de mensaje y transporte

Unadecisiónacertadahechapor los autoresdeSOAPconsisteenla separacióndela definicióndelmensajey de su transporte.Estaesuna lista de posiblestransportesparael mensajeSOAP,algunosmas probables que otros: HTTP, SMTP, MQSeries, Raw sockets, Files, Named Pipes, Carrier Pigeon.

La mayoríade los desarrolladoresseenfocaránenHTTP comoel protocoloestándarde transportepara los mensajes SOAP.

19


3.3.2 HTTP

HTTP esel transportemasutilizado paraSOAPporqueesampliamenteaceptadoy difundido.Lacombinaciónde HTTP, el protocolode transporteestándarparala Web,y SOAP,el candidatoparaelformato de mensajeestándar,constituyeuna poderosaherramienta.HTTP hace que sea el grantransporteparaSOAP,quelos autoresaseguranquelasreglasparasuusocomotransportesonpartedelas especificaciones de SOAP.

Hay un pardereglasbásicasparael usodeHTTP comotransportedeSOAP.Losmecanismosparaenviarun mensajeSOAPsobreHTTP esel estándarHTTP POSTmétodo.Un HTTP POSTenvíaunbloquededatosa unaURI particularenun servidorWeb.En estecasoel mensajeSOAP,estebloquede datosesel propio mensajeSOAP.Porqueel mensajeSOAPesXML, el cabezalContent-TypedelHTTP POSTdebeser“application/soap”.Si hay unarespuestaal mensaje,esteretornaunarespuestaHTTP .Ej. :

20


POST /timeserver HTTP/1.1

Content-Type: application/soap

Content-Length: ###

SOAPaction: “urn:mysoaptime”

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'

soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>

<soap:Header>

<h:from xmlns:h='http://www.mysoap.com/Header'>[email protected]</h:from>

</soap:Header>

<soap:Body>

<w:GetLocalTime xmlns:w='http://www.mysoap.com/timeserver/'>

<w:country>Uruguay</w:country>

</w:GetLocalTime>

</soap:Body>

</soap:Envelope>

Lasprimeras4 líneasdeesteejemploestánrelacionasal HTTP transport.La primer líneacontieneel métodoHTTP, y la URI indica el lugar del endpoint.Esteejemplorepresentaun mensajeSOAPrequestenviado a la URL http://www.mysoap.com/timeserver. La primer línea también indica laversión 1.1 de HTTP usadaen esterequest.Las siguientes3 líneasson el cabezal HTTP. Las 2primerassonestándaresdeHTTP. Content-Typeindicael tipo MIME del contenidodel POST.Todoslos mensajesSOAP deben usar application/soap.Content-Lengthdice el tamaño en bytes delcontenido.El último cabezal,SOAPAction,esespecíficode SOAP.El mensajepor si sólo no cambiaporqueestasiendotransportadopor HTTP, SOAPActionheaderno cambiaporqueestáenviandounmensaje SOAP.

3.3.3 SOAPAction Header

La especificaciónSOAP define un cabezaladicional a ser usadocuandoel mensajeSOAP estransportadosobreHTTP, y estecabezalesel SOAPActionHeader.Estoesun indicio al servidorqueun particularHTTP POSTcontieneun mensajeSOAP,y el valor del cabezalesla URI queindica lasintencionesdel mensajeSOAP. Esto le permite al firewall y otros servidoresrealizar procesoscondicionalesbasadosenla presenciadel SOAPActionHeader.La necesidaddeSOAPActiondependede cómo nuestro endpoint está implementado.

3.3.4 Status Code

HTTP retornaun códigode status.Estossonenteros,y estánseccionadosdentrode clasesde 100elementos.Por ejemplo,cualquieraen el rango200-299indica éxito. SOAPcolocaun requerimientosobreel transportedeHTTP cuandoesteesusadoparaintercambiarmensajes.Si la respuestacontieneuna falla, entonces el código de status debe ser 500, que indica un Internal Server Error.

21


4 Casos de Aplicación

4.1 IntroducciónA los efectos de probar esta tecnología se presentarán 2 casos puntuales de aplicación.

Los casos a implementar son los siguientes:

- Transacciones: Se trata de implementar una típica transacción comercial con fuertesrequerimientos de seguridad.

- Cursores: Setrataderecorreren formaremota(sobreunaLAN e Internet)unacoleccióndedatosmedianteun cursor.Comoejemplossepuedenplantearun cursordeBasedeDatos,laspaginasdeun reporte o los ítems de un catalogo.

4.2 Presentación del ProblemaA continuación se presentara de forma detallada los problemas existentes en los casos a resolver.

4.2.1 Transacciones

El objetivo es probarestatecnologíaen escenariosen dondelos serviciostienen un alto gradodeseguridad,tales como los encontradosen el contexto de transaccionescomerciales(por ejemplo,serviciosen dondesepermitetransferirdinerode unacuentabancariaa otra,o realizarun pedidodecompra). Para esto se deben contemplar las siguientes requisitos de Seguridad:

4.2.1.1 Confidencialidad de la transmisión

La transacción puede contener información confidencial, por lo que el contenido de la comunicación nopuede ser entendible por una tercera persona que la pudiera interceptar.

4.2.1.2 Asegurar la integridad

Es necesarioasegurarquela informacióntransmitidano puedasermodificada,ya seapor el servidor(parabrindar garantíasal cliente), por el cliente (parabrindar garantíasal servidor),por un agenteexterno que interceptó y modificó la misma o por errores en la transmisión.

4.2.1.3 Autentificación

Involucradosclasesde requerimientosde seguridad: Una es la identidaddel creadordel mensaje,lacualesllamadaautentificacióndel mensaje.La otraesla autentificacióndela identidaddequiénenvíay de quién recibe el mensaje, la cual es llamada sender/recipient authentication.

Desdela perspectivadelqueenvíaenmensaje(sender),significaasegurarla identidaddel querecibeelmensaje autenticado

Desdela perspectivadel querecibeel mensaje(recipient),significaasegurarla identidaddel queenvíadel mensaje y el contenido del mensaje autenticado.

22


4.2.1.4 Asegurar el no repudio

Debe garantizarse que ninguno de los participantes en la comunicación pueda negar parte en la misma.

4.2.1.5 Evitar copias de transacciones como válidas (replay)

Se debe poder distinguir entre una transacciónenviadapor el cliente, y una copia de la mismatransacción, haya sido reenviada por error o por una tercera parte con fines fraudulentos.

4.2.1.6 Evitar el reenvío de transacciones (forward)

Esnecesarioevitar quela transacciónseareenviadaa un destinatarioqueno seael deseado.Conestose deseaevitar el casoen que un receptortrata fraudulentamentede reenviaruna transaccióna otroreceptor, y lo que sucede si esta tercera parte reclama que ha recibido la transacción del emisor.

4.2.2 Publicación de Cursores

Una de los requerimientosdel proyectoconsisteen recuperarcoleccionesde datosa travésde WS,comopor ejemploen el casode recorrerun reporteo cargarun combo.A tal fin, puedeconsiderarseesto como un caso particular del recorrido de un cursor, por ejemplo los cursores de un RDBMS.

Los objetivosdeestecasoa implementarsonlos derecorrerun cursordeformaremotay cuidandolossiguientes detalles:

4.2.2.1 Mantenimiento de Estados

Para recorrer un cursor se debe mantener en el servidor la posición en la que se encuentra el mismo.

4.2.2.2 Consideraciones de Performance

En el casode recorrergrandescantidadesde datosseráimportanteque la respuestadel sistemaencuanto a performance sea aceptable.

4.2.3 Perfil del producto

Esteproyectose desarrollaen el marcodel productoEDF (EnterpriseDevelopmentFramework), elcual consisteen un ambientede interoperabilidadentre un conjunto de técnicasy productosquepermiten el desarrollo de una nueva generación de aplicaciones realmente centradas en la red.

Entre las técnicas se encuentran: ambientes cliente-servidor de múltiples capas, workflow,push/publish/subscribe, CIM (Customer Interaction Management), formularios electrónicos, OLAP.

23


4.2.4 XForms

Dentro de la capade presentación,una forma habitualde interaccióncon el usuarioes a travésdeformularios. Últimamente se han remitido propuestasa la W3C para estandarizarel modelo deformularios,haciendohincapiéen la separaciónde la presentacióndel formulario y su contenido.Actualmente, existe una propuesta de definición en este sentido llamada XForms [10].

Ideasoft implementaestapropuestaen JForms,un motor de ejecuciónde formularios.Uno de losobjetivosdeesteproyectoconsisteenproveerinfraestructuraparapermitir la ejecuciónde formulariosmedianteWeb Services.Parael casode transacciones,un formulario que contengainformacióndetransferenciade dineroentrecuentasbancarias,puedeconsiderarsecomounatransacciónelectrónica.De igual manera,por ejemploel llenadodevaloresdeun comboenun formularioo el paginadodeunreporte puede verse como la recorrida de un cursor.

24


4.2.5 Plataforma y herramientas

Ideasoftutiliza fuertementela plataformaJava,junto con todaslas herramientasrelacionadasa ella.Asimismo,sele dio prioridada la utilizacióndeherramientasopensource,talescomoTomcat,ApacheSOAP, etc. La única excepciónadmitida fue la utilización de la XML Security Suite de IBM, unproductoparafirmasdigitalesdearchivosXML. Hoy endíaunaalternativaopensourceesel Apache-XML-Security-J, la cual no fue utilizada porque al momento de comenzar la fase de implementación nohabíasido liberada.La primeraversióncorrespondea febrerode 2002, y actualmentese encuentradisponible la versión 1.0.3. Para mas detalles, ver Apéndice – Plataforma y Herramientas

25


5 DiseñoEn estasecciónse presentarandistintaspropuestastecnológicas,detallandolos requerimientosquesatisfacen.

5.1 Transacciones

5.1.1 Firma Digital

La firma digital (SOAP-DSIG)definela sintaxisy procedimientosparafirmar digitalmentemensajesSOAP y validar su firma. La firma digital permite que los mensajesseanautenticadoscontra unusuario.Estatecnologíaha sido implementadaen productoscomercialespor IBM, Microsoft y otros.Una transacción del tipo comercial requiere del no repudio. SOAP-DSIG tiene este propósito.

EspecíficamenteSOAP-DSIGdefineun formatode datosparacalculary agregarla firma digital a undocumentoXML. Unafirma digital sebasaenunacriptografíadeclavepública,y generalmentetomamuchomástiempocomputarunafirma enlugardeun hasho un MAC (MessageAuthenticationCode)de clave simétrica.El emisory receptorno necesitancompartiruna clave secreta,el servidorpuedeidentificar al creador del mensaje, lo cual constituye una garantía de que la firma es del creador.

La firma digital de un documentoXML se representapor el elementoSignature, el cual tiene lasiguienteestructura("?" denotaceroo unaocurrencia;"+" denotaunoo masocurrenciay "*" denotacero o mas ocurrencias):

<Signature>

<SignedInfo>

(CanonicalizationMethod)

(SignatureMethod)

(<Reference (URI=)? >

(Transforms)?

(DigestMethod)

(DigestValue)

</Reference>)+ </SignedInfo>

(SignatureValue)

(KeyInfo)?

(Object)*

</Signature>

En un mensajeSOAPel elemento<Body>contienelos datosdela transacción.Estossonfirmados,a partir de su firma segenerael elemento<Signature>,el cual esincluido enel headerde SOAP.Laclave usadapara firmar el mensajees identificadapor el elemento<KeyInfo> la cual garantizala

26


identificacióndel usuarioque creo el mensaje.Finalmenteel mensajeSOAP firmado es enviadoalservidor. Para mas detalles, ver Apendice - XML Signature

La firma digital permitesolucionarel problemadel posiblerepudiodeunatransacción,y aseguralaintegridaddelos datostransmitidos.Parasatisfacerlos requerimientosdeno repudioesnecesariotenersimultáneamentela autentificacióndel mensajemedianteel uso de firma digital y cumplir con losrequerimientos de autentificación del emisor. Esto último se consigue mediante SSL.

5.1.2 SSL

SSLesun protocoloampliamenteusadoparatransmitirdocumentosHTML desdeun sitio seguro,y aseguraal usuario una comunicaciónencriptadacon el sitio. Es normalmenteutilizado enaplicaciones B2C (business-to-costumer).

La negociación del SSL se puede resumir a grandes rasgos en estos pasos:

Tantoel clientecomoel servidorintercambianlos certificadosX.509 paraprobarsuidentidad.Loscertificados son verificados comprobando la validez de las fechas y la firma digital de una Autoridad deCertificados (organizaciónque emite certificados) conocida. El cliente generaaleatoriamenteunconjuntode clavesqueseránusadosparala encriptación.Las clavessonencriptadasusandola clavepública del servidor y son enviadasal servidor de forma segura.Se usanclavesdiferentesen lacomunicación cliente - servidor que en la del servidor al cliente, con un total de cuatro claves.

Seacuerdaun algoritmo de encriptación(paramantenerla privacidadde la comunicación).Paramas detalles, ver [11]

SSL asegurala confidencialidadde la comunicacióny la autentificacióndel servidorfrentea losclientes y (opcionalmente) de los clientes frente al servidor.

Porotrapartecabedestacarquefue desechadala alternativadeutilizar XML encriptado[12], puesal momentodeescogerunasolución,la especificaciónseencontrabaenestadodeWorking Draft, porlo que se opto por una tecnología madura y estándar.

5.1.3 Manejo de tickets

Paraasegurarquetodoslos mensajesválidosseandistintos,seintroduceel conceptode ticket. Unticket constabásicamentede un númerode secuencia,el cual sirve paranumerarlos mensajes,untimestamp,que indica el momentoen que es enviadoel mensaje,y un identificadordel destinatario(Identity Recipient).El númerode secuenciay el identificadordel destinatariosongestionadospor elservidory luegomanejadospor el cliente,mientrasqueel timestampesdirectamenteagregadopor elcliente. Estos datos son mantenidos para cada sesión.

Al manejarticketsseevitael replaydemensajes,yaquecadamensajetendránumerosdesecuenciay timestampsdistintos,y el forwarddemensajes,ya quecadaticket identificaal destinatarioenel quese puede ejecutar el formulario

5.2 Cursores

Parael casopuntualde recorrercursoresen formaremota,sepresentandistintasalternativasy losrequerimientos que satisfacen.

27


5.2.1 Manejo de sesiones por parte del servidor

Los WS son statelesspor definición, por lo que el mantenerel estadoa travésde los distintosrequestesunproblemano cubiertopor la especificación.Pararesolverestecaso,seenuncianal menosdos posibles opciones:

Provista por la infraestructura de Web Service:

- Usar implementacionespropietariasque resuelvanel problema,brindandoWS statefulde formatransparente, tales como las provistas por Apache SOAP 2.2 o .NET

Implementada dentro de la Aplicación:

- Construir aplicacionescliente/servidorde forma que intercambienun identificador de sesiónosimilar entrelos distintosrequest,y manejarenlasaplicacionesla administracióncorrespondientealas sesiones.

En este caso se optó por la primera opción por varias razones:

- Estafuncionalidadal serbrindadapor la infraestructuraevita la necesidaddeprogramarunalógicade manejo de sesiones, lo cual no se encuentra dentro de los objetivos de este proyecto.

- Al permitir quela infraestructurarealiceel manejodesesiones,el sistemasevuelvemasescalabley performante.

- Por ultimo seapuestaa queestacaracterísticaseapartedel estándaren futurasversiones,pueselmanejo de sesiones es algo altamente utilizado y básico en aplicaciones no triviales.

5.2.2 Benchmarks

Unadudaimplícita encualquieraplicaciónqueutilice WebServiceradicaencomoserásudesempeñoal momentodesu puestaen marcha.En estecasopor tratarsederecorrergrandescantidadesdedatosestepuntoescrucial. Por estose decidiórealizarun estudiocomparativode estatecnologíafrenteaotras alternativas propietarias (aunque posiblemente mas performantes) como ser Java – RMI.

El objetivodeestebenchmarkesconfrontarWebServicescontraRMI enel casopuntualde tenerquerecorrerunacolecciónde datosen forma remota.Seeligió RMI por serunaalternativaconociday sepuedeutilizar exactamenteel mismocódigo del cursor.Se esperaque seamasperformantepuesnoinvolucra parseo de XML y el overhead de empaquetado y transporte de datos es menor.

En particular se desea comparar :

- El recorrer los datos solicitándolos de a uno por vez.

- El recorrer los datos solicitándolos de a ráfagas (cache en el cliente).

- El desempeño en función del tamaño de las tuplas a transferir.

- La performance en una LAN y en Internet

28


6 PrototipoA continuaciónse presentala implementaciónrealizadaen baseal diseñodescritoen el punto

anterior.Primerose describirála plataformay el entornoen el que se realizó el sistema.Luego sedetallaránlas clasesimplementadasparael casode las transacciones,y por último sepresentaránlasclases implementadas para el manejo de cursores.

6.1 Estudio de PlataformaTodaslas clasesfueron implementadasen el lenguajeJava,versión 1.3 [13]. Como servidor y

contenedorde servletsse utilizó el JakartaTomcatversión3.2.1 [14]. La implementaciónde SOAPutilizada fue el ApacheSOAP 2.2 [15]. Parael manejode las firmas digitalesde XML seutilizó elIBM XML SecuritySuite [16]. Como parserde archivosXML se utilizó el Xercesv. 1.2.3. [17] ycomo procesadorde XSLT se utilizó el Xalan 2.1.0 [18]. Tambiénes necesariopara el correctofuncionamientode este producto la instalacióndel JavaMail 1.2 [19] y el JavaBeansActivationFramework 1.0.1 [20].

Para la instalación de estos componenteses necesarioun orden predefinido en el classpath,configurararchivosde Tomcaty del SOAPde apache.Tambiénsedebengenerarcertificadoscon elkeytool para que luego puedan ser tomados por el XMLSS y por el Tomcat para el SSL.

Por mas detalles de instalación y configuración Apendice – Instalación y Configuración

6.2 Modelo de trabajo de Apache SOAP sobre Tomcat

ApacheSOAP proveeun manejobásicode visualización,deploy y ejecuciónde Web ServicessobreTomcat.El accesoal SOAPen Tomcatesa travésde , en estopuntosepresentantresaccionesposibles a realizar, las cuales son:

- List: Lista los WebServices disponibles.

29


- Deploy: Agregar un Web Service a la lista.

- Un-Deploy: Borrar un Web Services de la lista de disponibles.

Para mas detalles, ver Apéndice – Administracion de Web Services con Apache SOAP

30


El modelo de trabajo del Soap sobre Tomcat es el siguiente:

Aplicación Cliente

Aplicación Servidor

Apache SOAP Parser de XML

Apache SOAP Listener(RPCRouterServlet)

Web Application Server

Registro remoto de Servicios

Apache SOAP

Parser de XML

SO

AP

Estediagramadefineel funcionamientobásicodeunainvocacióna un WebServiceutilizandoApacheSOAP, el cual es el siguiente:

- La Aplicaciónclientea travésdel ApacheSOAPLibrary creay envíaun requestSOAPal servidor().

- En el servidorWeb esrecibidoesterequestpor partede un servlet(rpcroutermapeadoa la claseRPCRouterServlet).

- Buscaenla RemoteServicesRegistryla claseasociadaal método,la instanciay por ultimo ejecutael método solicitado por el cliente.

Algunas extensionesal framework de ApacheSOAP necesitanla capacidadde interactuarcon el

31


mensajeSOAP al momentode recibirlo o enviarlo. Parafacilitar estetipo de interaccionesApacheSOAP provee la interface EnvelopeEditor, la cual consta de los métodos:

- public void editIncoming(Reader in, Writer out) throws SOAPException;

- public void editOutgoing(Reader in, Writer out) throws SOAPException;

Estos métodos serán invocados después de enviar un mensaje y antes de recibirlo:

Aplicación Cliente

Aplicación Servidor

Apache SOAP Parser de XML

Apache SOAP Listener(RPCRouterServlet)

Web Application Server

Registro remoto de Servicios

Apache SOAP

Parser de XML

EnvelopeEditors

6.3 Mecanismo de mantenimiento de sesiones (Web Services stateful)El mantenimientode las sesionesseconsiguehaciendoqueel servicioqueseestácomunicando víaHTTP seteecookiesapropiadasparamantenerla sesión.Estassoncopiadasy almacenadasenel objetoorg.apache.soap.rpc.RPCMessage.Callusadopara invocar el servicio. Si otra llamadaes realizandousandoel mismoobjetoCall, esacookieesdevueltaal servidor,manteniendola sesión.Paraesto,esnecesario configurar el cliente de la siguiente manera:

32


Call call = new Call ();

SOAPHTTPConnection shc = new SOAPHTTPConnection ();

shc.setMaintainSession (false);

call.setSOAPTransport (shc);

Cabedestacarqueel objetoSOAPHTTPConnectiondebeserel mismoa lo largode todala sesión.Si serealizaunnuevo“shc = newSOAPHTTPConnection()”, ésteestableceráunanuevaconexiónconel servidor y la información de la sesión se perderá.

6.3.0.1 Deploy del Web Services para el mantenimiento de sesiones

Paraqueel Web Servicemantengala sesión,debeserrealizadosu deploycon la opciónScopeen“Session”, en lugar de “Request”

Por mas información sobre el deploy de un Web Service,ver HIPERVÍNCULO "ApendiceXXXX.doc" Apéndice – Administracion de Web Services con Apache SOAP

6.4 Transacciones

6.4.1 Soporte de comunicación sobre SSL

Paraasegurarla confidencialidadde la información,se habilita la comunicacióncliente/servidormedianteSSL [11]. A continuación,semencionanlos pasosseguidosparaconfigurarla comunicaciónpor SSL entre el servidor y el cliente.

6.4.1.1 Configuración del servidor

ParausarHTTPconel conectorSSLenTomcat,seefectúael siguientecambioenla configuración,

33


en el archivo server.xml:

<Connector className="org.apache.tomcat.service.PoolTcpConnector">

<Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/>

<Parameter name="port" value="8443"/>

<Parameter name="socketFactory" value="org.apache.tomcat.net.SSLSocketFactory"/>

<Parameter name="keystore" value="/var/tomcat/conf/keystore" />

<Parameter name="keypass" value="changeit"/>

<Parameter name="clientAuth" value="true"/>

</Connector>

Aquí seindica queel keystoreesel fichero /var/tomcat/conf/keystore. La passworddel keystorees changeit, se especificaque los clientesse debenautentificary que el puerto utilizado para lacomunicación segura será el 8443.

Paraqueel Tomcatutilize socketsseguros,debeinstalarsela JavaSecureSocketExtensiono JSSE1.0.2 [21]. Los jars de jssedebenestaren el CLASSPATHy en $JAVA_HOME/jre/lib/ext (JAVA >1.2). Parte de la configuración consiste en editar el archivo

$JAVA_HOME/jre/lib/security/java.security

y añadir la linea

security.provider.2=com.sun.net.ssl.internal.ssl.Provider

Pordefecto,Tomcatutilizaráel certificadoquetienealias“tomcat” enel keystore.Parala creaciónde un certificado con esas características se utiliza el siguiente comando:

keytool -genkey -alias tomcat -keyalg RSA

6.4.1.2 Configuración del cliente

Para la configuración del cliente será necesario setearle al cliente 2 properties, las cuales son:

- javax.net.ssl.trustStore:Indica el camino y nombre del keystoreque contiene los certificadosconfiables para el cliente.

- java.protocol.handler.pkgs: Indica la implementación del URL handler para el protocolo HTTPS.

Ejemplo:

System.setProperty("javax.net.ssl.trustStore"," keystore_path\keystore_name");

System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");

Adicionalmentedebeagregarsecomoproveedorde seguridadla clasequeimplementael HTTPS,por ejemplo con la siguiente línea:

34


Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

Por ultimo y como sustituciónal intercambiode certificadosdel handshakede SSL, se debeingresarel certificado del servidor en el keystoredel cliente y el certificado del cliente en elkeystore del servidor.

6.4.2 Soporte de firma Digital

El soporteparafirma digital de archivosXML se brinda a travésde la API IBM XML SecuritySuite.Esteproductofue elegidodebidoqueal momentodecomenzarel proyecto,fue el quepresentómenosproblemasal realizarletestbásicos.Al día de hoy seha ampliadonotoriamentela cantidaddeopciones posibles. Por mas información acerca de las implementaciones disponibles ver [22].

El firmadode los paquetesSOAPenel clientey la verificacióndela firma digital enel servidorserealiza mediante los llamados EnvelopeEditors,mencionadosen el punto 6.1.2. Las clasesimplementadaspuedenverse en el siguiente diagrama(en fondo claro se encuentranlas clasesimplementadas por terceros, y en fondo oscuro las clases implementadas para este proyecto):

35


EnvelopeEditorAdapter

(from transport)

ClientSignedEnvelopeEditor

ClientSignedEnvelopeEditor()editOutgoing()

(from client)

EnvelopeEditor

editIncoming()editOutgoing()

(from transport)

ClientEnvelopeEditor

ClientEnvelopeEditor()editIncoming()

(from client)

ServerEnvelopeEditor

ServerEnvelopeEditor()editIncoming()editOutgoing()

(from server)

Verifier

$ VERIFY_NOTHING : int = 0$ VERIFY_SIGNATURE : int = 1$ VERIFY_ALL : int = 2

Verifier()transformMessage()getSignatureElement()hasSignatureElement()verify()getDigestValue()getSignatureValue()

(from util)

Signature

Signature()getInstance()sign()getSignatureElement()verify()getAlias()

(from util)

-ivSignature

-ivSignature

La claseEnvelopeEditorAdapteresunaclaseutilitaria queimplementala interfaceEnvelopeEditor,siguiendoel patrónAdapter[23], parabrindarunaimplementaciónbásicadelos métodoseditIncomingy editOutgoing. Cabemencionarquela implementación“por defecto”(dejandoel cuerpodel métodoen blanco) causaría un mal funcionamiento de la aplicación, bloqueando el flujo de información.

La claseClientEnvelopeEditorseencargadeenviarun mensajeSOAPsin modificarlo,y derecibirun mensajeSOAP firmado digitalmentepor el servidor,y enviarlo al cliente si la firma digital escorrecta, o en caso contrario levantar una excepción.

La claseClientSignedEnvelopeEditorse encargade firmar digitalmenteel mensajeSOAP querecibey enviarloposteriormente.Parael casoderecibir la respuestadel servidor,secomportade igualforma que ClientEnvelopeEditor, ya que hereda el método editIncoming.

Del lado del servidor,la claseServerEnvelopeEditorseencargade verificar si la firma digital delmensajeSOAP recibido es correcta,si éstecontienealguna.En casoafirmativo, ejecutael método,agregandocomoparámetroslosdatosnecesariosparaalmacenary verificar a posteriorila firma digital.

36


Estosdatospuedenseralmacenadosenunabasededatoso similar, paraevitarun posiblerepudiodelcliente.De lo contrario,si el mensajeno contienefirma digital y el métodola requiere,seretornaunaexcepción.Si no la requiere,seejecutael método.Estaclasetambiénseencargadefirmar digitalmentelas respuestasprovenientesde la ejecuciónde los métodos,para dar garantíasal cliente acercadelresultado de las transacciones.

Seimplementarondosclasesutilitarias paratrabajarcon las firmasdigitales:unallamadaVerifier,que es utilizada por las clasesClientEnvelopeEditory ServerEnvelopeEditorparaverificar la firmadigital, y una llamada Signature que es utilizada por ClientSignedEnvelopeEditoryServerEnvelopeEditor para firmar digitalmente los mensajes SOAP.

Paraobtenerlos certificadosdigitalesnecesariosal momentode firmar y verificar las firmas, seimplementóunaclaseutilitaria llamadaKeyStoreUtil,queseencargadeproporcionarunainstanciadeun certificado, a partir de un identificador. La implementaciónactual los obtiene a partir de unkeystore,o archivoen formatoJKS (JavaKey Store),peroes fácilmentemodificable.De estaformaquedaabierto el sistemaparaque en un futuro puedanser tomadosde otras fuentes,como ser unservidor LDAP o una base de datos.

KeyStoreUtil

getCertificate()getKey()

(from util)

Verifier



(from util) Signature

Signature()getInstance()sign()getSignatureElement()verify()getAlias()

(from util)

KeyStoreUtilImp

KeyStoreUtilImp()getCertificate()getKey()

(from util)

Para demostrarque es posible realizar la comprobacióna posteriori de la firma digital, seimplementó una aplicación que realiza la verificación:

37


La relación entre las clases puede verse en el siguiente diagrama:

38


Verifier



(from util)

VerificadorFrame

VerificadorFrame()main()jbInit()actionPerformed()verifyExecute()class$()

(from client)

JFrame

$ EXIT_ON_CLOSE : int = 3defaultCloseOperation : introotPaneCheckingEnabled : boolean

(from swing)

Aquí se muestrauna implementaciónen dondela aplicaciónGUI que interactúacon el usuarioinstancialocalmentela clasequerealizala verificación.A su vez, se publicó como Web Serviceunmétodo que permite realizar la verificación en forma remota, implementado en la clase VerifierWS:

39


VerifierWS

VerifierWS()verifyExecute()

(from server)

Verifier



(from util)

Parafacilitar la ejecuciónde los Web Servicesa travésde clientesJava,seimplementóunaclaseque encapsulala mayor partede la complejidadinherentea la configuraciónde la llamadaa WebServices. Estas llamadas manejan y resuelven los siguientes problemas:

- Configurar los “mapType”. Estosson los mapeosentre los objetos Javay su correspondienterepresentaciónen XML. De estamaneraes transparenteparael usuariofinal la serializacióndeobjetos java a XML y viceversa.

- setTargetObjectURI: Identificador del Web Service a utilizar.

- setMethodName: Identificador del método a ejecutar.

- setEncodingStyleURI: Identifica el Encoding a utilizar (por defecto esorg.apache.soap.Constants.NS_URI_SOAP_ENC).

- Preparar y setear el vector correspondiente a los parámetros de cada método a ejecutar.

- Setear el número de secuencia correspondiente a cada ejecución.

Estaclasesellama XFormsProxy,e implementael patrónProxy,descritoen [23]. Los clienteslainstancian, e invocan a los Web Services a través de sus métodos:

40


TestFrame

$ NORMAL_MODE : int = 0$ NRO_SEQU_MODE : int = 1$ DATE_MODE : int = 2$ APP_NAME_MODE : int = 3

TestFrame()main()jbInit()loginButton_actionPerformed()getStackTraceAsString()ejecutarButton_actionPerformed()setGUIData()

(from client)XFormsProxy

call : EServiceCall

XFormsProxy()getTicket()login()execute()prepareExecute()prepareLogin()sendExecute()sendLoginMessage()class$()

(from client)

-xFormsProxy

JFrame

$ EXIT_ON_CLOSE : int = 3defaultCloseOperation : introotPaneCheckingEnabled : boolean

(from swing)

6.4.3 Secuencia de Ejecución de Transacciones.

A continuación se detalla el ciclo de la ejecución de una transacción, y las clases involucradas.

41


En estediagramasemuestrael ciclo devida de unatransacción.Básicamente,constadeun iniciodesesión(medianteel métodologin) y la ejecucióndela transacción(medianteel métodoexecute). Enla ejecuciónde la transacciónparticipanlos EnvelopeEditors(descritosen la sección6.1.2) paralafirma y la verificación, tal como se menciona en el punto 6.1.5.

La clase WebServiceTransactionImp,que implementa la interfaces WebServiceTransactionencapsulala lógica de la ejecuciónde la transacción,y brinda la implementaciónparalos métodospublicados como Web Services, siguiendo la idea del patrón Facade [23].

42


WebServiceTransaction

execute()execute()

login()

(from server)

ControlUserImp

ControlUserImp()checkUser()

(from server)

WebServiceTransactionImp

WebServiceTransactionImp()login()execute()execute()

(from server)

ControlUser

checkUser()

(from server)

43


El detalle del deploy como Web Service puede verse en la siguiente figura:

Los campos destacables de la herramienta de deploy son los siguientes:

ID: Un URN que identifica unívocamenteal Web Servicepara los clientes.Comunmenteseutiliza el formato urn:UniqueServiceID

44


Scope: Define el tiempo de vida del objeto que respondeal request.Existen principalmentetresvalores posibles:

Request: Por cada request, se crea una instancia del objeto, se utiliza y se desecha

Session: La instancia del objeto es única durante toda la sesión

Application: Sólo una instancia del objeto es creada durante todo el tiempo de vida del

SOAP servlet

Methods: Define los nombres de los métodos que pueden ser invocados en este objeto

Provider Class: Indica la claseque brinda la implementacióndel Web Service.Estaclasedebeestar accesible (en el classpath) por el web container

Type mappings: En estasecciónsedescribela relaciónde los objetosutilizadosy las clasesquelos serializan.

Para una mejor descripción de todos los campos relacionados con el deploy, ver [24].

El resultadode la transacciónesrepresentadopor el objetoTransactionResult,dichoobjetomanejalos siguientes datos:

- transactionOk: Status de la ejecución del Web Service.

- Message: Mensaje asociado a la respuesta.

- errors: Vector de errores asociado a la ejecución de la transacción y no a aspectos concernientes a laejecución del Web Service.

XFormResult

XFormResult()getSoapMessage()setSoapMessage()getTransactionResult()setTransactionResult()

(from domain)

TransactionResult

transactionOk : boolean

TransactionResult()isTransactionOk()getTransactionOk()setTransactionOk()getMessage()setMessage()setErrors()getErrors()

(from domain)

-transactionResult

TransactionError

global : boolean

TransactionError()getMessage()setMessage()isGlobal()setGlobal()getFieldName()setFieldName()

(from domain)

**

45


6.4.4 Tratamiento de Errores

Básicamentese distinguen dos clases de errores, estos son errores de ejecución (descriptosanteriormente)y erroresde seguridad.A continuaciónsedetallaranlos diferentestipos de erroresdeseguridad:

- Error en el login: Usuario o password no válidos

- Número de secuencia incorrecto: El número enviado por el cliente no es el esperado

- Timestamp no válido: La hora indicada por la transacción está fuera de rango

- Firma digital no válida: La firma digital del paquete SOAP no verifica.

- Recipient no válido: Se intentó ejecutar la transacción en un recipient distinto al indicado.

Ante cualquiera de éstos errores se lanza una SOAPException,con el código y el mensajecorrespondientes.

6.4.5 Objetos de Intercambio (ValueObjects)

Pararealizarel intercambiode informaciónentrelos distintoscomponentesdel sistema,se siguió elpatrón ValueObjects, implementando varios JavaBeans, actuando como contenedores de datos:

Participant

getUser()getPasswd()

getDN()setUser()

setPasswd()setDN()

(from domain)

Ticket

getSequenceNumber()setSequenceNumber()getIdentityRecipient()setIdentityRecipient()

setDate()getDate()

(from domain)

TicketImp

sequenceNumber : int

getIdentityRecipient()setIdentityRecipient()setDate()getDate()TicketImp()getSequenceNumber()setSequenceNumber()

(from domain) ParticipantImp

ParticipantImp()getUser()setUser()getPasswd()setPasswd()getDN()setDN()

(from domain)

46


6.5 CursoresEn estasecciónse comentaránlos detallesde implementacióndel casode aplicaciónreferido a loscursores. En particular, se comentarán por un lado las clases construidas para demostrar la viabilidad deestatecnologíaaplicadaa estacasopuntual,y por otro lasconstruidasparacompararlos WebServicescontra RMI. (benchmarks). Los resultados de esta comparación se presentan en el capítulo 7.

6.5.1 Cursor Abstracto

La ideade un cursorabstractoesbásicamentela acciónderecorrerunalista deobjetos,estosobjetosson genéricosy la implementaciónes totalmenteindependienteal tipo de datosde los mismos.Acontinuación se presenta la API Cursor, proporcionada por la empresa Ideasoft.

47


interfaceCursorContainer

interfaceCursorFactory

+createCursor(cursorSpec:CursorSpec):Cursor

interface

RecordAccess

+getRecord():Record

+getRow():int

interface

CursorMetadata

+getColumnCount():int

+isSearchable(par1:int):boolean+getColumnDisplaySize(par1:int):int

+getColumnLabel(par1:int):String

+getColumnName(par1:int):String

+getPrecision(par1:int):int

+getScale(par1:int):int+getColumnType(par1:int):int

interface

CursorSpec

+getFamily():String

+getType():String+getParameter():Object

+getSearchSpec():Object

interfaceCursor

+getId():String

+moreThan(x:int):boolean

+search(searchSpec:Object):void

+next():boolean+previous():boolean

+first():boolean

+last():boolean+beforeFirst():void

+afterLast():void+absolute(i:int):boolean

+relative(i:int):boolean

+getRow():int

+getObjectAccess():ObjectAccess+getRecordAccess():RecordAccess

+getDataAccess():DataAccess+close():void

interface

ObjectAccess

+getObject():Object+getRow():int

interface

DataAccess

+getRow():int

+wasNull():boolean+getString(par1:int):String

+getBoolean(par1:int):boolean

+getByte(par1:int):byte

+getShort(par1:int):short+getInt(par1:int):int+getLong(par1:int):long

+getFloat(par1:int):float

+getDouble(par1:int):double+getBigDecimal(par1:int,par2:int):BigDecimal

+getBytes(par1:int):byte[]

+getDate(par1:int):Date

+getTime(par1:int):Time+getTimestamp(par1:int):Timestamp+getString(par1:String):String

+getBoolean(par1:String):boolean

+getByte(par1:String):byte

+getShort(par1:String):short+getInt(par1:String):int

+getLong(par1:String):long

+getFloat(par1:String):float+getDouble(par1:String):double+getBigDecimal(par1:String,par2:int):BigDecimal

+getBytes(par1:String):byte[]

+getDate(par1:String):Date

+getTimestamp(par1:String):Timestamp+getTime(par1:String):Time

+getMetaData():ResultSetMetaData

+getObject(par1:int):Object+getObject(par1:String):Object

+findColumn(par1:String):int+getBigDecimal(par1:int):BigDecimal

+getBigDecimal(par1:String):BigDecimal

interface

Record

+getFieldsCount():int

+getFieldAsString(fieldName:String):String

+getField(fieldName:String):Object

6.5.2 Implementación Básica de un Cursor

Se realizó una implementaciónconcretade un cursor, diseñadopara accedera una basede datosmedianteJDBC.La claseDBCursorFactoryImprecibeun DBCursorSpecImpquecontienela consultaa la basede datos,y devuelveuna instanciade la claseDBCursorImpque puedeser utilizada pararecorrer el resultado de la consulta.

48


DBCursorSpecImp

DBCursorSpecImp()getFamily()setFamily()getType()setType()getParameter()setParameter()getSearchSpec()setSearchSpec()DBCursorSpecImp()DBCursorSpecImp()

(from cursor)

Cursor

(from api)

CursorSpec

(from api)

CursorFactory

(from api)

DBCursorImp

DBCursorImp()DBCursorImp()getId()moreThan()search()next()previous()first()last()beforeFirst()afterLast()absolute()relative()getRow()getObjectAccess()getRecordAccess()getDataAccess()getCursorCapabilities()close()

(from cursor)

DBCursorFactoryImp

DBCursorFactoryImp()createCursor()setSessionContext()

(from cursor)

6.5.3 Implementación de un Cursor con Caché

Pararealizarunaimplementaciónmasinteligentessobreun cursor,sepensoen un cursorcon cacheo.El mismoimplementala ideabásicade un cache,publicandola interfacede un cursor,pidiendode aráfagaslos objetosa un cursor básicoy almacenandouna copia de los últimos. La arquitecturaseilustra en la siguiente figura:

Base de Datos

DBCursor

CacheCursor

Ráfagas

Peticiones simples

Las clases implementadas se presentan en el siguiente diagrama:

49


Cursor

(from api)

CacheCursor

firstCase : booleanrelativePosition : intabsolutePosition : inthasLast : booleancacheSize : intloadSize : int

getId()CacheCursor()moreThan()search()next()previous()first()last()beforeFirst()afterLast()absolute()relative()getRow()getObjectAccess()getRecordAccess()getDataAccess()getCursorCapabilities()close()

(from cursor)

CacheObjects

absolutePosition : intrelativePosition : inthasLast : boolean

CacheObjects()getAccsesorsObjects()setAccsesorsObjects()getAbsolutePosition()setAbsolutePosition()getRelativePosition()setRelativePosition()isHasLast()setHasLast()

(from cursor)

RecordAccess

(from api)

DBCursorImp


(from cursor)

DataAccess

(from api)

#data

CommonAccess

CommonAccess()getDataAccess()setDataAccess()getRecordAccess()setRecordAccess()getObjectAccess()setObjectAccess()remove()

(from cursor)

**

-recordAccess

-dataAccess

ObjectAccess

(from api)

-objectAccess

El mecanismo de cacheo puede resumirse en el manejo de las siguientes variables:

- cacheSize: Esta variable establece la cantidad de elementos que almacena temporalmente el cursor.

- loadSize:Establecela cantidaddeelementosquesecargancuandoserequiereun elementoquenose encuentra en memoria.

Juntocon estasimplementacionestambiénseconstruyeronclasesutilitarias parapoderrepresentarenmemoria los objetos del cursor, ya que un ResultSet no es una clase contenedora, sino un apuntador a labase de datos. Por lo tanto se encapsuló la información en este conjunto de clases:

50


DataAccess

(from api)

DBCursorImp


(from cursor)

ResultSetWrapper

setRows()ResultSetWrapper()ResultSetWrapper()close()getRow()getRows()wasNull()getString()getBoolean()getByte()getShort()getInt()getLong()getFloat()getDouble()getBigDecimal()getBytes()getDate()getTime()getTimestamp()getString()getBoolean()getByte()getShort()getInt()getLong()getFloat()getDouble()getBigDecimal()getBytes()getDate()getTimestamp()getTime()getMetaData()getObject()getObject()findColumn()getBigDecimal()getBigDecimal()

(from util)

java.sql.ResultSet

6.5.4 Publicación de un Cursor como Web Service

El fin principal de estecasode aplicaciónes realizar la publicaciónde un cursor medianteWebServices.Paraesto,seimplementóla claseWebServicesCursor,quecumplecon la interfaceCursorysirvecomofachadadeun CacheCursor.Tambiénagregamétodosparabrindarráfagasdeobjetosy asíproporcionar soporte para caché en el cliente. La arquitectura se muestra en la siguiente figura:

51


Base de Datos

DBCursor

CacheCursor

Ráfagas

Peticiones simples

WebServiceCursor

Ráfagas

Las clases mencionadas se ilustran en el siguiente diagrama:

Cursor

(from api)

WebServiceCursor

WebServiceCursor()init()init()getId()moreThan()search()next()previous()first()last()beforeFirst()afterLast()absolute()relative()getRow()getObjectAccess()getObjectsAccess()getRecordsAccess()getDatasAccess()getRecordAccess()getDataAccess()getCursorCapabilities()close()

(from server)

-cursor

CacheCursor

firstCase : booleanrelativePosition : intabsolutePosition : inthasLast : booleancacheSize : intloadSize : int

getId()CacheCursor()moreThan()search()next()previous()first()last()beforeFirst()afterLast()absolute()relative()getRow()getObjectAccess()getRecordAccess()getDataAccess()getCursorCapabilities()close()

(from cursor)

52


Conel fin de poderserializarla claseResultSetWrapper(queno esun JavaBean,y por lo tantono sepuede utilizar el org.apache.soap.encoding.soapenc.BeanSerializer),se implementó una clase querealiza la serialización a y desde XML, llamada ResultSetWrapperSerializer

Serializer

(from xml)

Deserializer

(from xml)

ResultSetWrapperSerializer

ResultSetWrapperSerializer()marshall()unmarshall()getPropertyDescriptors()getWriteMethod()instantiateBean()class$()

(from util)

ResultSetWrapper

(from util)java.sql.ResultSet

53


6.5.5 Implementación de un Cliente

Paraprobar la utilidad de estatecnología,se implementóun cliente gráfico que recorreun cursoratravésdeWebServices,medianteun mecanismode cachedel ladodel cliente.El mismosiguela ideadesolicitaral servidorráfagasdeelementos,y mantenerunacopiadelos mismosenel cliente(ráfaga).A continuación se describe la arquitectura mediante un diagrama:

Base de Dat os

DBCursor

CacheCursor

Ráfagas

Peticiones simples

WebServiceCursor

Ráfagas

Ráfagas

Cliente

Gráfico

54


Las clases implementadas para esto se presentan en el siguiente diagrama:

CursorFrame

position : int

CursorFrame()main()jbInit()primeroButton_actionPerformed()previoButton_actionPerformed()siguienteButton_actionPerformed()ultimoButton_actionPerformed()crearCursorButton_actionPerformed()

(from client)

WebServiceCursor(from server)invoke (Web Service)

Gráficamente,el resultadopuedeverseenel siguiente“screenshot”.En el mismoseagregala nociónde“Ráfaga”,la cual indica la cantidaddeelementosa traerdesdeel servidorcadavezquesesolicita un nuevoelemento.A travésdel mismosepuedecrearun cursora partir deunaconsulta y recorrer su resultado gráficamente.

6.5.6 RMI

Tambiénfue implementadoun clienteRMI y su correspondienteservidor.Los mismostienenunalógica similar al cliente para Web Servicesy fueron construidospara realizar los Benchmarkscorrespondientes.

55


RMICursor

(from rmi)

Cursor

(from api)

Remote

(from rmi)

RMICursorClient

RMICursorClient()main()

(from rmi)

RMICursorImp

main()RMICursorImp()init()init()getId()moreThan()search()next()previous()first()last()beforeFirst()afterLast()absolute()relative()getRow()getObjectAccess()getObjectsAccess()getRecordsAccess()getDatasAccess()getRecordAccess()getDataAccess()getCursorCapabilities()close()

(from rmi)

CacheCursor(from cursor)

-cursor

6.5.7 Objetos de Intercambio (ValueObjects)

Pararealizarel intercambiodeinformaciónentrelos distintoscomponentesdel sistema,sesiguióelpatrón ValueObjects, implementando varios JavaBeans, actuando como contenedores de datos.

CommonAccess

CommonAccess()getDataAccess()setDataAccess()getRecordAccess()setRecordAccess()getObjectAccess()setObjectAccess()remove()

(from cursor)

CacheObjects

absolutePosition : intrelativePosition : inthasLast : boolean

CacheObjects()getAccsesorsObjects()setAccsesorsObjects()getAbsolutePosition()setAbsolutePosition()getRelativePosition()setRelativePosition()isHasLast()setHasLast()

(from cursor)

**

56


7 BenchmarksLaspruebasderendimientoo Benchmarkssedefinencomounaseriedepruebasllevadasa caboen

el softwareen una gran variedadde circunstancias,como por ejemplodistintasredeso una variadagranularidaden la informaciónsolicitada.Presentaremosdosdiferentesbenchmarks,uno parael casode transacciones,variandolos nivelesde seguridady otro sobrela performancede cursoresfrente aotra tecnología.En cada caso primero se mencionael objetivo del estudio, luego se presentaelescenarioen el que fueron realizadaslas pruebas,se detallanlos pormenoresde la ejecucióny porúltimo se enumeran los resultados asociados a cada caso.

7.1 Transacciones

7.1.1 Objetivo

EsteBenchmarktienecomoobjetivo medirel desempeñodel prototipoimplementadoparael casodeaplicaciónde las transaccionesdescritoenel punto6.4.Los aspectosa considerarestánreferidosalcostoque tienenen la performancelos requisitosde seguridad,talescomo la encriptacióndel canal(SSL [11]) y el firmado digital de los paquetesSOAP, estudiadossobre distintas redes(LAN eInternet).

7.1.2 Escenario

Cliente� Hardware : Pentium II, 64 Mb. RAM, tarjeta de red 10 Mb, modem 56 Kb.

� Software : W98, JRE 1.3, Apache Soap 2.2

Servidor� Hardware : Pentium IV, 256 Mb. RAM, tarjeta de red 10 Mb

� Software : W2000, JRE 1.3. Tomcat 3.2.1, Apache Soap 2.2

LAN : cliente y servidor conectados a un Switch 100 Mb.

Internet : las pruebas se realizaron con una conexión a 33.6 Kb.

Nota: Laspruebasserealizaronencondicionesdetráfico relativamentebajoy todoslos servidoresdedicados para estas pruebas.

7.1.3 Ejecución y Presentación de los resultados

Parala ejecuciónsetrabajóconun paquetede88 Kb, sin tomarencuentael overheaddel mensajeSOAP y el HTTP. Este tamañode paquetese consideraun ejemplo válido de una transacciónde

57


mediana complejidad.

Las consultasse realizanen un formato de tiempo "no think" (sin pensar)dondelos pedidosserealizan continuamente.Esto representauna situación irreal, por lo que cada flujo de consultasrepresenta la carga de trabajo de una gran cantidad de usuarios simultáneos en el mundo real.

En este punto se probaron los siguientes 8 casos. Se realizaron 5 consultas por caso, tomándose elpromedio como valor representativo, por mas detalles ver Apendice - Resultados Benchmark.xls

Transporte Tecnología Tamaño Dato Duración (ms)Canal sin EncriptarPaquete sin Firmar 472

Paquete Firmado 846Canal Encriptado Paquete sin Firmar 778

Paquete Firmado 1.142Canal sin EncriptarPaquete sin Firmar 6.274

Paquete Firmado 6.676Canal Encriptado Paquete sin Firmar 27.736

Paquete Firmado 27.462

Comopuedeobservarse,parael casodeLAN el costode firmar el paqueteincideenla duracióntotal de la transacción en un factor de 1,6 veces (1,8 si no se encripta el canal y 1,46 en caso contrario),mientrasque ese factor es de 1,03 (1,064 si no se encripta el canal y 1,009 en casocontrario),prácticamente despreciable.

Desdeotro puntode vista,puedeversequela encriptacióndel canalincide enun factor de 1,45para el caso de una LAN, y en un factor de 4,25 en el caso de Internet.

7.2 Cursores

7.2.1 Objetivo

La ideaquepersigueesteBenchmarkescompararWebServicescontraunatecnologíapropietariay conocidacomo RMI, para brindar un punto de referenciaa la hora de considerarsu uso. ElrendimientodeRMI ya ha sido estudiado(ver [25]) y seconsideróunaalternativarazonableparaestecaso. A continuación se presenta una tabla de [26] que ilustra el overhead de utilizar RMI:

Pararealizarel estudio,se definieroncuatrodimensionesque representanlas característicasmas

58


interesantes a comparar:

- Tecnología: Java RMI contra Web Services.

- Red: Internet contra LAN.

- Tamaño de los paquetes: Se evaluaron distintos tamaños de las respuestas.

- Tamaño de la ráfaga: Variar la cantidad de elementos que el servidor retorna por cada round trip.

7.2.2 Escenario

Cliente� Hardware : Pentium II, 64 Mb. RAM, tarjeta de red 10 Mb, modem 56 Kb.

� Software : W98, JRE 1.3, Apache Soap 2.2

Servidor� Hardware : Pentium IV, 256 Mb. RAM, tarjeta de red 10 Mb

� Software : W2000, JRE 1.3. Tomcat 3.2.1, Apache Soap 2.2

Conjunto de datos : � Los cursoresrecorrieronuna tabla de aproximadamente8.000 tuplascontra una basede

datos Oracle 8.1.6 sobre un servidor Intel con 2 procesadores, 2 Gb. RAM, Solaris 7.

LAN : cliente y servidor conectados a un Switch 100 Mb.

Internet : las pruebas se realizaron con una conexión a 33.6 Kb.

Nota: Laspruebasserealizaronencondicionesdetráfico relativamentebajoy todoslos servidoresdedicados para estas pruebas.

7.2.3 Ejecución

En este punto se probó los siguientes 12 casos :

Para la ejecución se trabajó con 3 tamaños distintos de registros :

� Pequeños : tuplas de aproximadamente 56 bytes.

� Medianos : tuplas de aproximadamente 336 bytes.

� Grandes : tuplas de aproximadamente 616 bytes.

59


Las consultasse realizanen un formato de tiempo "no think" (sin pensar)dondelos pedidosserealizan continuamente.Esto representauna situación irreal, por lo que cada flujo de consultasrepresenta la carga de trabajo de una gran cantidad de usuarios simultáneos en el mundo real.

Parael casodepresentacióndelos datosseagruparanpor tablaspararáfagasdetamaño1 a 200enintervalos de 20.

Transporte Tecnología Tamaño Dato N° CasoLan Web Services Pequeños Caso 1

Medianos Caso 2Grandes Caso 3

RMI Pequeños Caso 4Medianos Caso 5Grandes Caso 6

Internet Web Services Pequeños Caso 7Medianos Caso 8Grandes Caso 9

RMI Pequeños Caso 10Medianos Caso 11Grandes Caso 12

7.2.4 Presentación de los Resultados

Las tablascon los valoresobtenidosde las pruebasrealizadasse encuentranen el Apéndice -Resultados Benchmark.xls

A continuaciónse presentanalgunasgráficas,resaltandolos aspectosmás significativos de laspruebas.

60


Tamaño de ráfaga/Tamaño de mensaje, Tecnología para el caso de una red local (LAN)

Tamaño de ráfaga/Tamaño de mensaje, Tecnología para el caso de Internet

61


Ya queel casode tamañode paquete= 1 marcaunagrandiferencia,sepresentangráficasde losmismos casos, en donde ha sido ocultado este valor.

Tamaño de ráfaga/Tamaño de mensaje, Tecnología para el caso de una red local (LAN)

Tamaño de ráfaga/Tamaño de mensaje, Tecnología para el caso de Internet.

62


8 ConclusionesLas conclusionesde este proyecto se dividirán en cuatro secciones:conclusionessobre la

tecnologíay suestadoactual,conclusionessobrelasalternativasposibles,conclusionessobreel trabajorealizadoparacumplir con los casosdeaplicacióny conclusionessobreel futuro de los WebServices.Por último, se mencionarán posibles trabajos a desarrollar como continuaciones de este proyecto.

8.1 Sobre la tecnología Es evidentela fuerzaquehantomadolos Web Servicesen la industria.Prácticamentetodaslas

grandesempresasdesoftwareestánincorporandoa susproductosel conceptodeinteractuara travésdeWeb Services.El usode estándaresy protocolosabiertostalescomo HTTP, XML, SOAP,WSDL yUDDI permitenconvertir las aplicacionescorporativasen Web Servicesy asíconseguirun alto nivelde interoperabilidadentreellas.Asimismo,el númerode implementaciones,toolkits y frameworksdedesarrollodisponiblesestácreciendoen forma acelerada,lo que permitesuponerque el númerodedesarrolladores que se vuelque a trabajar con Web Services también crezca rápidamente.

Un detallea destacar,sin embargo,consisteen que ciertosaspectosde los Web Servicesquetodavíano hansidoestandarizados,estánsiendoresueltospor las implementaciones.Estopuedellevara problemasde mantenimiento(seránecesarioadaptarel código existenteal estándar,cuandoésteaparezca)y a unbajonivel deinteroperabilidadentresistemasbasadosenimplementacionesdedistintoorigen.Si bien esteproblemaescomúnen las aplicacionesde hoy en día,estaríaen contrade unadelas principalescaracterísticade los Web Services,la cual consisteen permitir la interoperabilidaddesistemasheterogéneosenformatransparente.Un claroejemplosebrindaráenel punto8.2.2,al tratareltema de los Web Services stateful.

8.2 Sobre la aplicación a estos casosAlgo quese hizo evidentea pocode empezaresteproyecto,y que puedegeneralizarseal estado

actualde la tecnologíade Web Services,es la falta de madurezde las herramientasdisponibles.Lamayoríatieneun númeroreducidodefuncionalidades(por ejemplo,el IBM WSTK 3.1,queincluyeungenerador de archivos WSDL, sólo permite generarlos a partir de un JavaBean que utilice tipos básicos,lo que restringefuertementeel tipo de clasesque puedenser publicadasen forma automáticacomoWebServicesconestaherramienta)y la documentaciónenmuchascasosesescasao nula(porejemploel ApacheSOAP2.1o la IBM SOAPEnvelopeApi).Lasdemosy ejemplosqueacompañanal softwarenormalmente son básicas, y no ilustran problemas complejos.

8.2.1 Transacciones

Unaconclusiónimportantesobreestecasoradicaenquefue posibleimplementarenformaexitosaun soportepara transaccioneselectrónicasbasadoen Web Services.Mediante SSL se consiguióalcanzarel nivel estándardeseguridadencuantoa la confidencialidadde la transmisión.Incorporandola firma digital seobtuvierongarantíasde integridady no repudiotantoparael servidorcomoparaelcliente.Por último, a travésdel manejode ticketsseevita la posibilidadde quemensajesduplicadosseanprocesadoscomo mensajesválidos. La implementaciónde utilitarios que permitenverificar la

63


firma digital a posteriori cierra el circulo en cuanto a asegurar la intencionalidad de la transacción.

Cabeseñalarun aspectodel estadodel arte en estecampo:Si bien la firma digital de XML esestándar, todavíano lo esaplicadaa SOAP;el estadode la especificaciónde éstaparaSOAPesdeNOTE [27] por lo que no puedeasegurarseque la implementaciónactual termine cumpliendoelestándar, si bien se apega al estado actual de la especificación.

Como era de esperar,altos nivelesde seguridadafectanen forma negativaa la performancedelsistema.Las conclusionesextraíblesa partir de los resultadosexpuestosen el punto 7.1.3 puedendividirse en dos grupos fundamentales, sobre LAN y sobre Internet.

Para el caso de la LAN, tomando como base la duración de una transacción de paquetes sin firmar ysin SSL, se observaun incrementode 1,8 para el casode paquetefirmado sin SSL, de 1,64 parapaquetessin firmar y con SSL y de 2,41 para paquetesfirmados y sobreSSL. Por lo tanto unarecomendaciónquesurgedeestoconsisteenevitarel firmadodepaquetesno “sensibles”(por ejemplo,considerandola transaccióncomo un formulario, firmar sólo el “submit” de la transacción,y no lospaquetesquepuedangenerarseparael llenadodel formulario).Estosignifica ademásquecumplir conlos requisitosmáximosde seguridadocasionanunacaídasignificativaen la performancedel sistema(casidosvecesy mediamaslento).Sin embargoparaalgunasLAN esposiblepensarenalternativasdeseguridada otrosniveles,talescomola restricciónde accesofísico a las líneasde transmisión,por locualpuedellegara serinnecesarioel usodeSSLy deestamaneramejorarde 2,41a 1,8 la perdidadeperformance del sistema.

En el casode Internety tomandonuevamenteel tiempoen procesarunatransacciónbasadaen unpaquetesin firmar y sin SSL, seobservaun incrementode 1,06 parael casode paquetefirmado sinSSL, de 4,42 para paquetessin firmar y con SSL y de 4,37 parapaquetesfirmados y sobreSSL.Tambiénseobservaqueel firmado del paqueteafectaen 1,01 parael casode una transmisiónsobreSSL.De estopuedeconcluirsequela diferenciaentreel firmar o no firmar un paqueteesmínimay noincidirá en la performancedel sistema.En estecasoel costode utilizar SSL afectanotoriamentelaperformance(casicuatrovecesy mediamaslento)peropor tratarsedeunaconexiónsobreInternet(unmedio no seguro) es prácticamente imprescindible su utilización.

Para el mantenimientode los tickets, es necesariorealizar programacióndel lado del cliente,programaciónquedebeser repetidaparacadacliente o lenguajequeconsumael Web Service.Estoplanteaunacontradicciónconla filosofía delos WebServices,la cualproponesu invocacióncomounsimpleRPC.Los ticketssirvenparaqueel servidorindiquecual transacciónacepta(con el sequencenumber)y cuandose realizó (con el timestamp).Si se flexibilizan algunosrequerimientos(que elcliente elija el timestamp, que pueda realizar una transacción sin el consentimiento del servidor y que elrecipientse indique como un parámetromás)no es necesarioel mantenimientode tickets.Tanto eltimestamp como el sequence number son válidos para evitar los paquetes duplicados.

8.2.2 Cursores

Al igual queenel casodelastransacciones,fue posibleimplementarel mecanismoderecorridodecursoresmedianteWebServices.El diseñoescogidopermiteutilizar el cursorbasadoenWebServicescomocualquierotro cursor,ya quetanto la clasequepublica los métodosdel Web Servicescomo laclase que maneja el cache del lado del cliente implementan la interface Cursor.

Un aspectoproblemáticodel estadoactualde la tecnologíaconsisteen que las implementacionesavanzanmásrápidoquelos estándares.Porejemplo,sedetectóun temadelicadoal tenerqueresolverel problemadel mantenimientode las sesiones,para utilizar Web Servicesstateful. Para esto se

64


estudiarondos posiblessoluciones,detalladasen el punto 5.2.1. La solución adoptada(utilizar elmecanismodemantenimientodesesiónprovistopor la implementacióndeSOAP)no formapartedelaespecificaciónactual,y de hechootrasimplementaciones([28],[29]) resuelvenesteproblematambiénde forma propietaria. Esto puede traer problemas de mantenimiento e interoperabilidad.

Otro ítem a teneren cuentaesel relacionadocon la optimizaciónde la performance.Comopuedeapreciarseen el estudiode Benchmarks,para obteneruna performance“aceptable”, fue necesarioestablecerun mecanismodesolicitud por ráfagase implementarlógicadecacheodel lado del cliente.Estoimplicaquesi sedeseaaccedera eseserviciodesdeclientesimplementadosenlenguajesdistintos,es necesarioreprogramarla lógica de cacheoen cadalenguaje,o utilizar clientespropietarios.Estasalternativas se contraponen a algunas de las bases del modelo de los Web Services.

Una observacióninmediatay esperablea partir de los Benchmarksconsisteen que los WebServicespresentanactualmenteunaperformancemuy baja con relacióna unaalternativapropietariacomo RMI. Considerandoel casoen que no fue necesariomodificar la interfaceCursor (o sea,lainformaciónestransmitidaen ráfagasde tamaño1) el sistemasecomportóentre118,4y 84,74vecesmas lento para el caso LAN, y entre 4,4 y 4,2 veces mas lento para el caso Internet.

De estopuedeconcluirseque la diferenciade rendimientoprácticamentedescartala alternativabasadaenWebServicesparael casoLAN, dejandocomoprincipalargumentofavorableel apoyoenlainteroperabilidaddel sistema.Asimismo,unade las característicasa favor de los Web Servicescomoser la capacidadde actuaren forma transparentesobrelos firewalls muchasvecesno es esencialenambientes controlados como una LAN.

La alternativapropuesta(modificar la interface Cursor para que soportepedidosen ráfagaseimplementarlógicadecacheoenel cliente)brindaunasoluciónintermedia,ya quesi bienno alcanzaaser tan performantecomoRMI, mejorala pérdidade performanceen masde un 90% (Web Servicespasadeser99,09vecesmaslentoa 8,6veces)pararáfagasdemasde100elementos.De estaforma,sibien se mantieneuna mayor interoperabilidad,implica que se debareprogramarla lógica de cacheoparacadaclienteo lenguajequeconsumael WebService,lo cualva contrael modelo.A continuaciónsemuestrala variaciónde la relaciónentreWebServicesy RMI, a medidaqueseaumentael tamañode la ráfaga de datos:

En el caso Internet, si bien RMI continúa siendomas performanteque los Web Services,lasdiferenciassonmenosdramáticas.Seobservaunapérdidadeperformancede 4,23vecessi seutilizanráfagasde tamaño1, pérdidaquedisminuyea menosde 1,8 vecessi seconsideranráfagasdemasde100elementos,lo quecorrespondea unamejorademasdel 55%.Esto,unidoa queenestecontextolapresenciade firewalls es extremadamentefrecuente,la alternativa de los Web Serviceses muyrazonable,ya quepresentaunasoluciónqueapoyala interoperabilidadconun costoenla performanceen muchos casos aceptable.

65


A modo de resumen,puede concluirse que para un sistemaque tenga como escenariosdeinteraccióntanto InternetcomoLAN, con requisitossimilaresal casode cursores,la interfacecon lacapade negociosno deberíabasarseexclusivamenteen unade las dos tecnologías.Por un lado, losWeb Servicespresentanseriosproblemasde performanceen ambientesLAN, y por otro RMI esunaalternativacerrada,que requierede configuracionesespecialesen los firewalls paracomunicarseatravés de Internet. La siguiente figura propone una arquitectura que ejemplifica estos conceptos.

Capa de Negocios

RMI

WEB SERVI CES

LAN

I nte

rnet

La capade negocioses publicadaen la LAN a travésde RMI, y los Web Servicespuedeninteractuardirectamentecon la capade negocioso con la capaRMI. DesdeInternet,sólo esposibleacceder a la capa de Web Services. Cabe destacar que los Web Services son utilizables también a travésde la LAN, aunque por lo ya expuesto, no se aconseja.

Otra conclusiónque surgedel análisisde los benchmarkscorrespondea la relación entre eltamañode los datosintercambiadosy el tiempoempleadoen transmitirlos.Puedeverseque anteunaumento del tamaño de los datos transmitidos (ya sea por un incremento en el tamaño de la ráfaga o porun incrementoen el tamañode los paquetes)la velocidadde transmisiónaumenta,tantoparael casoWeb Servicescomoparael casoRMI, lo cual eraesperable.A continuaciónsepresentanlas gráficasde velocidades en función del tamaño de la ráfaga, para LAN e Internet.

66


Velocidad Web Ser vices (Internet )

0,00

1000,00

2000,00

3000,00

4000,00

5000,00

6000,00

7000,00

8000,00

1 20 40 60 80 100 120 140 160 180 200

Tamaño R áf ag a

Chicos

Medianos

Grandes

Velocidad RMI (Internet)

0,00

2000,00

4000,00

6000,00

8000,00

10000,00

12000,00

1 20 40 60 80 100 120 140 160 180 200

Tamaño Ráfag a

byt

es/s

eg

Chicos

Medianos

Grandes

Velocidad Web Services (LAN)

0,00

10000,00

20000,00

30000,00

40000,00

50000,00

60000,00

70000,00

1 20 40 60 80 100 120 140 160 180 200

Tamaño R áf ag a

Chicos

Medianos

Grandes

Velocidad RMI (LAN)

0,00

100000,00

200000,00

300000,00

400000,00

500000,00

600000,00

700000,00

1 20 40 60 80 100 120 140 160 180 200

Tamañ o Ráfaga

byt

es/s

eg

Chicos

Medianos

Grandes

Analizandola variacióndela velocidaddeunatecnologíacontrala otra,comosepresentaenlassiguientesgráficas,puedeobservarsequeparael casoLAN, el utilizar ráfagasdisminuyela diferenciaentrelasvelocidades,llevándolasa valoresentre16-14y 8-7,pararáfagasmayoresa 140valores.Parael casoInternetseda un fenómenosimilar, en dondela diferenciade velocidadessereducea valoresentre 2 y 1,6. Esto demuestraque la soluciónpropuesta(no traer datosen forma unitaria, sino enráfagas) constituye una alternativa efectiva.

Relación entre v elocidades (LAN)

0,00

20,00

40,00

60,00

80,00

100,00

120,00

140,00

1 20 40 60 80 100 120 140 160 180 200

T a mañ o R áf a ga

Chicos

Medianos

Grandes

Relac ión entre v eloc idades (Internet)

0,00

0,50

1,00

1,50

2,00

2,50

3,00

3,50

4,00

4,50

5,00

1 20 40 60 80 100 120 140 160 180 200

T amañ o R áf a ga

Chicos

Medianos

Grandes

Porlo tanto,unabuenaestrategiaa seguirconsisteenno realizarpequeñospedidosdedatos,o encasodehacerlo,traerlosjuntocondatosasociadoso quetenganunaaltaprobabilidaddeserrequeridosa continuación.Por ejemplo,supóngaseel casode una aplicaciónGUI que manejaun combopara

67


permitirleal usuarioseleccionardepartamentos,y otrocomboquele permiteseleccionarlocalidadesenfunción del departamento,y se deseaque los combosseancargadosa partir de Web Services.Unaposibleestrategiaradicaen utilizar un WebServicesparacargarel combodedepartamentos,y luego,cadavezquesecambiededepartamento,seinvoquea un WebServicesparacargarlaslocalidadesdelnuevodepartamentoseleccionado.Estaestrategiaplanteamuchospedidosde pequeñotamaño,lo queposiblementelleve a una baja performance.Una mejor soluciónconsisteen solicitar las localidadesjunto con los departamentos,paraquede estamanerase genereun único pedidode mayor tamaño.Claramente, tampoco es recomendable llevar está práctica al extremo.

Otraconclusiónquesepuedeobtenerdeestoesqueparaaplicacionesendondeel rendimientoescrítico, los WebServicesnosonaplicablesensuformabásica.Sepuedemejorarla performancedelosWebServicesconalternativasquesealejendel modelo,comoel casodel cacheoantesmencionado,ono respetando estrictamente el protocolo SOAP. Por ejemplo, el encoding style de SOAP establece quecadapropiedadde un objeto se mapeecon un elementoXML, incluso si se trata de tipos simples,cuandosepuedeobtenerunamayorperformanceal parsearsi la propiedadsemapeacomoun atributodel tipo nombre=valor.

Porúltimo, seplanteanlassiguientesrecomendacionesenfuncióndelasposiblesaplicacionesdeestatecnología:parael casode las transacciones,sedemostróqueesposiblesu utilizaciónbajo todaslas garantíasrequeridas,y ya queparamuchoscasosel tiempode realizarla transacciónno escrítico(por ejemploenel casodeejecutarun formularioel usuariopasala mayorpartedel tiempollenándolo,y normalmentees aceptableun tiempo de procesorelativamenteprolongado)y por lo tanto laperformancedel round trip del Web Serviceno constituyeun inconvenienteinsuperable.El mayorproblemaradicaen que todavíano estáncompletamentedefinidosalgunosestándaressobreel tema.Sobrelos cursorespuedendiferenciarsedoscasos:unoendondelos pedidosseandegrantamañoy endondeun tiempoderespuestaseaaceptable(por ejemploenel casodel paginadodeun reporte)y otroparacuandolos pedidossonpequeñosy esnecesariounarápidarespuesta(por ejemplo,enel casodeun protocolode interacción“fina” con el usuario).Parael primer caso,esviable unasoluciónbasadaen Web Services, mientras que en el otro es muy difícil que la performance sea aceptable.

8.3 Sobre la alternativa utilizadaEl softwarebasea utilizar (Tomcat,ApacheSOAP,Xerces,etc.)surgiónaturalmentea partir de

los requerimientos de la empresa Ideasoft: software libre, open source y basado en el lenguaje Java.

Durantela eleccióndela herramientaa utilizar parala generacióndefirmasdigitalesenXML, seconsultarony evaluaronalgunasde las implementacioneslistadasen [22]. Como se mencionaen lasección6.4.2, la utilización del IBM XML SecuritySuite [16] se basóen que fue la que presentómenosproblemasde instalacióny configuración,ademásde cumplir el requerimientode funcionarsobre la plataforma Java.

De la utilizacióndeestasherramientassepuedeconcluirquela implementacióndelos objetivosesfactible, aunquefue problemáticala configuracióne instalaciónde los mismos,debido en muchoscasosa conflictos entreversionesy a una documentaciónpobre en tamañoy calidad.Un detalleamencionar es que debido a la falta de estándares en aspectos antes mencionados (por ejemplo en el casostateful),es complejasu utilización sin los utilitarios provistosdel lado del cliente, y prácticamenteimposible acceder desde clientes basados en otra plataforma (por ejemplo .NET).

68


8.4 Sobre el futuro Como se mencionó,la presenciade los Web Servicesen la industria es cadavez mas fuerte.

Posiblementeseanla alternativapara comunicarsistemasheterogéneosmas utilizada en el corto ymedianoplazo. La baseen los estándaresde la W3C fomentanla interoperabilidadsin problemasinherentesa implementacionespropietarias.En la medidaqueseestandarizenalgunosde los aspectosproblemáticosantesmencionados,las implementacionesbrinden una performanceaceptabley lasherramientasmejorensu calidad, los Web Servicesse convertiránen la basede la integracióndesistemas en el futuro.

8.5 Posibles extensiones al proyecto� Mostrar la interoperabilidaddel sistemaimplementandoun cliente en un lenguajediferentea Java,

como Delphi o algún lenguaje de la plataforma .NET� Evaluarotrasimplementaciones.En particularla XML SecurityJ deApache,unaAPI alternativaopen

sourceparael firmado de archivosXML. No seutilizó paraesteproyectodebidoa lo expuestoen elpunto4.2.5.Asimismo,seencuentradisponible(enversiónbeta)unanuevaimplementacióndeSOAPpor partedeApache,llamadaAxis, queprometeun mejordesempeñoquela implementacióndeSOAPutilizada en este proyecto.

� Si biensedemostróla viabilidaddela infraestructuraprovistay el diseñorealizadoesindependientedela lógicaa publicar,un puntointeresanteconsisteenprobarsuintegraciónconEDF,y realizarpruebascompletas de la ejecución de formularios XForms.

� Un objetivo másambiciosoqueel propuestoparaesteproyectoconsisteen la implementaciónde unframeworkquepermitala publicacióndelógicadenegociosenformatransparentecomoWebServicesseguros.Su finalidadconsistiríaen queel usuariodel frameworkproveasu WebServicese indicandodetallesdeinfraestructura(repositoriodecertificados,baseparael almacenamientodefirmasdigitales,etc.) consiga su publicación con los niveles de seguridad conseguidos en este proyecto.

69

Web Services

Documents

Transcript of Web Services