!!!!!!! Recomendaciones!sobre!la!adopción!de!un!modelo!de! interoperabilidad!para!el!estado!de!chile!!!!
|
|
- Benito Giménez Sandoval
- hace 8 años
- Vistas:
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
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 /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": " 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
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 detalles1 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 detallesIngenierí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 detallesGLOSARIO. 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 detallesSistema de Mensajería Empresarial para generación Masiva de DTE
Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesMª 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 detallesIntroducció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 detallesComponentes 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 detallesTECNOLOGÍ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 detallesService 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 detallesPORTAL 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 detallesUniversidad 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 detallesService 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 detallesSERVICE 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 detallesUna 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 detallesCapítulo 5. Cliente-Servidor.
Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor
Más detallesGUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000
1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas
Más detallesResumen del trabajo sobre DNSSEC
Resumen del trabajo sobre Contenido 1. -...2 1.1. - Definición...2 1.2. - Seguridad basada en cifrado...2 1.3. - Cadenas de confianza...3 1.4. - Confianzas...4 1.5. - Islas de confianza...4 2. - Conclusiones...5
Más detalles<Generador de exámenes> Visión preliminar
1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,
Más detallesSISTEMAS DE INFORMACIÓN II TEORÍA
CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR
Más detallesIAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)
IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) Introducción 1. Como se indica en la Norma Internacional de Auditoría 401, "Auditoría en un contexto informatizado", los objetivos globales
Más detallesEMPRESAS PÚBLICAS DE MEDELLÍN E.S.P. DIRECCIÓN CONTROL INTERNO PROYECTO NORMALIZACIÓN ACTIVIDAD DE AUDITORÍA INTERNA
DCI-PN-EA-01 VERSIÓN 02 Página 2 de 12 TABLA DE CONTENIDO 1. INTRODUCCIÓN... 3 2. ROL... 3 3. PROFESIONALIDAD... 3 4. AUTORIDAD... 4 5. ORGANIZACIÓN... 4 6. INDEPENDENCIA Y OBJETIVIDAD... 5 7. ALCANCE...
Más detallesInfraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor
Infraestructura Tecnológica Sesión 5: Arquitectura cliente-servidor Contextualización Dentro de los sistemas de comunicación que funcionan por medio de Internet podemos contemplar la arquitectura cliente-servidor.
Más detallesMETODOLOGIAS DE AUDITORIA INFORMATICA
METODOLOGIAS DE AUDITORIA INFORMATICA Auditoria Informatica.- Certifica la integridad de los datos informaticos que usan los auditores financieros para que puedan utilizar los sistemas de información para
Más detallesVisión General de GXportal. Ú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 detallesConvergencia, 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 detallesVisió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 detallesArquitectura 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 detallesCapítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema
Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.
Más detallesARQUITECTURA TÉCNICA ASIGNATURA: MATERIALES DE CONSTRUCCIÓN II CURSO: 2009-2010 APUNTES TEMA 1: CONTROL DE CALIDAD
ARQUITECTURA TÉCNICA ASIGNATURA: MATERIALES DE CONSTRUCCIÓN II CURSO: 2009-2010 APUNTES TEMA 1: CONTROL DE CALIDAD. CONCEPTO. EVOLUCIÓN CON EL TIEMPO. NORMA UNE EN ISO 9001:2000 Profesor: Victoriano García
Más detallesDesarrollo 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 detallesJAVA 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 detalles2524 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 detallesQ-expeditive Publicación vía Internet
How to Q-expeditive Publicación vía Internet Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-expeditive 3 Índice Introducción... 3 Publicación de servicios... 3 Ciudadanos... 3 Terminales de auto
Más detallesEjemplo Manual de la Calidad
Ejemplo Manual de la Calidad www.casproyectos.com ELABORADO POR: REPRESENTANTE DE LA DIRECCION APROBADO POR: GERENTE GENERAL 1. INTRODUCCIÓN Nuestra organización, nació en el año XXXXXXXXX, dedicada a
Más detallesDIPLOMADO EN SEGURIDAD INFORMATICA
DIPLOMADO EN SEGURIDAD INFORMATICA Modulo 9: Soporte Computacional Clase 9_3:Protocolos de comunicación y conectividad de arquitecturas multiplataforma. Director Programa: César Torres A Profesor : Claudio
Más detallesSecretaría General OFICINA NACIONAL DE GESTIÓN Y PATRIMONIO DOCUMENTAL DIRECTRIZ TÉCNICA
Secretaría General OFICINA NACIONAL DE GESTIÓN Y PATRIMONIO DOCUMENTAL DIRECTRIZ TÉCNICA Tratamiento de documentos electrónicos aplicados a documentación de la Universidad Nacional de Colombia (Actualizada
Más detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesCustodia 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 detallesDocumentació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 detalles3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE
3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar
Más detallesCONCLUISIONES Y RECOMENDACIONES
CONCLUISIONES Y RECOMENDACIONES CONTENIDO 7.1 Verificación de Hipótesis 7.2 Conclusiones 7.3 Recomendaciones Mónica Cecilia Gallegos Varela - 145 - VERIFICACIÓN DE HIPÓTESIS La hipótesis planteada al inicio
Más detallesSistemas de Gestión de Documentos Electrónicos de Archivo (SGDEA)
Sistemas de Gestión de Documentos Electrónicos de Archivo (SGDEA) Agenda 1. Introducción 2. Concepto Documento Electrónico 3. A que se le denomina Documento Electrónico 4. Componentes de un Documento Electrónico
Más detallesCapítulo IV SEGURIDAD DE LA INFORMACIÓN ROLES Y ESTRUCTURA ORGANIZACIONAL
Capítulo IV SEGURIDAD DE LA INFORMACIÓN ROLES Y ESTRUCTURA ORGANIZACIONAL 4.1 Situación actual La administración de seguridad de información se encuentra distribuida principalmente entre las áreas de sistemas
Más detallesSISTEMAS 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 detallesSistema de SaaS (Software as a Service) para centros educativos
Sistema de SaaS (Software as a Service) para centros educativos Definiciones preliminares: Qué es SaaS? SaaS (1) es un modelo de distribución del software que permite a los usuarios el acceso al mismo
Más detallesEnginyeria del Software III
Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad
Más detallesPROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...
Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detallesGeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008
Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento
Más detallesARQUITECTURA DE DISTRIBUCIÓN DE DATOS
4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia
Más detallesWindows Server 2012: Infraestructura de Escritorio Virtual
Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información
Más detallesARC 101 Architecture Overview Diagram
ARC 101 Architecture Overview Diagram Estudio de Arquitectura para la evolución tecnológica de los aplicativos de ATyR Banco de Previsión Social ATYR Evolución Tecnológica Pág 1 of 10 Tabla de Contenidos
Más detallesWorkflows? Sí, cuántos quiere?
Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención
Más detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detallesLos mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:
SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas
Más detalles9.1 Conceptos básicos
1 Colección de Tesis Digitales Universidad de las Américas Puebla Zuñiga, Víctor Alejandro 9.1 Conceptos básicos En este capítulo, se analizarán cinco arquitecturas diferentes y se discutirá cómo están
Más detallesTópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN
Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.
Más detalles0. Introducción. 0.1. Antecedentes
ISO 14001:2015 0. Introducción 0.1. Antecedentes Conseguir el equilibrio entre el medio ambiente, la sociedad y la economía está considerado como algo esencial para satisfacer las necesidades del presente
Más detallesIntroducción. Componentes de un SI. Sistema de Información:
Introducción. Sistema de Información: Conjunto de elementos relacionados entre sí de acuerdo a ciertas reglas, que aporta a la organización la información necesaria para el cumplimiento de sus fines, para
Más detallesProgramació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-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo
Página 11 5. Estructura del programa de evaluación con personal externo 5.1 Introducción Esta sección presenta la estructura del programa de evaluación con personal externo. Describe las funciones y responsabilidades
Más detalleselastic PROJECTS INFORMACIÓN COMERCIAL PROJECTS
PROJECTS elastic PROJECTS INFORMACIÓN COMERCIAL Inscripción Registro Mercantil de Pontevedra, Tomo 3116, Libro 3116, Folio 30, Hoja PO-38276 C.I.F.: B-36.499.960 contact@imatia.com 1 INTRODUCCIÓN Mediante
Más detallesCloud Security Alliance. Recomendaciones de Seguridad para Usuarios
Cloud Security Alliance Recomendaciones de Seguridad Contenido Qué es el Cloud Computing?... 2 Modelos de Servicios... 2 Modelos de Implementación... 3 Recomendaciones a los Usuarios para la adopción del
Más detalles2. DEFINICIÓN DEL SISTEMA INTEGRADO DE GESTIÓN - SIG
2. DEFINICIÓN DEL SISTEMA INTEGRADO DE GESTIÓN - SIG Para poder entender cuál es el propósito del SISTEMA INTEGRADO DE GESTIÓN - SIG, lo primero que debemos tener claro son los conceptos de SISTEMA, GESTIÓN
Más detallesTí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 detallesARQUITECTURA ORIENTADA A SERVICIOS (SOA) EN LA JUNTA DE ANDALUCÍA
ARQUITECTURA ORIENTADA A SERVICIOS (SOA) EN LA JUNTA DE ANDALUCÍA Dirección General de Administración Electrónica y Calidad de los Servicios Consejería de Justicia y Administración Pública Junta de Andalucía
Más detallesGerencia 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 detallesServidores Donantonio
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detallesUtilidades de la base de datos
Utilidades de la base de datos Desde esta opcion del menú de Access, podemos realizar las siguientes operaciones: Convertir Base de datos Compactar y reparar base de datos Administrador de tablas vinculadas
Más detallesNORMA ISO 9001. Estos cinco apartados no siempre están definidos ni son claros en una empresa.
NORMA ISO 9001 0. Concepto de Sistema de Gestión de la Calidad. Se define como el conjunto de normas interrelacionadas de una empresa u organización por los cuales se administra de forma ordenada la calidad
Más detallesSISTEMA DE PAPELES DE TRABAJO PARA AUDITORÍA SPT AUDIT
SISTEMA DE PAPELES DE TRABAJO PARA AUDITORÍA SPT AUDIT INTRODUCCIÓN La documentación de auditoría ó papeles de trabajo son el respaldo que tiene el auditor para registrar los procedimientos aplicados,
Más detallesO jeto de apre r ndizaje
Herramientas de Gestión para Objetos de Aprendizaje. Plataforma AGORA Victor Hugo Menéndez Domínguez Universidad Autónoma de Yucatán, México :: mdoming@uady.mx Manuel Emilio Prieto Méndez Universidad de
Más detallesPatrones 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 detallesGestión de la Configuración
Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de
Más detallesManual Operativo SICEWeb
Manual Operativo SICEWeb Gestión de Expediente Digital Expediente Único de Clientes y Otros 1 Índice Contenido Expediente Único de Clientes y Otros... 1 Índice... 2 MODELO DE GESTIÓN DOCUMENTAL (MGD)...
Más detallesPOSGRADO EXPERTO.NET DESARROLLO DE SOFTWARE
POSGRADO EXPERTO.NET DESARROLLO DE SOFTWARE DESCRIPCIÓN Microsoft es una de las principales empresas dedicada al mundo de las tecnologías, haciendo grandes esfuerzos para ponerse a la cabeza de la actualidad
Más detallesMACROPROCESO GESTIÓN TECNOLÓGICA
Versión 1.0 Página 1 de 5 1. OBJETIVO Suministrar las fases para la puesta en producción de aplicaciones y sistemas de información desarrollados o adquiridos por el Instituto Colombiano de Bienestar Familiar
Más detallesFAST-SE: Un Componente JBI para transacciones guiadas por SLAs 1
FAST-SE: Un Componente JBI para transacciones guiadas por SLAs 1 José Antonio Parejo Maestre, Antonio Manuel Gutiérrez Fernández, Pablo Fernández Montes y Antonio Ruiz Cortés. Universidad de Sevilla {japarejo,
Más detallesGuí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 detallesResumen de la solución SAP SAP Technology SAP Afaria. Gestión de la movilidad empresarial para mayor ventaja competitiva
de la solución SAP SAP Technology SAP Afaria Gestión de la movilidad empresarial para mayor ventaja competitiva Simplificar la gestión de dispositivos y aplicaciones Simplificar la gestión de dispositivos
Más detallesCOMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD
COMISION DE REGLAMENTOS TECNICOS - CRT COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD SUB COMITÉ SECTOR EDUCACION NORMAS APROBADAS NTP 833.920-2003 Guía de aplicación de la Norma
Más detallesTítulo de la pista: Windows Server 2012 Detalles técnicos de redes
Título de la pista: Windows Server 2012 Detalles técnicos de redes Módulo 2: Administración de la dirección IP Manual del módulo Autor: James Hamilton-Adams, Content Master Publicado: [introducir fecha]
Más detallesCONCLUSIONES 155 A través de cada uno de los capítulos del presente documento se han enumerado una serie herramientas de seguridad que forman parte del sistema de defensa de una red y que, controlan su
Más detallesGestión de proceso y documentos
Gestión de proceso y documentos 20154 Cómo agilizar y aumentar el control en sus procesos y sacar provecho de su acervo documental Alguna vez en su empresa se han preguntado......dónde está la versión
Más detallesMaster en Gestion de la Calidad
Master en Gestion de la Calidad Registros de un Sistema de Gestion de la Calidad Manual, procedimientos y registros 1 / 9 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer que es un registro
Más detallesSOLUCIÓ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 detalles1. Resumen.. 3. 2. Objetivos.. 3. 3. Introducción. 3
1 Índice 1. Resumen.. 3 2. Objetivos.. 3 3. Introducción. 3 4. Aplicación web para la gestión de una memoria corporativa: reportes de actividades (proyectos) 4.1 Metodología... 4 4.2 Lenguajes y herramientas
Más detallesEntidad Formadora: Plan Local De Formación Convocatoria 2010
Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú
Más detallesAlfresco permite su integración y personalización en sistemas de gestión documental para implementar funcionalidades específicas
INTRODUCCIÓN La flexibilidad y facilidad de integración de Alfresco en arquitecturas distribuidas de tipo SOA permiten a Mecatena el desarrollo de proyectos de gestión de contenidos, de cara a los nuevos
Más detallesGUÍA METODOLÓGICA PARA LA REALIZACIÓN DE PROCEDIMIENTOS DOCUMENTADOS DE SISTEMAS DE GESTIÓN
GUÍA METODOLÓGICA PARA LA REALIZACIÓN DE PROCEDIMIENTOS DOCUMENTADOS DE SISTEMAS DE GESTIÓN 1. Objetivo 2. Introducción 3. Procedimiento de control de documentos 4. Procedimiento de control de registros
Más detallesTema 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 detallesCAPÍTULO 3 Servidor de Modelo de Usuario
CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes
Más detallesLISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M
No. REQUISITOS EXISTE ESTADO OBSERVACIONES 4. SISTEMA DE GESTION DE LA CALIDAD 4.1 Requisitos Generales La organización debe establecer, documentar, implementar y mantener un S.G.C y mejorar continuamente
Más detallesRBAC4WFSYS: 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 detallesClientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detalles