!!!!!!! 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SOLUCIÓN SITUACIÓN ACTUAL

SOLUCIÓN SITUACIÓN ACTUAL SITUACIÓN ACTUAL La necesidad de las organizaciones de ser más competitivas en un mercado dinámico ha generado estructuras organizacionales complejas y exigentes en términos de calidad y eficiencia. Sobre

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

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

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

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

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

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

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

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

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

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

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

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

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

Programación páginas web JavaScript y PHP

Programación páginas web JavaScript y PHP Programación páginas web JavaScript y PHP Curso de desarrollo de aplicaciones web. Para ello se estudia la programación de la parte cliente con JavaScript y la programación de la parte servidor con la

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

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

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

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

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

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

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

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

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

abacformacio@abacformacio.com

abacformacio@abacformacio.com Programación de páginas web con PHP Curso de desarrollo de aplicaciones web. Para ello se estudia la programación de la parte cliente con JavaScript y la programación de la parte servidor con la tecnología

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

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

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

Arquitectura de Proyectos de IT. Integración. Ing. Gastón Coco Ing. Nicolás Passerini Ing. Juan Arias Ing. Gustavo A. Brey Ing.

Arquitectura de Proyectos de IT. Integración. Ing. Gastón Coco Ing. Nicolás Passerini Ing. Juan Arias Ing. Gustavo A. Brey Ing. Integración Ing. Gastón Coco Ing. Nicolás Passerini Ing. Juan Arias Ing. Gustavo A. Brey Ing. Santiago Blanco 2005 Agenda # Tema Duración 1 Por qué integración? 10 min 2 Métodos de integración 25 min 3

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

Servicios Web Ministerio del Interior N10

Servicios Web Ministerio del Interior N10 Servicios Web Ministerio del Interior N10 Introducción Propósito. Definir e indicar a los usuarios, los requerimientos y buenas prácticas para la implementación de los servicios y tecnologías utilizadas

Más detalles

La seguridad en Zyncro

La seguridad en Zyncro La seguridad en Zyncro El Software como Servicio (SaaS) está siendo adoptado rápidamente por las organizaciones que demandan seguridad, fiabilidad y disponibilidad. Zyncro fue creado a la vista de estos

Más detalles

Una puerta abierta al futuro

Una puerta abierta al futuro Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico

Más detalles

TrustedX: eidas Platform

TrustedX: eidas Platform TrustedX: eidas Platform Plataforma de identificación, autenticación y firma electrónica para entornos Web. Proporciona aseguramiento de la identidad basada en autenticación adaptativa y el reconocimiento

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

Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de

Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de Murcia Director General de Informática Consejería de Economía y Hacienda Comunidad Autónoma de la Región de Murcia Jefe

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

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

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

Desarrollo y servicios web

Desarrollo y servicios web Desarrollo y servicios web Luisa Fernanda Rincón Pérez 2015-1 Qué vimos la clase pasada? 1. Fin tutorial HTML 2. Nombres de dominio 3. URLs 3 Sesión 4. Método GET - POST Qué haremos hoy? 1. Tipos de solicitudes

Más detalles

MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions

MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions S MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este

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

Convergencia, Interoperabilidad y. Fernando González-Llana Gerente de Cuenta AGE T-Systems

Convergencia, Interoperabilidad y. Fernando González-Llana Gerente de Cuenta AGE T-Systems Convergencia, Interoperabilidad y Arquitecturas de Servicios Gerente de Cuenta AGE T-Systems Palabras clave Convergencia digital, Interoperabilidad, Semántica, IDABC, SOA, Módulos Comunes, Protección de

Más detalles

POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN

POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN PÁGINA Nº1 POLÍTICA DE DESARROLLO, MANTENCIÓN Y ADQUISICIÓN DE SISTEMAS DE INFORMACIÓN Versión 1.0 MINISTERIO DE OBRAS PÚBLICAS ELABORADO POR: Dirección General de Obras Públicas FECHA: 9/09/2012 REVISADO

Más detalles

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: TIPOS DE SI: SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS, GROUPWARE, SISTEMA DE WORKFLOW Material diseñado y elaborado por: Prof. Anna Cecilia Grimán SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS Los Sistemas

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

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

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

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

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

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

Programa de Capacitación y Certificación.

Programa de Capacitación y Certificación. NIVEL 1.- INFRAESTRUCTURA DE REDES Programa de Capacitación y Certificación. INFORMES@COMPUSUR.COM.MX WWW.COMPUSUR.COM.MX 1 Contenido NIVEL 1. INFRAESTRUCTURA DE REDES... 4 6421 CONFIGURANDO Y RESOLVIENDO

Más detalles

Proyecto Piloto. Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE

Proyecto Piloto. Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE Proyecto Piloto Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE Contenido Punto de Partida Objetivos Solución Propuesta Como Trabajaremos Calendario de Alto Nivel Siguientes Pasos

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ó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

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

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

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

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

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE CAPACITACIÓN Versión 05 Diciembre 2008 INDICE Introducción... 3

Más detalles

PCI Day Today PCI DSS. WebSphere DataPower. 2008 IBM Corporation

PCI Day Today PCI DSS. WebSphere DataPower. 2008 IBM Corporation PCI DSS WebSphere DataPower AGENDA Necesidades DataPower y PCI Demo Línea de productos LO QUE BUSCAN LOS EJECUTIVOS Flexibilidad crecer mas rápido Eficacia gastar menos Capacidad de Reacción aumentar la

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 9: Desarrollo de aplicaciones Web híbridas 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

Más detalles

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK 1 LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK Miguel Angel Abellán Juliá Gerente de Soluciones para Administraciones Públicas. Hewlett-Packard Española,

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

Historia de revisiones

Historia de revisiones Herbert Game Descripción de la Arquitectura Versión 1.8 Historia de revisiones Fecha Versión Descripción Autor 29/08/2011 1.0 Creación del documento Juan Pablo Balarini Máximo Mussini 30/08/2011 1.1 Actualización

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

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA

UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD DE CIENCIAS ECONOMICAS ESCUELA DE CONTABILIDAD AUDITORIA INFORMATICA TRABAJO PRÁCTICO DE AUDITORIA INFORMATICA Profesor: Lic. Marco Antonio Leiva Fernández 5to

Más detalles

Análisis de la visibilidad global de los publicadores de los recursos geográficos estandarizados

Análisis de la visibilidad global de los publicadores de los recursos geográficos estandarizados Análisis de la visibilidad global de los publicadores de los recursos geográficos estandarizados AnetaJ. Florczyk, F.Javier López-Pellicer, Javier Nogueras-Iso, F.Javier Zarazaga-Soria Universidad de Zaragoza,

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA INTEGRAL DE ATENCIÓN A CLIENTE(A)S, USUARIO(A)S Y BENEFICIARIO(A)S

Más detalles

Guías y Procedimientos para la Creación y Publicación de Páginas Web del Recinto Universitario de Mayagüez

Guías y Procedimientos para la Creación y Publicación de Páginas Web del Recinto Universitario de Mayagüez Guías y Procedimientos para la Creación y Publicación de Páginas Web del Recinto Universitario de Mayagüez Revisión: Diciembre 2008 Propósito: Este documento describe los procedimientos para la creación

Más detalles

Custodia de Documentos Valorados

Custodia de Documentos Valorados Custodia de Documentos Valorados En el complejo ambiente en que se desarrollan los procesos de negocio actuales, se hace cada vez más necesario garantizar niveles adecuados de seguridad en la manipulación

Más detalles

RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC

RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC Proyecto Integrador de Tecnologías Computacionales Autor: Roberto García :: A00888485 Director: Jorge A. Torres Jiménez Contenido Introducción

Más detalles

SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA

SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA Oscar García Reyes Business Sales Consultant. Área de Seguridad Grupo SIA Carlos Guerra Belver Consultor Técnico. Área de Infraestructuras de Seguridad

Más detalles

PROGRAMACIÓN PÁGINAS WEB JAVASCRIPT Y PHP

PROGRAMACIÓN PÁGINAS WEB JAVASCRIPT Y PHP PROGRAMACIÓN PÁGINAS WEB JAVASCRIPT Y PHP OBJETIVOS Estudiar la programación de la parte cliente con JavaScript y la programación de la parte servidor con la tecnología PHP y el servidor de bases de datos

Más detalles

DESPLIEGUE DE SENTINET

DESPLIEGUE DE SENTINET DESPLIEGUE DE SENTINET INTRODUCCIÓN Sentinet es una solución que proporciona gestión y gobierno de infraestructuras SOA desplegadas tanto on-premise, en la nube o en entornos híbridos. Sentinet está desarrollada

Más detalles

PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto

PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto Introducción: Sobre casi cualquier tema del quehacer humano que se aborde, existen

Más detalles