SOAP SOAP es un protocolo para el intercambio de mensajes sobre redes de computadoras, generalmente usando HTTP.

Est basado en XML, a diferencia de DCOM y CORBA que son binarios; esto facilita la lectura por parte de los humanos, pero tambin los mensajes resultan ms largos y, por lo tanto, considerablemente ms lentos de transferir. Existen mltiples tipos de modelos de mensajes en SOAP pero, por lejos, el ms comn es el RPC, en donde un nodo de red (el cliente) enva un mensaje de solicitud a otro nodo (el servidor) y el servidor inmeditamente responde el mensaje al cliente. Los mensajes SOAP, son idependientes del sistema operativo, y pueden transportarse en varios protocolos de internet como SMTP, MIME y HTTP. SOAP al principio significaba Simple Object Access Protocol, luego fue Service Oriented Architecture Protocol, pero actualmente es simplemente SOAP. El acronismo inicial, fue dejado de lado en la versin 1.2, cuando se volvi una recomendacin de la W3C el 24 de junio de 2003, porque su nombre daba a confusin. SOAP fue diseado por David Winer, Don Box, Bob Atkinson y Mohsen Al-Ghosein en 1998 con respaldo de Microsoft. Actualmente, la especificacin SOAP es mantenida por el XML Protocol Working Group de la W3C.

RPC
Para el Estado socialista de China continental, vase Repblica Popular China. El RPC (del ingls Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar cdigo en otra mquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tena que estar pendiente de las comunicaciones, estando stas encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o funcin y enviando ste de vuelta el resultado de dicha operacin al cliente. Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre s. La mayora de ellos utilizan un lenguaje de descripcin de interfaz (IDL) que define los mtodos exportados por el servidor.

Hoy en da se est utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de stos pueden ser SOAP o XML-RPC.

Orientacin a Servicios: Dnde Quedaron los Objetos

Posted on enero 22, 2006

Das

atrs estaba hablando sobre integracin de aplicaciones. Hoy es muy difcil hablar de

integracin ignorando el concepto de Orientacin a Servicios (Service Orientacion o SO) y especialmente el estilo arquitectnico conocido como SOA

Uno de los que me escuchaba cumple hoy un rol jerrquico, est alejado de la tecnologa y sus ltimos acercamientos estuvieron en el mainframe. Por ende se haba salteado tambin la experiencia de programacin dentro de un lenguaje del paradigma de programacin orientada a objetos (object-oriented programming u OOP). A este paradigma slo lo conoci por artculos, lo que lo llev a preguntarme -Cuando se habla de "orientacin a servicios" y "orientacin a objetos", ambos conceptos son intercambiables? Existen dos mitos (bueno, seguramente varios ms) respecto de la orientacin a servicios

Mito 1: Orientacin a Servicios y Orientacin a Objetos son la misma cosa Mito 2: Orientacin a Servicios viene a suceder a la Orientacin a Objetos

Vamos a refutar a cada uno por separado Mito 1: SO.equals(OO) Quienes acuan esta creencia, en ms de un caso, ven mala f de los grandes vendors en el sentido de "cada tantos aos salir a la calle con un verso nuevo para captar atencin, pero es todo lo mismo de siempre". Voy a ser enftico: la Orientacin a Servicios poco tiene que ver con la Orientacin a Objetos El paradigma Orientado a Objetos es un paradigma de programacin que enfatiza el concepto de encapsulamiento de funcionalidades cohesivas en clases. Esto permite al resto de la aplicacin abstraerse de la complejidad encapsulada, mejorando la mantenibilidad del sistema global. Por otra parte, es posible maximizar el reuso de toda o parte de la lgica mediante un esquema jerrquico donde las clases (o tipos) heredan propiedades y mtodos de otros, pudiendo estos ltimos ser reimplementados en las clases descendientes. Ese esquema jerrquico es el que permite que la aplicacin tenga un comportamiento polimrfico, segn cual sea el miembro de la jerarqua al que se le

invoca un mtodo dado. Suficiente lo dicho sobre OOP, no? Creo que an aprobara el examen terico. Pasemos a revisar el otro paradigma La Orientacin a Servicios es un paradigma arquitectnico que planea a un sistema con la premisa de integrar funcionalidades autnomas, en contraposicin a la tendencia de disear primero sistemas aislados y pretender integrarlos a posteriori. A estas funcionalidades autnomas es que se las llama Servicios, y se pretenden que duren a largo plazo, a la par que se espera de los mismos alta disponibilidad y estabilidad. De este modo los sistemas se ensamblan adaptivamente de estos servicios distribuidos. En ese sentido, los sistemas s estn pensados para cambiar Hay cuatro premisas que Microsoft distingue como fundamentales en la Orientacin a Servicios

Las fronteras son explcitas. El punto de interaccin del consumidor y el proveedor est perfectamente demarcado, aceptado, de modo que ambas partes se comuniquen va intercambio de mensajes. Del punto de vista del desarrollo, este intercambio simplifica la integracin. No obstante se debe considerar que en ejecucin cada cruce de frontera paga peaje Los servicios son autnomos. Esto implica compromisos mutuos: el consumidor no debe asumir cmo el proveedor implementa el servicio (plataforma, lenguaje de programacin, diseo interno, etc); el proveedor no debe suponer que el consumidor siempre acte adecuadamente (que pase los parmetros dentro de los rangos de valores, que recupere estados inconsistentes, etc). Este principio de autonoma tiene como objetivo que el proveedor pueda versionar su servicio, desplegarlo, etc, en forma absolutamente transparente y sin impacto para los consumidores El intercambio de mensajes se basa en contratos. Ambas partes intercambian mensajes de estructuras dadas. Estas estructuras se definen con esquemas neutrales. El contrato de un servicio aglutina todos los posibles esquemas de mensaje, tanto de entrada como de salida, que el servicio tiene considerados. En la medida en que los contratos se conserven se apuntala el principio de autonoma. Una recomendacin surgida de la experiencia es que los mensajes se compongan de la mnima informacin posible, de datos bsicos. Preferentemente datos primitivos que clases serializadas, ya que estas ltimas aumentan el acoplamiento entre ambas partes: a la primera modificacin en alguna de las mrgenes habra que rehacer el contrato, se entiende? An cuando sea inevitable modificar el contrato, es recomendable versionar el servicio La compatibilidad semntica se declara con polticas. La premisa anterior hace referencia a la compatibilidad estructural: el qu de la integracin. Tambin hay que contemplar el cmo o el quin de los requerimientos operacionales. Me refiero a acuerdos de nivel de servicio, encriptacin de partes del mensaje, canales de transporte habilitados, obligatoriedad de autentificacin, integridad transaccional, y varios etc. Este principio establece que tales requerimientos no deben estar embebidos en la lgica ni del proveedor ni del consumidor del servicio, sino que se deben fijar como polticas de compatibilidad implementadas en la infraestructura de integracin. WS-Policy es una especificacin de WS-I que pone en prctica este concepto mediante un esquema basado en aserciones

Mito 2: SO reemplazar a OO Falso: la segunda premisa de la orientacin a servicios establece un principio de autonoma. Dentro de las fronteras de un servicio, a los ojos de un consumidor del

mismo, es indiferente si se ha optado por COBOL CICS, COBOL VMS, por SmallTalk, J2EE o TI-BASIC. La refutacin del mito anterior procuraba dejar en claro que SO no es lo mismo que OO. Ahora reafirmemos que ni siquiera son cosas comparables. Perfectamente se puede tener un sistema empresarial cuya arquitectura est orientada a servicios, en tanto que algunos o todos estos servicios estn implementados autnomamente dentro de un lenguaje o plataforma orientado a objetos Para responderle al ttulo de este artculo, entonces, los objetos quedan dentro de las fronteras de los servicios. La Orientacin a Servicios, en ese sentido, no es ms que una evolucin de tcnicas de integracin ya que hasta el momento se vena usando el mismo paradigma Orientado a Objetos:

El Object Management Group (OMG) en su momento cre CORBA, un modelo de integracin basado en objetos distribuidos Microsoft tena DCOM J2EE especificaba EJB basado en comunicacin RMI

Es materia opinable concluir que estos tres esquemas resultaron exitosos o no (si es por adopcin, fueron exitosos, si es por eficacia en la resolucin del problema, estimo que habr opiniones a favor y en contra). Lo innegable es el alto grado de acoplamiento del enfoque resultante de compartir clases. La premisa de la orientacin a servicios busca no repetir ese error al establecer que se comparten contratos y no clases. Esto explica el masivo vuelco de la industria a la tecnologa de Servicios Web, actualmente el estndar orientado a servicios de mayor aceptacin