Revisión de Los Servicios Web SOAP/REST

Universidad Revisinde
deVigo:
losServicios
Metodologas
parael
Desarrollode
Serviciosenla
Web
Web
SOAP/REST:
Caractersticas
yRendimiento
AlbertoLosSantosAransay,albertolsa@gmail.com
Marzo2009
0 RevisindelosServiciosWebSOAP/REST:Caractersticas yRendimiento
Marzo 2009
NDICE
1.INTRODUCCIN .............................................................................................................................. 1
2.ARQUITECTURASORIENTADAASERVICIOS .............................................................................. 2
3.SERVICIOSWEB .............................................................................................................................. 6
3.1.SOAPWS ................................................................................................................................... 7
3.1.1.WS* ................................................................................................................................. 11
3.2.ServiciosWebREST .............................................................................................................. 12
3.2.1.ArquitecturaREST .......................................................................................................... 13
3.2.2.Ejemplo............................................................................................................................ 14
4.CARACTERSTICASSOAPyREST ................................................................................................ 17
4.1.DebateSOAPvsREST ............................................................................................................ 18
5.RENDIMIENTO .............................................................................................................................. 20
6.CONCLUSIONES ............................................................................................................................ 23
7.REFERENCIAS ............................................................................................................................... 24
NDICEDEFIGURAS
Figura1:Arquitecturaorientadaaservicios[2]...............................................................................................2
Figura2:LosServiciosWebsebasanenestndaresabiertosparainterconectaraplicacionesy
usuariosindependientementedelasplataformas[3]....................................................................................6
Figura3:InteraccinatravsdeServiciosWeb[9]........................................................................................8
Figura4:Estructuradelosmensajes[10]...........................................................................................................9
Figura5:LosserviciosWebenFuncionamiento[11].................................................................................10
Figura6:EjemploconlasfuncionesdeREST[20]........................................................................................13
Figura7:GoogleApps[29]......................................................................................................................................19
1 RevisindelosServiciosWebSOAP/REST:CaractersticasyRendimiento
Marzo 2009
1.INTRODUCCIN
Coulouris1definilossistemasdistribuidoscomosistemasenlosqueloscomponenteshardware
y/o software existentes en una red de computadoras, se comunican y coordinan sus acciones
medianteelintercambiodemensajes.
Este concepto se ha popularizado durante los ltimos aos, debido a varios factores. El primer
factorqueimpulseldesarrollodesistemasdistribuidosfuelaaparicinderedeslocalesdealta
velocidad. Otro factor importante ha sido el avance tecnolgico en las prestaciones de los
ordenadorespersonalesyeldesarrollodesoftwareparasoportaraplicacionesdistribuidas.
LossistemasdistribuidosseliganconelconceptodeWebeInternet.ConlaevolucindelaWeb,y
laaparicindenuevasreas,interacciones,necesidadesyaplicaciones,surgeelconceptodeWeb
2.0.EstetrminofueacuadoporTimO'Reillyen2004parareferirseaunasegundageneracin
en la historia de la Web basada en comunidades de usuarios y una gama especial de servicios,
comolasredessociales,losblogs,loswikisolasfolcsonomas,quefomentanlacolaboracinyel
intercambiogildeinformacinentrelosusuarios.
Las primeras arquitecturas que pueden considerarse orientadas a servicio (SOA) se basaban en
CORBA(CommonObjectRequestBrokerArchitecture),queactuabacomounacapadeabstraccin
para interconectar los distintos elementos de la arquitectura y construir los servicios. Otras
tecnologas anteriores fueron DCOM (Distributed Component Object Model) o RPC (Remote
ProcedureProtocol).ConlanecesidaddediseareimplementarsistemasdistribuidosenlaWeb
de forma eficiente, surgen diversos desafos, algunos centrados en el propio desarrollo
(rendimiento,experienciadeusuario,etc.)yotroscomplementarios,basadosenlareusabilidady
compatibilidad de los servicios. Sobre estas necesidades aparecen los Servicios Web,
proporcionando mecanismos estndar para interconectar a los distintos usuarios con los
servidoresdeinformacin.
ComoveremosestosserviciosextiendenlascaractersticasbsicasdelasArquitecturasOrientadas
aServicios,focalizandosusobjetivosensercompletamenteinteroperables,ademsdereusables,
destacandotambinpornoserexcesivamenteeficientesenrelacinasurendimiento.
Ladistribucindelpresentetrabajoeslasiguiente:
EnelsiguientecaptuloveremosqusonlasarquitecturasSOA(orientadasaservicio).
Una vez revisados sus principales conceptos, estudiaremos en el captulo 3 los Servicios
Web,ymsconcretamentelasdoslneasactualesmsdestacadas:losServiciosWebSOAP
ylosServiciosWebREST.
En el captulo 4, se revisarn las principales caractersticas de los Servicios Web SOAP y
REST, indicando sus principales beneficios y limitaciones. Adems, se expondr de forma
introductoriaeldebateSOAPvsREST.
En el captulo 5 intentaremos detallar el trabajo existente sobre el rendimiento en los
Servicios Web, aunque no sea el principal objetivo de estos sistemas, es un concepto
fundamentalalahoradeofrecercualquierservicio.
Porltimo,lasconclusionessernrealizadasenelcaptulo6.
http://www.coulouris.net/
Marzo 2009
2.ARQUITECTURASORIENTADAASERVICIOS
Segn[1]SOA(ServiceOrientedArchitectureoArquitecturaOrientadaaServiciosencastellano)
son arquitecturas de software que definen el uso de servicios como soporte a los requisitos del
negocio, cuyo objetivo es alcanzar el mnimo acoplamiento posible entre agentes software. Un
servicio es una unidad de trabajo realizada por un proveedor de servicios para alcanzar un
resultadofinaldeseadoporunconsumidordelservicio.Tantoelproveedorcomoelconsumidor
delserviciosonrolesrealizadosporagentessoftwareenlugardesuspropietarios.
En un sentido general, una arquitectura orientada a servicios es una solucin software que
pretende permitir a la empresa organizar y hacer uso de mltiples procesos. Con SOA, las
aplicaciones software ya no son enormes bloques de funciones y procesos. En cambios, estas
aplicaciones se componen de servicios modulares ensamblados. Recordemos que un servicio es
una funcin software simple (como por ejemplo, cancelar la reproduccin de un CD). Puede ser
ejecutada bajo demanda por cualquier sistema, sin tener en cuenta el sistema operativo,
plataforma,lenguajedeprogramacinoposicingeogrfica.
LoqueesrevolucionarioacercadeSOAnoeselconceptoensmismo,elcualhaestadopresente
desdehacetiempo,sinoelhechodequesepuedeimplementaratravsdelaWWW(WorldWide
Web).Delamismaformaquelaspginaswebsecarganencualquierplataforma,losserviciosweb
trabajan de forma similar, sin tener en cuenta la plataforma, ya que se construyen utilizando
estndaresuniversales.
Figura1:Arquitecturaorientadaaservicios[2]
Suenademasiadoabstracto,perorealmenteSOAseencuentranactualmenteentodosloslugares.
Porejemplo,sitenemosunreproductorMP3yqueremosescucharunacancin,loencendemosy
damos al play en la seleccin que queramos. As el reproductor nos ofrece el servicio de
reproduccin de canciones. Este reproductor puede ser reemplazado por una minicadena que
Marzo 2009
soportereproduccindeMP3desdeundispositivoUSBexterno,ofreciendoelmismoserviciode
reproduccindecanciones,perocomomejorcalidadydistintascaractersticas.
La idea de SOA parte directamente de la programacin orientada a objetos, la cual sugiere una
relacin entre los datos y su procesamiento. As, definen los servicios formalmente a travs de
interfaces independientes de la plataforma subyacente y del lenguaje de programacin. Estas
interfacesocultanlasparticularidadesdesuimplementacin,loquelashaceindependientesdel
desarrollador y del lenguaje de programacin. A travs de estas arquitecturas se consiguen
diseareimplementarsistemasaltamenteescalablesquereflejanlalgicadenegocioyalavez
facilitan la interaccin entre distintos sistemas propietarios o de terceros. La razn por la cual
queremosquealguienhagaeltrabajopornosotrosesporqueesexperto.Utilizarunservicioes
generalmentemsbaratoyefectivoquehacerlopornosotrosmismos.As,lamayoradenosotros
comprendemos que no podemos ser expertos en todo. La misma regla se puede aplicar a la
construccindesistemassoftware.
CmoconsigueSOAdesacoplarlosagentessoftwarequeinteractan?Utilizandodosprincipios
enladefinicindelaarquitectura:
1. Escogerunpequeoconjuntodeinterfacessimplesydistribuidasparatodoslos
agentessoftwareparticipantes.Slolasemnticagenricaescodificadaenlas
interfaces. stas deberan estar disponibles universalmente para todos los
proveedoresyconsumidores.
2. Definir mensajes descriptivos por un esquema extensible que se entrega a

travsdelasinterfaces.Noseofreceinformacinsobreelfuncionamientodel
sistema a travs de mensajes. Los esquemas son los encargados de limitar el
vocabularioyestructuradelosmensajes.
Las interfaces son tremendamente importantes, si stas no han sido bien definidas o no
funcionan, el sistema no funciona. Integrar ms interfaces es caro, y adems incrementa la
posibilidaddeerroresenaplicacionesdistribuidas.Lasinterfacesremotassonlapartemslenta
de la mayora de las aplicaciones distribuidas. Con todo esto, en lugar de construir nuevas
interfaces para cada aplicacin, tiene ms sentido reutilizar unas genricas para todas las
aplicaciones.
As, ya que slo disponemos de unas pocas interfaces genricas disponibles, debemos incluir
dentrodelosmensajessemnticaespecficasobrelasaplicaciones.Podemosenviarcualquiertipo
demensajesobrenuestrasinterfaces,perohayunaspocasreglasaseguirparapoderdecirque
unaarquitecturaesorientadaaservicio.
Primero, los mensajes deben ser descriptivos, ms que instructivos, porque el proveedor
delservicioesresponsablederesolverelproblema.Porejemplo,serasimilaralasituacin
deiraunrestauranteydeciralcamareroloquetegustaratomarytuspreferencias,pero
nodeberamosexplicaralcocinerocmococinartusplatos,pasoporpaso.
Segundo, los proveedores de servicio no sern capaces de entender tu peticin si tus

mensajes no estn escritos en un formato, estructura y vocabulario comprensible por
todos los involucrados. As, limitar el vocabulario y la estructura de los mensajes es una
necesidadparalograrunacomunicacineficiente.Cuantomsrestringidoseaelmensaje,
Marzo 2009
mssencilloesentenderlo.
Tercero, la posibilidad de extensiones es de vital importancia. El mundo es un sitio

cambianteentodomomento,ydeformasimilareselentornoenelqueviveelsoftware.
Estoscambiosdemandancambioscorrespondientesenelsistemasoftware,consumidores
de servicios, proveedores, y los mensajes que intercambian. Si los mensajes no son
extensibles,losconsumidoresyproveedoresestarnbloqueadosenunaversinconcreta
del servicio. Restriccin y extensibilidad estn profundamente relacionadas, se necesitan
ambas,eincrementarunasuponeunareduccindelaotra.Loidealeslograruncorrecto
balance.
Cuarto, una SOA debe poseer un mecanismo que permita al consumidor descubrir un
proveedor de servicios bajo el contexto de un servicio buscado por el consumidor. El
mecanismodebeserflexible,ynodeberaserunregistrocentralizado.
Existen adems un nmero de posibilidades adicionales que se pueden aplicar en SOA para
mejorarsuescalabilidad,rendimientoyfiabilidad:
Servicio stateless (sin estados): Cada mensaje que enva un consumidor a un proveedor
debe contener toda la informacin necesaria para que el proveedor la procese. Esta
restriccinhacemsescalableaunproveedordeserviciopuestoqueelproveedornotiene
quealmacenarinformacindeestadoentrepeticiones.Estosepuededenominarservicio
deproduccinenmasayaquecadapeticinpuedesertratadademaneragenrica.Esta
restriccinademsproveedemsvisibilidad,yaquecualquiersoftwaredemonitorizacin
puede inspeccionar una peticin independiente y extraer su intencin. Esto permite
adems la recuperacin de forma sencilla de fallos parciales, puesto que no hay estados
intermedios,haciendoelserviciomsfiable.
Servicio stateful (con estados): Los servicios con estados son necesarios en diversas
situaciones.Porejemplo,alestablecerunasesinentreelconsumidoryelproveedor.Las
sesiones se establecen tpicamente por razones de eficiencia. Enviar un certificado de
seguridadencadapeticinesunacargaimportante,tantoparaelconsumidorcomopara
el proveedor, es mucho ms rpido reemplazar el certificado con un token compartido
entre ambos. Otra situacin es la de ofrecer un servicio personalizado. Estos servicios
requieren que tanto el consumidor con el proveedor compartan el mismo contexto,
incluido en o referenciado mediante mensajes intercambiados entre el consumidor y
proveedor. El inconveniente de este requisito es que puede reducir la escalabilidad del
proveedordeservicio,yaquepuedenecesitarrecordarelcontextoparacadaconsumidor.
Adems, incrementa el acoplamiento entre el proveedor de servicio y el consumidor, y
hacequeelcambioentreproveedoresseamsdifcil.
Peticiones idempotentes (que no realizan ningn cambio): Las peticiones duplicadas

recibidas por un agente software tienen el mismo efecto que una peticin nica. Este
requisitopermitequelosproveedoresyconsumidoresincrementenlafiabilidadtotaldel
servicio,simplementerepitiendolapeticinsihahabidoalgnfallo.
Podemos decir entonces, que SOA no es una herramienta, sino un conjunto de patrones de
construccindenuevasaplicacionesmsdinmicasymenosdependientes.SOAfacilitaelaccesoa
la lgica de negocios y la informacin entre diversos servicios de una manera sistemtica,
Marzo 2009
pudiendoademsorquestardiversosserviciosremotosparacomponerunonico.Lamayorade
las definiciones identifican la utilizacin de Servicios Web, los cuales veremos en el siguiente
captulo,enlaimplementacindeunaarquitecturaorientadaaservicios.Noobstante,sepuede
implementarutilizandocualquierotratecnologabasadaenservicios.
Marzo 2009
3.SERVICIOSWEB
Los Servicios Web se han convertido en la implementacin ms utilizada en arquitecturas
orientadas a servicios. Esto se debe a que poseen un conjunto de caractersticas que permiten
cubrirtodoslosprincipiosbsicosdelaorientacinaservicios.
Figura2:LosServiciosWebsebasanenestndaresabiertosparainterconectaraplicacionesy
usuariosindependientementedelasplataformas[3]
Marzo 2009
El concepto de Servicio Web puede resultar confuso, ya que no existe una definicin nica
universalmente aceptada sobre lo que son y lo que el concepto engloba. Los Servicios Web
surgieroncomounconjuntodeprotocolos,estndaresyrecomendaciones,definidosporlaW3C
[5](WorldWideWebConsistorium)yOASIS[6](OrganizationfortheAdvancementofStructured
InformationStandards),paralograrlainteroperabilidadenlainteraccinentremquinas,sistemas
softwareyaplicacionesatravsdelared.LadefinicindeServicioWebhaestadosiemprebajo
debateenelgrupodetrabajodelaarquitecturadeServiciosWebdelW3C[7].
Aunquenoesttotalmentecerrado,seaceptageneralmentequeunServicioWebesunaSOAcon
restriccionesadicionales:
1. LasinterfacessedebenbasarenprotocolosdeInternetcomoHTTP,FTPySMTP.
2.
LosmensajesdebenserXML,exceptoparadatosanexosbinarios.
As,unaposibledefinicinserahablardeelloscomounconjuntodeaplicacionesodetecnologas
con capacidad para interoperar en la Web. Estas aplicaciones o tecnologas intercambian datos
entre s con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como
procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a
travsdelaWeb.
Estos servicios proporcionan mecanismos de comunicacin estndares entre diferentes
aplicaciones, que interactan entre s para presentar informacin dinmica al usuario. Para
proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo
seaposiblesucombinacinpararealizaroperacionescomplejas,esnecesariaunaarquitecturade
referenciaestndar.
AunquepodemosencontrardiversosestilosdeServiciosWeb,enesteestudionoscentraremosen
aquellosbasadosenSOAP(odenominadoscomnmenteWS),yenREST,descartandoporejemplo
otraslneascomoXMLRPC[8](consideradoelprecursordeSOAP).
3.1.SOAPWS
UnServicioWebSOAPintroducelassiguientesrestriccionessobrelascaractersticasyacitadasde
SOA:
1. Excepto para datos binarios anexos, los mensajes deben ser transportados
sobreSOAP.
2. LadescripcindeunserviciodebeserhechaenWSDL.
3. Uso de UDDI, que son las siglas del catlogo de negocios de Internet
denominadoUniversalDescription,DiscoveryandIntegration.
Marzo 2009
ElsiguientegrficomuestracmointeractaunconjuntodeServiciosWeb:
Figura3:InteraccinatravsdeServiciosWeb[9]
Vemos que en todo este proceso intervienen una serie de tecnologas que hacen posible esta
circulacindeinformacin.UnServicioWebestformadoporlossiguientescomponentes:
Lgica. Se trata del componente que procesa la peticin para generar la informacin
solicitada por el cliente. Bsicamente resuelve el problema y puede, para ello,
comunicarseconotrosServiciosWeb,accederabasesdedatosobieninvocarAPIdeotras
aplicacionessolicitandolainformacin(opartedeella)quehadegenerarparaenviaren
formatoXML.
SOAP (Simple Object Access Protocol). Protocolo de comunicacin, basado en XML, que
sirveparalainvocacindelosServiciosWebatravsdeunprotocolodetransporte,como
HTTP ( SMTP, etc.). Consta de tres partes: una descripcin del contenido del mensaje,
unasreglasparalacodificacindelostiposdedatosenXMLyunarepresentacindelas
llamadas RPC para la invocacin y respuestas generadas por el Servicio Web. El mensaje
SOAP est compuesto por un envelope (sobre), cuya estructura est formada por los
siguienteselementos:header(cabecera)ybody(cuerpo).
Marzo 2009
Figura4:Estructuradelosmensajes[10]
UDDI (Universal Description, Discovery and Integration): Directorio donde es posible

publicarlosServiciosWeb,permitiendoconelloquelosposiblesusuariosdeeseservicio
puedanobtenertodalainformacinnecesariaparalainvocacinyejecucindelServicio
Web.UndirectorioUDDIofreceunaseriedeinterfacesqueposibilitantantolapublicacin
como la obtencin de informacin sobre los Servicios Web publicados. La informacin
registradaseclasificasegnloquesedeseeobtenerdelservicio:
o Informacindenegocio:acercadequinpublicaelservicio.
o Informacindeservicio:descripcindeltipodeservicio.
o Informacindeenlace:direccin(URL,porejemplo)paraaccederalservicio.
WSDL (Web Services Description Language). Lenguaje basado en XML que permite la
descripcindelosServiciosWebdefiniendolagramticaquesedebeusarparapermitirsu
descripcinycapacidades(datos,comandosqueaceptanoproducen),ysupublicacinen
undirectorioUDDI.
Veamosahoraunejemploconcreto,dondeunaseriedeServiciosWebinteractanparaofrecer
unaaplicacincomn:
Marzo 2009
Figura5:LosserviciosWebenFuncionamiento[11]
Segnelejemplodelaimagenanterior,unusuariosolicita,atravsdeunaaplicacin,informacin
sobre un viaje que desea realizar haciendo una peticin a una agencia de viajes que ofrece sus
servicios a travs de Internet. La agencia de viajes ofrecer a su cliente (usuario) la informacin
requerida.Paraproporcionaralclientelainformacinquenecesita,estaagenciadeviajessolicita
asuvezinformacinaotrosrecursos(otrosServiciosWeb)enrelacinconelhotelylacompaa
area.Laagenciadeviajesobtendrinformacindeestosrecursos,loquelaconvierteasuvezen
cliente deesos otros Servicios Web que le vana proporcionar la informacin solicitada sobreel
hotelylalneaarea.Porltimo,elusuariorealizarelpagodelviajeatravsdelaagenciade
viajesqueservirdeintermediarioentreelusuarioyelServicioWebquegestionarelpago.
Acontinuacinsemuestraelcdigoqueseutilizaraparasolicitarunviaje:
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reserva xmlns:m="http://empresaviajes.ejemplo.org/reserva"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:referencia>
uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
</m:referencia>
<m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
</m:reserva>
<n:pasajero xmlns:n="http://miempresa.ejemplo.com/empleados"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:nombre>Pepe Ejemplo</n:nombre>
</n:pasajero>
</env:Header>
<env:Body>
<p:itinerario
xmlns:p="http://empresaviajes.ejemplo.org/reserva/viaje">
<p:ida>
<p:salida>Nueva York</p:salida>
<p:llegada>Los Angeles</p:llegada>
<p:fechaSalida>2001-12-14</p:fechasalida>
<p:horaSalida>ltima hora de la tarde</p:horaSalida>
Marzo 2009
<p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
</p:ida>
<p:vuelta>
<p:salida>Los Angeles</p:salida>
<p:llegada>Nueva York</p:llegada>
<p:fechaSalida>2001-12-20</p:fechaSalida>
<p:horaSalida>media-maana</p:horaSalida>
<p:preferenciaAsiento/>
</p:vuelta>
</p:itinerario>
<q:alojamiento
xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
<q:preferencia>ninguna</q:preferencia>
</q:alojamiento>
</env:Body>
</env:Envelope>
DurantelaevolucindelasnecesidadesdelasaplicacionesbasadasenServiciosWeb,porejemplo
de las grandes organizaciones, se han desarrollado mecanismos que permiten enriquecer las
descripciones de las operaciones que realizan sus servicios mediante anotaciones semnticas y
condirectivasquedefinenelcomportamiento.Sonlasdenominadasextensiones,queveremosde
formaresumidaenelsiguienteapartado.
3.1.1.WS*
La simplicidad si bien es el punto fuerte de los servicios Web, tambin en determinados casos
puede ser su taln de Aquiles, ya que operaciones como asegurar las comunicaciones o enviar
archivosbinariospuedenconvertirseentareasmuycomplejas.
SOAP puede ser extendido realizando adiciones de mdulos de funcionalidad. Este enfoque
permite a los desarrolladores usar los mdulos y funcionalidad que ellos necesitan, sin tener la
necesidaddeimplementarlatotalidaddeestos.
Algunasdelasextensiones,denominadasWs*,quepuedenserdeseablesenlosproveedoresson
lassiguientes:
AttachmentsPermiteincluirdocumentosnoXML,comoarchivosbinariosoimgenes.
Routing/Intermediaries Relacionadas al proceso de enviar mensajes SOAP a travs de

intermediarios. Permite agregar varios Servicios Web (WS) y ofrecerlos como parte del
paquete,incrementandolaescalabilidaddelosservicios.
Security Da un marco de seguridad a la comunicacin. As el SOAP envelope soporta

integridad del mensaje, confidencialidad y autenticacin. Describe certificados X.509,
ticketsKerberos,etc.
Quality of Services QoS es una medida que mide la calidad del servicio, con esta
extensinesposiblecaracterizarelfuncionamientodelservicio.
Context/PrivacyRelacionadaconlaWSSecurity,hacereferenciaaguardarelcontextoy
privacidad,delentornodelosusuarios.
Marzo 2009
Adems existen otros foros encargados de ofrecer extensiones para cubrir escenarios ms
complejos, o incrementar la interoperabilidad entre los distintos servicios. Los trabajos ms
importantesqueactualmenteseestnllevandoacaboson:
Interoperability [12]: Este grupo se encarga de promover la interoperabilidad de los

Servicios Web entre cada una de las plataformas, aplicaciones y lenguajes de
programacin. Se trata de un foro abierto donde se ofrecen a los clientes o posibles
usuariosdeguasdeimplementacinprcticasrecomendadasysoporteparaeldesarrollo
deservicioswebinteroperables.
Security [13]: trata de definir unos requisitos a aplicar en los mensajes SOAP para
aumentar la seguridad en el uso de los Servicios Web garantizando la integridad de los
mensajes,laconfidencialidadylaautenticacin.
BPEL4WS (Business Process Execution Language for Web Services) [14]: Lenguaje para
describir procesos de negocio sobre Servicios Web. Este lenguaje, combinado con las
especificaciones WSTransaction [15] y WSCoordination [16], determina como se deben
dedefinir,coordinareintegrarlosprocesosdenegociodentrodelaempresaoconotros
proveedores,atravsdesistemasheterogneos.
EnelsiguienteenlacedeINOOQ[17]sepuedeencontrarunmapamuycompletoconunarevisin
delosestndaresrelacionadosconlosServiciosWeb.
3.2.ServiciosWebREST
EltrminoREST[18],acrnimodeREpresentationalStateTransfer,fueintroducidoporprimera
vezporRoyFielding[19](unodeloscreadoresdeHTTP)enlalecturadesutesisparadescribirun
tipo de arquitectura de los sistemas en red. Un Servicio Web REST es un SOA basado en el
concepto de recurso. Un recurso es cualquier cosa que tiene una URI (Uniform Resource
Indentifier),pudiendotenerceroomsrepresentaciones.
UnServicioWebRESTtienelassiguientescaractersticas:
1. LasinterfacesdebenconstruirsesobreHTTP.Lassiguientesfuncionessondefinidas:
- HTTP GET: Usado para obtener una representacin de un recurso. Un
consumidor lo utiliza para obtener una representacin desde una URI. Los
servicios ofrecidos a travs de este interfaz no deben contraer ninguna
obligacinrespectoalosconsumidores.
- HTTPDELETE:Seusaparaeliminarrepresentacionesdeunrecurso.
- HTTPPOST:Usadoparaactualizarocrearlasrepresentacionesdeunrecurso.
- HTTPPUT:Seusaparacrearrepresentacionesdeunrecurso.
2. LamayoradelosmensajessonXML,definidosporunesquemaXML.
3. MensajessimplessepuedencodificarenlasURL.
4. Los servicios y los proveedores de servicios deben ser recursos, mientras que los
consumidorespuedenserunrecurso.
Marzo 2009
Figura6:EjemploconlasfuncionesdeREST[20]
LosServiciosWebRESTrequierenpocainfraestructura,apartedelastecnologasHTTPestndary
XML, que actualmente son soportadas por la mayora de los lenguajes de programacin y
plataformas. Los servicios web REST son simples y efectivos, ya que HTTP es el interfaz ms
extendidoyessoportadoporlamayoradelasaplicaciones.
3.2.1.ArquitecturaREST
LaWebportanto,secomponederecursos,ycomohemosdichounrecursoescualquierobjetode
inters,identificadoporunaovariasURIs.Porejemplo,lacompaadeventaonlineAlbertoLS.A.
puededefinirunrecursoordenador,ylosclientesaccederaeserecursomediantelasiguiente
URL:
http://www.albertolsa.com/productos/ordenador
La representacin del recurso sera devuelta al cliente (por ejemplo, productosOrdenador.html).

Esta representacin sita al cliente en un estado. Cuando se accede a la representacin del
recurso, la aplicacin del cliente realiza una transferencia de estado (Representational State
Transfer).
LamotivacinparaRESTfuecapturarlascaractersticasdelaWebquehacandelapropiaWebun
xito.EstascaractersticasestnsiendoahorausadasparaguiarlaevolucindelaWeb.
REST no es un estndar, sino que es un estilo de arquitectura (de forma anloga, no hay un
estndar clienteservidor, sino que hay un tipo de arquitectura clienteservidor). Sin ser un
estndar,RESThaceusodeestndares:
HTTP[RFC1945]:HyperTextTransferProtocol.
URL[RFC1738](UniformResourceLocator):Mecanismodeidentificacinderecursos.
Marzo 2009
XML/HTML/PNG/etc.:Distintosformatosderepresentacinderecursos.
TiposMIME:Comotext/xml,text/html,image/png,etc.
AlgunascaractersticasdeRESTson:
ClienteServidor:Estilodeinteraccinbasadaenpull(bajodemanda).
Sin estado: Cada peticin desde un cliente hacia un servidor debe contener toda la
informacin necesaria para comprender la peticin, y no puede tomar provecho de
ningncontextoalmacenadoenelservidor.
Cach: Para mejorar la eficiencia de la red, las respuestas deben ser capaces de ser
etiquetadascomocacheablesonocacheables.
Interfazuniforme:Todoslosrecursossonaccesiblesmedianteuninterfazgenrico(por
ejemplo,HTTPGET,POST,PUT,DELETE).
Recursosconnombres:Elsistemasecomponederecursosquesonnombradosusando
unaURL.
Representaciones de recursos interconectados: Las representaciones de los recursos
estn interconectadas usando URLs, por tanto un cliente est capacitado para
progresardeunestadoaotro.
Componentesencapas:Intermediarios,talescomoservidoresproxy,servidorescach,
gateways,etc.,puedenserintroducidosentrelosclientesylosrecursos,paraofrecer
rendimiento,seguridad,etc.
3.2.2.Ejemplo
Imaginemos que la empresa anteriormente citada, AlbertoL S.A. (empresa de componentes
informticos),hadesplegadovariosserviciosparapermitirquesusclientespuedan:
Obtenerunalistadecomponentes.
Obtenerinformacindetalladasobreuncomponenteenparticular.
Enviarunaordendecompra.
VeamoscmoestosserviciosseimplementaransobreREST.
Obtenerunalistadecomponentes
El Servicio Web dispone de una URL para un recurso con la lista de componentes. Por
ejemplo,elclienteusaralasiguienteURLparaobtenerla:
http://www.albertolsa.com/componentes
Notar que cmo el Servicio Web genera la lista de componentes es completamente

transparentealcliente.TodoloqueelclientesabeesquehasolicitadolaURLanterioryque
el documento que contiene la lista de componentes le ha sido devuelto. Puesto que la
implementacin es transparente a los clientes, AlbertoL S.A. es libre de modificar la
implementacinquehaypordebajodeesterecurso,sininfluenciaralosclientes.Estoeslo
quedenominamosbajoacoplamiento.
Marzo 2009
steesunejemplodeldocumentoqueelclienterecibe:
<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.albertolsa.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Part id="00345"
xlink:href="http://www.albertolsa.com/componente/00345"/>
<Part id="00346"
<Part id="00347"
<Part id="00348"
</p:Parts>
Asumimos que el servicio ha determinado (a travs de procesos de negociacin) que el

clientequierelarepresentacincomoXML(paraprocesamientoM2M).Vemosquelalista
decomponentestieneenlacesparaobtenerinformacindetalladasobrecadauno.Estoes
unacaractersticaclavedeREST,elclientesetrasladadeunestadoalsiguienteexaminando
yeligiendolasURLsdeentrelasalternativasquedisponeeldocumentorespuesta.
Obtenerlainformacindetalladadeuncomponente
ElServicioWebofreceunaURLparacadarecursocomponente.Porejemplo,veamosuna
peticindelcomponente00345:
http://www.albertolsa.com/componente/00345
Esteseraeldocumentoquerecibiraelcliente:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.albertolsa.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<ID>00345</ID>
<Nombre>Teclado</Nombre>
<Descripcion>Teclado marca Manzana(R)</Descripcion>
<Especificacion
xlink:href="http://www.albertolsa.com/componente/00345/specif
ication"/>
<CosteUnidad moneda="EUR">10.00</CosteUnidad>
<Cantidad>10</Cantidad>
</p:Part>
Denuevoseobservacomoestainformacinestenlazadaanamsdatos(laespecificacin
para este componente se puede encontrar yendo al enlace). Cada documento respuesta
permitealclienteiraunainformacinmsdetallada.
Enviarunaordendecompra
ElServicioWebtienedisponibleunaURLparaenviarunaordendecompra.Elclientedebe
crearundocumentodeinstanciadeordendecompra,quedebeajustarsealesquemaquela
empresahadiseadoparaesteproceso.ElclienteenvaOC.xmlmedianteunHTTPPOST.
Elserviciodeordendecompra,respondealHTTPPOSTconunaURL,dondeelclientepuede
encontrarlainformacindelaordenencualquiermomentoyaseditarlaoactualizarla.La
Marzo 2009
ordendecomprapasaaserunfragmentodeinformacincompartidoentreelclienteyel
servidocomounServicioWeb.
Marzo 2009
4.CARACTERSTICASSOAPyREST
Como ya se ha ido comentando durante el trabajo, los Servicios Web ofrecen varios beneficios
sobreotrostiposdearquitecturasdecomputacindistribuidas[21]:
Interoperabilidad: sta es la ventaja ms importante de los Servicios Web. stos

tpicamentetrabajanfueraderedesprivadas,ofreciendoalosdesarrolladoresrutasno
propietarias a sus soluciones. Por tanto, los servicios suelen tener mayor vida til,
recibiendo mayor retorno ante la inversin en el servicio desarrollado. Adems, los
desarrolladorespuedenoptarporsulenguajedeprogramacinfavorito,puestoquesu
implementacin est soportada sobre la mayora de las tecnologas existentes. Por
ltimo,graciasalusodemtodosestndardecomunicaciones,losServiciosWebson
virtualmenteindependientesdelaplataforma.
Usabilidad:LosserviciosWebpermitenquelalgicadenegociodediferentessistemas
puedanserexpuestassobrelaWeb.Estoofrecealasaplicacioneslalibertaddeelegir
elServicioWebquenecesitan.Envezdereinventarlaruedaparacadacliente,sloes
necesario incluir la lgica de negocio especfica a la aplicacin en el lado del cliente.
Esto permite que se desarrolle tanto el servicio como el cdigo del lado del cliente
usandoloslenguajesyherramientasquesedeseen.
Reusabilidad:LosServiciosWebnoofrecendirectamenteunmodelodedesarrollode
aplicaciones,perocasi,yaquesedisponedeunaaproximacinquenecesitaunmnimo
desarrollodecdigoparaeldesarrollodedichosservicios.Estofacilitalareutilizacin
decomponentesenotrosservicios.
Despliegue: Los Servicios Web se despliegan sobre tecnologas de Internet estndar.

Esto hace posible desplegar Servicios Web sobre firewalls hasta sobre servidores
corriendoenInternetenlaotrapartedelglobo.Adems,graciasalusodeestndares,
laseguridadesposible(medianteelusodeSSLporejemplo).
Peropodemostambinencontrarinconvenientesolimitaciones:
AunquelasimplicidaddelosServiciosWebesunaventaja,enalgunosaspectospuedeser
un estorbo. Los Servicios Web usan protocolos basados en texto plano que usan un
mtododemasiadopesadoparaidentificarlainformacin.Estosignificaqueenocasiones
las peticiones son ms largas que las peticiones codificadas con un protocolo binario. El
tamao extra es ciertamente slo una cuestin a tratar sobre conexiones lentas, o
conexionesextremadamentesaturadas,peroesalgoaconsiderar.
Tanto HTTP como HTTPs (el ncleo de los protocolos Web) son simples, pero no fueron
inicialmente considerados para sesiones largas. Tpicamente, un navegador realiza una
conexin HTTP, solicita una pgina web y despus se desconecta. En entornos CORBA o
RMI, un cliente se conecta al servidor, pudiendo permanecer conectado durante un
periodoextensodetiempo,recibiendoinformacinperidicaenelcliente.Estainteraccin
es difcil de obtener con los Servicios Web, y es necesario un trabajo extra para
conseguirlo.
Marzo 2009
El problema con HTTP y HTTPS cuando se emplean para sustentar Servicios Web es que
estos protocolos son stateless, sin estado, la interaccin entre el servidor y el cliente es
tpicamentebreve,ycuandonohaydatossiendointercambiados,elservidoryelclienteno
tienenconocimientosobreelotro.Msespecficamente,sielclientehaceunapeticinal
servidor,recibirinformacin,ysiinmediatamentecaedebidoauncortedecorriente,el
servidornuncasabrqueelclienteyanosigueactivo.Elservidornecesitaunaformade
mantener un seguimiento sobre lo que el cliente est realizando y tambin determinar
cundounclienteyanoestactivo.
Tpicamente,unservidorenvaalgntipodeidentificadordesesinalclientecuandoste
accede por primera vez al servicio. El cliente usa este identificador cuando realiza
peticionesalservidor.Estopermitealservidorrecuperarcualquiertipodeinformacinque
tengasobreelcliente.Adems,elservidordeberautilizarunmecanismodetimeoutpara
determinarcundounclientenoestactivo.Sielservidornorecibeunapeticindesdeun
clientepasadoundeterminadotiempo,seasumequeelclienteestinactivoyseeliminala
informacinqueseestabamanteniendo.Esteoverheadextra,significamayortrabajopara
losdesarrolladoresdelosServiciosWeb.
Para realizar transacciones no pueden compararse en su grado de desarrollo con los

estndares abiertos de computacin distribuida como CORBA (Common Object Request
BrokerArchitecture).
Surendimientoesbajosisecomparaconotrosmodelosdecomputacindistribuida,tales
comoRMI(RemoteMethodInvocation),CORBA,oDCOM(DistributedComponentObject
Model).Esunodelosinconvenientesderivadosdeadoptarunformatobasadoentexto.Y
es que entre los objetivos de XML no se encuentra la concisin ni la eficacia de
procesamiento.
EsteltimohechoseacentaenlosServiciosWebsobreSOAP,yaquelascabecerasdelmensaje
introducenunoverheadconsiderable[22],cosaquenoocurreconREST.Veamosenlasiguiente
seccinunresumendeldebateexistenteenlaactualidadsobreambasfilosofas.
4.1.DebateSOAPvsREST
EldebatesobreSOAPyRESTestenauge[24][25].Endefinitiva,sonsolucionesparaunmismo
problema,laintegracindesistemas.EmpresascomoGoogle[26],Facebookyotroshantomado
yalaopcinRESTparalaimplementacindesusServiciosWeb.
LosRESTfulWebServiceshandemostradosucapacidadpararesponderdemaneraefectivaalos
requerimientos de publicacin y sindicacin de contenido y medios. Sin embargo, SOAP encaja
mejor en soluciones con un mayor alcance y requisitos mayores, tanto en nmero de
servicios/operaciones, nmero de aplicaciones cliente, nmero de equipos de desarrollo
implicadosycomplejidaddemensajes,principalmenteenfocadosaldesarrolloempresarial.
Si bien en Internet las grandes empresas estn tendiendo a ofrecer sus servicios sobre REST,
debido principalmente a la sencillez de invocacin que ofrecen, y su limitado overhead (en los
servicios sobre SOAP, las cabeceras y datos que no son la informacin relevante a transmitir
Marzo 2009
ocupangranpartedelanchodebanda),podemosdecirquenosiempreRESTeslamejoropcin.
Porejemplo,RESTllevaasociadoHTTPcomonicoprotocolodetransporte.Sitenemosnecesidad
de utilizar otro tipo de transporte como JMS, SOAP s es vlido, pero no as el caso de REST.
Adems,ennivelesdeseguridad,lapilaWS*(concretamenteconsudefinicindeWSSecuritya
niveldemensaje)permiteunmayorniveldeseguridadqueREST(queseimplementaencasode
necesidadaniveldeHTTPcomotransporte).
LasextensionesWS*sonunadelascaractersticasqueadolecenlosserviciosREST.Perocadavez
existen ms iniciativas para poder cubrir estas posibles lagunas. En relacin a la seguridad,
AmazonapuestaporelestndarHMAC[28],parapoderautenticarlaspeticionesREST,porloque
quizsenelfuturoveamosqueRESTpuedesupliralosServiciosSOAPentodoslosaspectos.
Mientras tanto, ambas iniciativas tienen su hueco y dependiendo de la necesidad ser ms

recomendadoutilizarunosuotros.Loquesesclaro,esqueRESTvaadarmuchoquehablarde
aquapocotiempo,dehechoseestutilizandoyaampliamente(lasindicacindeblogsporRSSo
ATOM utilizan REST; Google expone sus servicios web como REST, eBay y Amazon ofrece una
interfaz REST para sus desarrolladores, etc.), y esto supone que cuanto ms se puja por una
tecnologa,statienelaposibilidaddeevolucionarmsrpidamente.
Figura7:GoogleApps[29]
Una vez revisados los principales puntos de discusin y el debate SOAP vs REST, en el siguiente
captulonoscentraremosenelrendimiento,intentandoestudiarlaproblemticaylosesfuerzos
realizadosparamejorarestecomportamiento.
Marzo 2009
5.RENDIMIENTO
Mientras SOA ofrece diversos beneficios, muchas de sus implementaciones estn diseadas de
modo que no favorecen el rendimiento. SOA est diseada sobre los principios de flexibilidad,
extensibilidad y reusabilidad. Los sistemas del pasado estaban fuertemente acoplados, siendo
generalmentebastanteeficientes,perofrgilesydifcilesdecambiar.Tendananosermodulares,
porloquesumantenimientoeracaroanteposiblesadaptaciones.
Flexibilidadyreuso[30]sonobjetivosimportanteseneldiseoeimplementacindelosservicios,
quepermitenobtenerbeneficioscuantificables.Laflexibilidaddelsistemapermiteagilidadenel
negocio, que puede ser la diferencia entre el xito o el fracaso. La extensibilidad permite una
integracin ms rpida de nuevas funcionalidades, para soportar cambios en los requisitos del
negocio.Elreusopuedeincrementarlaproductividadyreducirelmantenimientodespus.
MientrasqueSOAofreceestosbeneficios,eldiseodemuchasimplementacionesnofavoreceel
rendimiento.Rendimientoesuntrminoqueseusaamenudoparadistintosconceptos:
Scaleup (escalabilidad): La tasa de transferencia es un concepto importante que puede

serdefinidocomoelnmerodemensajesdeuntamaodadoquepuedenserprocesados
en un periodo de tiempo dado. La latencia es un concepto relacionado, describe cunto
tarda un mensaje dado en viajar a travs del mismo sistema. Estos trminos pueden ser
usadosparadescribirlacapacidaddeunsistemaparascaleup,esdecir,paraescalarlo.
Scaleout(distribucin):Sistemasdistribuidosycomputacinparalelasonreasestudiadas
desdehacemsdeunadcada.Haygananciassignificantescuandolascargasdetrabajose
dividenencomponentesquesonllevadasacaboenmltiplessitiosenelmismomomento.
Sinembargo,hayretosquedebenserresueltosparasatisfacerlasreglasrequeridasporlos
negocioscuandoelprocesamientoparaleloesempleado.
Para disear un Servicio Web con mayor rendimiento, hay varios principios importantes que
debenserconsiderados:
Utilizarlaherramientacorrectaparaeltrabajo:SOAnosignificasiempreServiciosWeb,los
cuales al hacer uso de XML y SOAP, no son tan eficientes como desarrollos propietarios.
Porloquesienuncasodado,elobjetivoprincipaleslarapidezenlacomunicacin,quizs
seamejoradoptarunaalternativaalosServiciosWeb.
Intentar mantener el servicio ligero: El parseo XML puede introducir un overhead

importante, generando cuellos de botellas en caso de transmitir mensajes grandes entre
componentes. Adems, hay que examinar concienzudamente el tamao de los mensajes
XMLysuposiblereduccin.
Hacer ms de una cosa a la vez: En el diseo de los servicios podemos considerar

descomponer el procesamiento en bloques ms pequeos, que trabajen de forma
coordinadaparaincrementarelrendimiento.
Disear la interfaz del Servicio Web para minimizar el trfico de la red: Una API bien
diseada puede hacer que elcliente minimiceel nmero de peticiones paraconseguir la
Marzo 2009
informacin.
MensajesSOAPlargosycomplejospuedensuponeruncuellodebotella,debidoaltiempo
quellevaparsearlosyserializarlos/deserializarlos.
ElementosSOAPintermedios(gateways,proxys)puedenminimizarelparseodemensajes.
Introducir seguridad incrementa los costes de rendimiento: No todo el trfico SOAP

necesita ser seguro, y en ocasiones el coste en rendimiento de un mtodo de seguridad
endtoend (por ejemplo, WSSecurity) es mayor que el que introduce un mecanismo de
seguridadaniveldetransporte(comoSSL).
La codificacin binaria de cierta informacin en ocasiones supone un incremento de

rendimiento.
El cacheo es una forma de mejorar el rendimiento en servicios de procesado intensivo,

aunqueengeneralesaplicablesloparaserviciosdeslolectura.
Conexionespersitentessonbuenasencasodedisponerdeungrannmerodemensajes
detamaoreducido.Paramensajesmayores,tienemenorefectividad.
El estilo Document/Literal de los mensajes SOAP son menores en tamao y menos

complejosquelosmensajesdetipoRPC/SOAP.
De forma ms concreta, cada vez es necesario disponer de aplicaciones ms completas en

Internet, las cuales necesitan hacer muchas llamadas a servicios empresariales, para poder
presentar los resultados a los usuarios. Si los Servicios Web tardan demasiado tiempo, el User
Interfacing (presentacin de la informacin al usuario) llevar demasiado tiempo y por tanto se
percibirunrendimientopobre.
Portanto,segnlaaplicacinoservicio,podemoseliminartodaslascaractersticasnonecesarias,
paraobtenerunrendimientomayor,acostadereduciropcionesextra,comoesobvio.
Denuevoenelsiguienteestudio[32],seestudialacalidaddeservicio(QoS)paraServiciosWeb,
presentandoalgunadelasopcionescitadasenestecaptulo.Bsicamenteydeformaresumida:
Usarparserseficientesyligeros,mensajesXMLreducidosenlamedidadeloposibles,usodetipos
de datos simples en los mensajes SOAP adems de usar el cacheo en Servicios Web, es decir,
almacenarinformacinintermediaparaserservidasinvolveraprocesartodalainformacin.
Cmofuncionaraestecacheodeinformacin?
Para los Servicios Web sobre HTTP (Servicios Web XML y sobre Internet), se puede cachear los
resultados del procesado para usarlos en futuras peticiones (en code google hay un espacio
reservado para un proyecto en esta lnea [36]). Esta posibilidad es vlida principalmente para
serviciosdeslolectura,comoyasehaindicadoantes,queporejemplohacenpeticionesenbases
de datos que dan acceso a contenido semiesttico (catlogos de productos, informacin de
marketing,etc.).VariaspartesdelmensajeSOAPsepuedenusarparaidentificarunvocamentela
peticinparacachearla.
Marzo 2009
Lacapacidaddecachingesprovistadefiniendopolticascachingyconstruyendoidentificadoresde
cachbasadosen:
AccinSOAP
SOAPEnvelope
Componentepuerto
OperacinSOAP
ParmetrosdeoperacinSOAP
Laspolticasincluyenreglaseintervalosdeexpiracinparaasegurarlavalidaddelainformacin
salvada. Los componentes que no necesitan el parseo del SOAP Envelope, ofrecern la mayor
ganancia de rendimiento. Por ejemplo, en la especificacin SOAP se define la cabecera HTTP
SOAPAction en la peticin, que es usada por los servidores proxy HTTP para distribuir las
peticiones a los distintos servidores HTTP. Esta cabecera puede usarseen elcaso de cach para
construirlosIDssintenerqueparsearelmensajeSOAP.ElidentificadorIDcach,puedeentonces
usarseparaencontrarlarespuestadelserviciodeinformacindesdelacach,paraoptimizarasel
rendimiento.
Marzo 2009
6.CONCLUSIONES
Hemos visto que los Servicios Web surgieron ante la necesidad de disponer de un conjunto de
solucionesparainterconectarlosserviciosyusuariosenlaWeb.Desdesuaparicin,basadosen
las Arquitecturas Orientadas a Servicio (SOA), han ido evolucionando en pos de cubrir las
necesidadesquehanidoapareciendoarazdelasnuevasaplicaciones,negocios,caractersticasde
losusuariosyposibilidadesdelaRed.
ActualmenteexistendosramasimportantesenrelacinalosServiciosWeb.Cadaunadisponede
unaarquitecturapropia,yporconsiguientesufuncionamientoycaractersticasqueofrecenson
distintas. Los Servicios Web basados en SOAP, se podran catalogar como clsicos, siendo los
componentes principales empleados XML (para codificar la informacin), SOAP (para formar los
mensajes), WSDL (para definir los servicios ofrecidos, a modo de contrato entre el servidor y el
cliente)yUDDI(queesunregistrodondesepublicanlosservicios).Porelcontrario,losServicios
WebREST,directamentetrabajansobrelosprotocolosdered(comoHTTP)yhacenusodeXML,
paraenviardatoscompuestos.
Los Servicios Web basados en REST han adoptado el propio funcionamiento de la Web, siendo
realmente simple transferir la informacin. Disponen de unas funciones bsicas, para poder
interactuar,yasevitarintroducirdemasiadainformacinextraenlosmensajes.LosServiciosWeb
SOAP,establecenunaspautasmuymarcadasparaqueelclienteyelservidorsepuedanentender,
loquehacequeenocasionesralenticenlainteraccin.
LasgrandescompaasdeInternet,estntendiendoaparalizarelsoportedesusServiciosWeb
SOAP,pasandoapotenciarydesarrollarAPIssobreREST(eselcasodeGoogle,Yahoo!,Amazon,
etc.).Enelmarcoactual,lafacilidadysencillezdeestosserviciosestganandolabatallaaSOAP,
pero como se ha indicado, todava hay caractersticas que REST no ha llegado a cubrir. Las
extensionesWS*permitendisponerdefuncionalidadesenmuchoscasosnecesarias,oalmenos
interesantes, para por ejemplo implementar mayor seguridad. Por tanto, SOAP y REST pueden
coexistir, cada uno orientado a un mbito: SOAP puede cubrir las necesidades empresariales,
dondelasempresaspuedentenerunmayorcontroldesusserviciosinternos(ydesuinformacin
privada), y REST tendera a usarse en las aplicaciones Web actuales (y composiciones de stas,
comoporejemploenelcasodelosMashups).
EnlaliteraturaofrecidasepuedevercmolosServiciosWebRESTsuperancompletamentealos
ServiciosWebbasadosenSOAPenrelacinalrendimiento.Cuandonosreferimosarendimiento,
hablamosporejemplodelnmerodepeticionesquesepuedentratarenunperiododeterminado
de tiempo. SOAP no fue concebido con el objetivo de ser eficiente, y para enviar un mensaje
bsico,incluyedemasiadosdatosadicionales.Hemosintentadorevisarcmosepodrasolucionar
esta desventaja, o al menos mejorar este rendimiento, puesto que hay bastantes iniciativas
entornoaesteaspecto.Porltimodetallar,quetambinexistecadavezmsactividadenrelacin
adotardecaractersticasextraalosServiciosWebbasadosenREST,comopodraserunaopcin
equiparableaWSSecurityenSOAP.
Enelfuturoveremossialgunodelosdosganalacarrera,peromiopininpersonalesquequizs
latendenciaseaenfocarlosWSSOAPparadesarrollosempresarialesydejarRESTparalaWeb.El
hechodequelasAPIsdelasprincipalescompaasseanREST,dictaminarquelosdesarrollares
pretendaninstaurarestametodologacomoreferencia,conelconsiguientepeligroparaSOAP.
Marzo 2009
7.REFERENCIAS
[1]HeH.WhatIsServiceOrientedArchitecture.Septiembre,2003.[online]
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
[2]Figuraextradade:http://ischool.tv/news/category/youtube/
[3]Figuracreadapor:CarlesSalas
[4]Schekkerman,J.EnterpriseArchitecture&ServiceOrientedArchitecture(SOA).[online]
http://www.enterprise
architecture.info/Images/Services%20Oriented%20Enterprise/EA_ServiceOriented
Architecture1.htm
[5]PginaWebdelWorldWideWebConsortium:http://www.w3.org/
[6]PginaWebdeOasis:http://www.oasisopen.org/home/index.php
[7]GrupodetrabajoWebServicesArchitecture:http://www.w3.org/2002/ws/arch/
[8]PginaWebdeXMLRPC:http://www.xmlrpc.com/
[9]Figuraextradade:
http://www.di.uniovi.es/~labra/cursos/Web20/images/VocabServiciosWeb.png
[10]TelefnicaWebServices.Mayode2003.[online]
http://empresas.telefonica.es/documentacion/WP_Web_Services.pdf
[11]W3CGuaBrevedeServiciosWeb.ltimamodificacin:09/01/2008.[online]
http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
[12]PginawebdelgrupoWSInteroperability:http://www.wsi.org
[13]WebsobreWSSecure:http://www
106.ibm.com/developerworks/webservices/library/wssecure
[14]WebsobreBPEL:http://www106.ibm.com/developerworks/webservices/library/ws
bpel
[15]WebsobreWSTransactionsspecificationsdeIBM:
http://www.ibm.com/developerworks/webservices/library/wstranspec
[16]WebsobreWSCoordinationdeIBM:http://www
106.ibm.com/developerworks/library/wscoor
[17]PsterdeinnoQsobrelosestndaresdeServiciosWeb:http://www.innoq.com/soa/ws
standards/poster/innoQ%20WSStandards%20Poster%20200702.pdf
Marzo 2009
[18]L.Costello,BuildingWebServicestheRESTWay.[online]
http://www.xfront.com/RESTWebServices.html
[19]PginaWebdeRoyT.Fielding:http://www.ics.uci.edu/~fielding/
[20]Figuraextradade:http://rails.mimbles.net/wp
content/uploads/2008/01/rest_model.png
[21]Advantages&DisadvantagesofWebservices
http://social.msdn.microsoft.com/Forums/enUS/asmxandxml/thread/435f43a9ee174700
8c9dd9c3ba57b5ef/]
[22]PautassoC.RESTfulWebServicesPresentacin.Abril2008.
[23]DubrayJ.AFairComparisonofRESTandWS*usinganArchitecturalDecision
Framework:istheDebateOver?Discusinonline,Mayode2008.
http://www.infoq.com/news/2008/05/restvswsstar
[24]JavaHispanoPodcast035ArquitecturaSOAyServiciosWeb(SOAP/REST).Febrero
de2009.[online]
http://www.javahispano.org/contenidos.item.action?id=7237760&menuId=JH_PODCASTS
[25]PrescodP.RootsoftheREST/SOAPDebate.[online]
http://prescod.net/rest/rest_vs_soap_overview/
[26]GoogleRESTsearchAPI:http://blogoscoped.com/archive/20080409n26.html
[27]REST,FuturodeSOA?:http://www.espaciosoa.net/2007/06/13/rest%C2%BFfuturo
desoa/
[28]FirmaHMACSHA1:http://docs.amazonwebservices.com/AmazonSimpleDB/200711
07/DeveloperGuide/index.html?HMACAuth.html
[29]Figuraextradade:https://www.strongtech.com/i/images/googleapps.jpg
[30]HighPerformanceSOAaContradictioninTerms?,Noviembrede2006:
http://www.webservices.org/weblog/patrick_leonard/high_performance_soa_a_contradictio
n_in_terms
[31]PandrangiN.PI:Beefuptheperformanceofsynchronouswebservices,Juliode2007:
https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/6912
[32]SumraR.QualityofServiceforWebServicesDemystification,Limitations,andBest
Practiceshttp://www.developer.com/services/article.php/2027911
[33]PerformancebestpracticesforWebservices,Mayode2004:
http://www.soaprpc.com/archives/000020.html
[34]CohenF.DiscoverSOAPencoding'simpactonWebserviceperformance.Marzode
Marzo 2009
2003.http://www.ibm.com/developerworks/webservices/library/wssoapenc/
[35]DebatingthePerformanceofSOAP,REST,HTTP,andOtherDistributedComputing
Toolkits:http://hinchcliffe.org/archive/2005/08/10/1540.aspx
[36]WebdelproyectoenGoogledeWSCache:http://code.google.com/p/wscache/
[37]PautasoC.,ZimmermannO.,LeymannF.RESTfulWebServicesvs.BigWebServices:
Making the Right Architectural Decision. WWW 2008, April 2125, 2008, Beijing, China.
[online]http://www.jopera.org/files/www2008restwspautassozimmermannleymann.pdf

Revisión de Los Servicios Web SOAP/REST

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Revisión de Los Servicios Web SOAP/REST

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Revisinde

2. Definir mensajes descriptivos por un esquema extensible que se entrega a

Segundo, los proveedores de servicio no sern capaces de entender tu peticin si tus

Tercero, la posibilidad de extensiones es de vital importancia. El mundo es un sitio

Peticiones idempotentes (que no realizan ningn cambio): Las peticiones duplicadas

UDDI (Universal Description, Discovery and Integration): Directorio donde es posible

Routing/Intermediaries Relacionadas al proceso de enviar mensajes SOAP a travs de

Security Da un marco de seguridad a la comunicacin. As el SOAP envelope soporta

Interoperability [12]: Este grupo se encarga de promover la interoperabilidad de los

La representacin del recurso sera devuelta al cliente (por ejemplo, productosOrdenador.html).

Notar que cmo el Servicio Web genera la lista de componentes es completamente

Asumimos que el servicio ha determinado (a travs de procesos de negociacin) que el

Interoperabilidad: sta es la ventaja ms importante de los Servicios Web. stos

Despliegue: Los Servicios Web se despliegan sobre tecnologas de Internet estndar.

Para realizar transacciones no pueden compararse en su grado de desarrollo con los

Mientras tanto, ambas iniciativas tienen su hueco y dependiendo de la necesidad ser ms

Scaleup (escalabilidad): La tasa de transferencia es un concepto importante que puede

Intentar mantener el servicio ligero: El parseo XML puede introducir un overhead

Hacer ms de una cosa a la vez: En el diseo de los servicios podemos considerar

Introducir seguridad incrementa los costes de rendimiento: No todo el trfico SOAP

La codificacin binaria de cierta informacin en ocasiones supone un incremento de

El cacheo es una forma de mejorar el rendimiento en servicios de procesado intensivo,

El estilo Document/Literal de los mensajes SOAP son menores en tamao y menos

De forma ms concreta, cada vez es necesario disponer de aplicaciones ms completas en

Vous aimerez peut-être aussi