web services. estado del arte

EstadodelArtedelosServiciosWeb 2008

12 EdwinValenciaCastillo

2.2. OPERACIONESDELAARQUITECTURALasoperacionesquesepuedenrealizarconlosserviciosWeb,sonlassiguientes:

2.2.1. Publicar/CancelarUnproveedordeserviciospodrapublicarundeterminadoserviciocomercial (ebusiness)aunoomsregistrosdeservicios,ademsde,evidentemente,cancelardichapublicacinenunmomentodado.

2.2.2. BuscarLossolicitantesdeservicios(clientes)podrninteractuarconunoomsregistrosparadescubrirunconjuntodeservicioscomercialesconlosquepuedaninteractuarparaencontrarunasolucinasusproblemas.

2.2.3. Enlazar(Bind)Lossolicitantesdeserviciosnegociancon losproveedores la formadeaccedereinvocarasusservicioscomerciales(ebusiness).

Como secomento,un servicioWebesunacoleccinde funcionesque sonpresentadascomounasolaentidadyqueesanunciadaenlaredparaserusadaporotrosprogramas.Sonporlotanto,bloquesdeconstruccinparacrearsistemasdistribuidosabiertos.En la figura 3 podemos observar la relacin existente entre los componentes y lasoperacionesdelaarquitectura.

Figura3.Relacionesentreloscomponentesqueconformanlaarquitectura

deserviciosWebActualmente, lasaplicacionesque seestn realizando,poseen la capacidaddebuscaryseleccionar serviciosdinmicamente en tiempo real,basndoseenparmetros comoelcosto, la calidad,o ladisponibilidad.Esto suponeunagran ventajaa lahoradeutilizarsistemas basados en serviciosWeb, ya que el sistema, de forma automtica, elegir elservicioquemsseajusteasusnecesidades,yporlotantoelrendimientodelsistemaseverincrementado.



2.3. MODELOSARQUITECTONICOSEl W3C Web Service Architecture Working Group[1] definen modelos arquitectnicoscomosubconjuntocoherentedelaarquitecturaquesecentrabsicamenteenunaspectoconcretodentrodelaarquitectura.Cadamodelointentaexplicaralmximoelaspectoenelquesehacentrado.Unmodelotambindebedefinirtodaslasdependenciasquepuedapresentarconrespectoaotrosaspectos incluidosen laarquitecturadentrode lacualseubica. En la Figura 6mostramos las relaciones existentes entre los distintosmodelosmedianteunarepresentacingrficadelosmismos.

Figura4.Metamodelodelaarquitecturadeserviciosweb[1]

2.3.1. ElModeloorientadoamensajesEstemodelo se enfoca en aquellos aspectos relacionados con losmensajes, suestructura,elmtododetransporte,etc.Estemodelonoatiendenialporqudelosmensajesniasusignificado.El intersprincipaldeestemodelosesitaen laestructura de los mensajes, las relaciones existentes entre los que envan losmensajes, los que los reciben y otros intermediarios que tengan que procesartambin losmensajespara reenviarlos.Relacionados con losmensajes,hayunaseriedeconceptosqueresultaninteresantesdentrodelaarquitecturayqueestemodelocomenta,mostrandocuales larelacinqueguardanunosconceptosconotros,aunquelaprofundidadconquedebesertratadoseescapaalaprofundidadconlaquetrataremoslacuestin.



Figura5.Modeloorientadoamensajes[1]

2.3.2. ElModeloorientadoaserviciosEstemodelosecentraenaspectosdelaarquitecturarelacionadosconlosserviciosylasaccionesprincipalmente.Elpropsitoprincipaldeestemodeloesexplicarlasrelacionesexistentesentreunagente,losserviciosqueofreceoimplementaylossolicitantesde losservicios.Comoes lgico,unagentenopodra llevaracabo latareadeofrecerserviciosalosclientessinotuvieralacapacidaddeenviaryrecibirmensajes, pero estemodelo no hace referencia losmensajes o almtodo detransportede losmismos.ElModeloOrientadoaServicio se construye sobreelModeloOrientadoaMensajes,perocentrndoseen lasaccionesen lugarde losmensajes. En la figura 8 semuestran algunos conceptos relacionados con estemodeloylasrelacionesexistentesentreellos.

Figura6.Modeloorientadoaservicios[1]

2.3.3. ModeloorientadoarecursosEstemodelosecentraenaquellosaspectosdelaarquitecturarelacionadosconlosrecursosyelmodelodeservicioasociadoconlamanipulacindelosmismos.El Modelo Orientado a Recursos se construye sobre el Modelo Orientado aServicios, principalmente por el desarrollo del modelo de servicio asociado alrecursoyel conjuntodeaccionespara sumanipulacin. La funcinprincipaldeestapartedelaarquitecturaesexplicarlaWebens,ycmoserelacionaconlosserviciosweb.Estemodelo intentaexplicarestoltimomostrando comoun losrecursos son un concepto independiente, y como lamanipulacin de stos sonsolamente una instancia del Modelo de Servicios, slo que con sus propiosserviciosyaccionessobrelosrecursos.Acontinuacinenlafigura9,semuestranalgunosconceptosrelacionadosconestemodeloylasrelacionesexistentesentreellos.



Figura7.Modeloorientadoarecursos[1]

2.3.4. ModelodePolticasEstemodelosecentraenaquellosaspectosdelaarquitecturarelacionadosconlaspolticas,yporextensin,conlaseguridadylacalidaddelservicio.Elconceptodepolticaesmuysimple,essimplementeunarestriccinsobreelcomportamientode los agentes y los servicios. La seguridad, es bsicamente un conjunto derestricciones respecto del comportamiento de las acciones y del acceso a losrecursos.Demanerasimilar,lacalidadseconsideratambinuntipoderestriccinque puede ser aplicada a los servicios. En el Modelo de Polticas, estasrestricciones semodelanalrededorde losconceptosdepolticay sus relacionesconotroselementosdelaarquitectura,porello,elModelodePolticasresultaserunmarco de trabajo en el que implementar la seguridad. Sin embargo, existenmuchos otros tipos de restricciones y polticas relevantes a los SW, incluyendorestriccionesaniveldeaplicacin.

Figura8.ModelodePolticas[1]



III. ESTANDARESYESPECIFICACIONESRELACIONADOSCONLOSSERVICIOSWEBEn la actualidad existen organizaciones relacionadas con la definicin de estndares yespecificaciones, estas se encuentran en constante trabajo, buscando que los serviciosweb sean cada vez ms interoperables y seguros. Una breve descripcin de estasorganizaciones,obtenidade[11]sedetallaacontinuacin:WebServicesInteroperabilityOrganization(WSI),Esunaorganizacindeindustriaabiertaquebuscapromoverlainteroperatibilidaddelosservicioswebentreplataformas,sistemasoperativosylenguajesdeprogramacin.Lacomunidadagrupaorganizaciones ldereseneldesarrolloservicioswebqueayudanadesarrollar servicios web interoperables proporcionando direccin, practicasrecomendadas y soporte de recursos. Especficamente,WSI crea, promueve y apoyaprotocolosgenricosparael intercambio interoperabledemensajes entre los serviciosweb.WorldWideWebConsortium(W3C)fuecreadaenoctubrede2004paradirigirelWorldWideWebdesarrollandoprotocoloscomunesquepromuevansuevolucinyasegurensuinteroperabilidad. ElW3C esta conformado pormas de 350 organizaciones de todo elmundoyhaganadoreconocimientointernacionalporsuscontribucionesalcrecimientodela web. ElW3C esta diseando la infraestructura, y definiendo la arquitectura y lastecnologasbaseparalosserviciosweb.Internet Engineering Task Force (IETF) Esuna gran comunidad internacional abiertadediseadoresde red,operadores,vendedorese investigadores referidoscon laevolucindelaarquitecturadeinternetysuoperacin.Organization for theAdvancementof Structured Information Standards (OASIS) Esunconsorcio internacional sin fines de lucro que conduce el desarrollo, convergencia yadopcindeestndaresebusiness.Elconsorcioproducemsestndaresdeservicioswebque cualquier otra organizacin junto con estndares para seguridad, ebusiness, yesfuerzosdeestandarizacin enel sectorpblico ymercadosdeaplicacinespecifica.Fundadoen1993,OASIS tienemsde4000participantes,representando amsde600organizacionesymiembrosindividualesen100pases.Acontinuacinsemuestraelncleodeestndaresparalosserviciosweb.Laseparacinentrecapasindicalasdependenciasaproximadasentreestas.
http://www.oasis-open.org/



Figura9.Piladeserviciosweb[1]

Comunications transporte: La especificacin de los estndares de servicios web

(SOAP y WSDL es esencialmente independiente del medio de transporte. Lainteroperabilidad garantiza aHTTP como protocolo usado para transmitirmensajesSOAP, lo que no quita que se pueda utilizar cualquier otro protocolo para lamensajera.

Mensajera:SOAPestenelncleode lacapade lamensajeraen losserviciosweb.SOAPdefineunmodelodecodificacinextensible,basadoenXML.LaimportanciadeSOAPesquebrindaelmarcoparaconstruirlaoperabilidadonthewireentiempodeejecucin. La capa de mensajera tambin est diseado para convivir con otrosprotocolosdemensajeranoXML

Descripciones:Alserdbilmenteacoplado,elmodeloorientadoaservicios requierequeseexplicitenlascapacidadesylosrequisitosdelservicioofrecido.Sedasoportealadescripcindeserviciosendosniveles.Ladefinicinfuncional(quhaceelservicio)en la formade lenguajededefinicinde interfaces (basadoenXML) loproporcionaWSDL. ste describe los protocolos especficos de transporte y el modelo demensajera a utilizar para interactuar con el mismo. Las descripciones sobre losrequisitosdecalidaddelservicio (Comoseutilizaelservicio)seofrecenenformade"polticas de servicio web", codificando informacin tal como los requisitos deseguridaddelservicio,losprotocolosfiablesdemensajeraaseguirolosrequisitosdeprivacidad.LaespecificacinWSPolicydefineun lenguajesimpleparacodificarestosrequisitos.

Procesos:EstacapaincluyeprocesostalescomoeldeDescubrimiento,lacoordinaciny la negociacin de la interaccin. El primero nos brinda la capacidad de descubrirdinmicamentenuestros serviciosweb,de vincularlos yde interactuar conellos. Laespecificacin UDDI (Universal Description, Discovery and Integration) define elservicioypermiteeldescubrimientodeserviciosbasadosensufuncinycapacidadesdeclaradas,pudindose,enlosentornosmsdinmicos,definircontratosqueregulenla interaccinentredossociosdeserviciosrespectoacaractersticasde laprestacindelservicio,consideracionesfinancieras, legales,etc.Estosepuedeespecificarenun



formato legible por la mquina. La capacidad de negociar estos contratosdinmicamente ser de vital importancia para llevar a cabo la visin completa delparadigmadelaorientacinaservicios.

Asimismoen[3],podemosencontrarunarepresentacingraficayagrupacindetodoslosestndaresyespecificaciones.

Figura10.Estndaresyespecificacionesrelacionadosalosserviciosweb[3]

Laagrupacindeestosestndares, lascualesseobtuvieronde [3]y [11] ,sedescribeacontinuacin: Transporte

BEEP,elprotocoloextensiblede intercambiodebloques(BlocksExtensibleExchangeProtocol BEEP),referidogeneralmentecomoBXXP,esunframeworkparaconstruirprotocolosdeaplicacin.HasidoestandarizadoporelIETF(InternetEngineeringTaskForce)yesparalosprotocolosdeinternetcomoXMLloesparalosdatos.

MensajesEstasespecificacionesyestndaresdemensajesintentanproporcionarunframeworkparaelintercambiodeinformacinenunentornodistribuidoydescentralizado.SOAP1.1(Note)SOAP1.2(Specification)WebServicesAddressingWebServicesNotification(WSBrokeredNotification,WSBaseNotification,WSTopicsWebServicesAttachmentsProfile1.0MTOMSerializationPolicyAssertion(WSMTOMPolicy)Version1.0

DescripcinydescubrimientoLosservicioswebsonsignificativossolosi losusuariospotencialespuedenencontrarinformacin suficienteparapermitir suejecucin.Elenfoquedeestosestndaresyespecificacionesesladefinicindeunconjuntodeserviciosqueapoyenladescripciny descubrimiento de los negocios, organizaciones y otros proveedores de serviciosweb; losservicioswebquehacendisponiblesy las interfacestcnicasquesepuedenutilizarparateneraccesoaestosservicios.UDDI3.0WSDL1.1(Note)WSDL1.2(Workingdraft)
http://www.ibm.com/developerworks/webservices/library/x-beep/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/x-beep/?S_TACT=105AGX04&S_CMP=LPhttp://www.w3.org/TR/2000/NOTE-SOAP-20000508/http://www.w3.org/TR/soap12-part0/http://www.ibm.com/developerworks/webservices/library/specification/ws-add/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-notification/?S_TACT=105AGX04&S_CMP=LPhttp://www.ws-i.org/Profiles/AttachmentsProfile-1.0.htmlhttp://www.ibm.com/developerworks/webservices/library/specification/ws-mtom/?S_TACT=105AGX04&S_CMP=LPhttp://uddi.org/pubs/uddi_v3.htmhttp://www.w3.org/TR/wsdlhttp://www.w3.org/TR/2003/WD-wsdl12-20030611/



WSDL2.0(WorkingGroup)WebServicesSemanticsWSDLSWebServicesMetadataExchangeWebServicesPolicyAssertionsLanguageWebServicesPolicyAttachmentWebServicesPolicyFrameworkWebServicesResourceFramework

Confiabilidad

No es posible solucionar aspectos del negocio si los participantes no pueden estarseguros de la culminacin exitosa del intercambio de mensajes. La mensajeraconfiable que permite que los mensajes sean entregados confiablemente entreaplicacionesdistribuidasenpresenciadecomponentessoftware,sistemasofallasdelared,esporlotantocriticoenlosserviciosweb.WebServicesReliableMessagingWSRMPolicyAssertion

Transacciones

Las transacciones son un concepto fundamental en la construccin de aplicacionesdistribuidasconfiables.Unentornodeservicioswebrequiereuncomportamientodecoordinacin proporcionado por un mecanismo de transaccin tradicional paracontrolarlasoperacionesyelresultadodeunaaplicacin.WebServicesAtomicTransactionWebServicesBusinessActivityWebServicesCoordination

Seguridad

Usando estas especificacionesde seguridad, las aplicacionespueden garantizarunacomunicacin seguradiseadapara trabajar conun frameworkde servicioswebengeneral.WebServicesFederationLanguageWSFederation:ActiveRequesterProfileWSFederation:PassiveRequesterProfileWebServicesProvisioningWebServicesSecureConversationLanguageWebServicesSecurity1.0WebServicesSecurityAddendumWSSecurityKerberosBindingWebServicesSecurityPolicyWebServicesTrustSecurityAssertionMarkupLanguage(SAML)

Procesosdenegocio

Unprocesodenegocioespecificaunordendeejecucinpotencialdeoperacionesdeunacoleccindeserviciosweb, losdatoscompartidosentreestosserviciosweb,quesociosestn involucradosycomoellosestn involucradosenelprocesodelnegocio,junto con elmanejo de excepciones para las colecciones de serviciosweb y otros
http://www.w3.org/2002/ws/desc/http://www.ibm.com/developerworks/webservices/library/specification/ws-wsdl-s/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-mex/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-polas/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-polatt/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-polfram/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-resource/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-rm/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-rmreload/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-tx/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-tx/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-tx/http://www.ibm.com/developerworks/webservices/library/ws-fed/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-fedact/http://www.ibm.com/developerworks/webservices/library/ws-fedpass/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-provis/http://www.ibm.com/developerworks/webservices/library/specification/ws-secon/?S_TACT=105AGX04&S_CMP=LPhttp://www.oasis-open.org/specs/#wssv1.0http://www.ibm.com/developerworks/webservices/library/ws-secureadd.html?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-seckerb/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/ws-secpol/?S_TACT=105AGX04&S_CMP=LPhttp://www.ibm.com/developerworks/webservices/library/specification/ws-trust/http://xml.coverpages.org/saml.html



aspectos involucrados como serviciosmltiples yorganizacionesparticipantes.BPELespecificaelprocesodenegocioycomolosservicioswebserelacionan.WSBPELExtensionforPeopleBusinessProcessExecutionLanguageforWebServicesV1.1

Administracin

Laadministracindeservicioswebesdefinidacomounconjuntodecapacidadesparadescubrir la existencia, disponibilidad, funcionalidad, rendimiento, uso, asi como elcontrolyconfiguracindeunserviciowebconlaarquitecturadeserviciosweb.Pueslosserviciosweblleganinfluyentesycrticosparalaoperacindelnegocio,latareadeadministrarloseimplementarlosesimperativaalxitodelasoperacionesdelnegocio.WebServicesDistributedManagementWebServicesManageabilityWebServicesManageabilityConceptsWebServicesManageabilityRepresentationWSResourceTransferWebServicesServiceRegistryandRepository

Enlasiguientefigurasepresentatodoslosestndaresyespecificacionessegn[11]

FiguraNo.11.Piladeestndaresyespecificacionesdelosserviciosweb[11]



Enlosprrafossiguientespresentaremosunbreveresumendelosprincipalesestndaresyespecificacionesdelosservicioswebysusaspectosprincipales.

3.1. SOAP(SimpleObjectAccessProtocol)ElestndarSOAP(ensuversinactual1.2,recomendadoporW3Censusegundaedicinenel2007[10])defineunprotocoloquedasoportealainteraccin(datos+funcionalidad)entreaplicacionesenentornosdistribuidosyheterogneos,yes interoperable,esdecir,neutral a la plataforma, lenguajes de programacin, independiente del hardware yprotocolos. Funciona sobre la infraestructura (estndares) existentes en Internet. SOAPdefine cmo organizar la informacin XML de unamanera estructurada y tipada paraintercambiarla entre losdistintos sistemas. Elprotocolo SOAP simplifica el acceso a losobjetos, permitiendo a las aplicaciones invocar mtodos de objetos o funciones, queresidenensistemasremotos.

En [12] se indica que SOAP es fundamentalmente un paradigma de intercambio demensajesenunslosentido,sinestado,pero lasaplicacionespuedencrearpatronesdeinteraccin ms complejos (por ejemplo, peticin/respuesta, peticin/respuestasmltiples, etc.) combinando tales intercambios de un solo sentido con caractersticasproporcionadasporelprotocoloutilizadoy/o informacinespecficade laaplicacinencuestin. SOAP no interfiere en la semntica de cualesquiera datos especficos deaplicacinquecomunica,nitampocoenasuntostalescomoenenrutamientodemensajesSOAP, transferenciadedatos fiables,cortafuegosqueatraviesa,etc.Noobstante,SOAPproporciona elmarco de trabajo por el que la informacin de aplicaciones especficaspuede comunicarse de forma extensible. Tambin, SOAP proporciona una descripcincompletadelasaccionesquedeberealizarunnodoSOAPalrecibirunmensajeSOAP.

En[13],detallaqueSOAPespecifica: Un formato demensaje para una comunidad unidireccional, describiendo cmo se

empaquetalainformacinendocumentosXML. UnconjuntodeconvencionesparausarmensajesSOAP,para implementarelpatrn

de interaccinRPC,definiendo cmo los clientespueden invocarunprocedimientoremotoenviandounmensajeSOAPycmo losserviciospuedenresponderenviandootromensajealllamador.

Un conjunto de reglas que una entidad que procesamensajes SOAP debe seguir,definiendoenparticularloselementosXMLqueunaentidaddebeleeryentender,ascomo las acciones que deben tomar si no entienden el contenido (reglas decodificacindedatos).

UnadescripcindecmosedebetransportarunmensajeSOAPsobreHTTPySNMP.Se definirn bindings a otros protocolos de transporte en futuras versiones de laespecificacin.

LosmensajesSOAPsonfundamentalmentemensajesenunadireccin,desdeunemisor(cliente) hacia un receptor (servidor), y las comunicaciones son del tiporequest/response.Todos losmensajessondocumentosXMLconsupropioesquema,queincluyesuspropiosespaciosdenombres(namespaces),elementosyatributos.



SOAP define dos namespaces: envelope y encoding. Como caracterstica destacable,podemosdecirquenopuede tenerDTDasociados. LosmensajesSOAP constande tressecciones(verfigura4):envelope,headerybody. Envelope(envoltura):Eselelementorazdelmensajeparadescribirsucontenidoyla

formadeprocesarlo. Header(encabezado):informacindeidentificacindelcontenido. Body(cuerpo):eselcontenidodelmensaje.

Figura12.SeccionesdeunmensajeSOAP

Se pueden realizar extensiones al protocolo; esto es posible gracias a la adiccin demdulosdefuncionalidad.Esteenfoquepermitealosdesarrolladoresusarlosmdulosyfuncionalidadesquenecesiten,sinlanecesidaddetenerqueimplementarlatotalidaddeestos.Enpocaspalabras,elprotocolopuede serextensible.Algunasde lasextensionesmsimportantesquesepuedenrealizarsonlasquesemuestranacontinuacin: Attachments: Hace referencia a la posibilidad de incluir un documento no XML, o

archivo binario, enviar documentos de fax, imgenes de medicina, dibujos deingeniera,ocualquierotrotipodeimgenes,codificadasenBase64.

Routing/Intermediaries:RelacionadasconelprocesodeencaminarmensajesSOAPatravs de intermediarios. Este mecanismo ofrece la posibilidad de agregar variosserviciosWebyofrecerloscomopartedeunpaquete.Estoesunatareaquepermitehacer los servicios Web escalables a travs del direccionamiento, incluso, haciamltiplesservidores.

ReliableMessaging:Determina cuanto tiempo espera un servidor cuando enva unmensajeyesperaporlarespuesta.

Security:Estaextensinnospermitirdarunmarcodeseguridada lacomunicacin.Algunos de los aspectos podran ser aplicar SSL, firma digital, etc.Mediante XMLSignaturepodemosproporcionar integridad,autenticacindemensajes,y/oserviciosdeautenticacindefirmas.

Quality of Service (QoS): Es una medida para calificar la calidad del servicio,determinandolausabilidadyutilidaddelservicio.

Context/Privacy:Referenciaalosmecanismosparaguardarelcontextoylaprivacidaddelentornodelosusuarios.



TransactionSupport: Permitequeungrupodeoperacionesoaccionessecomportencomosifueranunasimpleunidad(otodofallaotodoesunxito).

EncuantoalrendimientodelosmensajesdeSOAPutilizandoHTTPyXML,comparadoconelrendimientodemensajesbinariosutilizadosporCORBA,DCOMyRMI,sepuedeafirmarque en el caso de los ltimos, tanto el destinatario y remitente tienen conocimientocompletodelcontenidodelmensajeynocodificanmetainformacincomolosnombresotipodeargumentos.Quizsestemtodoseaeficiente,perodificultaa los intermediarioselprocesamientodemensajes.Ydebidoaquecadasistemautilizaunacodificacinbinariadistinta,dificultalaconstruccindesistemasinteroperables.DadoqueSOAPutilizaXMLparacodificarmensajes,esrelativamentesencilloprocesarlosmensajes en cadapasodelprocesode llamada.Adems, la facilidadde depuracin demensajesSOAPpermitelaconvergenciarpidadelasdiversasimplementacionesdeSOAP,locualesimportanteenlainteroperabilidadagranescala.

3.2. WSDL(WebServiceDescriptionLanguage)ElWSDL(WebServiceDescriptionLanguage)[8],creadooriginalmenteporIBM,MicrosoftyAriba.TieneunrolyunpropsitosimilaraldelosIDL(InterfaceDefinitionLanguage)delas plataformasmiddleware es decir, ofrecer un software de conectividad que permiteofrecer un conjunto de servicios que hacen posible el funcionamiento de aplicacionesdistribuidassobreplataformasheterogneas.UnarchivoWSDLesundocumentoXMLquedescribe los servicios Web, en particular sus interfaces. Como caracterstica que lodiferenciade losIDL,esqueWSDLdebedefinir losmecanismosdeacceso(protocolos)alos serviciosWeb. Otra caracterstica diferenciadora es la necesidad de definir (en laespecificacin) la localizacindel servicio (puntos finales). La separacinde interfaces yenlaces de protocolos, y la necesidad de incluir informacin de localizacin permite ladefinicindeespecificacionesmodulares.WSDLpermitedefinir interfacesmscomplejasy expresivas; permitiendo definiciones de interacciones asncronas y diferentesparadigmasdeinteraccin,ylaposibilidaddecombinaroagruparoperaciones.Enlafigura3,semuestraundiagramacon laarquitecturade lossistemasbasadosenserviciosWeb,enelqueserepresentanlosestndaresdescritos.

WSDLesunformatoXMLquedescribelosserviciosderedcomounconjuntodeendpointsqueprocesanmensajescontenedoresdeinformacinorientadatantoadocumentoscomoa procedimientos. Las operaciones y losmensajes se describen de forma abstracta, ydespusseenlazanaunprotocoloderedyaunformatodemensajeconcretoparadefinirun endpoint de red. Los endpoints concretos relacionados se combinan en endpointsabstractos(servicios).

El lenguajeWSDLesextensible, loquepermite ladescripcindeendpointsde redysusmensajes, independientemente de los formatos de los mensajes o protocolos de redutilizadosparacomunicarse.

EldocumentoWSDLdeunservicioproporcionadospiezasdeinformacinbsicas:(1)unaparteointerfaceabstracta(independientedelaaplicacin)y(2)unaparteespecfica,que



define losenlacesaprotocolose informacinde lospuntos finalesdeaccesoalservicio.Verfigura5.

Figura13EstructuradeundocumentoWSDL

Laparteabstractaestcompuestapor: Definicionesdeport types:anlogosa los interfacesen IDL.Cadaport typeesuna

coleccinlgicadeoperations. Operations:Cadaoperationdefineunintercambiosimpledemensajes. Message:Unmessageesunaunidaddecomunicacinquerepresentaunintercambio

dedatosenunanicatransmisinlgica. Types: Un sistema de tipos (types) usados por las operations (por defecto XML

Schema).

Laparteespecficaestcompuestapor: DefinicionesdeBindings:seespecificalacodificacindelosmensajes,ylosenlacesa

protocolosdetodaslasoperacionesymensajesdefinidaenunporttype. Definiciones de Ports: se especifica en qu direccin (URI) se puede acceder a la

implementacindelporttype.Definenunpunto final (lugarde lared)dondeestelservicio.

DefinicionesdeServices:definenunaagrupacindePorts.

Esta es la forma que tieneWSDL de describir los serviciosWeb, en trminos de losmensajesqueaceptaygenera.Actacomocontratoentreunconsumidor(cliente)ydichoservicio.WSDLpuededescribirpuntosfinalesysusoperacionessinespecificarelformatode losmensajeso losprotocolosde red (SOAP,HTTPGET/POSTyMIME)a loscualeselpuntofinalestligado.

EllenguajededescripcindeserviciosWebes,porlotanto,elequivalenteaunresumendiseadoenXML,enelcualsedescribenlosserviciosWeb,indicandodndeseubicanylaformadeinvocarlos.AcontinuacinsemuestraunejemplodedocumentoWSDL.



3.3. UDDI(UniversalDescriptionDiscoveryandIntegration)El UDDI[9], es un directorio que contiene un registro/repositorio de descripciones deserviciosWeb.EsteestndarpermitealasempresasregistrarseenuntipodedirectoriodeInternetque lesayudaaanunciar sus servicios,de tal formaqueel restodecompaaspuedan localizarsusserviciosyrealizartransaccionesen laWeb.Elprocesoderegistroyconsultas se realiza utilizandomecanismos basados en XML yHTTP(S). Por lo tanto, laespecificacinUDDItienedosobjetivosesenciales,enprimerlugarservirdesoportealosdesarrolladores para encontrar informacin sobre servicios Web y poder construirclientes; y por otro lado, facilitar el enlace dinmico de servicios Web, permitiendoconsultarreferenciasyaccederaserviciosdeinters.

Siemprehasidounretolacomunicacinentrelosnegociosaniveldeaplicaciones,dadalaenorme cantidad de plataformas, herramientas,mecanismos y procesos que cada cualutiliza. XML se presenta como la solucin para el intercambio de datos de una formatransparente. Tambin, la evolucin de protocolos como SOAP, ya comentadoanteriormente,proporcionaunaplataformaparaelintercambiodeserviciossobrelared.Si el mecanismo de comunicacin entre las plataformas es el XML, y la forma decomunicacinesSOAP,lacuestinqueseplanteaescmoencontraralasorganizacionesqueproporcionanserviciosconlosquecomunicarse.LarespuestaeselUDDI.UDDI,aunquefuecreadooriginalmenteporIBM,MicrosoftyAriba,desdesuversin3,laorganizacinOASIS[14]seencargadesumantenimiento.UDDI se concibi como un registro de negocio, es decir un servicio de directorio y unnombrado sofisticado conjuntamente. Especifica un marco para describir y descubrirserviciosWeb.UDDIdefine estructurasdedatos yAPIsparapublicardescripcionesdeserviciosenelregistro,ymtodosdeconsultaparabuscardescripcionespublicadas.LasAPIsdeUDDIestnespecificadasconWSDLyconSOAPBinding,loquepermiteaccederaellascomoserviciosWeb.La especificacin UDDI tiene dos objetivos esenciales: (1) ser un soporte a losdesarrolladores para encontrar informacin sobre servicios Web y poder construiraplicacionesclientesquelosinvoquen,y(2)facilitarelenlacedinmicodeserviciosWeb,permitiendoconsultar referenciasyaccederaserviciosde inters.La informacinenunregistroUDDIsealmacenaenficherosXMLconunaestructura jerrquica.Loselementosbsicosdeestaestructurason: BusinessEntity:Eselelementotoplevel,describeunnegocioounaentidadqueha

registradounservicioenUDDI. BusinessService:DescribeunservicioWebquehasidoexpuestoporunaentidadde

negocio, soporta el nombrado de un servicioWeb y lo asocia con una entidad denegocioyconlainformacindebinding.SoportalaasignacindecategorasalservicioWeb(industria,productos,cdigosgeogrficos,etc.).

BindingTemplate: Describe la informacin tcnica necesaria para enlazar con unservicioWebenparticular.EsteelementosoportaelnombradodeunservicioWebysuasociacinconunaentidaddenegocioeinformacindebinding.LainformacindebindingsedescribecomounpuntodeaccesoqueposeeunatributollamadoUrlTypeutilizado para especificar los siete puntos de entrada:mailto, http, https, ftp, fax,phone,other.



tModel: Estructura demetadatos genrica para representar cualquier concepto oconstruccin (definicionesdeprotocolos, ficherosWSDL,XMLSchemas,espaciosdenombres,esquemasdecategoras,etc.).

Figura14.EstructuradedatosUDDI

Conceptualmente,lainformacinproporcionadaporunaorganizacinqueofreceserviciosWebenunregistroUDDIconstadetrescomponentes: Seccin Blanca: Es muy similar a la informacin que aparece en un directorio

telefnico,queincluyedireccin,contactoyotrosidentificadoresconocidos. SeccinAmarilla:Esmuysimilarasuequivalentetelefnico,e incluyecategorasde

catalogacin industrial tradicionales, ubicacin geogrfica, etc.Mediante el uso decdigosyclavespredeterminadas, losproveedoresdeserviciossepuedenregistraryas facilitar a pospotenciales usuarios de sus servicios la bsqueda usando estosndicesdeclasificacin.

Seccin Verde: Contiene la informacin tcnica de los servicios ofrecidos por losproveedores.Se incluyen referenciasdeespecificacionesde serviciosWebas comoinformacincomplementariapara losmecanismosdiversosdebsquedabasadosenURL.

3.4. WSSECURITY

Estaespecificacinmanejaelcifradoy firmasdigitales,permitiendocrearunaaplicacinen la cual losmensajesnopuedan serescuchados ilegalmente yquelno repudio seaposible.DescribeampliacionesparalosmensajesSOAPproporcionandocalidaddeproteccinconintegridaddemensajes,confidencialidaddemensajesyautenticacinsimpledemensajes.Laespecificacinproporcionaunconjuntodemecanismosparaayudaradesarrolladoresdeservicioswebaasegurarel intercambiodemensajesSOAP.Estosmecanismosbsicosde seguridad pueden combinarse de varias formas para acomodar una variedad demodelosdeseguridadusandounavariedaddetecnologasdecifrado.Estosmodelosdeseguridadsedescribenen[15]yseresumenacontinuacin: ModelodeSeguridaddeMensajes:Especificaunmodelodeseguridaddemensajes

abstracto en trminosde seguridadde tokens combinado con firmasdigitalespara



proteger y autenticar mensajes SOAP. Los tokens de seguridad afirman validez ypuedenserusadosparaafirmarelenlaceentrelossecretosdeautenticacinoclavesylasidentidadesdeseguridad.

Proteccin de Mensajes: Proteger el contenido del mensaje de ser divulgado(confidencialidad) o modificado sin deteccin (integridad) son las principalespreocupacionesdelaseguridad.Estaespecificacinproveeunmedioparaprotegerunmensaje por cifrado y/o firma digital de un cuerpo, una cabecera o cualquiercombinacin deellos(opartesdeellos).La integridadde losmensajesestprovistopor una firma XML en conjunto con tokens de seguridad que aseguran que lasmodificaciones a mensajes sean detectados. Los mecanismos de seguridad sondiseadosparasoportarmltiplesfirmas,potencialmentepormltiplesactores/rolesSOAPyparasonextensiblesparasoportarformatosdefirmaadicional.

Demandasprdidaso invalidas:Unrecipientedemensajesdeberechazarmensajesconteniendofirmasinvlidas,demandasdemensajesperdidosomensajesquetienenvalores inaceptables. Dichos mensajes son no autorizados (omalformados). Estaespecificacinproveeunaformaflexibleparaqueelproductordemensajeshagaunademanda sobre las propiedades de seguridad asociando cero o ms tokens deseguridadconelmensaje.

HaytresproblemasprincipalesinvolucradosenlaseguridaddelintercambiodemensajesSOAP,ylosWSSecurityproveenrespuestasparatodoellos,peronodirectamente.Esdehecho, una especificacin que habla no sobre cmo proteger el mensaje, sino comopermitiralreceptorqueconozcacmohasprotegidoelmensaje.El primer problema es identificar y autenticar el cliente. Porque hay muchas formasdiferentesdecreartokensdeseguridad,WSsecuritynoespecificaunmedioenparticular,perodefinealgocomotokensdeseguridaddiferentesdebensertransferidos dentrodemensajesSOAP.Esdecir,sedejaal receptorconocercomoextraer tokensdeseguridaddelmensajeparaprocesar.El segundo problema es asegurar la integridad del mensaje. WSSecurity usa firmasdigitalesparaeso,empleando laespecificacinde firmasXMLmasque inventandoalgonuevo. La firma XML es una recomendacin delW3C que provee unmecanismo parafirmardigitalmentedocumentosXML.El tercer problema est en mantener el mensaje seguro y evitar que sea escuchadoilegalmentemientrasestaentrnsito.Unavezms,WSSecurityempleaotroestndardelW3C,elcifradoXML,queproporcionaunmecanismoparacifrardocumentosXML.

WSSecuritydefinecomoagregarfirmasXMLycabecerasde cifradoXMLparamensajesSOAP.EnlasiguientefigurasemuestracomoseintegraWSSecurityaSOAP.



Figura15.WSSecurityintegradoconSOAP

3.5. WSPOLICYEstaespecificacinampliaelWSSecurity,permitiendodetallarmsespecficamentecmoyporquienunserviciopuedeserusado.ElframeworkWSPolicicy,esunaespecificacinquepermiteaunserviciowebtenerunconjuntodereglasquedebenserresueltas,oconsumidas.Losautoresdeclientesdeservicioswebdebenentoncesestudiarlainformacindelaspolticasparaversipuedenonoadherirseaestaspolticas.As,unclientenopodraserinscritoparaaccedersimplementeaunserviciowebquetengaunapolticaquerequierequetodoslosmensajesseanencriptadosofirmadosdealgunamanera.ElW3CdescribeelmodelodeSWPOLICYen[16],elcualconstade: Policy Assertion (Poltica de asercin) una poltica de asercin identifica un

comportamientoqueesunrequerimiento(ocapacidad)deuntema,indicasemnticadedominioespecifico(porejemplo,seguridad,transacciones)yesperanserdefinidasenespecificacionesseparadasydedominioespecifico.

PolicyAlternative (Poltica alternativa)unapoltica alternativa esuna construccinlgica que representa una coleccin potencialmente vaca de polticas de asercin.Una poltica sin aserciones indica sin comportamiento.Una poltica con una omsasercionesindicacomportamientoimplicadoparaaquellasysoloaquellasaserciones.

El vocabulario de una poltica alternativa es un conjunto de todos los tipos deasercionesdentrode laalternativa.Elvocabulariodeunapolticaesunconjuntodetodoslostiposdeasercionesusadosentodaslaspolticasalternativasenlapoltica.Unaasercincuyotipoespartedelvocabulariodeunapolticaperooestincluidoenunaalternativaesexplcitamenteprohibidoporlaalternativa.Lasasercionesdentrodeunaalternativano sonordenadas, y losaspectos comoelordenenlacualescomportamientoesaplicadoaunsujetoestnmasalldelalcancedeestaespecificacin.

Poltica: A nivel abstracto una poltica es una coleccin potencialmente vaca depolticas alternativas.Una poltica con cero alternativas no contiene opciones; una



polticaconunaomsalternativasindicaseleccinenrequerimientos(ocapacidades)dentrodelapoltica.Lasalternativasno sonordenadas, yas losaspectos tales comopreferenciasentrealternativasenuncontextodatovanmsalldeestaespecificacin.

Web services: Aplicado en elmodelo de serviciosweb, una poltica es usada paratransportarcondicionesenunainteraccinentredosserviciosweb.Lasatisfaccindeaserciones en la poltica usualmente da como resultado un comportamiento quereflejaestas condiciones.Tpicamenteelproveedordeun serviciowebexponeunapoltica para transportar condiciones, bajo las cuales proporciona el servicio. Unsolicitantepuedeusarestapolticaparadecidirsiutilizaonoelservicio.Unsolicitantepuedeescogercualquieralternativapuestoquecadauna,esunaconfiguracinvlidapara la interaccin conelservicio,perounsolicitantedebeescogersolounasimplealternativaparauna interaccinconunserviciopuestoquecadaunorepresentaunaconfiguracinalternativa.

3.6. WSIAunquelosservicioswebsesuponefuerondiseadosparalainteroperatibilidad,enlaactualidadhaybastanteflexibilidadenlasespecificaciones,yquelasinterpretacionesentrediferentesimplementacionespuedecausarproblemas.WSIproporcionaunconjuntodeestndaresyprcticasparaprevenirestosproblemas,ascomopruebasestandarizadasparaverificarsihayproblemas.Elprimerdesafoescomprenderelproblemadelainteroperatibilidadysuimportanciaenelmundodelosserviciosweb.Losservicioswebhoysonconstruidosusandounacomplejafamiliadetecnologasrelacionadasyestndares,quegeneranmuchasfuentesdetemasrelacionadosconlainteroperatibilidad.ElWSIdefinidoenelBasicProfileVersion1.0porelWebServiceInteroperatibilyOrganizacin[17],consistedeunconjuntodeespecificacionesdeservicioswebnopropietarios,juntoconaclaracionesyenmiendasaesasespecificacionesquepromuevenlainteroperatibilidad.

3.7. WSBPELEsunlenguajedecomposicindeServiciosWebOrientadoaProcesos.SebasaenWSDLydehechounprocesoWSBPELpuedeserexpuestoatravsdesupropioWSDLyportantoser invocado como cualquier otro Servicio Web (permitiendo la reutilizacin de losmismos). Naci como combinacin de WSFL (Web Service Flow Language de IBM,orientadoagrafosybasadoenelcontroldeloslinksentretareas)yXLANG(WebServicesforBusinessProcessDesigndeMicrosoft,basadoenuncontroldeflujosconsecuencias,condiciones, bucles, etc) y ha evolucionado adquiriendo lo mejor de cada uno eintentando evitar las malas prcticas de los mismos (debido a que el paradigma deutilizacin de ambos es distinto y a veces de lugar a situaciones de construccinsobrelapadas).WSBPELdefineunconjuntodetareasbsicasparalacomposicindeserviciosweb: Tareas de Invocacin (Invoke): Invocacin de operaciones oneway o request

responseenunservicioweb. Tareas de Recepcin (Receive): Permite el bloqueo de un proceso a la espera de

llegadadeunmensaje.
http://es.wikipedia.org/wiki/WSDL



Tareas de Respuesta (Response): Permite enviar un mensaje en respuesta a unmensajerecibidopreviamente.

TareasdeEspera(Wait):Permitelaesperaduranteuntiempodelproceso. TareasdeAsignacin(Assign):Permitecopiardatosdeunlugaraotro. TareasdeLanzamiento(Throw):Permiteindicarquehaocurridounerror. TareasdeFinalizacin(End):Permitefinalizarlaorquestacindelainstanciaencurso.Adems,lastareasestructuradassonutilizadasparacombinarlasprimitivasenotrasmscomplejas: Tareassecuenciales(sequence):Defineunordensecuencialdetareas. Tareasdedecisin (switch):Permite seleccionarun caminoenparticularenbasea

unacondicin. Tareasdeeleccin:Permitebloquearyesperarlallegadadeunmensajeoestablecer

untiempolmitedeespera(timeout).Cuandounodeloseventosocurre,seejecutanlastareasdesignadas.

Tarearepetitiva(While):Permiterepetirungrupodetareasmientrassecumplaunadeterminadacondicin.

Tareasparalelas:Permiteparalelizarlaejecucindeciertogrupodetareas.WSBPEL trata todos los estados como una coleccin de tipos demensajesWSDL. Esacoleccin demensajes que constituyen un estado es lo que se llama contenedor. Losmensajesdeuncontenedorpuedenser losenviadoso recibidosconclientesoserviciosexternos; incluso losutilizados internamenteporelprocesoparacomputacin temporaldelosmismos.Asimismo,lacomunicacinsedefineatravsdelosPortTypedelosWSDL.WSBPELsostienelaideadeuncontenedorparacadatareaenelflujodefinido,cadaunode los cuales tiene una definicin de esquema. As, unmensaje se corresponde a uncontenedor,quebsicamenteesun servicioweb con informacinadicional sobrecomoprocesarlo,posiblesprecondicionesypostcondiciones.Demodogrfico,unprocesodefinidoenWSBPELtendralasiguienteforma:

Figura16ProcesoWSBPEL



Todos los accesos adatos ymanejosde losmismos enWSBPEL esdefinidoutilizandoestndares como XPath y XSLT, adems de basarse en los contratos de serviciosestablecidospormediodelosWSDL.Durante laejecucindeunproceso sepuedenestablecermsdeunaconversacinconserviciosexternos,por loqueesnecesarioestablecermecanismosaniveldeaplicacinparacorresponderlosmensajesyconversacionesconlasinstanciasdeprocesosqueseanobjetos de losmismos. Para ello,WSBPEL ofrece lo que se conoce como CorrelationSetsoGruposdeCorrelaciones.Estossonconjuntosdepropiedades,que juntossirvenparadefiniruna conversacinaniveldeaplicacindentrodeuna instanciadeproceso.Bsicamente son identificadoresnicosde instanciasdeproceso,quepermite saberentodomomentoque instanciacorrespondeaqumensajerecibidooenviadoatravsdelmismo.WSBPELpuede serutilizado tantoparaorquestacinde servicios (llamadasaprocesosejecutables;entendiendocomotallasllamadasaserviciosylaespecificacindecomosellevan a cabo) como para coreografa de servicios (llamadas a procesos abstractos;entendiendocomotallosmensajespblicosaintercambiarentredosomspartes).Por lo general, la implementacin de WSBPEL vara segn el fabricante y de hechoalgunos lo interpretan como un Script XML que puede ser ejecutado con un motorespecfico;mientrasqueotroslointerpretancomounlenguajedeintercambio.Laltimaespecificacin, la 2.0 incluye nuevas caractersticas como inicializacin de variables,transformacin XSLT de variables, acceso XPath a datos de variables, etc. Estaespecificacinhasidoaprobadael31/01/2007porOASISyse ladocumentacindeesteestndarestdisponibleen[18].

IV. RESTUNAPROPUESTAALTERNATIVAASOAPEnlosltimosaossehapopularizadounestilodearquitecturaSoftwareconocidocomoREST (RepresentationalStateTransfer).EstenuevoestilohasupuestounanuevaopcindeestilodeusodelosServiciosWeb.Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolossimilaresmediante la restriccin de establecer la interfaz a un conjunto conocido deoperacionesestndar (porejemploGET,PUT,).Por tanto,esteestilosecentramseninteractuarconrecursosconestado,queconmensajesyoperaciones.UnejemplodeutilizacindeSOAPyRESTesAmazon,quienposeeambosestilosdeusodesus serviciosWeb.Peroel85%de sus clientesprefieren la interfazREST.Apesarde lapromocinque lasempresashan invertidoparaensalzaraSOAP,parecequeesevidentequelosdesarrolladoresprefieren,enalgunoscasos,laaproximacinmssencilla,REST.

4.1. DEFINICIONElautorde [19] indicaqueRESTesunestilodearquitecturade softwarepara sistemashipermediasdistribuidostalescomolaWeb.EltrminofueintroducidoenlatesisdoctoraldeRoyFielding[20]en2000,quienesunodelosprincipalesautoresdelaespecificacindeHTTP.Enrealidad,RESTserefiereestrictamenteaunacoleccindeprincipiosparaeldiseodearquitecturas en red. Estos principios resumen como los recursos son definidos ydiseccionados. El trmino frecuentemente es utilizado en el sentido de describir acualquierinterfazquetransmitedatosespecficosdeundominosobreHTTPsinunacapa



adicional,comohaceSOAP.Estosdossignificadospuedenchocaro inclusosolaparse.Esposible disear un sistema software de gran tamao de acuerdo con la arquitecturapropuestaporFieldingsinutilizarHTTPosininteractuarconlaWeb.Ascomotambinesposible disear una simple interfaz XML+HTTP que no sigue los principios REST, y encambioseguirunmodeloRPC.CabedestacarqueRESTnoesunestndar,yaqueestansolounestilodearquitectura.AunqueRESTnoesunestndar,estbasadoenlosestndaresHTTP,URL,Representacindelosrecursos(XML/HTML/GIF/JPEG/)yTiposMIME(text/xml,text/html,).

4.2. PRINCIPIOSLosobjetivosdeesteestilodearquitecturaselistanacontinuacin: Escalabilidad de la interaccin con los componentes. La Web ha crecido

exponencialmentesindegradarsurendimiento.Unapruebadeelloseslavariedaddeclientes que pueden acceder a travs de laWeb: estaciones de trabajo, sistemasindustriales,dispositivosmviles,

Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede

interactuarconcualquierservidorHTTPsinningunaconfiguracinespecial.Estonoesdeltodociertoparaotrasalternativas,comoSOAPparalosServiciosWeb.

Puesta en funcionamiento independiente. Este hecho es una realidad que debe

tratarsecuandosetrabajaenInternet.Losclientesyservidorespuedenserpuestasenfuncionamientoduranteaos.Portanto,losservidoresantiguosdebensercapacesdeentenderseconclientesactualesyviceversa.Disearunprotocoloquepermitaestetipo de caractersticas resulta muy complicado. HTTP permite la extensibilidadmedianteelusode lascabeceras,a travsde lasURIs,a travsde lahabilidadparacrearnuevosmtodosytiposdecontenido.

Compatibilidadconcomponentesintermedios.Losmspopularesintermediarosson

variostiposdeproxysparaWeb.Algunosdeellos,lascaches,seutilizanparamejorarel rendimiento. Otros permiten reforzar las polticas de seguridad: firewalls. Y porltimo, otro tipo importante de intermediarios, gateway, permiten encapsularsistemasnopropiamenteWeb.Por tanto, la compatibilidad con intermediariosnospermite reducir la latencia de interaccin, reforzar la seguridad y encapsular otrossistemas.



REFERENCIASBIBLIOGRAFICAS[1] W3CWorldWideWebConsortium.(2004)."WebServicesArchitecture."Accedidoel

16/03/2008,2008,dehttp://www.w3.org/TR/2004/NOTEwsarch20040211/.[2] W3CWorldWideWebConsortium.(2008)."GuaBrevedeServiciosWeb."Accedidoel

11/02/2008,dehttp://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb.[3] IBM.(2008)."StandardsandWebservices."Accedidoel16/03/2008,de

http://www.ibm.com/developerworks/webservices/standards/.[4] M.Endrei,J.Ang,A.Arsanjani,S.Chua,P.Comte,P.Krogdahl,M.Luo,andT.Newling,

Patterns:ServiceOrientedArchitectureandWebServices:InternationalBusinessMachinesCorporationRedBooks,2004.

[5] J.McGovern,S.Tyagi,M.Stevens,andS.Matthew,JavaWebServicesArchitecture.SanFrancisco:MorganKaufmann,2003.

[6] I.Garcia,M.Polo,F.Ruiz,andM.Piattini,Serviciosweb:UniversidaddeCastillaLaMancha,2005.

[7] W3CWorldWideWebConsortium.(2001)."WebServiceDefinitionLanguage(WSDL)."Accedidoel29/03/2008,dehttp://www.w3.org/TR/wsdl.

[8] W3CWorldWideWebConsortium.(2007)."WebServicesDescriptionLanguage(WSDL)Version2.0Part1:CoreLanguage."Accedidoel29/03/2008,dehttp://www.w3.org/TR/wsdl20/.

[9] OASIS.(2004)."UDDISpecTC."Accedidoel30/3/2008,dehttp://www.oasisopen.org/committees/uddispec/doc/spec/v3/uddiv3.0.220041019.htm.

[10] W3CWorldWideWebConsortium.(2007)."SOAPVersion1.2."Accedidoel30/3/2008,dehttp://www.w3.org/TR/soap/.

[11] InnoQ.(2006)."WebServicesStandards:AnoverviewoftheWebservicesstandardslandscape"Accedidoel23/4/2008,dehttp://www.innoq.com/soa/wsstandards/.

[12] W3CWorldWideWebConsortium.(2003)."SOAPVersin1.2Parte0:Fundamentos."Accedidoel30/3/2008,dehttp://www.w3c.es/Traducciones/es/TR/2003/RECsoap12part020030624/.

[13] V.Pelechano,"Serviciosweb.Estandares,extensionesyperspectivasdefuturo,"2005.[14] OASIS.(2007)."OASISStandardsandOtherApprovedWork."Accedidoel30/3/2008,de

http://www.oasisopen.org/specs/index.php.[15] OASIS.(2004)."WebServicesSecurity."Accedido,28/04/2008,dehttp://docs.oasis

open.org/wss/2004/01/oasis200401wsssoapmessagesecurity1.0.pdf.[16] W3CWorldWideWebConsortium.(2006)."WebServicesPolicy1.2Framework(WS

Policy)."Accedidoel5/5/2008,dehttp://www.w3.org/Submission/WSPolicy/.[17] WebServiceInteroperatibilyOrganizacion.(2004)."BasicProfileVersion1.0."Accedidoel

05/05/2008,dehttp://www.wsi.org/Profiles/BasicProfile1.020040416.html.[18] OASIS.(2007)."OASISWebServicesBusinessProcessExecutionLanguage(WSBPEL)TC

PublicDocuments."Accedidoel05/05/2008,dehttp://www.oasisopen.org/committees/documents.php?wg_abbrev=wsbpel.

[19] R.N.Marset.(2006)."RESTVSWEBSERVICES."Accedidoel8/4/2008,dehttp://www.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf.

[20] R.T.Fielding,"ArchitecturalStylesandtheDesignofNetworkbasedSoftwareArchitectures."vol.DoctorofPhilosophyinInformationandComputerScienceIrvine:UniversityofCalifornia,2000.8/4/2008
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/http://www.w3c.es/divulgacion/guiasbreves/ServiciosWebhttp://www.ibm.com/developerworks/webservices/standards/http://www.w3.org/TR/wsdlhttp://www.w3.org/TR/wsdl20/http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htmhttp://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htmhttp://www.w3.org/TR/soap/http://www.innoq.com/soa/ws-standards/http://www.w3c.es/Traducciones/es/TR/2003/REC-soap12-part0-20030624/http://www.w3c.es/Traducciones/es/TR/2003/REC-soap12-part0-20030624/http://www.oasis-open.org/specs/index.phphttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdfhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdfhttp://www.w3.org/Submission/WS-Policy/http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.htmlhttp://www.oasis-open.org/committees/documents.php?wg_abbrev=wsbpelhttp://www.oasis-open.org/committees/documents.php?wg_abbrev=wsbpelhttp://www.dsic.upv.es/%7Ernavarro/NewWeb/docs/RestVsWebServices.pdf