martes, 27 de septiembre de 2016
domingo, 25 de septiembre de 2016
miércoles, 21 de septiembre de 2016
martes, 13 de septiembre de 2016
Principios de diseño SOA
Cuando un servicio se implementa como un servicio web, se debe adherir (proporcionar) un contrato de comunicaciones explícitamente declarado y definido colectivamente por uno o más descriptores del servicio, en el cual debe figurar especificaciones como:
• Nombre del Servicio.
• Forma de accesos.
• Funcionalidades que ofrece.
• Descripción de los datos de entrada de cada funcionalidad que ofrece.
• Descripción de los datos de salida de cada funcionalidad que ofrece.
De este modo, todo consumidor de los servicios accederá mediante el contrato, logrando la independencia entre el consumidor y la implementación del propio servicio. Con esto se evita el manejo incorrecto de los datos, se evita trabajo innecesario en la invocación entre estos servicios y también se pone de manifiesto que la existencia de un modelo de datos a nivel de servicio es una de las primeras necesidades que se debe tener en cuenta.
Ver más detalles de este principio.
2.- Bajo Acoplamiento:
Este principio hace referencia a que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
- con la implementación de la lógica del servicio.
- con los recursos del ambiente de implementación
- con la tecnología del vendedor
- con el padre del proceso de negocio
- con los miembros del servicio
Ver más detalles de este principio.
3.- Abstracción:
El principio de abstracción permite encapsular el servicio y reducir el acoplamiento. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo.
El uso de estándares permite definir interfaces uniformes que esconden la lógica del servicio respecto del entorno que le rodea (sistemas proveedores y consumidores).
Este nivel de abstracción permite centrarnos exclusivamente en la especificación del servicio, sin incluir información tecnológica ni de ninguna otra naturaleza, más allá de la propia especificación estándar del servicio desde el punto de vista del negocio al que sirve, que queda recogida en su contrato.
Ver más detalles de este principio.
4.- Reusabilidad:
La reutilización es el principal principio de la arquitectura SOA, cada servicio debe ser analizado, diseñado y construido de manera que su uso pueda ser explotado al máximo, es decir, cada servicio debe ser de algún modo genérico con el fin de que pueda usarse en diferentes contextos y satisfacer distintos objetivos. De esta manera, los servicios podrán ser reusables dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.
Por otro lado, estos servicios reutilizables deben estar diseñados de maneratal que su solución lógica sea independiente de cualquier proceso de negocio otecnología en particular.
Con este principio se busca reducir las posibilidades de duplicación de lógica.Si un servicio que ya existe en un contexto funcional se ajusta a la nuevalógica reutilizable, en lugar de crear un nuevo servicio, dicha lógica debe formar parte del servicio existente.
Ver más detalles de este principio.
5.- Autonomía:
Este principio nos dice que todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizado desde el punto de vista de la plataforma de ejecución.
Transformación gradual reduciendo el acceso a recursos compartidos e incrementando el aislamiento físico.
Ver más detalles de este principio.
6.- No estado:
Un servicio no debe guardar ningún tipo de información. El tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar deben provenir directamente de los parámetros de entrada. Esto maximiza la escalabilidad del servicio.
Tipos de estado:
- sesión
- contexto
- datos de negocio
Ver más detalles de este principio.
7.- Descubrimiento:
Todo servicio debe poder ser descubierto de alguna forma para que pueda descubierto, entendido y por tanto utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.
Ver más detalles de este principio.
8.- Composición:
Este principio nos dice que todo servicio debe estar construido de tal manera que pueda ser utilizado para construir servicios genéricos de mayor complejidad, el cual estará compuesto de servicios de menor nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).
El concepto de desarrollo de software a partir de componentes existentes independientemente fomenta el concepto de composición. Por ello el concepto de composición es heredado por la orientación a servicios, por lo que un proceso de negocio está automatizado mediante la combinación de múltiples servicios. Sin embargo, dentro de la orientación a servicios es mayor el enfoque en la creación de servicios que se pueden componer y recomponer dentro de múltiples soluciones para proporcionar la agilidad prometida por la SOA. Como resultado de este énfasis, algunas pautas son requeridas para el desarrollo de servicios que pueden ser efectivamente agregados en varias soluciones.
Ver más detalles de este principio.
Por qué los Web Services son hoy tan importantes
Por qué los Web Services son hoy tan importantes
Hagamos un poco de historia. En los primeros computadores corría un solo programa a la vez, pero en la medida que en un mismo computador podían correr varios programas al mismo tiempo, surgió la necesidad de contar con mecanismo de comunicación entre ellos, esto se llamó comunicación Task to Task y, este mecanismo a evolucionado debido que los computadores conforman redes. Por tanto, esta comunicación debe poder efectuarse entre un programa X, que corre en el computador Alfa, y otro programa Y, que corre en el computador Beta.
Para que esta comunicación funcione, primero debe existir un medio de comunicación entre el computador Alfa y el computador Beta; esto hoy esta resuelto con la Internet. Y segundo, el programa X debe saber conversar con el programa X. Para que esto ocurra el programador a cargo de X debe conocer de Y. A su vez el programador a cargo de Y debe conocer de X, por lo menos en los que se refiere al intercambio de datos. Esto hace que si no hay acuerdo entre el programador de X y el programador de Y, no hay comunicación posible.
La magia de los Web Services está en que el programador de X puede crear un Web Service para transferir datos sin necesidad de conocer al programador Y, ni a los programas que éste tiene a cargo. De modo que quien quiera recibir los datos solo necesita usar el Web Service y punto. Esto significa que pueden existir transferencias de datos entre distintas aplicaciones –programas- que funcionan en varios computadores, con distintos sistemas operativos, y que pertenezcan a diferentes empresas o instituciones.
A modo de ejemplo, si Ud. Ha despachado un material vía Federal Express y quiere conocer el estado de su despacho, esta empresa pone a su disposición un Web Service.
Definiciones
El término Web Services describe una forma estandarizada de integrar aplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa para la transferencia de los datos, WSDL se emplea para describir los servicios disponibles y UDDI se ocupa para conocer cuales son los servicios disponibles. Uno de los usos principales es permitir la comunicación entre las empresas y entre las empresas y sus clientes. Los Web Services permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos Sistemas de Información.
A diferencia de los modelos Cliente/Servidor, tales como un servidor de paginas Web, los Web Services no proveen al usuario una interfaz gráfica (GUI). En vez de ello, los Web Services comparten la lógica del negocio, los datos y los procesos, por medio de una interfaz de programas a través de la red. Es decir conectan programas, por tanto son programas que no interactúan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Web Services la interfaz para usuarios, por ejemplo mediante una pagina Web o un programa ejecutable, tal de entregarle a los usuarios un funcionalidad específica que provee un determinado Web Service.
Los Web Services permiten a distintas aplicaciones, de diferentes orígenes, comunicarse entre ellos sin necesidad de escribir programas costosos, esto porque la comunicación se hace con XML. Los Web Services no están ligados a ningún Sistema Operativo o Lenguaje de Programación. Por ejemplo, un programa escrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windows puede conversar con aplicaciones Unix. Por otra parte los Web Services no necesitan usar browsers (Explorer) ni el lenguaje de especificación HTML.
El modelo de computación distribuida de los Web Services permite la comunicación de aplicación a aplicación. Por ejemplo, la aplicación que procesa las órdenes de compra se puede comunicar con el sistema de inventarios, tal que este último le puede informar a la aplicación de compras cuales ítems deben comprarse por estar bajo su nivel mínimo. Dado el nivel integración que proveen para las aplicaciones, Los Web Services han crecido en popularidad y han comenzado a mejorar los procesos de negocios. De hecho, algunos postulan que los Web Services están generando la próxima evolución de la Web.
Tecnología Web Services
Los Web Services están construidos con varias tecnologías que trabajan conjuntamente con los estándares que están emergiendo para asegurar la seguridad y operatibilidad, de modo de hacer realidad que el uso combinado de varios Web Services, independiente de la o las empresas que los proveen, este garantizado. A continuación se describen brevemente los estándares que están ocupando los Web Services.
Hagamos un poco de historia. En los primeros computadores corría un solo programa a la vez, pero en la medida que en un mismo computador podían correr varios programas al mismo tiempo, surgió la necesidad de contar con mecanismo de comunicación entre ellos, esto se llamó comunicación Task to Task y, este mecanismo a evolucionado debido que los computadores conforman redes. Por tanto, esta comunicación debe poder efectuarse entre un programa X, que corre en el computador Alfa, y otro programa Y, que corre en el computador Beta.
Para que esta comunicación funcione, primero debe existir un medio de comunicación entre el computador Alfa y el computador Beta; esto hoy esta resuelto con la Internet. Y segundo, el programa X debe saber conversar con el programa X. Para que esto ocurra el programador a cargo de X debe conocer de Y. A su vez el programador a cargo de Y debe conocer de X, por lo menos en los que se refiere al intercambio de datos. Esto hace que si no hay acuerdo entre el programador de X y el programador de Y, no hay comunicación posible.
La magia de los Web Services está en que el programador de X puede crear un Web Service para transferir datos sin necesidad de conocer al programador Y, ni a los programas que éste tiene a cargo. De modo que quien quiera recibir los datos solo necesita usar el Web Service y punto. Esto significa que pueden existir transferencias de datos entre distintas aplicaciones –programas- que funcionan en varios computadores, con distintos sistemas operativos, y que pertenezcan a diferentes empresas o instituciones.
A modo de ejemplo, si Ud. Ha despachado un material vía Federal Express y quiere conocer el estado de su despacho, esta empresa pone a su disposición un Web Service.
Definiciones
El término Web Services describe una forma estandarizada de integrar aplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa para la transferencia de los datos, WSDL se emplea para describir los servicios disponibles y UDDI se ocupa para conocer cuales son los servicios disponibles. Uno de los usos principales es permitir la comunicación entre las empresas y entre las empresas y sus clientes. Los Web Services permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos Sistemas de Información.
A diferencia de los modelos Cliente/Servidor, tales como un servidor de paginas Web, los Web Services no proveen al usuario una interfaz gráfica (GUI). En vez de ello, los Web Services comparten la lógica del negocio, los datos y los procesos, por medio de una interfaz de programas a través de la red. Es decir conectan programas, por tanto son programas que no interactúan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Web Services la interfaz para usuarios, por ejemplo mediante una pagina Web o un programa ejecutable, tal de entregarle a los usuarios un funcionalidad específica que provee un determinado Web Service.
Los Web Services permiten a distintas aplicaciones, de diferentes orígenes, comunicarse entre ellos sin necesidad de escribir programas costosos, esto porque la comunicación se hace con XML. Los Web Services no están ligados a ningún Sistema Operativo o Lenguaje de Programación. Por ejemplo, un programa escrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windows puede conversar con aplicaciones Unix. Por otra parte los Web Services no necesitan usar browsers (Explorer) ni el lenguaje de especificación HTML.
El modelo de computación distribuida de los Web Services permite la comunicación de aplicación a aplicación. Por ejemplo, la aplicación que procesa las órdenes de compra se puede comunicar con el sistema de inventarios, tal que este último le puede informar a la aplicación de compras cuales ítems deben comprarse por estar bajo su nivel mínimo. Dado el nivel integración que proveen para las aplicaciones, Los Web Services han crecido en popularidad y han comenzado a mejorar los procesos de negocios. De hecho, algunos postulan que los Web Services están generando la próxima evolución de la Web.
Tecnología Web Services
Los Web Services están construidos con varias tecnologías que trabajan conjuntamente con los estándares que están emergiendo para asegurar la seguridad y operatibilidad, de modo de hacer realidad que el uso combinado de varios Web Services, independiente de la o las empresas que los proveen, este garantizado. A continuación se describen brevemente los estándares que están ocupando los Web Services.
lunes, 12 de septiembre de 2016
Crear un webservice básico con PHP y SOAP
SOAP es un protocolo de intercambio para servicios web basado en XML
¿cómo creamos un servicio web en PHP?
Para facilitarnos la vida empezaremos por descargar NuSOAP, un toolkit para el desarrollo de servicios web con SOAP en PHP, que nos proveerá de diversas clases para trabajar con este protocolo. Basta con descargarlo, descomprimirlo, meterlo dentro de nuestro proyecto y, cuando queramos usarlo, incluir nusoap.php como librería.
Ok, con NuSOAP instalado toca crear un servidor SOAP en nuestra aplicación. Para el ejemplo crearemos un servidor, lo llamaremos producto.php, que si recibe una petición donde se le pida una lista de libros devuelva tres títulos (es un ejemplo básico, piensa que en la realiadad podrías acceder a una base de datos y dar muchas más funcionalidades).
¿cómo creamos un servicio web en PHP?
Para facilitarnos la vida empezaremos por descargar NuSOAP, un toolkit para el desarrollo de servicios web con SOAP en PHP, que nos proveerá de diversas clases para trabajar con este protocolo. Basta con descargarlo, descomprimirlo, meterlo dentro de nuestro proyecto y, cuando queramos usarlo, incluir nusoap.php como librería.
Ok, con NuSOAP instalado toca crear un servidor SOAP en nuestra aplicación. Para el ejemplo crearemos un servidor, lo llamaremos producto.php, que si recibe una petición donde se le pida una lista de libros devuelva tres títulos (es un ejemplo básico, piensa que en la realiadad podrías acceder a una base de datos y dar muchas más funcionalidades).
<?php
require_once "nusoap.php";
function getProd($categoria) {
if ($categoria == "libros") {
return join(",", array(
"El señor de los anillos",
"Los límites de la Fundación",
"The Rails Way"));
}
else {
return "No hay productos de esta categoria";
}
}
$server = new soap_server();
$server->register("getProd");
$server->service($HTTP_RAW_POST_DATA);
?>
Ok, ahora necesitas un cliente, que llamaremos cliente.php. En el constructor, el cliente recibirá el url del servidor y para acceder al método que nos devuelve los libros recurriremos al método call(), al cual le pasaremos el nombre del método del servidor al que queremos acceder y los parámetros en forma de array. Además, también controlaremos que no haya errores en la comunicación.<?php
require_once "nusoap.php";
$cliente = new nusoap_client("http://localhost/producto.php");
$error = $cliente->getError();
if ($error) {
echo "<h2>Constructor error</h2><pre>" . $error . "</pre>";
}
$result = $cliente->call("getProd", array("categoria" => "libros"));
if ($cliente->fault) {
echo "<h2>Fault</h2><pre>";
print_r($result);
echo "</pre>";
}
else {
$error = $cliente->getError();
if ($error) {
echo "<h2>Error</h2><pre>" . $error . "</pre>";
}
else {
echo "<h2>Libros</h2><pre>";
echo $result;
echo "</pre>";
}
}
?>
Con esto ya tienes una idea múy básica del funcionamiento de un webservice SOAP construído con PHP. Pero claro, nos falta un archivo WSDL para tener un webservice decente. Aunque dicho archivo puede ser escrito a mano, NuSOAP puede generarlo por ti pasándole ciertos parámetros, por lo que lo ideal sería generarlo en el servidor. Así que modifica tu producto.php para que quede tal que así:<?php
require_once "nusoap.php";
function getProd($categoria) {
if ($categoria == "libros") {
return join(",", array(
"El señor de los anillos",
"Los límites de la Fundación",
"The Rails Way"));
}
else {
return "No hay productos de esta categoria";
}
}
$server = new soap_server();
$server->configureWSDL("producto", "urn:producto");
$server->register("getProd",
array("categoria" => "xsd:string"),
array("return" => "xsd:string"),
"urn:producto",
"urn:producto#getProd",
"rpc",
"encoded",
"Nos da una lista de productos de cada categoría");
$server->service($HTTP_RAW_POST_DATA);
?>
Como ves, el cambio en es cuando llamamos a register, ya que en vez de pasarle, como antes, el método en cuestión, le añadimos también varios argumentos para generar el WSDL:- El primer array nos permite definir el argumento de entrada y su tipo de datos
- El segundo define la función de retorno y su tipo de datos
- urn:producto es la definición del namespace
- urn:producto#getProd es donde definimos la acción SOAP
- Luego viene el tipo de llamada,que puede ser rpc, como en el ejemplo, o document
- Tras esto definimos el valor del atribute use, que puede ser encoded o literal
- Finalmente viene una descripción de qué hace el método al que llamamos
$client = new nusoap_client("libros.wsdl", true);
Fuente
martes, 6 de septiembre de 2016
lunes, 5 de septiembre de 2016
Suscribirse a:
Comentarios (Atom)
