!!!!!!! Recomendaciones!sobre!la!adopción!de!un!modelo!de! interoperabilidad!para!el!estado!de!chile!!!!

Tamaño: px
Comenzar la demostración a partir de la página:

Download "!!!!!!! Recomendaciones!sobre!la!adopción!de!un!modelo!de! interoperabilidad!para!el!estado!de!chile!!!!"

Transcripción

1 Recomendacionessobrelaadopcióndeunmodelode interoperabilidadparaelestadodechile RosaA.Alarcón DoctorenCienciasdelaIngeniería 06deAgostode2014

2 1. Títulodelproyecto Recomendaciones+ sobre+ la+ adopción+ de+ un+ modelo+ de+ interoperabilidad+para+el+estado+de+chile+ 3. Autor(es) Dr.RosaA.AlarcónChoque 2. Cuerpodelinforme hojas(incluyeportada) 4. Fechadelinforme 04/07/ AntecedentesdelaInstituciónMandante Nombre Dirección : Subsecretaria de Economía y Empresas de MenorTamaño : Av. Libertador Bernardo O'Higgins 1449, Torre II,SantiagodeChile. Teléfono : Resumen 6. Contrapartetécnica AndrésArellanoRecabarren DirectorGobiernoDigital EncoordinaciónconelEncargadode la División de Empresas de Menor Tamaño Estedocumentopresentaunresumendeconsideracionestécnicasquesirvendebaseaunconjuntode recomendaciones para la adopción de un modelo de interoperabilidad basado en el modelo arquitectónicorestparaelestadodechile. Dr.RosaA.AlarcónChoque

3 NormasGenerales 1 ElpresentedocumentopresentaelInformedelestudio Recomendaciones+sobre+la+ adopción+de+un+modelo+de+interoperabilidad+para+el+estado+de+chile desarrollado porencargodelaunidaddemodernizaciónygobiernodigital,ministeriosecretaria GeneraldelaPresidencia. 2 Los alcances de este infome están definidos explícitamente en la Sección 2 del presentedocumento. 3 Para el desarrollo de este infome se utilizó la información individualizada en la SecciónReferenciasquefueronaportadasporRosaA.Alarcón. 4 La información contenida en el presente informe no podrá ser reproducida total o parcialmente,parafinespublicitarios,sinlaautorizaciónpreviayporescritoderosa A.AlarcónmedianteunContratodeUsodeMarca. 5 LaUnidaddeModernizaciónyGobiernoDigitalpodrámanifestarydejarconstancia verbalyescrita,frenteaterceros,seanestosautoridadesjudicialesoextrajudiciales, que el trabajo fue preparado por la Dr. Rosa A. Alarcón, y si decide entregar el conocimiento del presente informe a cualquier tercero, deberá hacerlo en forma completaeíntegra,ynopartesdelmismo.

4 Contenido 1. Objetivos Alcances Metodología Marcoconceptual ServiciosWebTradicionales(WSDL,SOAPyWSb*) ServiciosWebREST Composición/WorkflowsdeserviciosREST Modelodecomponentes Modelodeaccesoadatos Modelodeseleccióndeservicio Modelodeorquestación(workflow) RefinacióndelacomposicióndeserviciosconQoS Composicióndeserviciosqueconsideraseguridad ClavesdeAPI(APIkeys) Nombredeusuarioycontraseña HTTPBasicAuthentication HTTPDigestAuthentication OpenID OAuth ComposicióndeserviciosRESTconsiderandoseguridad MonitoreoyAuditoriadeserviciosREST RecomendacionesparalaadopcióndeunmodelodeinteroperabilidadREST Modelodeaccesoadatos:APIREST Consideracionesdediseñoarquitectónico Modelodeorquestación Seguridad MonitoreoyAuditoria Referencias Anexo1:EspecificaciónRAML...28

5 1. Objetivos Definir un conjunto de recomendaciones para el diseño y adopción de un modelo de interoperabilidad para el Estado de Chile, particularmente considerando tecnologías WebligerastalescomoaquellasbasadasenREST. 2. Alcances ElalcancedeestedocumentoincluyeunarevisióndelosconceptosprincipalesdeREST pues estos van a justificar y dar detalles de los impactos de las recomendaciones propuestas.elalcancedeestedocumentoselimitaapresentarunmodelogeneralde servicios REST que comprende la composición de servicios (o workflow), aspectos de seguridad, monitoreo, auditoria y algunos detalles de diseño arquitectónico fundamentales. Las recomendaciones a realizarse buscan dar origen a políticas de estadoenlaimplantacióndedichomodelo. 3. Metodología Se hará una revisión de la literatura relevante y reciente así como de los productos, tecnologíasyestándaresquepuedanestarrelacionadosconelobjetivodeesteinforme. Estoselementosseránseñaladosenunaseccióndereferencias. 4. Marcoconceptual 4.1 ServiciosWebTradicionales(WSDL,SOAPyWSX*) Los Servicios Web tradicionales exponen datos y funcionalidad que puede ser consumida por otros servicios. Tradicionalmente, los servicios web proporcionan un documentowsdl(webservicedescriptionlanguage)[1]quedescribesuinterfazylas condiciones para ser consumidos(por ejemplo, con anotaciones WSbPolicyAttachment [2]).EstosserviciostípicamentesebasanenelestándardelaWebSOAP(SimpleObject Access Protocol) que también ha sido enriquecido para soportar características de seguridad, transparencia de ubicación, manipulación del despacho del mensaje, confiabilidad, etc. Estas características se implementan mediante una serie de estándares que apuntan a las propiedades no funcionales o de calidad (Quality( of( Service,( QoS) y en conjunto se denominan WSb* y han sido fuertemente por su complejidad y su dependencia de middleware (y altos costos) para poder ser manejables.( Las arquitecturas SOA típicamente explotan éste tipo de servicios para constituirse en un middleware que permite propiedades fundamentales tales como visibilidad,descubrimiento,consumoymonitoreodeservicios.estatecnología,expone en una dirección Web (URL) un punto único de entrada (endpoint)( a un conjunto de operacionessobreentidadesdedatosqueseocultanalcliente.(

6 Las operaciones se describen en un documento WSDL estándar; la semántica del servicionoesexplícitayporlogeneralrequierededocumentosadicionalesdestinadaa ingenieros que implementan los clientes del servicio, con el fin de comprender el alcance,efectos,condicionespreviasysuposicioneshechaspordiseñadoresdeservicio. Losclientesinteractúanconlosservidoressiguiendoladescripción;siéstacambia,los clientes fallan.los clientes no pueden recibir notificaciones sobre los cambios a la descripciónylasemánticadefallaysurecuperaciónsonadbhoc. Elprocesodecombinarlafuncionalidaddedosomásservicios(componentes)enuno nuevo(servicio compuesto) que proporciona valor agregado, se llama composición de servicios. En este informe se van a usar los conceptos workflow y composición de servicios refiriéndose a la idea de componer servicios. La selección de componentes adecuadospuedesermanualoautomática(esdecir,determinadaporunalgoritmo);el comportamientodelserviciocompuesto(esdecir,elordendeinvocacióndeserviciosy latransformacióndedatos)conformanunworkflowquesepuededeterminartambién deformamanualoautomática,yaseaentiempodediseño(composiciónestática)oen tiempodeejecución(composicióndinámica)[3]. La información que se produce durante la interacción entre un cliente particular y el servidor, es decir el estado de la aplicación, se mantiene en el lado del servidor (ej. Cookie( de( sesión,( la( instancia( o( thread( de( ejecución( de( un( workflow)( y por tanto se denomina Stateful, lo que repercute negativamente en la escalabilidad del servidor(y porendedelservicio)yaumentalacomplejidaddelastransaccionesdegranolargo(ej. Workflowsquetomanvariosdíasy/oinvolucranavariasentidades). EnresumenelSOAtradicional(basadoenWSDL,SOAPyWSb*)secaracterizaporuna altacomplejidad,unaescalabilidaddifícilycostosadeimplementar,altoacoplamiento, una difícil evolución de los servicios, y mecanismos sofisticados de seguridad, lo que requiereunmiddlewaresofisticadoyunafuertedependenciadeproveedores[4]. 4.2 ServiciosWebREST La Transferencia de Estado basada en Representaciones(REST, Representational State Transfer)eselnombredelestiloarquitectónicoenquesebasalaWebysecaracteriza porpermitirunaaltaescalabilidad,rendimientoycapacidaddeevolución,propiedades quetambiénsondeseablesparalosserviciosweb. Enestecontexto,elestiloarquitectónicoRESTpuedeentendersecomounsubconjunto restringido de SOA [1]. A diferencia de las operaciones WSDL, en REST los elementos centrales son los recursos, que son entidades abstractas identificados por URIs y que pueden ser manipuladas a través de una interfaz uniforme, es decir, un conjunto reducido de operaciones estándar cuya semántica es bien conocida de antemano por todos los componentes arquitectónicos (browsers, servidores, proxies, DNSs, caches, etc.), ejemplos de esta interfaz son el protocolo de transporte hipertextual, HTTP; el protocolodepublicaciónatom,atompub,etc.

7 En REST, el estado de la aplicación se modela explícitamente mediante recursos cuyo estado se transfiere a/de los clientes como consecuencia de la ejecución de las operaciones estándar. El estado se muestra a los clientes por medio de representaciones, que son documentos serializados según los tipos de medios específicos (por ejemplo, XML), y contiene enlaces a recursos relacionados (links) y controlesquepermitenalosclientesrealizaroperacionesquecambianelestadodelos recursos(porejemplo<link=urirel="service.post">,<form...>,etc.).nohaygarantía de que las operaciones, los recursos o incluso la red permanecen disponibles o sin cambios, sin embargo, debido a que existe una interfaz de falla uniforme (ej., los códigos de error del protocolo HTTP) con una semántica bien conocida, los clientes puedenrecuperarse. En un servicio REST no existen endpoints, sino entrypoints( a una red de recursos interconectados con un modelo hipermedial subyacente que determina no sólo las relacionesentrelosrecursos,sinotambiénlaposiblereddetransicionesdeestadode los recursos. Losclientes REST (ej. Browsers controlados por humanos) descubreny deciden que links/controles seguir/ejecutar dinámicamente. Esta restricción se conoce como HATEOAS (hipermedia como el motor del Estado aplicación) o simplemente hipermedia. LosserviciosRESTfulestáncobrandoimpulsoenlaindustriadebidoalasimplezadelas herramientas necesarias para implementarlos (a diferencia del middleware generalmente caro y complejo de SOA), su alta capacidad para proveer una mejora importanteencuantoadisponibilidad,escalabilidadyperformance(graciasaloscachés y statelesness, principalmente).((con el objetivo de garantizar una alta capacidad de evoluciónindependiente(yanárquica)ymantenerunacoplamientobajo,enrestnose considera necesaria la existencia de un documento de descripción de recursos. Los servicios REST aparecen con posterioridad a la definición de REST como un estilo destinadoalmanejoderecursosporpartedepersonas.enelmundosoa,sinembargo, una de las principales tareas es la integración, donde los clientes pueden ser otros servicios Web. En este entorno, la falta de esta una descripción de servicios limita la capacidad de consumir el servicio por parte de clientes de máquina (otros servicios) genéricos y en la práctica las llamadas Web APIs que cumplen el rol de servicios REST proveen amplia documentación, nuevamente destinada a los implementadores de clientes. Las diferencias arquitecturales entre los servicios WSDL/SOAP y REST (es decir, centralizado Vs. distribuido, centrado en operaciones Vs. centrado en recursos, fuertemente acoplado Vs. débilmente acoplado [5]), hacen difícil vislumbrar cómo aplicarlosresultadosdetecnologíasymetodologíasqueconsideransoawsdl/soapa los servicios REST. De acuerdo a Pautasso [6] se necesitan menos decisiones arquitectónicas al elegirse los servicios REST (son más simples), también se permite mayor flexibilidad y control por parte de los desarrolladores, independencia de los proveedores de soluciones envasadas, pero requiere experiencia técnica en cuanto a diseño, desarrollo y mantención, además no existen soluciones de middleware

8 especializado que ofrezcan características típicas del middleware WSDL/SOAP tales comotransacciones,confiabilidad,seguridadaniveldelmensajeenlugardelcontenido. 4.3 Composición/WorkflowsdeserviciosREST La composición de servicios incluye seis dimensiones: un modelo de componentes, un modelo de acceso a datos, un modelo de selección de servicio, un modelo de orquestación,unmodelotransacciones,yunmodelodecontroldeexcepciones[3,7] Modelodecomponentes EnWSDL/SOAP los servicios son los componentes principales de la arquitectura, en tantoqueenrestlosonlosrecursosylascoleccionesdelosrecursos[8,9].eldiseño de los componentes WSD/SOAP consideran supuestos a nivel de dominio (ej. Las operaciones), en tanto que en REST los supuestos se hacen a nivel de aplicación (ej. Mediatypes)ysonpocos,estandarizados,ybienconocidos.Esdecir,losrecursosdeben identificarse con una URI (Universal Resource Identifier); el estado de los recursos deben obtenerse mediante representaciones codificadas en algún estándar conocido (ej. HTML) o acordado con el cliente (ad hoc); los recursos deben ser manipulados a través de links( y controles (por ejemplo, un formulario HTML) incrustados en las representacionesdelrecurso;lasrepresentacionesdeterminanentiempodeejecución elconjuntodetransicionesdeestadodelosrecursosdisponiblesparalosconsumidores (hipermediacomoelmotordeestadodelaaplicación[10]) Modelodeaccesoadatos Elmodelodeaccesoadatosdefinecómoseespecificayseintercambianlosdatosentre los componentes [11]. A diferencia de los servicios basados en WSDL, el modelo de datos consiste en representaciones estandarizadas que no se refieren a información específica de dominio (ej. Un esquema XML para pagar impuestos), sino que son modelosgenéricos,otiposdemedios(ej.text/html,etc),paraserinterpretadospor clientesgenéricos(ej.navegadoresweb).lainformaciónintercambiadaentreclientesy servidoressiguelasreglasdealgúnprotocolodered(ej.http,atompub,etc.),donde los mensajes deben incluir toda la información requerida por los servidores para procesarlos.esdecir,no(se(guarda(información(del(estadode(la(aplicación(en(el(servidor( (ej.cookiesdesesión),sinoelcliente(ej.caché) Modelodeseleccióndeservicio Elmodelodeseleccióndeserviciodeterminacómoseeligeuncomponentedeservicio para ser parte de una composición, ya sea de forma estática(en tiempo de diseño) o dinámica (en tiempo de ejecución). En WSDL/SOAP la selección estática ocurre con ayuda de herramientas como buscadores en repositorios de servicios; la selección

9 dinámicaserestringealcampodelainvestigación.enrest,losclientesinspeccionanlas representaciones para encontrar los links y controles que marcan las transiciones posibles para un recurso y descubrir los URI delos componentes de servicio, así, el cliente encapsula la lógica de selección de servicio. La restricción de hipermedia desacopla clientes de servidores y permite a los servidores evolucionar de forma independiente(es decir, cambiar el nombre de host o la estructura URI en tiempo de ejecución),sinromperalosclientes.paratiposdemedioslimitados(ej.representación deoctetos),loscontrolessepuedenincrustarenlascabecerashttp(weblinking[12]) Modelodeorquestación(workflow) El modelo de orquestación define el orden y las condiciones de invocación de los componentes de servicio. Cuando se centraliza el control de la invocación, el estilo se llama orquestación [13], y de lo contrario se llama coreografía. En un modelo de orquestaciónexisteuncomponentecentral(orquestador)quecoordinalainvocaciónde los componentes. Para WSDL/SOAP, las orquestaciones se pueden especificar en lenguajescomowsbbpel[14]ointerfacesgráficasparaesbsyejecutarsepormotores de orquestación. Para REST, debido a que no existe una descripción estándar del servicio, tampoco existen herramientas genéricas que faciliten la definición de orquestaciones. El estilo basado en navegaciones de REST permite naturalmente workflows implementados mediante recursos y transiciones (embebidas en representaciones). Sin embargo, la interacción es descentralizada, los componentes estándébilmenteacopladosypuedenmutarencualquiermomento.estacaracterística, llamada evolución, plantea un desafío a la composición de servicios ya que los componentes (recursos) pueden cambiar inesperadamente. Por lo tanto, los clientes deben hacer pocos supuestos sobre los recursos y retrasar la debreferencia con los recursosrealeshastaelmomentodelainvocación(enlacedinámicotardío)[8]. LainvestigacióneimplementacionesdeindustriaenWSDL/SOAPyRESTsecentranenla orquestación, siendo JOpera [8] el framework (de investigación) más maduro para el caso de REST. En JOpera, el control y flujo de datos se modelan visualmente mientras queunmotorejecutaelserviciocompuestoresultante.en[15],elcontrolylosdatosse modela e implementan usando una Red de Petri mientras que la interacción y comunicación con los recursos mismos se modela en una descripción de servicio denominadarell[16].en[17],elflujodecontrolseespecificaensparqlylosservicios invocadospodríanserendpoints(wsdl/soaposerviciosrest(esdecir,recursos);desde la perspectiva orquestador, los servicios se describen como grafos. En [18] las descripciones de grafo de los recursos están disponibles públicamente (puede ser descubiertas usando HTTP OPTIONS). Un conjunto de restricciones regula cuándo ciertos controles se pueden ejecutar en los recursos (por ejemplo, obtener cierto estado),demaneraqueunmotororquestadorpodríarealizarunacomposición,perono seindicacómoexpresaresasrestricciones.losdosprimerosenfoquespermitenenlace dinámicotardíoylarestriccióndehipermedia.en[19]seproponendiversasestrategias para implementar el orquestador en REST: un recurso dedicado a llevar registro del

10 estadodeunhilodecomposición(unainstanciadelworkflow),unconjuntoderecursos donde cada estado de la composición se modela explícitamente. Ambas alternativas permitenmonitoreoyloggingdelasactividadesrealizadasdurantelaejecucióndeuna instanciadeunworkflowporloquepuedenfacilitarlaauditoriadeservicios. 4.4 RefinacióndelacomposicióndeserviciosconQoS Las propiedades no funcionales, normalmente llamadas QoS (Quality of Service) [20] incluyencategoríasindependientesdeldominio,comoelrendimiento,laconfiabilidad, la seguridad, la integridad de transacciones, la red, la infraestructura y los costos de invocacióndeservicio,entreotros.lasqosseusanparadeterminarlaconvenienciao nodeinvocarunserviciocomponenteenlugardeotro.lamayoríadelosesfuerzosde estandarizaciónsobrecomposicióndeserviciossecentranenlosservicioswsdl/soap. En estos servicios, losdescriptores del servicio (WSDL) hacen posible especificar las propiedades funcionales de las operaciones, así como de las variables de entrada y salida; las propiedades no funcionales se especifican mediante una familia de estándares WSb* de industria (ej. WSbSecurity [21], WSbPolicy [22], etc) junto con técnicasbienconocidasavecesimplementadasdemodoadbhoc(ej.lafirma)[23]. WSb*hasidofuertementecriticadaporsucomplejidad,loquerequieredeunconjunto deherramientaseinfraestructurademiddlewaresofisticadoparapoderserpuestasen práctica.estetipodeapisesestándaryricoperoessumamentecomplejo,sinembargo alserestándarsepuedeleerpormáquinas(i.e.software)loquefacilitalacomposición deserviciosylaexistenciadeherramientasdeapoyo Composicióndeserviciosqueconsideraseguridad Lanecesidaddemantenerlasinteraccionessegurasesfundamentalparalosserviciosy con mayor razón para los servicios compuestos en la web y por lo tanto se hace importantelacapacidaddedescribirlascapacidadesyrequerimientosdeseguridadde losservicios[24,25].eldominiodelaseguridadnopuedesermodeladoporunaúnica métricayaqueabordavariasdimensiones,porejemplo: Confidencialidad:Serefierealosmecanismos(estándaroadbhoc)quepermitenla comunicación confidencial, como la codificación(ej. MD5, SHA1, SHA256). Cuando dosserviciosintercambianmensajesdemodoqueunterceractorinterceptandoel mensajenopuedeentenderlo,entonceslainteraccióngarantizaconfidencialidad. Integridad:Demanerasimilaralaconfidencialidad,seutilizanmecanismosdefirma digital para asegurar la integridad del mensaje. Muchos servicios implementan su propiomecanismodefirma(ej.ordenarlosdatos,aplicarunalgoritmodecifrado,y concatenar la clave resultante con el contenido original). Si un tercero no pudo alterar el mensaje enviado o se identifica correctamente que fue alterado y por tantosedeberechazar,lainteraccióngarantizalaintegridaddelmensaje. Autenticación:Serefierealosprotocolosutilizadosparacomprobarlaidentidadde

11 losactoresenunainteracción.sielreceptordeunmensajepuedecomprobarqueel remitenteesrealmentequiendiceser,lainteraccióngarantizaautenticación.siun remitente autenticado no es rechazado sin razón alguna, entonces se provee Non( Repudiation.(Estos incluyen autenticación básica HTTP y autenticación cifrada[26], OpenID[19],nombredeusuarioycontraseña,tokendeaplicación,etc.Todosellos se basan en tokens simples(ej. Strings) o complejos(ej. Certificados digitales) que representanlaidentidaddelcliente. Autorización: Se refiere a los mecanismos utilizados para conceder derechos( de( acceso( sobre algunos recursos, como el protocolo OAuth [27]. Estos mecanismos puedensertansimplescomounalistadecontroldeaccesootancomplejoscomo algoritmosdeautorizaciónquerequierenunasecuenciadepasos,coninformación parcialymecanismosdeseguridadencadapaso(ej.kerberos). Estasdimensionestípicamentesecombinan,loquehacecomplejomodelareldominio deseguridadparaunservicio.losrequerimientosdeseguridadpuedendeterminarsede formaestática(ej.losdatosdebenserencriptados),perotambiénpuedenimplicarun comportamientodinámico(ej.protocolosdeautenticación)proporcionadoatravésde coreografías en la Web (ej. el protocolo de autorización de OAuth [27] que involucra redireccionesdelcliente). En[29]sereconocelanecesidaddelapuestaenprácticayverificacióndepolíticasde seguridadygestióndeseguridaddistribuidasparaservicioswsdl/soap,yunasolución basada en dominios jerárquicos y atributos transversales a las distintas entidades de seguridad es propuesto. Las políticas se aplican por medio de monitores distribuidos que filtran y controlan el flujo de información entre los servicios. Un enfoque más limitado es presentada por[30], donde un mecanismo de control de acceso se lleva a cabo sobre la base de un modelo de cálculo de eventos y monitores compatibles que garantizanlaejecucióndeunapolíticadeseguridad. NoexisteunesfuerzodeestandarizaciónsimilarenelcampodelosserviciosREST;por ejemplo, la seguridad Web ha evolucionado orgánicamente para hacer frente a las necesidadestecnológicasydeusuarioquehanidoapareciendo,dandolugaraenfoques ligeros,descentralizadosycomplementarioscapacesdeescalarconlademanda,riesgos de seguridad y bajas garantías de la Web. En Maleshkova et al. [31] se presenta una revisióndelaswebapisrestquehasidoautodeclaradasasí(incluyendowsdl,rest, basadoenxml,apiweb,etc.)enelsitioprogrammablewebencuantoasuapoyode mecanismosdeseguridad.seanalizaron222serviciosdelacategoríadeserviciosrest (18%), que abarca 51 categorías de servicios (ej. búsqueda, geolocalización, etc). Los mecanismos de seguridad encontrados incluyen una variada gama de prácticas desde lasmássencillas(lamayoría),alosestándaresdelw3cenmateriadeseguridadenla Web.Porejemplo,38%utilizaclavesdeAPI(APIkeys)conelfinúnicofindecontarlos accesosdeclientesautenticados(noautorización),mientrasqueelprotocolooauthes utilizadoporel6%delservicioinformado.hayquetenerencuenta,sinembargo,que los principales proveedores de servicios REST (ej. Facebook, Twitter, Google, etc)

12 permiten y requieren autenticación OAuth debido a casos de fraude y robo de identidad.acontinuaciónsepresentanestosmecanismos ClavesdeAPI(APIkeys) Es una estrategia de autenticación simple donde las credenciales de los consumidores para recuperar un recurso restringido pasan directamente al proveedor dentro de la solicitud.enestecaso,lacredencialeslaapi(keyqueidentificaalclienteynotienepor quéestarcifradaofirmada;estaestrategianoproveeniconfidencialidad,niintegridad, niautorización[33] Nombredeusuarioycontraseña Este es otro ejemplo de estrategia de autenticación simple donde las credenciales se envíandirectamentedesdeelconsumidoralproveedor,peroenestecasoserequiere tanto credenciales de identificación( y contraseña. Las credenciales no tienen por que estarcifradasofirmadasyelmensajetienelaspropiedaddeautenticaciónúnicamente, aunque debido a que es más fuerte que la API key, puede usarse con mecanismos complementarios(ej.acl)paragarantizarautorización HTTPBasicAuthentication Este es un protocolo más complejo para la autenticación. Este es un estándar compatible con la mayoría de los navegadores web [19]; su objetivo es proporcionar másseguridadalenvíodeinformacióndeautenticaciónentextoplano.esteprotocolo requierecompartirlascredencialesdelosclientesenunacadenaopacaenviadaatravés del cliente Web en el encabezado de una solicitud HTTP, siguiendo un mecanismo de cifradoconocidocomocodificaciónbase64yunalgoritmosimpledefirma.igualquela autenticaciónporusuarioycontraseña,estaestrategiaaseguraautenticación,ypuede serusadoparaautorización HTTPDigestAuthentication LaAutenticaciónBásicaporHTTPnoesunprotocolomuyseguroparalaautenticación de usuarios, porque la entidad codificada se transmite como texto que se puede decodificarfácilmente.elestándarwebhttpdigestproporcionaunapoyomásfuerte, ycomplejoalaconfidencialidadylaintegridad.elnombredeusuarioylacontraseñade las credenciales deben ser firmados con ciertos atributos, proporcionados por el servidorseguro,mediantemecanismostalescomomd5.esteprotocoloseimplementa endosfasescuyosresultadosintermediosvancifradosydebenconcatenarse.eneste caso se asegura autenticación, confidencialidad e integridad, y puede ser usado para autorización[26].

13 OpenID Este protocolo de autenticación es significativamente diferente de los demás, ya que requiereunainteracciónconunterceroquevalidalapruebadeidentidad.estetercero es el proveedor de OpenID; un consumidor (usuario) puede autenticarse contra un serviciomediantelapresentacióndeuntoken(generadoporunproveedordeidentidad conelqueelconsumidorseharegistradoanteriormenteyenelqueconfíaelservicio [19] OAuth OAuth [27] es un protocolo de autorización abierto que permite a una aplicación de terceros(unservicio)accederalosrecursosproporcionadosporunservicio(servidorde recursos) que son propiedad de un usuario reconocido por el servidor de recursos.el usuariotienequeautorizaralaaplicacióndetercerosparaaccederalosrecursos,sin necesidad de que el usuario exponga sus credenciales de autenticación a la aplicación deterceros.laautorizaciónserepresentacomountokentemporalopermanente. 4.5 ComposicióndeserviciosRESTconsiderandoseguridad EnREST,lainvestigaciónsobrecomposicióndeserviciosesbastanterecienteyelinterés enlaspropiedadesdecalidaddeserviciosehancentradoprincipalmenteenseguridad. Porejemplo,en[34]unserviciobasadoenAPIsRESTsedefineparaapoyaracuerdosde nivel de servicio basados en el estándar WSbAgreement [35]. Los acuerdos (y sus plantillas) se modelan como recursos REST codificados en el tipo de medio application/xml,cuyociclodevidayestadosemanejapormediodeverboshttp.graf etal.[36]presentanunmarcodecontroldeacceso,autorizaciónenelladodelservidor basado en reglas que limitan el acceso a los recursos servidos de acuerdo a las operacioneshttp[36].en[37]unmarcodeobligacionesdelladodelservidorpermitea los diseñadores de servicios extender un núcleo de políticas existentes con reglas que regulan el acceso a la información de los usuarios. Las reglas pueden desencadenar transacciones adicionales (ej. el envío de un correo electrónico de confirmación, el registro del intento de acceso a la información para futuras auditorias) o incluso modificar el contenido de la respuesta o el protocolo de comunicación(ej. Cambiar a HTTPS).Allam[23]buscahomologarlosserviciosyRESTyWSDL/SOAPconsiderándolos cajas negras, donde la interacción ocurre como un simple paso de mensajes entre clientesyservidores.laspolíticasdeseguridadsepuedencolocaralrecibiroalenviar un mensaje, así como a nivel local, es decir, en el lado del servidor o del cliente. Esta visiónsinembargonotieneencuentalainteraccióncomplejaqueinvolucraaterceros (ej.oauth),olaheterogeneidaddelainterfazdelservicio[38],dondelosestándaresde la industria se aplican de diversas maneras (ej. firmas que usan SHA256, pero la modificanasugusto).

14 4.6 MonitoreoyAuditoriadeserviciosREST En el área de los servicios Web tradicionales, organizaciones como la Organización de InteroperabilidaddeWebServices(WSbI)promuevenlainteroperabilidadentrediversas plataformaseimplementacionesguiandolaelecciónycombinacióndeestándareswsb* yfomentandolapuestaenmarchadebuenasprácticasatravésdeunaseriedeperfiles. Conelfindeasegurarlaconformidaddeunaimplementaciónparticularaalgúnperfil específico,seplanteaelusodeherramientasdemonitoreo,registro(logger)yanálisis, que se conocen en conjunto como WSJI( Testing( Tools( [39]. El WSbI Monitor es un componenteintermediarioqueactúainterceptandolosmensajessoapintercambiados entre un Web service y un cliente, generando registros de los eventos es un formato quepuedeseranalizadoposteriormenteparadeterminarlaconformidaddelaconducta del Web services y los formatos de mensajes (ej. Schemas) con algún Perfil WSbI. La mayoríadelosproveedoresdemiddlewaredeinfraestructura(jaxbwsdesun/oracle, Metro de Sun/Oracle, WCF WSb* de Microsoft, AXIS2 de Apache, etc.) afirman ser compatiblesalmenosconelperfilbásicodewsbi. En[40],elmonitoreoestáestrechamenterelacionadoconelworkflowuorquestación puessonlosmodelosespecíficosdeesteúltimolosquedeterminancómoyhastacierto puntoquémonitorear.zurmuehlen[41]clasificalastécnicasdemonitoreoycontrolde procesosdentrodelasorganizacionesdesdecuatroperspectivas:laperspectivadelos datos, la perspectiva del uso, la perspectiva de la herramienta y la perspectiva del método. La perspectiva de los datos se refiere a la recogida, almacenamiento y representación de la información para auditoría. La perspectiva de uso se refiere a la forma en que se aborda la gestión de control de procesos (por ejemplo, manejo de excepciones,gestiónglobaldelosprocesos,etc.).laperspectivadelaherramientatiene que ver con la arquitectura y las herramientas que se han desarrollado para el monitoreo y control, y la perspectiva del método esta relacionada con los enfoques conceptualesdemonitoreodeprocesosycontrol. La importancia del monitoreo aumenta cuando aumenta la dimensión de la infraestructura o servicios provistos, por ejemplo, en una plataforma de Cloud Computing, el monitoreo puede llegar a proveerse como un modelo adicional de servicio(monitoringbasbabservice,maas)[42].enestecaso,elmonitoreoincluyetareas tales como medición de consumo, aprovisionamiento, supervisión, facturación, planificacióndelacapacidad,conformidadconlaspolíticasdeseguridadacordadascon losclientes,gestióndelosnivelesdeservicio(slas)einformesparadartransparencia tantoparaelproveedorcomoparaelconsumidordelservicioutilizado[41]. EnelcasodeREST,alnoexistirinfraestructuraqueimplementeworkflows(exceptode investigación, tal como JOpera) el monitoreo se hace con base en los mensajes intercambiados entre cliente y servidor. Estas técnicas conocidas como Web( traffic(

15 analysis,puedenbasarseenweb(logs 1 (quesonregistrosdelosmensajesrecibidospor el servidor, incluyendo HTTP( headers y el código de respuesta que se envía al cliente. Los Web logs son archivos de texto plano que pueden llegar a ser extremadamente voluminosos pues el registro no discrimina el tipo de recurso solicitado, por lo tanto solicitudesdearchivosmediales(ej.fotos,iconos,etc.),deestiloydescriptingtambién son considerados. Los Web logs son posteriormente analizados para encontrar información relevante tal como tiempo de respuesta de las solicitudes de recursos, eficacia del almacenamiento en caché e intermediarios (ej. firewalls, analizadores de seguridad y sistemas de gestión y logging) [43], escalabilidad, planificación de la capacidadyrespuestaaataquesdedenegacióndeservicio[44],amenazasdeseguridad [45],opatronesdenavegación(consumo)[46],entreotros.Muchasvecesesteanálisis estediosopuesrequiereprocesamientodetextoplano,paraevitarestatareaalgunos permiten un registro en base de datos en paralelo, de todos los eventos que se consideren relevantes (no únicamente trafico de mensajes). En cualquier caso, es importantedeterminarquémonitorearpuesestosarchivospuedencrecerrápidamente y convertirse en un cuello de botella si la estrategia de escritura no está apropiadamenteimplementada. Elmonitoreoylaauditoriaestánfuertementerelacionados,peromásalládehablarde auditoria, quizás es conveniente hablar de responsabilidad (accountability [47]), entendida como la obligación última de actuar como administrador responsable en la protección y uso apropiado de la información personal de terceros. Desde esa perspectivaseconsideraunframeworkpreventivo,dedetecciónydecorreccióntantoa nivel de los usuarios(políticas de acceso, violación de estas y corrección de acciones), proveedores (políticas y análisis de riesgo, detección de intrusos y atribución de responsabilidades)comodelasautoridades(políticasdeprivacidad,auditoriayreportes de violaciones de políticas, evidencias y solución de disputas). En todos estos casos únicamentesepuedenejerceraccionesdeauditoriayatribuciónderesponsabilidadessi los mecanismos de monitoreo recolectan toda la información necesaria, en muchos casos sin embargo, esto no es posible y es necesario realizar una tarea tediosa de análisisdelosdiferenteslogsquemantienenlossistemas. 5. RecomendacionesparalaadopcióndeunmodelodeinteroperabilidadREST En la sección 4.2 se describen las características de los servicios REST así como se presenta una breve discusión de sus ventajas y desventajas frente a los servicios WSDL/SOAP. En la sección 4.3 se plantean las características que deben tener los servicios compuestos, orquestaciones o workflows (en este informe estos tres conceptosseplanteanenlasacepcionesqueloshacensinónimos)rest.enestasección sepresentanalgunasrecomendacionesparaponerenprácticaestosconceptos. 1

16 5.1 Modelodeaccesoadatos:APIREST DeacuerdoaFielding,autordeREST,una APIRESTdeberíadedicarlamayoríadesus esfuerzos descriptivos en definir los tipos de medios a utilizar para representar los recursos y avanzar el estado de la aplicación (i.e. incluir links y controles), o en la definiciónderelacionesextendidas,y/oenmarcashipertextualesparatiposdemedios estándar. Las APIs REST actuales mantienen tipos de medios conocidos(por ejemplo JSONoXML)ydedicansusesfuerzosendescribircómo(parámetros,URIs,etc.)deben ser consumidos los recursos y cuáles son las respuestas posibles, generando una enormevariaciónencuantoanotaciones(porejemplodocumentoshtmldescribiendo enlenguajenaturallaapi,documentosenjsondescribiendounejemplodelaapi,etc.) yestilosdelaapi.algunospocosesfuerzossehandedicadoadefiniryregistrartiposde medios(porejemplo,application/vnd.msbexcel)enregistrospúblicostalescomoiana 2. Estetipodeenfoqueesposibledebidoaquecorrespondenaunúnicoproveedorque hacelosesfuerzosposiblesparadefiniralgunaspocasestructurasderecursosgenéricas (por ejemplo entre 4 o 6) sobre las cuales se opera. En un escenario de diferentes actores (i.e. las entidades del estado) con diferentes servicios a proveer resulta casi imposible pensar en la definición de tipos de medios generales que puedan ser reutilizadosentodaslasentidades(porejemplo,application/vnd.rutbgov). Unasoluciónqueconjugalaflexibilidadnecesariaporlosproveedoresdeservicioscon la necesidad de estandarizar la provisión misma del servicio lo constituyen las descripciones de interfaces de servicio tales como WSDL. En REST se han propuesto algunoslenguajesdedescripcióntalescomowsdl2.0,wadl,wrdl,wdl,hal,rell, etc.peroningunohageneradolamasacríticanecesariaparaserprobadoenlaindustria y demostrar sus ventajas. Los primeros 4 han sido criticados por lo engorroso de su descripción,porserinnecesariamenteverbososypornorespetarlascaracterísticasde REST, los dos últimos en cambio respetan las características de REST, pero son propuestasdeinvestigaciónquenohanatraídoatenciónporpartedelaindustria. Recientemente algunas propuestas de documentación REST tales como Swagger 3, Blueprint 4 yraml 5 estánganandotracciónenlaindustriapuessonpropuestassimples yprácticas.lasdosprimerascubrenelciclodevidadedesarrollodeserviciosrestcasi completamenteperosonempresasdedicadasatemasnorelacionadosconintegración. EnelcasodeRAML,éstaesunapropuestabasadaenYAML 6 yjson 7,quesecentra únicamente en la descripción de APIs REST dejando a los desarrolladores la 2 3 https://helloreverb.com/developers/swagger

17 responsabilidad y libertad de su implementación. RAML considera los aspectos prácticosderestdejandoaldesarrolladorlapropiedaddehipermedia;ramlpresenta ademásunacargagramaticalbaja,loquefacilitasuaprendizaje.ramlesunapropuesta de MuleSoft 8, que es una empresa de integración con 8 años de experiencia con inversiones de SalesForce, Cisco y SAP Ventures entre otros y que suma usuariosyclientestalescomoaccenture,equifax,nestlé,mastercard,etc.enlafigura1 sepresentaunadescripciónramldeejemployenelanexo1suespecificación. 1. #%RAML title: World Music API 3. baseuri: 4. version: v1 5. traits: 6. - paged: 7. queryparameters: 8. pages: 9. description: The number of pages to return 10. type: number secured: include 12. /songs: #% 13. is: [ paged, secured ] 14. get: 15. queryparameters: 16. genre: 17. description: filter the songs by genre 18. post: 19. /{songid}: 20. get: 21. responses: : 23. body: 24. application/json: 25. schema: 26. { "$schema": "http://json-schema.org/schema", 27. "type": "object", 28. "description": "A canonical song", 29. "properties": { 30. "title": { "type": "string" }, 31. "artist": { "type": "string" } 32. }, 33. "required": [ "title", "artist" ] 34. } 35. application/xml: 36. delete: 37. description: 38. This method will *delete* an **individual song** Figura1.EjemplodeunaAPIRESTespecificadaenRAML Como se ve en la figura 1 el desarrollador tiene la libertad de especificar el servicio según sus necesidades, si bien esta flexibilidad es positiva en ese sentido, también constituye un riesgo pues diferentes desarrolladores pueden seguir diferentes 8

18 estrategias y realizar malas prácticas. Es importante que los supuestos fundamentales de las APIs sean claros y explícitos [48]. Adicionalmente, en la Figura 1, línea 25 se especificaunesquemadedatosparticularparalascanciones(quesondefinidascomo objetos enelesquema ),esdecir,ramltambién permitedefinirestructurasdedatosconsemánticasclarasquepuedenserreusadasen workflowsuotrosservicios,usadascomoreferenciasparaotrosdesarrolladores,usadas paravalidacióndelasllamadasdelservicioyqueporclaridadpuedenserdefinidasen documentosexternosalasapisrestrequiriendoportantorevisionesdecalidadyun repositorio.porestarazónseintroducenlassiguientesrecomendaciones: Recomendación 1: Definir un comité de gobernanza de SOAbREST, que contemple el ciclo de vida de los servicios, es decir el registro de servicios, la versión de servicios, la propiedad del servicio, modelación de servicios, composición de servicios, estrategias de descubrimiento y acceso a servicios, despliegue de servicios atómicos y workflows, seguridad de servicios, acuerdos deniveldeserviciosygestióndeservicios[49],ciclodevidadelosesquemasde datosycontroldecalidaddelosmismos. Recomendación 2: Adherir a algún estándar de descripción de interfaz de servicios(apisrest),enparticularserecomiendaraml. Recomendación3:CrearymantenerunrepositoriodeesquemasdedatosyAPIs RESTdemaneraquesefomenteelreusodeesquemasyservicios,secontribuya adifundirbuenasprácticasenlaconstruccióndeesquemasyapis,conelfinde facilitarlainteroperabilidadentrelosorganismosdelestado. En la Web existen diversos registros (IANA, IETF, ICANN, etc.) que facilitan la interoperabilidadentrelosdiferentescomponentesdelared.encuantoaapisresthan surgidodiferentesregistrosinformales(programmableweb 9,Mashape 10 )quehansido utilizadosporlacomunidadparadifundirinterfacesdeservicios(restono)paraotros desarrolladores. El registro debe conceptualizarse y diseñarse (su interfaz) como una herramientaparalabúsquedadeserviciosconloscualesinteroperaryparalabúsqueda deinterfacesqueresuelventareassimilares(yaseadelobjetivofinaldelservicioodela tecnología utilizada o desde el diseño de la interfaz) y que pueden servir a los desarrolladores como insumos del diseño de un workflow o como ejemplos para el diseñodesuspropiasinterfaces. Recomendación 4 : El comité de gobernanza debe aprobar y registrar los esquemas y APIs REST velando fundamentalmente por la existencia de buenas prácticas en el uso de los conceptos REST, HTTP, en el reuso de esquemas de datos,recursos,estrategiasdeseguridad,etc

19 Estaactividadesparticularmenteimportanteyesunapracticaseguidaporejemplopor IANA para el registro de tipos de medios, donde ingenieros expertos validan si el tipo propuesto ya existe y la propuesta es únicamente una variación del mismo o se diferencia en el uso del tipo o se están violando las reglas gramaticales o semánticas paraladefinicióndetipos.delamismamaneraelcomitédegobernanzadeberávigilar la sintaxis, semántica e intención del servicio propuesto así como los requisitos no funcionalesasociados. Recomendación5:Elcomitédegobernanzadebevigilareldiseñoarquitectónico delserviciopropuestoconelfindedetectarmalasprácticasdediseño. 5.2 Consideracionesdediseñoarquitectónico No solo es importante cómo la interfaz es diseñada sino que también es importante cómo el servicio (simple o workflow) es diseñado. Por ejemplo en los servicios Web tradicionales(wsdl/soap)elmétodohttppostseutilizacomountúnelparaenviar mensajes y se utiliza mal la semántica del método. Algunos desarrolladores podrían generar APIs REST para encapsular la llamada a servicios tradicionales violando el protocolo HTTP (estrategia seguida por WSDL 2.0). Debido a que el middleware tradicionalescasiimposibledemodificardemaneraqueaquellosserviciosdeconsulta utilicengetenlugardepost,estaviolaciónalprotocolodebeserpermitidaenlaapi REST,perodebeinformarselacausademaneraquenointroduzcaerroresfuturos. OtroproblematípicoestárelacionadoconlaimplementacióndelapropiedadStateless, esdecir,queelservidornodebeguardarmemoriadelasconversacionespreviasentre el cliente y servidor. Un ejemplo típico lo son las cookies de memoria que guardan el hecho de que el cliente se ha autenticado previamente (Statefull). Una solución para mantenerautenticacióndeserviciosinestadoloconsisteoauthqueutilizaauntercero parageneraruntokendeseguridadqueespasadoalcliente,demaneraquetodaslas transaccionesdebenenviarcomounparámetroeltokenquedemuestraqueelcliente estáautenticado. FinalmenteunasituaciónquerequiereexperienciadediseñoeselmanejodeCachés,el objetivo de los Cachés es permitir la replicación de los recursos, aún más acercar las réplicas al cliente final. Claramente esto tiene sentido si el recurso puede mantener múltiples copias consistentes durante algún tiempo, un ejemplo de ésta situación lo constituyen los recursos mediales (fotografías, iconos, imágenes de fondo, javascript, CSS, etc.), que toman ventaja de la existencia de los intermediarios Web (proxies, gateways,proxiesinversos,etc.)ydelprotocolohttpmediantelosheadersdemanejo de caché. En el caso de las transacciones, éstas no necesitan (por lo general) estar cacheadasporloquenotomanventajadelusodelainfraestructurahttpconestefiny

20 pueden utilizar otro tipo de infraestructura (por ejemplo un ESB) que otorgaría potencialmenteventajastalescomoseguridadyconfiabilidad. 5.3 Modelodeorquestación Respecto del modelo de orquestación, recordemos que en REST un servicio es un conjuntoderecursos(porejemplomedialestalescomoíconos,scripts,etc.)algunosde los cuales pueden ser recursos que representen instancias de un workflow(ver Figura 2). Teniendo como meta la escalabilidad, tiempo de respuesta, disponibilidad, flexibilidad, capacidad de ser monitoreado y auditado, se hace la siguiente recomendación. Recomendación 6: DebecapacitarsealosdesarrolladoresdeaplicacionesREST en los aspectos arquitectónicos del estilo y en sus consecuencias en cuanto a requisitosnofuncionales. Recomendación 7: Debendefinirsepatronesdediseñoparalaimplementación de workflows REST. Particularmente se propone el patrón de orquestación centralizada,sinestado,queseapreciaenlafigura2. Cliente <<resource>> Workflow <<servicio>> Servicio1 <<resource>> Workflow/{id} <<resource>> Log/{id} <<service>> Servicio2 <<resource>> Productos (1) (2) (3) (4) (5) (6) (7) POST /Workflow 303 (See Other) Location: /Workflow/{id} GET /Workflow/{id} Crea instancia 200 (OK) Actualiza estado de instancia GET /productos 200 (ok) lista de productos (8) (9) (10) POST /Log/{id} evento sincrono 200 (ok) Figura2.EjemplodeunaOrquestacióncentralizada,sinestado. Esdecir,unWorkflowpuedesermodeladocomounrecursoqueencapsulalalógica del mismo (un orquestador), y cada instancia (invocación o ejecución) del mismo se modelacomounrecursoadicional(porejemploworkflow/{id}),generadoapartir delainvocacióndelworkflow,comoseapreciaenlafigura2,mensajes1y2.eneste enfoque, el cliente conoce la URL del Workflow y requiere una instancia del mismo

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

TECNOLOGÍAS ASOCIADAS A LAS APLICACIONES WEB

TECNOLOGÍAS ASOCIADAS A LAS APLICACIONES WEB TECNOLOGÍAS ASOCIADAS A LAS APLICACIONES WEB Existen varios tipos de tecnologías para los Servidores Web, estas tecnologías se pueden dividir en 4 grupos principales que son: Tecnologías al lado del cliente

Más detalles

Servicios web. Jorge Iván Meza Martínez jimezam@gmail.com

Servicios web. Jorge Iván Meza Martínez jimezam@gmail.com Servicios web Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/71 Contenidos Que es un servicio web. Tecnologías

Más detalles

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN)

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN) COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA 1 Ismael Armando Zúñiga Félix y 2 Luicyana Pérez Figueroa 1,2 División de Estudios de Posgrado e Investigación (DEPI), Instituto

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Sesión 5 Introducción a REST

Sesión 5 Introducción a REST Sesión 5 Introducción a REST Sistemas Distribuidos Diego Sevilla Ruiz DITEC Facultad de Informática Murcia, 2012 Diego Sevilla Ruiz (DITEC Facultad de Informática) Sesión 5 Introducción a REST Murcia,

Más detalles

TEMA 5. Otras arquitecturas distribuidas IV. Web Services

TEMA 5. Otras arquitecturas distribuidas IV. Web Services TEMA 5. Otras arquitecturas distribuidas IV. Web Services IV. Web Services 1. Qué son los Web Services? 2. Ejemplos de Web Services 3. Tecnologías y arquitectura 3.1. Arquitectura 3.2. Lenguaje de descripción:

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Programación de red con Cisco Application Centric Infrastructure

Programación de red con Cisco Application Centric Infrastructure Informe técnico Programación de red con Cisco Application Centric Infrastructure Descripción general En este documento se examina la compatibilidad de la programación de Cisco Application Centric Infrastructure

Más detalles

2524 Developing XML Web Services Using Microsoft ASP.NET

2524 Developing XML Web Services Using Microsoft ASP.NET 2524 Developing XML Web Services Using Microsoft ASP.NET Introducción La meta de este curso es de proveer a los estudiantes con el conocimiento y habilidades requeridas para desarrollar soluciones basadas

Más detalles

Universidad Nacional Autónoma de México Dirección de Sistemas Dirección General de Personal

Universidad Nacional Autónoma de México Dirección de Sistemas Dirección General de Personal Universidad Nacional Autónoma de México Dirección de Sistemas Dirección General de Personal Presenta: Mtro. Israel Ortega Cuevas para la Red Universitaria de Colaboración en Ingeniería de Software y Base

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Desarrollo y servicios web

Desarrollo y servicios web Desarrollo y servicios web Luisa Fernanda Rincón Pérez 2014-2 Qué vimos la clase pasada? Introducción a Big Data Introducción a bases de datos NOSQL Características bases de datos NOSQL MongoDB como motor

Más detalles

Servicios Web. Capítulo 5: Introducción a los Servicios Web. Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es

Servicios Web. Capítulo 5: Introducción a los Servicios Web. Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es Servicios Web Capítulo 5: Introducción a los Servicios Web Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es http://diis.unizar.es/postweb/ Departamento de Informática e Ingeniería de

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Sistemas Distribuidos Servicios web. Rodrigo Santamaría

Sistemas Distribuidos Servicios web. Rodrigo Santamaría + Sistemas Distribuidos Servicios web Rodrigo Santamaría + Servicios web Introducción IDL SOAP REST XML/JSON-RPC 2 + Introducción 3 n Java RMI o Sun RPC son middleware de nivel alto, aptos para realizar

Más detalles

Portal Inteligente Medellín Documentación de la Arquitectura de Software

Portal Inteligente Medellín Documentación de la Arquitectura de Software Guías para las API de servicios Portal Inteligente Medellín Documentación de la Arquitectura de Software Juan G. Lalinde-Pulido Claudia M. Zea Luis F. Londoño Nicolás Hock Sergio A. Monsalve Departamento

Más detalles

Si usted quiere desarrollar con Bluevia y Java, esto es lo primero que debe saber

Si usted quiere desarrollar con Bluevia y Java, esto es lo primero que debe saber LIMINAL Si usted quiere desarrollar con Bluevia y Java, esto es lo primero que debe saber Mario Linares Vásquez mario.linares@liminal-it.con Junio 30 de 2011 Network as a Service - NaaS Que información

Más detalles

Introducción a WS-REST. Ing. Guillermo Roldós Agosto 2010

Introducción a WS-REST. Ing. Guillermo Roldós Agosto 2010 Introducción a WS-REST Ing. Guillermo Roldós Agosto 2010 Agenda Descripción general Arquitectura orientada a recursos (ROA) Soporte Java y.net Calidad de servicio Casos de estudio Dominios de aplicación

Más detalles

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 El problema: las aplicaciones tradicionales no le proveen la agilidad necesaria

Más detalles

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Los nuevos escenarios de programación con SAP Netweaver (serie de varios

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

Más detalles

INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA

INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA Ing. Marco Jiménez HA-2508 SEMINARIO DE TEMAS ARCHIVÍSTICOS 21-09-2010 Temas de la presentación Definiciones Interoperabilidad Sistema Importancia de

Más detalles

PIDE. Presentación. Proyecto Plataforma de Interoperabilidad del Estado. Preparado por: Equipo de Proyecto PIDE

PIDE. Presentación. Proyecto Plataforma de Interoperabilidad del Estado. Preparado por: Equipo de Proyecto PIDE PIDE Proyecto Plataforma de Interoperabilidad del Estado Presentación Preparado por: Equipo de Proyecto PIDE Contenido Introducción Objetivos del Estado Servicios al Ciudadano Situación Actual LA PIDE

Más detalles

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos.

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. I JORNADAS DE SIG LIBRE Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. Alejandro Guinea de Salas (1), Sergio Jorrín Abellán (2) (1) Director de Geograma

Más detalles

Web Services. Richard Rossel rrossel@inf.utfsm.cl. 23 de noviembre de 2004. Web Services

Web Services. Richard Rossel rrossel@inf.utfsm.cl. 23 de noviembre de 2004. Web Services Richard Rossel rrossel@inf.utfsm.cl 23 de noviembre de 2004 JAVA2 TOC s JAVA2 JAVA2 Definición Aplicaciones Autocontenidas y Modulares Basado en estándares (XML,HTTP) Aplicaciones se anuncian por la red

Más detalles

Service Broker. Bind. Service Consumer. Service Provider

Service Broker. Bind. Service Consumer. Service Provider En este capítulo, usted podrá empezar por mirar a la arquitectura orientada al servicio como un concepto en arquitectura para aplicaciones distribuidas. A continuación usted examinará cómo estas arquitecturas

Más detalles

1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON) TE: 0342-4602390 Int. 258/107 TE: 0345-4214590

1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON) TE: 0342-4602390 Int. 258/107 TE: 0345-4214590 Herramienta BPEL para el desarrollo de Aplicaciones de Comercio Electrónico con Servicios Web Baroni, Federico 1, Chezzi, Carlos María 2, y Tymoschuk, Ana Rosa 1 1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON)

Más detalles

Sistemas Operativos Distribuidos. Introducción a los Servicios Web (Web Services)

Sistemas Operativos Distribuidos. Introducción a los Servicios Web (Web Services) Introducción a los Servicios Web (Web Services) 2 Evolución de la Web Pasado: Web de documentos Páginas estáticas Web como un enorme repositorio de información Tecnologías: HTTP + HTML Presente: Web de

Más detalles

Servicios Web. Andrés Pastorini. TRIA Tecnólogo Informático

Servicios Web. Andrés Pastorini. TRIA Tecnólogo Informático Andrés Pastorini TRIA Tecnólogo Informático Un servicio web expone un conjunto de servicios para ser consumidos a través de la red. En otras palabras, un servicio web especifica un conjunto de operación(funciones

Más detalles

Tecnologías Grid Estándares grid

Tecnologías Grid Estándares grid Tecnologías Grid Estándares grid Master en Sistemas y Servicios Informáticos para Internet Universidad de Oviedo Estándares grid Introducción Introducción Justificación El grid se construye a base de diversos

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

HOJA TÉCNICA. SemTalk 2

HOJA TÉCNICA. SemTalk 2 HOJA TÉCNICA SemTalk 2 SemTalk 2 - Información Técnica SemTalk 2 es una herramienta para modelamiento de procesos de negocios y conocimientos orientado a objetos 100% compatible con MS Office. REQUERIMIENTOS

Más detalles

La aplicación práctica en el mundo empresarial de los estándares Web

La aplicación práctica en el mundo empresarial de los estándares Web La aplicación práctica en el mundo empresarial de los estándares Web El problema de la integración inter/intra empresas y la familia "XML" Enrique Bertrand XML Business Integration, Regional Director Software

Más detalles

Máster Universitario en Ingeniería Informá3ca. REST avanzado. Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA

Máster Universitario en Ingeniería Informá3ca. REST avanzado. Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA Máster Universitario en Ingeniería Informá3ca REST avanzado Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 OAuth Flask REST avanzado Objetivo 3 En Sistemas Distribuidos vimos cómo:

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC.

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow Palabras claves: Groupware, Workflow, BPCM, WfMC. Introducción A partir de la llegada de las computadoras personales al ambiente empresarial

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran:

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran: Desarrollo de aplicaciones y servicios web Cinxgler Mariaca Minda Cinxgler@udistrital.edu.co Presidente Capítulo de Computadores Rama IEEE Universidad Distrital Francisco José de Caldas Resumen: Este articulo

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Aplicaciones y Servicios Web (Web Services)

Aplicaciones y Servicios Web (Web Services) Aplicaciones y Servicios Web (Web Services) Joaquín Salvachúa DIT- jsalvachua@.upm.es -1- Internet NG Índice Problema a resolver Arquitectura SOAP WSDL UDDI Conclusiones -2- Internet NG Aplicaciones WEB

Más detalles

Máster Universitario en Ingeniería Informá3ca. REST avanzado. Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA

Máster Universitario en Ingeniería Informá3ca. REST avanzado. Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA Máster Universitario en Ingeniería Informá3ca REST avanzado Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 OAuth Flask REST avanzado Objetivo 3 En Sistemas Distribuidos vimos cómo:

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

Documentación Técnica Conector

Documentación Técnica Conector Documentación Técnica Conector Torre Ejecutiva Sur Liniers 1324, piso 4 Montevideo Uruguay Tel/Fax: (+598) 2901.2929* Email: contacto@agesic.gub.uy www.agesic.gub.uy Indice 1 Introducción...4 2 Casos

Más detalles

Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos

Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos Newsletter Noviembre 2012 Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos Contenido Por Ing. Iván García igarcia@datum.com.gt Página: El manejo de seguridad en los ambientes Web es uno de los puntos

Más detalles

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Arquitectura Java para el Cuarto Ejercicio José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Sumario Introducción Arquitectura en n-capas Arquitectura y el Cuarto Examen Java y su modelo

Más detalles

TEMA 5 LA FAMILIA XML EN LA NUEVA WEB

TEMA 5 LA FAMILIA XML EN LA NUEVA WEB TEMA 5 LA FAMILIA XML EN LA NUEVA WEB La Web, tanto cuantitativa como cualitativamente, se ha desarrollado extraordinariamente siendo el objeto de este texto ubicar el papel que XML juega y va a jugar

Más detalles

INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING. Características Técnicas y de Seguridad

INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING. Características Técnicas y de Seguridad INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING OCTOBER 13, 215 215 Índice Objetivo y metodología... 2 Resumen Ejecutivo... 2 Resultados (Seguridad)... 3 Nivel de Madurez (Seguridad)... 7 Resultados

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Curso de SOA. Nivel Avanzado

Curso de SOA. Nivel Avanzado Región de Murcia Consejería de Hacienda y Administración Pública Curso de SOA. Nivel Avanzado Módulo 3 Seguridad en SOA Escuela de Administración Pública de la Región de Murcia Contenidos del MODULO 3

Más detalles

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl)

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) EVOLUCIÓN DE LA WEB Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) Contenido Historia del Internet. La Web 1.0. Definición. Características. La Web 2.0. Definición. Tecnologías de la

Más detalles

DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML

DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML Luís Fernando GONZÁLEZ ALVARÁN Facultad de Ingenierías, Politécnico Colombiano Jaime Isaza Cadavid Medellín,

Más detalles

GALA. Servicios WEB. Curso ASP.NET Desarrollo de Sitios y Servicios Web con Visual Basic 2010, 24 h. L25. Servicios Web en Integración

GALA. Servicios WEB. Curso ASP.NET Desarrollo de Sitios y Servicios Web con Visual Basic 2010, 24 h. L25. Servicios Web en Integración L25. Servicios Web en Integración L25. en ASP.NET Tipo de proyecto Archivos.ASMX Igual que los.aspx, UN URL Imports System Imports System.Web.Services

Más detalles

Capítulo 7: Introducción a la dinámica de servicios Web

Capítulo 7: Introducción a la dinámica de servicios Web Servicios Web Capítulo 7: Introducción a la dinámica de servicios Web Pedro J. Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es http://diis.unizar.es/postweb/ Departamento de Informática

Más detalles

JBoss Enterprise Middleware. Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com

JBoss Enterprise Middleware. Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com JBoss Enterprise Middleware Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com UN FUTURO TAN ABIERTO COMO SEA POSIBLE CODIGO ABIERTO ESTANDARES ABIERTOS CONTENIDO ABIERTO

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

TFM Comunicación, Redes y Gestión de Contenidos

TFM Comunicación, Redes y Gestión de Contenidos TFM Comunicación, Redes y Gestión de Contenidos Aplicación móvil hibrida para control de asistencia y servicio técnico a domicilio y gestión de partes de trabajo Autor: Patricia Paguay Lara Tutorizado

Más detalles

Taller de Sistemas de Información 3. Presentación SCA

Taller de Sistemas de Información 3. Presentación SCA Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando

Más detalles

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace 5. Internet 5.1. Qué es Internet? Internet es una red mundial de equipos que se comunican usando un lenguaje común. Es similar al sistema telefónico internacional: nadie posee ni controla todo el sistema,

Más detalles

Introducción a los Servicios Web

Introducción a los Servicios Web Introducción a los Servicios Web Simon Pickin Departamento de Ingeniería Telemática Universidad Carlos III de Madrid Algunas cifras (muy aproximadas) La compañía de investigación de mercado IDC estima

Más detalles

Tema 6: Comparativa CORBA/Servicios Web

Tema 6: Comparativa CORBA/Servicios Web Tema 6: Comparativa CORBA/Servicios Web Introducción Para establecer una comparativa, es preciso tener en cuenta CORBA se introdujo en 1991 y Servicios Web en el 2000 CORBA es una solución más madura y

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España

Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España Dirección General de Servicios Abril 2015 Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España Pliego de prescripciones

Más detalles

SISTEMAS DE INFORMACIÓN DE LA ADMON PÚBLICA. Sistemas de Acceso. Sistemas. Sectoriales. Sistemas. Transversales

SISTEMAS DE INFORMACIÓN DE LA ADMON PÚBLICA. Sistemas de Acceso. Sistemas. Sectoriales. Sistemas. Transversales Interoperabilidad e Intranet Gubernamental II Taller de Trabajo Red GEALC Plataforma de Interoperabilidad: Lenguaje Común y Enrutador Transaccional Hugo Sin Triana Noviembre 9 de 2006 Director Técnico

Más detalles

Servicios Web: Orquestación y coreografías

Servicios Web: Orquestación y coreografías Servicios Web: Orquestación y coreografías E. U. I. T. en Informática de Oviedo Master de Ingeniería Web Servicios Web Juan Ramón Pérez Pérez (jrpp en uniovi.es) Orientación a Servicios. Principios. Los

Más detalles

Bases de Datos Especializadas

Bases de Datos Especializadas Bases de Datos Especializadas BASES DE DATOS ESPECIALIZADAS 1 Sesión No. 12 Nombre: DBMS y Tecnología Web Objetivo: Al término de la sesión, el alumno identificará la integración entre DBMS y la web. Contextualización

Más detalles

Ayudar a reducir costes de desarrollo, identificando los problemas desde las fases iniciales mientras el software está siendo programado-,

Ayudar a reducir costes de desarrollo, identificando los problemas desde las fases iniciales mientras el software está siendo programado-, Introducción bugscout es una herramienta de análisis estático de código (SAST) que nace con el objetivo de automatizar el proceso de la revisión manual de código para encontrar vulnerabilidades de seguridad

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Roles y responsabilidades de cumplimiento ante los requisitos de PCI DSS en los diferentes servicios en la nube y sus modelos de despliegue

Roles y responsabilidades de cumplimiento ante los requisitos de PCI DSS en los diferentes servicios en la nube y sus modelos de despliegue Objetivo Roles y responsabilidades de cumplimiento ante los requisitos de PCI DSS en los diferentes servicios en la nube y sus modelos de despliegue Retos asociados con la validación de cumplimiento de

Más detalles

Patrones y buenas prácticas en SOA/REST

Patrones y buenas prácticas en SOA/REST Patrones y buenas prácticas en SOA/REST Software como Servicio y Distribuido 2010/2011 Diego Sevilla Ruiz DITEC Facultad de Informática Murcia, octubre de 2010 Diego Sevilla Ruiz (DITEC Facultad de Informática)

Más detalles

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen Indizen Labs imade Marco de Desarrollo Aplicaciones de Indizen Índice de contenidos Indizen Labs Introducción a imade Metodología imade Arquitectura imade Herramientas imade Indizen Labs Indizen Labs Son

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Sistemas Ubicuos 4. Descubrimiento de servicios

Sistemas Ubicuos 4. Descubrimiento de servicios Sistemas Ubicuos 4. Descubrimiento de servicios Departamento de Arquitectura y Tecnología de Computadores 1 Descubrimiento de servicios 1. Introducción 2. Protocolos de descubrimiento de servicios 3. Estructura

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red. Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor;

Más detalles

Seguridad en Aplicaciones Web

Seguridad en Aplicaciones Web Seguridad en Aplicaciones Web Juan Isaias Calderón CISSP, GCFA, ECSA, CEH, MCP jcalderon@trustwave.com SpiderLabs Lámina 1 Dr. Roberto Gómez C. Inseguridad de las aplicaciones Web De 300 sites auditados

Más detalles

Servicios Web Estándares, Extensiones y Perspectivas de Futuro

Servicios Web Estándares, Extensiones y Perspectivas de Futuro Servicios Web Estándares, Vicente Pelechano DEPARTAMENTO DE SISTEMAS INFORMÁTICOS Y COMPUTACIÓN Contenido Servicios Web Estándares y Tecnologías Subyacentes. Infraestructura Básica SOAP WSDL UDDI La Pila

Más detalles

Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones

Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones Norma: Normas de Seguridad de Datos (DSS) Requisito: 6.6 Fecha: febrero de 2008 Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones Fecha de publicación:

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Cursos de Extensión Universitaria UNIVERSIDAD DE OVIEDO. Servicios Web (II)

Cursos de Extensión Universitaria UNIVERSIDAD DE OVIEDO. Servicios Web (II) Fernández Acebal acebal@ieee.org OOTLab PROGRAMACIÓN ORIENTADA A OBJETOS CON C# EN LA PLATAFORMA.NET (II) Dpto. de Informática Lab - Laboratorio de Tecnologías Orientadas a Objetos www.ootlab.uniovi.es

Más detalles

Clase. geniería de la Computación. Departamento de Ciencias e Ing. Diego C. Martínez - DCIC-UNS

Clase. geniería de la Computación. Departamento de Ciencias e Ing. Diego C. Martínez - DCIC-UNS Ingeniería de Ap plicaciones Web Clase 2 Diego C. Martínez Departamento de Ciencias e Ing geniería de la Computación Universidad Nacional del Sur Internet y sus servicios Internet define una forma de conexión

Más detalles

Integración al Servicio de la Empresa

Integración al Servicio de la Empresa Integración al Servicio de la Empresa Las Arquitecturas SOA permiten abordar los nuevos retos empresariales, ser más competitivos y disponer de sistemas de información integrados. Además, tecnologías como

Más detalles