instituto politÉcnico nacional - virtual.sepi.upiicsa.ipn.mx · capitulo 2 antecedentes,...

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE

INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

INTEGRACIÓN DE APLICACIONES

CORPORATIVAS MEDIANTE WEB

SERVICES

T E S I S

QUE PARA OBTENER EL GRADO DE:

MAESTRO EN CIENCIAS EN INFORMÁTICA

P R E S E N T A:

JOB HERNÁNDEZ JOFFRE

DIRECTOR DE TESIS: M. C. CARLOS GONZÁLEZ ESCAMILLA

MÉXICO, D.F. 2008

Agradecimientos

_________________________________________________________________________

AGRADECIMIENTOS:

A Dios: Por que aún para aquellos que niegan tu existencia siempre tienes un milagro, porque siempre he creído en la existencia de un ser que está más allá de mi entender y de la razón, porque mantienes mi fe viva en cualquier momento grato o triste de mi vida, sin olvidar nunca lo insignificante que soy ante tu grandeza.

A mis padres: Rosa (Angelina), la única gran Mujer que me ha amado aún sin conocerme y antes de

nacer, que ha cuidado de mi siempre y me ha enseñado desde mis primeros pasos a seguir por el camino del bien y por quien daría mi vida sin cuestionar nunca el por que. Gerardo, el hombre que me enseño que Dios está más allá de cualquier religión y quien me ha guiado siempre con rectitud, ética y una moral digna de un gran Hombre. A ustedes dos dedico todos y cada uno de mis logros y triunfos, inspirado siempre en su

ejemplo de superación constante, sin olvidar la humildad y sencillez que los caracteriza y que los hace aún más grandes y valiosos para mí.

A mis hermanos y mi cuñada: Elías, Ivonne y Ana con todo mi cariño y admiración por su apoyo y comprensión, porque

siempre están en mis oraciones y en mis pensamientos para que la vida les sonría en todo momento, pero sobre todo por seguir siempre unidos como hermanos y como familia.

A mis sobrinos: Erick, Hiromy y Kevin (mis otros hermanitos) por compartir conmigo estos momentos que

espero los inspiren a seguir adelante en la vida, a luchar y lograr grandes sueños sin bajar nunca los brazos por difícil que perezca el largo y sinuoso camino.

A mis amigos(as): Alberto (Betoman), mi camarada en esta travesía y por culpa de quien me enrole en ésta aventura llamada “la maestría”, misión cumplida al fin K. Yeni, porque en ti he encontrado una parte importante que llena muchos vacíos en mi vida y por que has logrado dar un giro radical a mi vida, cambiando por mucho todo lo que en un pasado no pensé sentir, con todo mi amor y mi cariño, gracias. Gisela por tu amistad y tu apoyo en momentos difíciles, por los buenos tiempos y experiencias compartidas, por las horas de conversación siempre amena y sincera, “Que tengas suertecita” y recuerda que: “todo es insignificante, nada es tan preocupante…”. Felipe Figueroa, Miguel Hernández (Mike), Jorge García, Karla González, porque de alguna manera también fueron participes de ésta experiencia conmigo, animándome siempre a llegar al final de ésta etapa, a Ustedes mi más sincero agradecimiento por todo.

A mi comisión revisora: Porque gracias a Ustedes, a sus enseñanzas, consejos, recomendaciones y demás, logran sembrar grandes cambios en la vida de nosotros sus alumnos, a Ustedes y con especial cariño a la profesora Emilia les doy las gracias por estos años de grandes enseñanzas.

A Ustedes y a todos los que de manera directa o indirecta contribuyeron en el logro de este objetivo, que para mí significa una pequeña aportación de todos ustedes a enriquecer una vida llena de bendiciones y satisfacciones, muchas gracias.

Âl tÄ y|ÇtÄ? xÄ tÅÉÜ Öâx Üxv|uxá? xá |zâtÄ tÄ tÅÉÜ Öâx wtáÊ Paul McCartney (1969)

Integración de aplicaciones corporativas mediante Web Services Índice General

UPIICSA - IPN

INTEGRACIÓN DE APLICACIONES CORPORATIVAS MEDIANTE WEB SERVICES.

Índice General

PÁGINA RESUMEN i

SUMMARY iii

INTRODUCCIÓN v

CAPITULO 1 Contexto General 1 CAPITULO 2 Antecedentes, Organizaciones y sus experiencias 13 2.1 Gobierno electrónico. 14 2.1.1 Clasificaciones de los servicios de gobierno en México según el nivel de madurez. 14 2.2 Experiencias e iniciativas nacionales. 19 2.2.1 Iniciativa del portal eGobiernoMéxico (eMéxico). 19 2.2.2 Principios del Gobierno Electrónico. 21 2.2.3 Estado actual del e-Gobierno en México. 24 2.2.4 Normativas existentes para el gobierno electrónico. 33 2.2.5 Avances y logros significativos. 34 2.2.6 Retos y desafíos del e-Gobierno en México. 36 2.2.7 Iniciativas principales para e-Gobierno en México. 43 2.3 Experiencias internacionales. 44 2.3.1 Reach. 44 2.3.2 GovTalk. 46 2.3.3 AGLS. 48 2.3.4 Organizaciones Internacionales. 49 2.4 Otras experiencias de integración en México. 50 2.4.1 Experiencias ERP Telcel – Oracle. 51 2.4.2 Experiencias ERP SAT – PeopleSoft. 53 CAPITULO 3 Conceptos, tecnologías de Información y Servicios Web. 55 3.1 Conceptos Básicos. 56 3.2 Definición de pautas. 63 3.2.1 Definiciones y bases teóricas. 63 3.2.2 Pautas de servicios web para el e-Gobierno. 65 3.2.3 Bases usadas para definir pautas. 65 3.3 Servicios Web. 67 3.3.1 Flujo documental. 67 3.3.2 Servicios. 68 3.4 Arquitectura Orientada a Servicios (SOA). 69 3.5 Requerimientos de los Servicios en el e-Gobierno. 70 3.5.1 Particularidades de los servicios en el e-Gobierno. 75 3.6 Tecnologías en Servicios Web. 77 3.6.1 Extensible Markup Language (XML). 77 3.6.2 Simple Object Access Protocol (SOAP). 79 3.6.3 Web Services Description Language (WSDL). 80 3.6.4 Universal Description, Discovery and Integration (UDDI). 81 3.7 Modelos Arquitectónicos. 83 3.8 Arquitectura de Servicios Web como descripción de servicios. 85 3.9 Guías para el uso de Web Services en servicios. 86

Integración de aplicaciones corporativas mediante Web Services Índice General

UPIICSA - IPN

PÁGINA CAPITULO 4 Casos de estudio y de éxito usando Servicios Web. 92 4.1 Caso 1. Servicio de Administración Tributaria (Inscripción al RFC). 95 4.1.1 Descripción del servicio. 95 4.1.2 Alternativa de solución. 101 4.1.3 Especificación de requerimientos de la solución. 102 4.1.4 Especificación de metadatos basados en requerimientos. 106 4.1.5 Reflexiones sobre el caso 1. 108 4.2 Caso 2: Sistema de Pago Centralizado de Nómina Federal. 111 4.2.1 Descripción del servicio. 112 4.2.2 Solución Desarrollada. 116 4.2.3 Especificación de requerimientos de la solución. 117 4.2.4 Especificación de metadatos basados en requerimientos. 121 4.2.5 Reflexiones sobre el caso 2. 124 4.3 Caso 3: Sistema de expedición de Pasaportes y/o Licencias. 127 4.3.1 Descripción del servicio. 128 4.3.2 Alternativa de solución. 134 4.3.3 Especificación de requerimientos de la solución. 136 4.3.4 Especificación de metadatos basados en requerimientos. 141 4.3.5 Reflexiones sobre el caso 3. 143 CAPITULO 5 Recomendaciones para desarrollo de Servicios Web. 148 5.1 Pasos recomendados 149 Conclusiones. 159 Relación de figuras. Relación de tablas. Glosario. Bibliografía. ANEXO A ANEXO B ANEXO C

Integración de aplicaciones corporativas mediante Web Services Resumen

UPIICSA – IPN i

Resumen

En los últimos años hemos visto el surgimiento y desarrollo del comercio electrónico a través de

Internet, el auge del modelo de negocios electrónicos llamado Business to Business (B2B siglas en

inglés) y la transformación de los servicios electrónicos tanto en la iniciativa privada como en el

Gobierno Federal de México y otros países de la región.

Estos modelos y paradigmas han alcanzado una etapa de interacción estándar de gran madurez

entre clientes y proveedores, esto es, comunicaciones simples entre usuarios y servicios que

tienden a incrementar exponencialmente el número de operaciones diarias con el paso del tiempo.

Con ello podemos mencionar a proveedores del sector privado como los bancos y las empresas

que ofrecen servicios particulares como telefonía, televisión, Internet, bienes y productos de

primera necesidad, por otra parte los servicios que ofrece el Gobierno Federal los cuales podemos

denominarlos a final de cuentas, como una interacción simple entre clientes y proveedores

(Ciudadanos y el Gobierno Federal o clientes y empresas privadas).

En los próximos años se vislumbran varios desafíos, ante los que destaca la automatización e

interoperabilidad de servicios que por las características gubernamentales o privadas, se

desarrollan en ambientes heterogéneos y distribuidos de acuerdo a las necesidades y

posibilidades tecnológicas, económicas y políticas de cada una de las organizaciones.

Los servicios electrónicos en México se han visto impulsados por la definición de leyes y decretos,

que entre otras cosas obligan a algunas empresas privadas y dependencias del Gobierno a poder

visualizar, recibir y generar documentación electrónica en un formato estándar.

Así mismo, les exige poder comunicarse, interactuar, intercambiar información y ser capaces de

entregar servicios a los ciudadanos o clientes para facilitarles el acceso a recursos, productos y

servicios propiamente dichos, muchos de los cuales son de acuerdo a su naturaleza altamente

complejos.

El cumplimiento de las metas fijadas, las exigencias vigentes y los plazos estipulados de los

servicios electrónicos en México han sido cumplidos parcialmente hasta la fecha, basta con echar

un vistazo al sector público, donde encontramos una gran cantidad de servicios que son

candidatos ideales a ser automatizados.

Integración de aplicaciones corporativas mediante Web Services Resumen

UPIICSA – IPN ii

Todo esto implica que un número importante de organizaciones privadas y de gobierno deberán

desarrollar servicios que permitan ver procesos más transparentes, más fáciles de usar y que

ayuden a los usuarios a vivir mejor, además de beneficiar a las organizaciones incrementando su

productividad y ayudando a los miembros de las organizaciones a servir mejor.

Ante este panorama, existen tecnologías que resultan notoriamente ventajosas, dado que ofrecen

una gran capacidad para interoperar dado que son extensibles, están diseñadas para ambientes

heterogéneos y entregan funcionalidades reutilizables por distintas fuentes, independientemente

del contexto bajo el cuál se invoca a los servicios.

Dado que las experiencias con ciertas tecnologías como los servicios web en el desarrollo de

servicios electrónicos son aún escasas, y más en estos tiempos en que las tecnologías y

comunicaciones a través de Internet son el futuro a explotar, las iniciativas pioneras son y serán

muy relevantes.

Esto nos indica que debido al alto número de servicios que hoy en día se desarrollan resulta clave

contar con una propuesta, pautas y/o buenas prácticas que guíen tal actividad sobre todo para el

sector público que de manera única sigue un mandato o estrategia integral.

Por otro lado la iniciativa privada puede o no estar obligada a seguir regulaciones o estándares

internacionales de calidad, pero si está obligada a incrementar el número de servicios ofrecidos a

través de Internet, no debemos olvidar que las empresas privadas buscan con toda razón

maximizar sus ganancias y su presencia en el mercado.

Considerando lo anterior, y basándose en experiencias de análisis, diseño y desarrollo sobre

casos de éxito particulares, este trabajo propone ideas, sugerencias y pautas técnicas para

diseñar, desarrollar y planificar servicios web en el marco del desarrollo de servicios electrónicos

en el Gobierno Federal.

Para el sector privado (si así lo consideran útil las organizaciones privadas) se identifican los

requerimientos principales de los servicios que entrega un proveedor, presentando guías sobre

interoperabilidad usando servicios web y discutiendo el rol de la definición de metadatos y

descripciones en los servicios.

Como resultado de este trabajo se concluye que los servicios web satisfacen los requerimientos de

los servicios en general para brindar servicios electrónicos, que resultan altamente superiores a las

otras tecnologías existentes y que debido a su madurez, soporte y flexibilidad, son una excelente

herramienta para desarrollar servicios tanto en la iniciativa privada como en el Gobierno Federal.

Integración de aplicaciones corporativas mediante Web Services Summary

UPIICSA – IPN iii

Summary

In the last years we have seen the born and development of e-commerce, the Business to Business

(B2B) model and a general transformation of electronic services in private industry around the

world, one case is the Mexican Government beside other countries of the region.

These models have accomplished the state of Interaction according with the maturity standard of

the Electronic Services[chapter 2], it says, simple communications between clients and providers.

In this way, we can do mention of some providers from the private industry like Banks and

companies that offer services as telephony, television, communications and services of elementary

needs.

In a similar way, there are services that the government offers and which we can denominate at the

end, as an interaction between clients and providers (citizens and government or clients and private

companies).

For the next years, we can see a lot of challenges, the principal goal is to get interoperability of

applications that are available in different environments of govern and private organizations, the

available services are developed at heterogeneous and distributed environments according with the

needs of technology and economic or politic possibilities of them.

The electronic services in México have been impulsed by the definition of laws and decrees that

obligate private companies and govern dependencies to visualize, receive and generate electronic

documentation in a standard format.

In the same way, they are required to communicate, interact, interchange information, and to be

capable of deliver services to the citizens or clients, the purpose is to make easier the access of

resources, products and the own services, a lot of which are highly complex agree with their nature.

The accomplished of the established goals, the current demands, and the estipulate times of the

electronic services in México, have been accomplished partially up to now. This implies that an

important number of private companies and govern dependencies, will should develop services to

allow transparent processes, easy access to resources and services, help people to have a better

live, etc.

The benefits will be for organizations, rising productivity, generating competitive advantages, and

helping to employees to serve in a better way, without forgetting to search solutions to operate in

and between their institutions in the short and medium term.

Integración de aplicaciones corporativas mediante Web Services Summary

UPIICSA – IPN iv

At this panorama, there are technologies that emerge with a lot of advantages, because they deliver

a high capability to interoperate, they’re extensible, they’re designed to heterogeneous

environments, and deliver reusable functions by distinct sources, independently of the context

under the services are invocated.

Due to the experiences with the web services technology in development of electronic services are

poor up to now, the pioneer initiatives are very relevant, and because of a high number of services

that are developed now, it results important to have a framework, rules and good practices to guide

this activity, overall for the public sector that follows an order or a unified strategy.

Considering the upper text, and taking advantage of experiences with analysis, design and

development over particular succeed cases, this work propose technical guides to design, develop

and planning web services into the frame of development for electronic services.

For Government requirements, is necessary to identify the main patterns of the services that deliver

a provider, presenting guides over interoperability using web services, and discussing the roll of the

definition of metadata and description of the services.

This document includes experiences where the web services satisfy a lot of requirements that

electronic services have, the reason is because they are over other available technologies and

because of their maturity, support and flexibility, they are an excellent tool to develop services at

private industry as in the Government.

At the end of this work, it presents a development proposal of services for the case of government

using web services that represents the experience and acquired knowledge during the work

developed.

As a result of this work, it presents a series of clauses that indicates benefits of web services, the

requirements satisfied by the technology in order to offer electronic services, the advantages of

them against other technologies thank to their maturity, support and flexibility and that web services

are an excellent tool for development of services in a private or government context.

Integración de aplicaciones corporativas mediante Web Services Introducción

UPIICSA – IPN v

Introducción

Durante los últimos diez años, la Internet ha permitido comunicar e integrar diversas fuentes de

información, ha provisto un conjunto de servicios que han intentado evolucionar a la par de las

necesidades de la sociedad y el mercado sin conseguirlo del todo, ha provocado un crecimiento y

desarrollo organizacional desmedido y desigual tanto en la iniciativa privada como en los gobiernos

del mundo entero.

Estas necesidades de información y comunicación se hacen presentes en un órgano tan

importante para México como lo es el Gobierno y en general para todas las organizaciones que

ofrecen servicios por la web, las cuales mediante iniciativas como la modernización del Estado y el

impulso del llamado gobierno electrónico o eGobierno (eGovernment) buscan:

� Entregar una mejor calidad de servicios, disminuir los costos actuales, incrementar la

productividad y agilizar los procesos y trámites vigentes.

� Hacer la vida más fácil para todos y mejorar la calidad de vida de aquellas personas para

las cuales se desarrollan soluciones ha sido una prioridad en el desarrollo de tales

proyectos.

� Se hace mucho énfasis en la política del gobierno de servir mejor a la gente a través de

instituciones más transparentes, lo cual aplica también para aquellas organizaciones

privadas que desean generar ventajas competitivas y generar más ganancias para sus

accionistas, beneficiando por consiguiente a sus clientes.

Para realizar tales tareas, el Gobierno ha utilizado diversas tecnologías y enfoques que han

resultado en varios casos exitosos, sin embargo, en este trabajo se argumenta como el uso de la

web y las tecnologías asociadas pueden ayudar a entregar un potencial mucho mayor y ofrecer

facilidades de desarrollo al abordar esta tarea.

Existen soluciones que no representan un gasto excesivo de recursos como puede ser la compra

de un producto tecnológico de marca reconocida, o bien la implementación de un sistema de

gestión lo bastante complejo como para no usarlo.

En otros casos encontramos soluciones que pueden representar una ventaja competitiva con

respecto a organizaciones que ofrecen servicios de la misma índole con un ahorro de recursos

significativo, sirviendo de mejor manera a los usuarios finales de la organización.


UPIICSA – IPN vi

Un ejemplo de los servicios que entrega el gobierno hoy en día es la posibilidad de realizar la

declaración anual de impuestos, a través del portal del Servicio de Administración Tributaria (SAT).

Este portal también permite realizar avisos al Registro Federal de Contribuyentes (RFC) sobre la

situación y régimen fiscal de cada uno de los ciudadanos registrados en dicho padrón, así como

participar en subastas de artículos incautados, consultar información sobre licitaciones del

Gobierno Federal, realizar pagos electrónicos y otros más.

En la figura 1, se muestran algunos los servicios que ofrece el SAT actualmente.

Figura 1: Trámites realizados en el portal del SAT.

Este trabajo busca contribuir a la definición de pautas técnicas, ideas y sugerencias que aporten

un poco de ayuda en el desarrollo de servicios automatizados e ínteroperables, soluciones que

traigan beneficios como la transparencia al requerir en menos cantidad la intervención de personas

en un flujo de trabajo.

Se busca además contribuir en el uso de menos papel, ya que al automatizar servicios vía

Internet se facilita la realización de algunos trámites burocráticos que actualmente representan un

desgaste económico, físico y emocional para los ciudadanos.

Un ejemplo de la automatización más eficiente de este tipo de servicios podría ser que una vez

capturada la información del contribuyente y que la información del mismo ha sido almacenada en

una base de datos central del SAT, esta información pueda estar disponible (bajo ciertas reglas de

seguridad) para cualquier dependencia o empresa en la que el contribuyente realice un trámite.


UPIICSA – IPN vii

En pocas palabras, que la información pudiera ser consultada por organismos públicos y privados,

de acuerdo a ciertas reglas y normas de seguridad, haciendo la vida más fácil a todos los usuarios

y clientes de las organizaciones.

Un beneficio tangible sería que se pudieran realizar los trámites a través de la Web, y que las

organizaciones intercambiaran la información necesaria electrónicamente sin solicitudes

burocráticas a través de documentos (en papel), atentas notas, requerimientos, etcétera.

Todo esto con un solo identificador que sería en el caso de nuestro país; el RFC o bien la Clave

Única de Registro de Población (CURP).

Para ello, algunos sistemas de información de las instituciones podrían comunicarse

adecuadamente siguiendo un protocolo definido, dependiendo de la información y los niveles de

seguridad que se dispongan para los datos a intercambiar (es decir, deberían poder interoperar). 1

La figura 2 muestra una idea de lo que se pretendería con la interoperación de la cual se habla.

Figura 2: Uso de un solo portal para todos los trámites públicos y privados.

1 Cabe resaltar que no necesariamente todas las interacciones entre dependencias del Gobierno son automatizables ya sea

por aspectos técnicos, legales, u otros.

Portal de acceso único a sitios del gobierno

Interacción con la iniciativa privada,

agilizando tramites y servicios a los usuarios

(ciudadanos)


UPIICSA – IPN viii

Con base en esto, la definición de pautas técnicas se centrará en la especificación de los

requerimientos descripciones y metadatos necesarios para poder interoperar y automatizar la

comunicación de servicios al interior y entre las dependencias del Gobierno Federal que así lo

permitan de acuerdo a sus lineamientos y reglamentos.

Estas pautas bien pueden ser aplicadas, según sea el caso, a otras organizaciones de gobiernos

locales o bien privadas, usando la o las tecnologías que se describen más adelante en éste trabajo.

Para ello se usará un enfoque basado en el Modelo de Arquitectura Orientada a Servicios [ws-arch,

Web services architecture description, W3C, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/], implementada

mediante la tecnología de servicios web, de la cual se estudiarán también sus características,

madurez, ventajas y limitantes.

Las Pautas de este trabajo son de carácter general y no representan una definición exhaustiva que

calce para todos los posibles problemas, pero se intenta que los casos de éxito presentados aquí

sirvan como guía o base para el desarrollo de propuestas más formales.

Definiciones de tecnologías e implementaciones específicas para algún problema particular quedan

fuera del alcance de este documento, sin embargo, se utilizan ejemplos y casos de éxito reales

para ilustrar los conceptos explicados y la intención del presente trabajo.

El trabajo está ordenado de la siguiente manera:

En el capítulo 1 se describe el problema a analizar junto con sus causas. Se conocerán sus

antecedentes, justificación y se hará una definición precisa del problema además de presentar la

justificación y objetivos del trabajo.

En el capítulo 2 se describen algunos casos de integración de aplicaciones corporativas, en los

cuales se han podido observar intentos por conseguir una integración de los sistemas vitales de las

organizaciones aquí tratadas y en cuyos casos las experiencias no han sido del todo exitosas.

Por tal razón se ha motivado la definición del presente trabajo para identificar el problema y definir

una propuesta de solución a tal necesidad de integración aplicativa.

El capítulo 3 hace una descripción de los conceptos y las tecnologías de la información que se

utilizan para desarrollar la solución al problema de integración aplicativa. Se describe además las

características de las tecnologías que ofrecen mayores ventajas y se plantea la base para el

desarrollo de una propuesta de solución.


UPIICSA – IPN ix

El capítulo 4 hace referencia a los casos de éxito que se utilizaron como referencia para el

desarrollo del presente trabajo y para la definición de la propuesta de solución presentada en el

capítulo 5.

Este capítulo presenta la pauta para la definición de los pasos a seguir durante el desarrollo de una

solución que implemente servicios web, identificando aspectos comunes en cada uno de los casos

que se estudiaron.

El capítulo 5 presenta a manera de pasos, lo que este trabajo arroja como producto final: una

propuesta para el desarrollo de aplicaciones que lleven a la integración de aplicaciones

corporativas, tomando como base la experiencia de los casos de éxito presentados aquí y

desarrollados por el autor de este documento en organizaciones tanto privadas como de gobierno,

desarrollando sistemas computacionales e implementando soluciones de integración aplicativa.

La última sección de este trabajo, resume a manera de conclusiones, las experiencias, resultados,

beneficios, desventajas, fortalezas, debilidades y demás valores encontrados a lo largo del

desarrollo de este documento.

Finalmente se comenta una recomendación final, para aquellas organizaciones que buscan

generar y alcanzar ventajas competitivas, ganancias, beneficios, y demás objetivos (dependiendo

de su naturaleza y ramo 2).

Es importante resaltar que la mayor parte de la bibliografía a la que se hace referencia en este

documento se encuentra encerrada entre corchetes [ ], la razón se debe a que por cuestiones de

presentación y espacio, se utiliza una abreviatura que se detalla al final del documento en la

sección correspondiente, cualquiera de las referencias puede ser consultada ya sea en línea o en

el respectivo libro, texto, archivo PDF, tesis, o lo que corresponda.

2 Entendiendo por naturaleza y ramo si se trata de una organización de gobierno, privada, con fines de lucro, paraestatal,

etcétera.

Integración de aplicaciones corporativas mediante Web Services

UPIICSA - IPN Página - 1 -

Capítulo

1

Contexto General

En el presente capítulo se describirá el problema a analizar junto con sus causas.

Se conocerán sus antecedentes, justificación y se hará una definición precisa del

problema



Capítulo 1 – Contexto General Integración de aplicaciones corporativas mediante Web Services. Por este término se deberá

entender y comprender el contexto bajo el cual las aplicaciones informáticas de cualquier

organización realizarán un intercambio de información de manera automática, segura y confiable

dentro de un flujo de trabajo bien definido.

El propósito será facilitar y agilizar los procesos vitales dentro de las empresas u organizaciones y

entregar respuestas más fiables en el corto tiempo considerando la importancia de los grandes

beneficios tanto para usuarios como para proveedores de servicios.

A lo largo de la historia del desarrollo de Software, se ha buscado un producto que solucione la

administración de recursos en el interior de las empresas y organizaciones del mundo entero. De

este modo han aparecido productos que facilitan el proceso administrativo 3, la toma de

decisiones4, la administración de recursos humanos

5 y otras actividades más que involucran los

procesos de una organización.

Como consecuencia de estos esfuerzos, hemos visto la aparición de términos y productos como

los ERP´s (Enterprise Resource Planning), GRP´s (Government Resource Planning), CRM

(Customer Resource Mannagement), WorkFlow´s 6 y muchos otros productos que pretenden

resolver el problema de la integración de todos los sistemas de información en una gran aplicación

corporativa.

Después de la aparición de los sistemas de información, se ha tratado de resolver el problema de

unificar los sistemas en una sola aplicación corporativa. Uno de los tantos problemas ha sido la

ausencia o poca promoción de guías, estándares y lineamientos para el desarrollo de las

soluciones, además de que no se tiene la cultura de fijar objetivos para desarrollar aplicaciones

integrales desde un inicio.

La constante aparición de lenguajes de programación, plataformas, contextos, paradigmas y

necesidades de negocio propias de cada empresa, han propiciado la aparición de muchos intentos

por resolver el problema de la integración, en este contexto los servicios web han aparecido como

uno de esos intentos que buscan resolver esos errores

3, 4, 5 Conceptos de planeación estratégica que se resuelven con los productos de Planeación y administración de Recursos

de una Empresa.



Los procesos que se realizan al interior de una organización requieren de un tratamiento

sistemático que se resume en definir un flujo de entradas y salidas, el modelado de estos procesos

y actividades es conocido como un flujo de trabajo (workflow 6).

Las tecnologías web (y en específico los servicios web) nacieron como una consecuencia y como

una propuesta para solventar las necesidades de interoperabilidad en aplicaciones distribuidas,

construidas sobre diversas plataformas y diversos lenguajes.

La madurez de las tecnologías y el uso de estándares abiertos como los son los servicios web

permite actualmente comunicar sistemas que parecían incompatibles entre si por las plataformas y

lenguajes que las soportaban, a la par de este crecimiento de las tecnologías se enriquecen los

servicios e información disponibles mediante la interacción de múltiples agentes en la Web.

El propósito principal de estas tecnologías de integración es hacer más fácil la operación interna de

las organizaciones que mejoran su operación considerablemente al no requerir rehacer su extensa

gama de aplicaciones, reduciendo en gran medida costos y tiempos de operación e incrementando

productividad y mayor extensión de servicios.

A pesar de que el tema de la interoperabilidad ha madurado bastante, aún no existen guías claras

ni documentación formal para saber cuando conviene aprovechar las bondades de los servicios

web (u otras tecnologías), sin embargo si es posible identificar casos de éxito con características

comunes para las distintas realidades y problemáticas que se presentan en un proceso de

integración de aplicaciones.

Por otra parte, de la misma forma en que hoy día el gobierno impulsa una política de

estandarización de sitios web gubernamentales [eGobiernoMéxico], procesos de transparencia al

interior de las dependencias, el lema “servir mejor a la gente” para “vivir mejor”, también se hacen

necesarias definiciones en otros aspectos de diseño más complejos y críticos como lo son los

servicios web y las tecnologías afines.

6 Workflow escrito como una sola palabra en inglés y traducido como Flujo de trabajo, es el estudio de los aspectos

operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le da seguimiento al cumplimiento de las tareas. Generalmente los problemas de flujo de trabajo se modelan con redes de Petri.



Estas necesidades de especificación se hacen más evidentes tomando el ejemplo de los sitios web

del Gobierno de México, creados antes de las políticas de calidad de los gobiernos a consecuencia

de la globalización y la difusión de los medios electrónicos [eGobiernoMéxico].

Una vez construidos estos sistemas no resulta tan simple modificarlos de manera que cumplan el

nuevo estándar o las nuevas políticas de calidad y de servicio público.

Haciendo un paralelo con los servicios web - una tecnología más compleja - la carencia de una

pronta especificación podría llevar a una gran variedad de diseños, arquitecturas, metadatos,

plataformas y otros conceptos incompatibles entre sí, que a la larga harían más complejo

solucionar el tema que los servicios web deben resolver, la interoperabilidad en la web.

El porqué se debe considerar a los servicios web se debe a que conlleva un sin fin de beneficios

que ayudan a cualquier organización que los implementa a servir mejor a la gente y a crear

mejores productos y servicios, permiten ver la ansiada descentralización de servicios y acceso a

más gente desde cualquier punto con acceso a la red o Internet, necesidades que pueden ser

cubiertas usando esta tecnología para conectar a las ya existentes.

Además, se debe considerar el creciente volumen de información manejado en los servicios que

ofrece el gobierno, la complejidad de las interacciones entre dependencias y las horas hombre

necesarias para darles cauce.

No sólo es un tema de costos económicos sino que también de tiempo perdido por los ciudadanos

(clientes o usuarios) que requieren de mejores servicios y servidores (funcionarios), más aun si

hablamos de empresas privadas naturalmente repercute en las ganancias y expectativas de

crecimiento.

Un ejemplo de lo anterior lo podemos visualizar en las recientes reformas a las leyes de acceso a

la información y transparencia en el gobierno, así como la prestación de servicios del gobierno por

Internet.

Un caso tangible de esto es el de la Ley Federal de Transparencia y Acceso a la Información

Pública Gubernamental (LFTAIPG) del Instituto Federal de Acceso a la Información (IFAI), así

como el Sistema de Solicitudes de Información (SISI, www.sisi.org.mx).



Con ejemplos así vemos que es posible ofrecer servicios ante la necesidad de una solución

automatizada que ínteropere entre sistemas heterogéneos de distintas dependencias del gobierno

para la solicitud de servicios y trámites gubernamentales como pueden ser las declaraciones de

impuestos o patrimoniales.

Finalmente cabe recalcar que existen algunas particularidades que caracterizan al gobierno

comparado con otras instituciones, que hacen más trascendentes la entrega de servicios de

manera efectiva y eficiente sin olvidar el principio de “TRANSPARENCIA” y de “SERVIR MEJOR A

LA GENTE”.

Una de esas particularidades radica en la importancia del Servicio Público Federal (SPF) y la

posibilidad de agilizar trámites que en el pasado o incluso hoy requieren de días, semanas e

incluso meses para poder tener acceso a los servicios del gobierno.

Además podemos mencionar las facultades y deberes de fiscalización, el manejo de información

pública o bien confidencial, las dependencias y relaciones entre documentos, trámites y

dependencias, y la entrega de servicios que resultan obligatorios o bien como derechos para los

ciudadanos (por ejemplo, el pago de contribuciones, el derecho a los servicios de salud, educación,

seguridad, migración, etc).

Nuevamente tomando un ejemplo de la iniciativa privada, podemos considerar a los bancos que

interactúan hoy día a través de sus portales en Internet con un número mayor de usuarios

(clientes).

En los últimos años se ha identificado que la mayoría de las empresas han tenido un crecimiento

exponencial en la infraestructura informática con la que cuentan, lo cual ha provocado que la

mayoría de estas empresas deseen fervientemente unificar el crecimiento de dicha plataforma

informática hacia una misma dirección, en el sentido de que exista un sólo canal de entradas y una

sola brecha de salidas.

Una plataforma informática integral se puede conceptualizar al interior como una caja negra (figura

3) en la cuál no importa lo que contenga dentro, ni la operación que realice sino lo que reciba a la

entrada y lo que ofrezca a la salida.



Figura 3. Conceptualización de un conjunto de aplicaciones como una caja negra Sin embargo, esta filosofía resulta complicada de entender cuando existe al interior de esta caja

negra un conjunto diverso de plataformas (UNIX, Windows, Solaris) y de lenguajes de

programación (Java, Microsoft .Net, Delphi, C, Visual Basic, etcétera), los cuales resuelven la

operación de la organización, pero que a la vez requieren y dependen de la información que

entregan a la salida las demás aplicaciones o entidades.

El problema general radica como ya se menciono anteriormente, en que la solución inicial no se

pensó como una sola unidad sino como un conjunto de soluciones a la medida en el momento de

que cada una de las necesidades apareció.

Particularmente el problema a resolver es la complejidad de lograr que todas esas aplicaciones

interactúen entre sí, sin la necesidad de procesos manuales que trasladen la información de salida

de un proceso o aplicación a la entrada de otro que realiza otro tratamiento de dicha información.

Podemos imaginar un proceso general sincronizado (figura 4), normalmente serializado y lento

debido a la intervención de los procesos manuales realizados por personas que requieren validar

las entradas y salidas de dichos procesos o aplicaciones.

Tal vez la solución más razonable sería rehacer todos los procesos o aplicaciones en una sola

aplicación, sin embargo esto puede resultar más costoso en cuanto al tiempo para lograrlo, debido

al análisis que requiere la solución integral más el tiempo de desarrollo e implantación necesarios

para ello (ciclo de vida del desarrollo de software).

Conjunto de aplicaciones

corporativas que procesan las

entradas y entregan salidas en respuesta a la demanda

Salidas con un mismo formato

Entradas de diversas fuentes



Figura 4. Interacción manual entre aplicaciones de una misma organización.

La manipulación de la información para llevarla de un proceso (o sistema) a otro, requiere de

tareas programadas manualmente y que no siempre resultan ser confiables debido a la propia

intervención de la mano de las personas.

La sustitución de estos procesos manuales por procesos automatizados o interfaces (figura 5) que

agilicen el intercambio de la información, es un paradigma generalizado que se presenta

actualmente en la mayoría de las organizaciones.

Hoy en día la mayoría de las organizaciones invierten fuertes cantidades de dinero y esfuerzos

exagerados para lograr la integración de aplicaciones en una metaplicación corporativa, la cuál

permita definir una mejor planeación, ayudar a la toma de decisiones en menor tiempo y generar

ventajas competitivas, por consecuencia esto les redituará en mejoras económicas y una mejor

respuesta hacia sus clientes o usuarios.

Sistema de Planeación

Sistema de Compras y Ventas

Sistema de procesos

corporativos

Sistema de Atención Informática

Sistema de R. H.



& - Intefaz o aplicación que sirve de intermediaria para automatizar el proceso de intercambio de información

- Documentos electrónicos (estructura, protocolo, estándar para intercambio de información entre aplicaciones). Figura 5. Interacción automatizada entre aplicaciones de la organización.

En la mayoría de las empresas y organizaciones privadas o de gobierno podemos encontrar

procesos de información bien definidos, algunos con un alto nivel de madurez por el tiempo que

han sido aplicados y mejorados. Sin embargo, el común denominador en todos ellos es la

interacción de la mano del hombre (usuarios) para intercambiar información entre los distintos

actores.

Esa intervención de los “usuarios” (figura 6) genera una serie de factores que retrasan el flujo de

información desde la entrada hasta la salida. Factores como la inspección visual, la clasificación de

documentos o datos extraídos, la generación de reportes y otros más que consumen un lapso de

tiempo que puede ser disminuido o incluso eliminado en algunos casos.

Otro factor que aparece derivado de los procesos de una inspección o clasificación “manual”, es el

número de errores agregados por una mala validación manual de la información que se acarrea o

se multiplica a lo largo del flujo desde la entrada hasta la salida.

Sistema de Planeación

Sistema de Compras y Ventas

Sistema de procesos

corporativos

Sistema de Atención Informática

Sistema de R. H.

&

&

&

&

&

&

&



Estos factores o problemas son en la mayoría de los casos revocables, la tarea es encontrar un

proceso automatizado (figura 7) que reemplace esas intervenciones manuales que provocan toda

esa serie de errores y retrasos.

La manera de solucionarlos requiere de un alto conocimiento del negocio (flujo de información) así

como un minucioso análisis de los procesos manuales y validaciones que se realizan al pasar de

una aplicación a otra, la definición de interfaces automatizadas para estos problemas no es una

tarea fácil.

Es necesario considerar que muchas veces esos procesos o validaciones se realizan a criterio

personal de los actores dentro del flujo, pero es posible ponderar la mayor cantidad de esos

criterios a modo de minimizar la intervención del criterio personal y manipulación de la información.

Figura 6. Proceso/Validación Manual

Figura 7. Proceso/Validación Automatizado

El objetivo principal de este trabajo es ofrecer una alternativa de solución al problema de

integración de aplicaciones corporativas (guía basada en casos de éxito), para reducir los costos y

desventajas de los procesos manuales que disminuyen la competitividad, la productividad y

merman la capacidad de respuesta al interior de las organizaciones que cuentan con una gran

diversidad de aplicaciones y de plataformas.

Proc. A

Proc. B

Proceso/validación Manual

Proceso/validación Automatizado

Proc. A

Proc. B



El objetivo mencionado anteriormente para este trabajo, puede ser descompuesto en los siguientes

objetivos específicos:

� Definir requerimientos para lograr interoperabilidad dentro de una organización y entre

dependencias (interoperabilidad vertical y horizontal respectivamente).

� Caracterizar el concepto de servicio, analizar la entrega de servicios, su contexto dentro

del e-Gobierno, su relación con sistemas existentes y revisar la arquitectura orientada a

servicios.

� Conocer el rol que juegan las descripciones (metadatos) de recursos en la entrega de

servicios y analizar como ellos pueden ayudar a la interoperabilidad y automatización de

los servicios.

� Presentar características, problemas y ventajas del uso de la tecnología de servicios web

para la entrega de servicios tomando en cuenta el modelo de e-Gobierno.

� Revisar casos de éxito que ejemplifiquen el uso y necesidad de las descripciones de las

pautas técnicas.

� Dar un primer impulso hacia la estandarización y profesionalización del desarrollo de

servicios en el e-Gobierno en México a fin de poder comparar, compartir, y replicar esta

experiencia entre las empresas privadas y de gobierno.

� Comentar las ventajas de implementar soluciones de integración para aplicaciones

corporativas mediante servicios web, dentro de los cuales se incluyen los objetivos del

Gobierno Federal como el de transparencia, servir mejor a la gente, mejorar la calidad de

los servicios que ofrece el gobierno, generar ventajas competitivas e incrementar la

productividad.

Para el desarrollo del presente trabajo, se hará uso de los recursos obtenidos a lo largo de la

experiencia profesional propia del tesista en la iniciativa privada, así como material recaudado de

Internet, fragmentos de documentos de dependencias de gobierno bajo autorización expresa y oral

por parte de los jefes inmediatos del tesista en cada dependencia, el uso de dichos documentos es

sólo como material de consulta para ejemplificar la solución que se pretende.

Como se ha comentado hasta aquí, existe un interés muy grande por parte de las organizaciones

para identificar su problemática de integración y solventarla de algún modo tratando de agilizar sus

procesos de información.

Uno de los problemas principales es que no existe una estandarización de dichos procesos ni de la

forma de operarlos, la hipótesis que surge en este contexto es que existe una preocupación más

grande por la compra de productos costosos que solucionen el problema y no por analizar primero

su situación actual.



Lo primero que debería hacerse es un análisis de cual se deriven las problemáticas y sus

necesidades, además de que se pierde de vista algo muy importante que es el ofrecer mejores

servicios y de ser más competitivos incrementando la productividad o bien sirviendo de mejor

manera, dependiendo del contexto público o privado.

Los productos que ofrecen los grandes proveedores de software prometen solucionar muchos de

los problemas comentados anteriormente, sin embargo, “al final todos terminan siendo un producto

que cubre solamente el 10 ó 20 por ciento de la problemática a resolver, sobre todo cuando no se

ha hecho el análisis pertinente de las necesidades en contraparte con las ventajes que ofrecen

dichos productos, por consecuencia esto hace más difícil la operación al interior de las

organizaciones”. [Ramiro Rodríguez 2003, Tesis ERP en la administración de proyectos de construcción ITESM Cd.

México].

El porcentaje restante termina siendo un desarrollo nuevo o a la medida por parte del proveedor

debido a que el negocio de la organización así lo requiere por su complejidad, por su situación

fiscal, organizacional u otras razones.

En algunos casos la implementación de un ERP, GRP, CRM, o cualquier otro modelo para la

planeación de recursos y administración de procesos, terminan siendo una solución que consume

dinero en exceso, tiempo y esfuerzos exponenciales, debido a que la implementación de dicho

sistema no siempre es lo que el proveedor promete.

La obtención de una metaplicación corporativa eficiente y funcional, depende más de la correcta

obtención de un grupo de personas con experiencia suficiente en el negocio para sacar adelante

un proyecto, y no de un producto que prometa cubrir el mayor porcentaje posible de la operación.

-Tal como lo dice Ramiro Rodríguez (2003) en su tesis "ERP en la administración de proyectos de

construcción” Biblioteca Digital ITESM [on-line database]. - menciona la importancia de que, para

implementar un sistema ERP debe formarse un equipo con las personas de mayor experiencia en

sus áreas, generalmente se menciona que "sí las compañías pueden operar el negocio como

siempre, sin la gente que ellos han puesto en los equipos de implantación, entonces se ha

seleccionado al personal equivocado para el proyecto ERP".



El equipo debe incluir gente técnica (que sabe como trabajar con el sistema ERP) y gente de

negocios que entiende como opera la compañía, como se representa en la figura 8, aunque se

debe reconocer que de ambos es mas importante el personal experto en el negocio.

Figura 8. Éxito de un proyecto ERP.

Como se puede inferir, a final de cuentas la solución termina siendo una reingeniería de los

procesos internos.

Donde lo más conveniente es realizar un esfuerzo interno para realizar el análisis pertinente, en

lugar de promover un producto que nos implique más esfuerzo innecesario y un gasto excesivo en

todos los aspectos, ya que terminan duplicándose las cosas al operar dos sistemas en paralelo (el

anterior y el nuevo ERP) por un largo tiempo que normalmente no llega a cumplir con el objetivo

fijado.

CONOCIMIENTO DEL SISTEMA ERP

CONOCIMIENTO DETALLADO SOBRE EL PROCESO DE NEGOCIO

ÉXITO DEL PROYECTO + =



Capítulo

2 Antecedentes, Organizaciones y sus experiencias

En este capítulo se habla de las experiencias que han tenido las organizaciones en

México (Gobierno Federal), en el mundo y en algunas empresas de la iniciativa

privada. Así también, se exponen sus ventajas y desventajas experimentadas en la

implementación de soluciones que resuelvan el problema de la integración de

aplicaciones.



2. Antecedentes, Organizaciones y sus experiencias.

2.1 Gobierno electrónico

El concepto de gobierno electrónico, e-Gobierno (o e-Government por su denominación en

inglés) fue acuñado como: “una forma de describir el quehacer del Gobierno, apoyado por las

nuevas tecnologías de información y comunicación (TIC), a fin de cumplir con sus funciones

eficiente y efectivamente” [e-gov-roadmap].

2.1.1 Clasificación de los servicios de gobierno en México según el nivel de madurez

La madurez del desarrollo del e-Gobierno se ha intentado revisar y medir mediante la definición de

sus etapas a través de trabajos realizados por parte de Universidades como el Tecnológico de

Monterrey campus Monterrey, la Universidad Nacional Autónoma de México (UNAM) a través de

estudios por parte del Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas IIMAS,

catedráticos de la Universidad Iberoamericana (UIA) en colaboración con el IIMAS y otros más,

hablando del caso de nuestro país se ha hecho el análisis desde el estado más primitivo al más

evolucionado.

Esto permite comparar el estado y evolución del gobierno electrónico en México con los avances

en otros países de la región y del primer mundo, además de poder definir una guía de desarrollo

con una propuesta de metodología más estandarizada.

Para ello, a continuación se presentan las etapas del enfoque evolutivo [Gil-Garcia Et Luna-Reyes, 2003,

Sahelin, 2003]

Inicial: Antes de definir cualquier etapa, podemos mencionar un estado inicial que representa el

estado en el que no existe comunicación electrónica (como servicios) hacia el exterior (ciudadanos

u otros agentes del estado), pero sí sistemas de información internos que pueden o no

comunicarse. A partir de esta base de infraestructura podemos mencionar las siguientes etapas del

enfoque evolutivo.



Las 6 etapas definidas son:

1. Presencia. Esta primera etapa se enfoca en clasificar y organizar información a través de

páginas web y garantizar la presencia de la dependencia gubernamental en Internet (o bien de la

compañía privada).

La mayoría de las iniciativas gubernamentales comienzan en esta fase, sin embargo, su utilidad es

limitada ya que carece de motores de búsqueda que facilitarían la tarea de encontrar datos.

No se encuentra dividida por segmentos ni tipos de usuarios, los sitios web pueden contener

información básica que permitiría contactar a los funcionarios por teléfono o tener acceso a ellos en

sus oficinas en ciertos horarios pero no se puede realizar ninguna interacción mediante Internet.

2. Información. Esta etapa engloba una gran cantidad de sitios gubernamentales, pues permite el

acceso de numerosas organizaciones públicas y privadas. Un portal de este tipo sirve como página

inicial o como plataforma de despegue para tener acceso a otras páginas útiles donde se pueda

localizar información de distintos departamentos, direcciones o dependencias del gobierno.

En esta etapa los usuarios pueden encontrar información más actualizada y especializada, además

cuenta con motores de búsqueda internos y/o externos.

3. Interacción. Existe mucha interacción entre los ciudadanos y los departamentos

gubernamentales, es posible que los usuarios encuentren información que resuelva sus

necesidades e intereses.

En algunos casos los sitios web utilizan contraseñas para proteger los datos o la identidad de sus

usuarios y de esta forma brindan garantías a la información personalizada y a la protección de

documentos.

En esta etapa se puede tener acceso a leyes, publicaciones gubernamentales y reportes que se

pueden obtener directamente de los sitios y transmitirse a sus computadoras personales para ser

revisados posteriormente sin necesidad de conexión.

Finalmente en esta etapa ya se encuentran los motores de búsqueda y la suscripción electrónica a

noticias relacionadas con el sitio gubernamental.

Se cuenta con correos electrónicos de funcionarios y servidores públicos, lo que facilita la

interacción entre gobierno y ciudadanos.

4. Transacción (Interacción en dos vías). En este punto las páginas gubernamentales utilizan el

potencial de Internet para proveer servicios públicos y no únicamente brindar información del

gobierno. Los ciudadanos pueden realizar transacciones seguras, confiables y rápidas a través de

Internet.



Se pueden obtener líneas de captura para pago de servicios o impuesto en bancos; renovar

permisos y licencias, tramitar pasaportes, consultar saldos, obtener citas para trámites, entre otros

ejemplos.

Como ventaja de esta etapa se permite “personalizar las funciones” según el tipo de usuario y

garantizar que la organización del sitio ayude a resolver necesidades, las cuales pueden ser de

información o contacto con el gobierno de acuerdo con las características específicas de cada

ciudadano (caso del IMSS, ISSSTE y SAT).

5. Integración ó Integración Vertical Interna (“Transformación”). Esta es una de las etapas

más avanzadas: el portal brinda múltiples servicios mediante una ventanilla única integral. Los

ciudadanos pueden acceder a todos los servicios de diferentes dependencias gubernamentales o

niveles de gobierno, sin preocuparse con qué departamento u organismo interactúan.

En esta “atmósfera virtual”, las fronteras entre departamentos, direcciones y subdirecciones no son

visibles a los ojos de los ciudadanos.

El gobierno les ofrece servicios en línea de acuerdo con las necesidades, funciones y jurisdicción

que tenga cada ciudadano para ofrecer servicios públicos de manera rápida y eficaz (para este

caso la página de presidencia.gob.mx y de e-GobMéxico.gob.mx, son candidatas a ocupar

próximamente este nivel de madurez, en principio por lo que representan para el gobierno y en

segunda por que pueden convertirse en los sitios de mayor demanda pública, dados los servicios

que deberán ofrecer) pero para ello, habrá que trabajar arduamente para integrarlas a dicho nivel o

etapa de madurez.

En esta fase el sitio web es transaccional, la interacción es personalizada (decisión, entrega y

eventualmente pago).

6. Participación Política. Esta es la última etapa y probablemente la más avanzada del enfoque

evolutivo, supone que el ciudadano no sólo interactúa con el gobierno sino que participa

activamente en la toma de decisiones gubernamentales.

Aquí ya es posible que los ciudadanos opinen sobre proyectos de ley o políticas públicas. De igual

forma, puede existir el voto electrónico sobre asuntos públicos u otras formas de participación a

través de los sitios gubernamentales, la página del IFE (Instituto Federal Electoral), es

evidentemente candidata por la función que desempeña y está obligada a llegar a este nivel de

madurez.



Con el objetivo de llevar a cabo la medición de los portales, estas seis etapas no son

necesariamente consecutivas y de hecho pueden considerarse como componentes diferentes,

aunque interrelacionados.

Es decir, un portal que provee buena información, que permite la interacción entre gobierno-

ciudadano, que tiene la capacidad de proveer servicios en línea, que presenta un alto grado de

integración y que promueve la participación política de la ciudadanía es un portal altamente

funcional. Sin embargo, no es necesario que un portal tenga todas las características relativas a

cada uno de los componentes.

La siguiente etapa de este estudio consiste en revisar los portales y asignarles un puntaje. Para

ello debe tenerse presente que cada indicador contiene uno o más reactivos (ver Tabla 1).

La ponderación que se haga de cada uno de los reactivos dará el puntaje final de cada indicador,

cuyo máximo es un punto. Por otra parte, el puntaje para cada indicador es un porcentaje del total

de indicadores que se encontraron en cada portal –seis en este caso. Una vez calculados los

puntos obtenidos por cada indicador, se suman y dividen entre seis (normalización); así se obtiene

un promedio denominado “puntaje total” que mide la funcionalidad del portal.

Los portales con mayor madurez tendrán un puntaje máximo de 1 punto.



Indicadores Reactivos (Sofisticaciones Tecnológicas y Organizacionales

Adicionales)

Presencia • Información limitada por el gobierno.

• Pocas páginas web hechas por simples agencias.

• Información estática acerca de la estructura y servicios del gobierno.

Información • Número mayor de páginas web.

• Portal estatal que contiene ligas a la mayoría de los estados del país.

• Información más dinámica (actualizaciones frecuentes).

Interacción • Las formas (leyes, reglamentos, documentos) se pueden descargar.

• Comunicación de doble banda a través del correo electrónico.

• Uso de máquinas y programas de búsqueda.

• Uso de chats, foros y otras formas interactivas de comunicación

(relacionadas con el servicio).

• Posibilidad de configurar (archivo de ciudadanía, uso de contraseñas).

Transacción • Servicios en línea (seguros), incluyendo pagos electrónicos (tarjetas de

crédito y líneas de captura).

• Más configurabilidad (uso de contraseñas, firma electrónica, etc.).

• Portal organizado acorde a las necesidades de las personas en lugar de

las estructuras gubernamentales.

Integración • Portal de servicio con un punto único de salida (agencias múltiples,

misma función, diferentes niveles de gobierno).

Participación

Política

• Participación de decisiones gubernamentales, voto electrónico,

encuestas en línea.

Fuente: Traducido por [Sandoval Almazán] y [Gil-García], 2005.

TABLA 1. EVOLUCIÓN DE LAS APROXIMACIONES A LA EVALUACIÓN DEL GOBIERNO ELECTRÓNICO.

Aunque este estudio tiene limitaciones que vale la pena considerar, representa un primer

acercamiento a la funcionalidad de los portales del sector público en México. El estudio presentado

sólo evalúa la funcionalidad de los portales en términos de los seis componentes mencionados: (1)

Presencia, (2) Información, (3) Interacción, (4) Transacción, (5) Integración, y (6) Participación.

Los resultados podrían cambiar de forma radical si se incluyen otros aspectos específicos como

calidad de la interfaz, sofisticación técnica del portal, rapidez en el despliegue de la información,



disponibilidad del contenido en varios idiomas, número de usuarios beneficiados por mes, entre

otros.

Es por ello que es necesario que las evaluaciones en el futuro sean muy claras en su método y

mencionen explícitamente qué aspectos son considerados y de qué forma es construido el índice

de funcionalidad o puntaje total.

Como puede verse, es necesario desarrollar una evaluación más integral que considere aspectos

cuantitativos y cualitativos, que reconozca innovaciones de los portales y que considere las

necesidades y características de los ciudadanos, a final de cuentas se trata de servir mejor y de

ofrecer servicios más fáciles de usar. Tal evaluación mejorará la calidad de los portales estatales,

sirviendo de guía y proporcionando ideas útiles que puedan ser retomadas por los responsables

del contenido en cada entidad, sin embargo, es una buena referencia para saber en donde

estamos parados como país en el marco de los que se denomina un buen portal de e-Gobierno.

2.2 Experiencias e iniciativas nacionales

2.2.1 Iniciativa del portal eGobiernoMéxico (eMéxico)

Antecedentes

En su toma de posesión el 1° de diciembre del año 2000, el entonces presidente de la República

Vicente Fox Quesada, anunció el lanzamiento del Sistema Nacional e-México a fin de integrar los

esfuerzos de diversas dependencias y entidades de la Administración Pública, así como de los

operadores de redes de telecomunicaciones entre otros actores, un proyecto de conectividad

nacional que incorporara tecnologías de vanguardia y contenidos en línea, particularmente los de

impacto social para México quedando este programa bajo la coordinación de la Secretaría de

Comunicaciones y Transportes [Fuente: SEDESOL, http://www.sedesol.gob.mx].

En la información que muestra la página de la Secretaría de Desarrollo Social (SEDESOL), se

muestran los principios que rigen en un principio las bases del eGobierno (e-Government por su

denominación en inglés) en México, con la puesta en marcha del sistema eMéxico cuyo objetivo se

plasmaba como el de “reducir la brecha digital existente entre diferentes sectores de la población

del país e integrarlas a la Sociedad de la Información”.



A la vez se anunciaba que su diseño debía responder a la necesidad de comunicaciones, mediante

el uso de las carreteras de información, lo cual permitiría a la población tener acceso a numerosas

oportunidades de desarrollo individual y colectivo, la integración de los individuos y grupos de la

sociedad, el fortalecimiento de la democracia y la participación ciudadana, el incremento del

conocimiento, la capacitación y la competitividad y una mejora en oportunidades de desarrollo y

calidad de vida.

El Sistema Nacional e-México definió tres ejes principales para su desarrollo. Se resaltaba que

estos ejes debían mantenerse coordinados como un todo, aún cuando sus características se

manejarán independientemente para efectos de ejecución. Los ejes rectores serían:

� Conectividad,

� Contenidos y

� Sistemas.

La Conectividad se refiere a la oferta de servicios integrales de comunicación, capaces de llevar

Internet a las Poblaciones del país, inicialmente a través de la creación de los Centros

Comunitarios Digitales (CCD's), principales vehículos que permitirían enlazar a las diversas

localidades que los integraran.

Los Contenidos serían parte indispensable para el Sistema, puesto que la conectividad que se

ofreciera debería utilizarse para la distribución y acceso de todo tipo de contenido digital que

ofreciera a la población: datos, información, conocimientos y servicios que se tradujeran en un

beneficio manifiesto en su desarrollo.

Dentro de los contenidos destacaban entre otros temas de importancia: Educación, Salud,

Economía, Gobierno, Ciencia y Tecnología. Estos temas son evidentemente una parte medular

de los servicios de cualquier organización gubernamental o privada.

A través de los Sistemas de programación computacional se integrarían los contenidos con sus

aplicaciones. La conectividad y el acceso se harían disponibles para el público en general a través

del uso de sistemas y tecnologías de información, bases de datos y otros avances tecnológicos

afines.



¿Quiénes participan en e-México?

Para comenzar con la implementación del sistema eMéxico se integraron grupos de trabajo en

conjunto con las dependencias involucradas a nivel federal como son la Secretaría de Educación

Pública (SEP), la Secretaría de Salud (SSA), la Secretaría de Desarrollo Social (SEDESOL), el

Instituto Nacional para el Federalismo y Desarrollo Municipal (INAFED) de la Secretaría de

Gobernación (SEGOB) y el Instituto Nacional para la Educación de los Adultos (INEA), coordinados

con la Secretaría de Comunicaciones y Transportes (SCT).

Entre junio y julio del 2002 se firmaron los convenios de colaboración intersecretarial entre la SCT y

cada una de las dependencias señaladas en el párrafo anterior, para establecer los compromisos

de las partes para lograr los objetivos establecidos para la conectividad. Asimismo, el 15 de julio

del 2002 se firmó la Declaratoria de Conectividad para el Sistema Nacional e-México, haciendo

pública la formalización de la firma de los Convenios Intersecretariales para la conectividad e-

México, dentro de la cual se instalarían y operarían los Centros Comunitarios Digitales e-México

(CCDs e-México).

Esta Declaratoria fue suscrita por el entonces Presidente de México, Vicente Fox Quesada, como

testigo de honor, y por los Secretarios de las Dependencias involucradas en la conectividad.

El 1º de octubre de 2002 se publicaron las bases de licitación para la contratación de los servicios

de conectividad satelital cuyo ganador fue la empresa Internet Directo, S.A. de C.V., concesionario

de la red pública de telecomunicaciones, para lo cual se firmó el contrato respectivo el 18 de

diciembre de 2002 y con ello se iniciaron los trabajos de instalación de la referida red satelital.

2.2.2 Principios del Gobierno electrónico

Junto con el nacimiento del gobierno electrónico, se definieron un conjunto de principios y objetivos

que rigen tal iniciativa: [eMéxico, http://www.emexico.gob.mx]

Misión del e-Gobierno

Aprovechar el potencial de las tecnologías de la información en un proceso integral de

innovación continua para prestar servicios de calidad con vocación social.



Visión del e-Gobierno

Ser un gobierno de clase mundial que hace uso intensivo de las tecnologías de la información

y comunicaciones para ofrecer los servicios de alto impacto en la sociedad mexicana.

Objetivos

� Incrementar la eficiencia, efectividad, rendimiento y productividad de los macro-procesos.

� Mejorar la calidad de los servicios públicos.

� Mejorar el acceso a la información pública.

� Incrementar la participación ciudadana.

� Mejorar la accesibilidad de los servicios, entregándolos por medios electrónicos.

� Reducción de costos.

� Mayor captación de Ingresos.

� Rendición de cuentas a los ciudadanos.

Figura 9. Estructura del eGobierno México (política del Buen Gobierno) [SFP-Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información]



Como lo muestra la figura 9 se definió una estructura de eGobierno que la cuál incorpora a la

Secretaria de Comunicaciones como principal actor y al Consejo Nacional de Ciencia y Tecnología

para encabezar las tareas de investigación y aplicación de TI, las cuales deberán estar

coordinadas y apegadas a los lineamientos de la Oficina del C. Presidente de la República.

Los proyectos de e-Gobierno habrán de integrar las siguientes características:

� Abiertos y penetrantes: Habrán de contar con servicios basados en estándares de Internet

y el conocimiento de la sociedad habrá de ser incluida en su totalidad.

� Orientada al ciudadano: Poner al ciudadano en el centro del pensamiento, con sistemas

que provean calidad y servicios personalizados en donde exista valor agregado en dichos

servicios.

• Integrar los servicios del gobierno en los procesos de negocios, las agencias y las

jurisdicciones para que dichos servicios aparezcan en línea como un sistema

completamente integrado.

• Fomentar las asociaciones público - privadas.

� Asegurar el acceso a todos los ciudadanos a las prestaciones disponibles en forma

electrónica, considerando las dimensiones social (quién accede), geográfica (dónde

accede) y temporal (cuándo accede).

� Que el beneficio obtenido por el ciudadano respecto a la forma presencial de acceder a las

prestaciones sea mayor.

� Garantizar y disponer de mecanismos adecuados para asegurar privacidad y seguridad en

el uso, acceso y transacción de información.

� Descentralizar la administración, mantenimiento y actualización de las TIC a cargo de los

servicios públicos, asegurando interoperabilidad entre ellos.

� Debido a la naturaleza de estos principios y a las tecnologías disponibles en el país

[eMéxico], la web ha comenzado a ser uno de los medios más importantes que permiten

un eficaz y eficiente acceso a los servicios por parte de los ciudadanos y otras

dependencias del Gobierno.

� Un claro ejemplo de esto, son los servicios e información en línea entregados en el portal

de TrámitaNet o la misma Secretaría de Gobernación [traminaNet].



La figura 10 muestra el esquema de integración de las aplicaciones de una organización que

interactúan con las de otras dependencias del gobierno federal a través de conexiones de Red

Privada Virtual (VPN por sus siglas en inglés).

Este tipo de enlaces son más seguros al no estar disponibles de manera pública sino a través

de un enlace virtual de manera privada.

Figura 10. Esquema de integración de aplicaciones entre Secretarias de Estado (Portal único)

Fuente: [SFP-Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información]

2.2.3 Estado actual del e-Gobierno en México

A pesar de que existen servicios en línea o al menos se tiene información sobre ellos, el uso de los

servicios en la web aún es bajo, por desconocimiento, por la poca difusión que se les da, por la

falta de medios para acceder a ellos (Internet) y otras razones de índole cultural, esto basado en la

comparación con los servicios disponibles sólo en oficinas (hablando de departamentos al interior

de una misma organización).

Por otro lado no podemos olvidar los importantes avances en la entrega de servicios por parte de

dependencias como el Servicio de Administración Tributaria (SAT), la tesorería del Distrito Federal,

el Instituto Nacional de Fomento a la Vivienda para los Trabajadores (INFONAVIT), la Secretaría



de Gobernación, el portal www.eMexico.gob.mx, el Instituto Mexicano del Seguro Social (IMSS),

entre otros, cabe resaltar que aún existen muchos casos donde las interacciones son manuales, no

existe interoperabilidad vertical u horizontal, ni el uso de las TIC acorde a las necesidades

actuales.

Un claro ejemplo de la falta de interoperabilidad entre organismos gubernamentales, son los

servicios ofrecidos en dependencias como los gobiernos Municipales, clínicas y hospitales del

sector salud.

Definir la mejor forma de incluir en el mediano plazo a estas dependencias en el desarrollo integral

del gobierno electrónico, resulta ser un importante desafío para el actual y los futuros gobiernos

federales.

Es importante destacar que el nivel de desarrollo de los servicios es un estimado 7 al momento de

la recolección de la información, se obtuvo a partir de estudios realizados por empresas privadas

que colaboran con proveedores como Oracle y PeopleSoft, así como universidades y centros de

investigación como la UNAM y el Tec de Monterrey campus Monterrey que cuentan con buena

reputación en el estudio de gobierno electrónico.

Sin embargo, existen varios proyectos al interior de las dependencias que buscan cumplir con los

objetivos del bueno gobierno, haciendo énfasis en automatizar los procesos internos y reducir

el número de operaciones manuales para brindar un mejor servicio a la población.

Utilizando el enfoque evolutivo mencionando anteriormente, en enero del 2006 se visitaron y

evaluaron los portales de los 31 estados y el Distrito Federal por parte de un grupo de

investigadores que se dieron a la tarea de hacer una evaluación del estado del eGobierno en

México [Sandoval 2006, Política Digital].

Este grupo utilizó el estudio del enfoque evolutivo y como lo marca dicho enfoque, para cada

afirmación se asignó el valor de un punto y el puntaje para cada componente fue calculado como el

porcentaje de reactivos (afirmaciones) que se encontraron en cada portal.

7 Estimado al mes de Diciembre de 2007.



Una vez calculados los porcentajes para cada componente, se sumaron y dividieron entre 5

(número de componentes que se tomaron en cuenta en ese estudio), obteniéndose un promedio

que se denomina “Puntaje total”.

Para finalizar, tomando el puntaje total, se asignaron lugares a los 32 estados del país. La Tabla 2

presenta los puntajes totales por entidad y por componente para los portales estatales.

TABLA 2. Estados con los mejores puntajes totales.

Como se puede observar el mayor porcentaje en el componente “Información” fue 100%, lo que

equivale a haber presentado 5 de las 5 características evaluadas para este componente.

Únicamente Morelos obtuvo el puntaje más alto en cuanto a información, pero la gran mayoría

obtuvieron 85.71%, lo que equivale a 4 de las 5 características evaluadas. Tamaulipas y Nayarit

obtienen cero puntos ya que se centran más en la interacción. Los estados de Quintana Roo,



Coahuila, Durango y Guerrero que figuran en las últimas posiciones carecen de un diseño

enfocado a la información pues sus portales están mayormente integrados a otras páginas

gubernamentales internas y no a un portal diseñado con un propósito informativo.

En el caso del componente “Interacción”, los estados de Sonora, Chiapas, Estado de México y

Tamaulipas alcanzaron el mayor porcentaje con 57.14%, lo cuál indica que han logrado

implementar mecanismos que permiten buena comunicación con sus ciudadanos. La mayoría de

las entidades tienen un porcentaje mayor a la media de 34.82, sólo nueve entidades están por

debajo de ésta. Sin embargo, es necesario impulsar más la interacción entre el gobierno y los

ciudadanos.

En cuanto al componente “Transacción”, debe destacarse que sólo 13 de las 32 entidades ya

realizan transacciones en línea (este estudio se realizó en los primeros días de enero del 2006). En

estos estados, ya sea de forma parcial o completa, se puede obtener algún servicio gubernamental

en Internet. En este rubro se evalúa el trámite completo, es decir sin necesidad de acudir a ninguna

oficina pública o llamar por teléfono. Nuevo León fue el estado con mejor servicio de trámites

completos en línea.

El componente “Integración” tiene una composición distinta de los anteriores indicadores, pues

muestra el grado de vinculación entre las distintas dependencias con el portal. El estado de Nuevo

León presenta el puntaje más alto con 55.56%, lo que representa 5 de las nueve características

evaluadas para este componente. Le siguen Sonora, Hidalgo, Yucatán, Zacatecas y Tamaulipas

que cuentan también con portales relativamente integrados, al menos de forma virtual. El resto de

los estados tienen puntajes relativamente bajos (de 22.22 a 11.11) y el promedio general es

30.21%.

Finalmente, el componente “Participación Política” es incipiente. La mayoría de las entidades

carecen de esfuerzos que impulsen la participación de sus ciudadanos a través de sus sitios web,

mientras aquellos que lo tienen es apenas un esfuerzo inicial (obteniendo solo 1 de 4 puntos

potenciales para este componente). No obstante, el resto de los indicadores permite ubicarlos en

determinado lugar de la lista.

Es importante destacar que la diferenciación regional no es tan marcada como pudiera esperarse.

Hay seis estados del norte del país en los primeros lugares del índice: Nuevo León, Sonora, Baja

California Norte, Tamaulipas, Sinaloa y Zacatecas; seis estados del centro: Morelos, Michoacán,

Hidalgo, Estado de México, Aguascalientes y San Luís Potosí; Jalisco, de occidente; y Yucatán y

Chiapas, del sur. Existe una tendencia de los estados norteños a tener mejores páginas web, pero



los estados del Centro y Sur realizan importantes esfuerzos que son muy comparables a los del

norte.

Por otra parte, el promedio global de los estados en todos sus rubros es de 32.76 puntos. 12

entidades se encuentran por debajo de esta media y 20 de ellas están por arriba del promedio. Lo

cual parece indicar que existen importantes diferencias entre estados con portales altamente

funcionales y estados que están comenzando a desarrollar este tipo de presencia electrónica.

Por último, el puntaje total combina las fortalezas de los estados en los distintos componentes.

Entre mayor avance tenga en uno o varios de los componentes la entidad adquiere mayor puntaje,

que la coloca en una mejor posición que el resto. Aunque los componentes o etapas no son

necesariamente consecutivos, como hemos mencionado, si se complementan y dan como

resultado portales con mayor funcionalidad y más útiles para los ciudadanos, las empresas y otras

entidades que interactúan de forma cotidiana con los gobiernos estatales [Sandoval 2006, Política

Digital].

En resumen, tal y como indica el artículo de Sandoval Almazán [Sandoval 2006, Política Digital]. -falta

mucho por indagar sobre este tema, y coincide ampliamente con otros artículos (como Mercado

Arceo, La TI automatiza al gobierno, 27/11/2006, InfoWorld) en que es necesario desarrollar una

evaluación más integral que considere aspectos cuantitativos y cualitativos, además que reconozca

innovaciones de los portales y que considere las necesidades y características de los ciudadanos.

De la misma forma, esta evaluación debe ayudar a mejorar la calidad de los portales estatales,

sirviendo de guía y proporcionando ideas útiles que puedan ser retomadas por los responsables de

los portales en cada entidad.

Según José Luís Torres, director Comercial del Sector Público, Salud y Educación de Oracle en

México y Centroamérica, vamos un poco adelante de la mitad de las cinco etapas anteriores,

estamos culminando la transaccionalidad, “las primeras etapas están al 100% de acuerdo al

estudio realizado en 2005 de e-government que hizo Naciones Unidas, México está posicionado

en el lugar número 9 en la transformación y madurez de gobierno electrónico, y ellos nos

colocan prácticamente en la etapa tres de interacción, en la cual estamos al 88% y en la parte

transaccional estamos en un 46%”.

Jose Luís Torres, consideró que para llegar a la etapa de integración o conectividad nos falta

mucho, “lo ideal sería estar en la Ciudad de México y pagar el catastro de alguna propiedad en

algún otro Estado de la República, para allá estamos avanzando, no obstante el problema no es



tecnológico sino político para que haya la apertura y acuerdos entre las diferentes entidades, pues

dada su autonomía esto es todavía prohibitivo en nuestro país”. [InfoWorld-Mercado Arceo]

De acuerdo con el “Índice Global de Preparación para el Gobierno Electrónico”; México está

situado en el lugar 31 de la Clasificación General, con un índice de 0.6061. Los tres países líderes

son Estados Unidos (0.9058), Dinamarca (0.9058) y Suecia (0.8983), seguidos del Reino Unido

(0.8777).

El desempeño relativo de la región durante 2005 fue mixto, con solo cinco países que fueron

capaces de mejorar su posición. Chile (22) mantuvo su posición de liderazgo regional con 0.6963,

Brasil con 0.5891 y Argentina con 0.5971.

Como es de imaginar, en términos de promedios regionales los países de Norte América lideran

con 0.8744, seguidos de Europa con 0.6012; luego Asia Sur y Oriente con 0.4922; luego América

Central y del Sur con 0.4643; luego Asia Occidental con 0.4384; luego el Caribe con 0.4282; luego

Asia Sur y Central con 0.3448; luego Oceanía con 0.2888 y finalmente África con 0.2643. Siendo el

promedio mundial de 0.4267 en el 2005.

Es interesante notar que de la región, solo México y Chile se encuentran sobre el promedio de los

países europeos y bastante por sobre el promedio de la región.

México se encontraba en el lugar 30 durante 2003 y 2004, cayendo al lugar 31 en 2005. Los países

con mayores avances son Corea (del 13° al 5° lugar entre 2003 y 2005); Singapur (del 12° al 7°

lugar entre 2003 y 2005) y; Malta (del 27° al 21° lugar entre 2003 y 2005), estas posiciones, se

pueden apreciar en la Tabla 3.

Lugar País Índice

1 Estados Unidos 0.9062

2 Dinamarca 0.9058

3 Suecia 0.8983

4 Reino Unido 0.8777

5 Republica de Corea 0.8727

6 Australia 0.8679

7 Singapur 0.8503

8 Canadá 0.8425

9 Finlandia 0.8231

10 Noruega 0.8228

11 Alemania 0.8050

12 Holanda 0.8021

13 Nueva Zelanda 0.7987

14 Japón 0.7801

15 Islandia 0.7794



16 Austria 0.7602

17 Suiza 0.7548

18 Bélgica 0.7381

19 Estonia 0.7347

20 Irlanda 0.7251

21 Malta 0.7012

22 Chile 0.6963

23 Francia 0.6925

24 Israel 0.6903

25 Italia 0.6794

26 Eslovenia 0.6762

27 Hungría 0.6536

28 Luxemburgo 0.6513

29 Republica Checa 0.6396

30 Portugal 0.6048

31 México 0.6061

32 Letonia 0.6050

33 Brasil 0.5981

34 Argentina 0.5971

35 Grecia 0.5921

36 Eslovaquia 0.5887

37 Chipre 0.5872

38 Polonia 0.5872

39 España 0.5847

40 Lituania 0.5786

41 Filipinas 0.5721

42 Emiratos Árabes Unidos 0.5718

43 Malasia 0.5702

44 Rumania 0.5704

45 Bulgaria 0.5605

46 Tailandia 0.5518

47 Croacia 0.5480

48 Ucrania 0.5456

49 Uruguay 0.5387

50 Federación Rusa 0.5329

TABLA 3. Clasificación a nivel mundial, fuente: “Índice Global de Preparación para el Gobierno Electrónico” de la ONU

La comparación de las posiciones obtenidas en los reportes del 2006, 2005 y 2004 para América

Latina y El Caribe, es la que se muestra en la siguiente tabla (tabla 4). En ella es relevante apreciar

que la comparación entre los reportes del 2004 y 2006, solo Chile y el El Salvador han logrado

avanzar, ambos en 3 posiciones. México en este mismo período retrocedió en 11 lugares y Brasil

en 13. Muy impactantes resultan el caso de República Dominicana, Paraguay y Argentina que

cayeron 32, 22 y 21 lugares respectivamente.



Posición Variación Variación País

2005 2004 2003 2004 a 2005 2003 a 2005

Chile 29 35 32 6 3

Brasil 52 46 39 -6 -13

Jamaica 54 49 53 -5 -1

México 55 50 44 5 -11

El Salvador 59 70 62 11 3

Colombia 62 66 60 4 -2

Uruguay 65 64 54 -1 -11

Panamá 66 69 58 3 -8

Costa Rica 69 61 49 -8 -20

Argentina 71 76 50 5 -21

Venezuela 81 84 72 3 -9

Perú 85 90 70 5 -15

República Dom 89 78 57 -11 -32

Guatemala 98 88 86 -10 -12

Honduras 100 97 98 -3 -2

Ecuador 107 95 89 -12 -18

Bolivia 109 99 90 -10 -19

Nicaragua 112 103 94 -9 -18

Paraguay 113 98 91 -15 -22

TABLA 4. Comparación de las posiciones obtenidas en los reportes del 2006, 2005 y 2004 para América Latina y El Caribe. Fuente: Informes del Global Information Technology Report de años anteriores.

A partir de la revisión de los principios del eGobierno, la administración del entonces presidente de

la republica Vicente Fox Quesada, implementó un plan de seguimiento para el desarrollo de las

tecnologías del gobierno electrónico al interior de todas y cada una de las dependencias, el plan

denominado “Agenda del Buen Gobierno” fue apoyado por el premio “INNOVA” cuyo objetivo

era incentivar y motivar a las dependencias de gobierno a implementar lo mejor de los proyectos

tecnológicos e innovadores en materia de gobierno electrónico.

A su vez, se designó a un comité (figura 11) que se encargaría de planear la interoperabilidad de

las distintas dependencias de gobierno, quedando plasmado todo ese conjunto de ideas e

iniciativas en un documento cuyos puntos importantes a cubrir eran:



� Lineamientos técnicos y administrativos.

� Programa de expansión de servicios.

� Convenios por Áreas Jurídicas de participantes.

� Etapa de instalación y pruebas.

Figura 11. Comité de Interoperabilidad Fuente: SFP- Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información

Durante la administración del gobierno pasado, se logró incrementar en gran medida el uso de los

servicios electrónicos disponibles en Internet, gracias a la promoción que continuamente se hizo en

medios de comunicación para promover el uso de servicios automatizados.

Entre los más utilizados podemos ver los del portal de INFONAVIT, los portales del gobierno del

Distrito Federal para el pago de servicios y de otros estados como Nuevo León y el Estado de

México, cuyos portales cuentan actualmente con una gran cantidad de servicios disponibles.

La figura 12 muestra el crecimiento en el uso de Internet en nuestro país en parte debido al

incremento de servicios disponibles en la red.



Figura 12. Número de usuarios de Internet en México Fuente: Secretaria de Comunicaciones y Transportes SCT

2.2.4 Normativas existentes para el gobierno electrónico

Como parte del proyecto de gobierno electrónico, se decidió crear un organismo que administrara

las normas y reglamentaciones de las nuevas tendencias administrativas en materia de gobierno

electrónico, de esta forma surgió la Normateca.

La Normateca Federal se sustenta en el Acuerdo para la difusión y transparencia del marco

normativo interno de la gestión gubernamental, emitida en conjunto por la Secretaria de Hacienda y

Crédito Público y la Secretaría de la Función Pública; su publicación se llevó a cabo el 6 de

diciembre del 2002 en el Diario Oficial de la Federación.

Las disposiciones que se pueden encontrar en la Normateca Federal, son aquellas de aplicación

general que rigen la operación y funcionamiento de las dependencias y entidades del Gobierno

Federal. Las disposiciones del Gobierno Federal se encuentran organizadas por materias y estas

son: las referentes al Servicio Profesional de Carrera, Recursos Humanos, Presupuestales, las de

Adquisiciones y Arrendamientos; Obra Pública, Transparencia y Bienes muebles.

Actualmente las leyes mexicanas no han logrado rebasar la barrera de los problemas políticos y

disputas por el poder, sin embargo, se ha logrado plasmar un plan de trabajo que contempla

normar la mayor parte de los procesos administrativos y de los servicios que se ofrecen a la

población en general.

De esta manera, se ha podido llevar a cabo una diversificación de canales que aunque no están

100% normadas o legisladas, se han llevado al plano del modelo de gobierno electrónico, como

ejemplo, podemos mencionar algunos de los servicios que más renombre han tenido en los últimos

años:



� Obtención de la CURP (Clave Única de Registro de Población).

� Realización de citas con el SAT (Servicio de Administración Tributaria).

� Consultar seguimiento en Chambanet (portal de bolsa de trabajo del gobierno).

� Consultar seguimiento en trabajaen.gob.mx, bolsa de trabajo para el Servicio Profesional

de Carrera (SPC).

� Seguimiento a licitaciones en Compranet.

� Avisar fallas de luz.

� Seguimiento de solicitudes de información en el IFAI (Instituto Federal de Acceso a la

Información).

� Citas con el ISSSTE (Instituto de Seguridad y Servicios Sociales de los Trabajadores del

Estado).

� Consulta de calificaciones (SEP – Secretaría de Educación Pública).

� Becas de la Secretaría de Relaciones Exteriores.

� Becas Crédito CONACYT (Consejo Nacional de Ciencia y Tecnología).

� Directorio de Librerías EDUCAL.

2.2.5 Avances y logros significativos

Aún y con todos los problemas de una labor tan complicada, innovadora y transversal, México ha

logrado una serie de avances muy significativos. Entre los más destacados se encuentran los

siguientes:

� Centros Comunitarios Digitales: Para brindar mayor acceso a las comunidades rurales

remotas, la Secretaría de Comunicaciones y Transportes por medio del programa eMéxico,

ha logrado abrir cerca de 10,000 puntos de acceso a Internet en centros comunitarios

unidos por la red satelital.

� Portal Ciudadano del Gobierno Federal: el Gobierno Federal reúne en un solo portal

todos los servicios y páginas web de las dependencias federales del gobierno con

información para los ciudadanos y contenidos orientados al tipo de usuario (jóvenes,

agricultores, migrantes, adultos de la tercera edad, discapacitados, empresarios, etc.).

www.presidencia.gob.mx , así como www.gob.mx .

� Transparencia y acceso a la información: Por medio de un sistema desarrollado de

manera conjunta entre el Instituto Federal de Acceso a la Información Pública (IFAI –

www.ifai.gob.mx ) y la Secretaría de la Función Pública (SFP- www.sfp.gob.mx), los

ciudadanos pueden solicitar cualquier información pública en posesión del Gobierno

Federal en cualquier momento y en cualquier lugar. El marco legal permite un uso eficiente



del sistema y obliga a los funcionarios a rendir cuentas a los ciudadanos y a fomentar la

confianza en las instituciones públicas.

� Licitaciones electrónicas: Desde el año de 1996, México ha usado exitosamente el

sistema en línea COMPRANET (www.compranet.gob.mx) para publicar licitaciones, licitar y

administrar las contrataciones del sector público. Más de la mitad de las compras públicas

del Gobierno Federal se hacen a través de COMPRANET, y el sistema ha sido actualizado

recientemente.

� Servicios de salud: El Instituto Mexicano del Seguro Social (IMSS – www.imss.gob.mx) es

una de las organizaciones públicas más avanzadas en materia de e-gobierno en México.

Gran parte de sus procesos internos han sido redimensionados y reestructurados por

medio del uso estratégico de TICs, los registros de sus pacientes están todos en bases de

datos en línea que permiten a los médicos hacer comparaciones inmediatas de casos

similares y tener un acceso inmediato al historial médico de un paciente; el sistema de

rendición de cuentas de las compras del IMSS y el registro en línea de los almacenes

médicos permiten un uso eficiente de los recursos de salud para los ciudadanos.

� Créditos financieros y servicios crediticios: Tanto Nacional Financiera como el Instituto

Nacional para el Fomento a la Vivienda de los Trabajadores (INFONAVIT –

www.infonavit.gob.mx) han revolucionado sus sistemas de administración y de aprobación

de créditos para particulares y empresas, lo cual ha resultado en una explosión de créditos

apoyado por la baja en las tasas de interés y el mejor tiempo de procesamiento de los

créditos a particulares.

� Administración tributaria: El Servicio de Administración Tributaria (SAT-

www.sat.gob.mx) y la Secretaría de Hacienda y Crédito Público (SHCP –

www.shcp.gob.mx) han modernizado los sistemas impositivos fiscales y han recortado los

procesos y tiempos para hacer declaraciones patrimoniales y fiscales en línea.

� Tramites y procesos administrativos: Han existido avances significativos en el Sistema

de Apertura Rápida de Empresas (SARE), que gestiona la Secretaría de Economía y del

Registro Único de Personas Acreditadas (RUPA) a cargo de la Secretaría de la Función

Pública, la Secretaría de Hacienda y Crédito Público y la Secretaría de Economía. Por

medio de ese sistema y este registro se hacen más eficientes los procesos y trámites para

abrir y registrar un negocio y se evita la duplicación y replicación de funciones, atribuciones

y tareas entre órganos públicos con competencias similares.

� Otros servicios informativos en línea como TRAMITANET (www.tramitanet.gob.mx),

DECLARANET (www.declaranet.gob.mx), y el Orden Jurídico Nacional publican

información detallada para ayudar a los ciudadanos en sus trámites.



2.2.6 Retos y desafíos del e-Gobierno en México

A pesar de estos avances, México enfrenta grandes retos en materia de e-Gobierno para el futuro,

entre los cuales se pueden destacar:

� La brecha digital: El mayor rezago y el reto más desafiante en México sigue siendo la

brecha digital. Según la Asociación Mexicana de Internet, 17 millones de mexicanos tienen

acceso a la red de redes. Pocos ciudadanos tienen acceso a Internet y a los servicios en

línea, la alfabetización digital es mínima y sufre de brechas generacionales,

socioeconómicas y de género, el gobierno digital no ha logrado penetrar en todos los

hogares mexicanos. Los beneficios de la modernización y del gobierno electrónico sólo han

impactado a la mayoría de los ciudadanos indirectamente (es decir, reducción de costos

globales de operación del Estado) y los beneficios directos sólo han llegado en general a

una población con acceso, con mayor nivel de educación y en su gran mayoría urbana. El

parámetro de impacto y de éxito de cualquier política pública destinada a la provisión de

servicios electrónicos es la brecha digital, y gran parte de los esfuerzos de cualquier

administración deberá de orientarse a reducirla. Asimismo, la población reducida de

usuarios no debería de ninguna manera constituir una condicionante para enfocar los

esfuerzos en los procesos internos del gobierno; al contrario, el e-Gobierno es un asunto

de los ciudadanos para los ciudadanos y deberá de enfocarse a ellos.

� Marco Legal: La incertidumbre jurídica, los vacíos legales, la inseguridad patrimonial y la

tramitología afectan la competitividad y el desempeño de las políticas informáticas y el e-

Gobierno, especialmente cuando éstas se vinculan con la necesaria participación de la

iniciativa privada. A ello habría que sumar los rubros de protección al consumidor para

compras en línea, la lucha contra delitos electrónicos como fraude o pornografía infantil y

de protección, confidencialidad y seguridad de datos personales. Asimismo, la

normatividad legal para el buen desempeño gubernamental no depende sólo del Ejecutivo

Federal sino también de las reformas legales que deben realizar los Estados de la

República. No existe en este rubro una visión conjunta de los tres órdenes de gobierno.

Las leyes que regulan las inversiones multianuales y la licitación, el arrendamiento y las

compras del sector público también podrían beneficiarse de cambios que les permitan

hacer un uso aún más eficiente de los recursos del Estado para cumplir con sus funciones.

� Integración del gobierno y colaboración entre dependencias: México es un país que

ha promovido fuertemente la innovación de sus dependencias gubernamentales, que ha

creado incentivos al reconocer a quienes desarrollen soluciones propias e innovadoras por

medio de reconocimientos presidenciales (tales como los Premios Innova), además de un



sistema de evaluación y de gestión que favorece la negociación de metas individuales

entre el Presidente y sus Secretarios y premia la obtención de metas previamente

negociadas. Esta orientación a resultados es lo que ha impulsado las acciones del

Gobierno Federal y ha permitido también ver resultados concretos de manera inmediata.

Sin embargo, también ha llevado el costo oculto de promover el trabajo individual y la

competencia entre Secretarías, lo cual va en contra del objetivo último del gobierno

electrónico: crear un gobierno amigable con una ventanilla única, integrado y a disposición

del ciudadano.

Dada la falta de un programa en esta dirección y de incentivos para promover proyectos de

integración y de colaboración, los casos de integración gubernamental y de colaboración

son excepcionales. Aunado a este reto de colaboración entre entidades del Gobierno

Federal se encuentra el mayor reto de colaboración entre distintos niveles de gobierno: el

panorama municipal es sumamente diverso y el universo es muy vasto.

Uno de los grandes retos en materia de e-Gobierno en México es integrar al Gobierno en

su totalidad con una misma arquitectura armonizada, desarrollar incentivos para fomentar

la colaboración e institucionalizarla como práctica en la gestión y diseño de proyectos y

constituirse como una herramienta capaz de unir todos los esfuerzos de los actores

involucrados en el gobierno electrónico.

� Desarrollo de indicadores de evaluación y monitoreo: Otro gran reto es el de

desarrollar indicadores para medir el desempeño del e-Gobierno y para así justificar

inversiones, rendir cuentas a los ciudadanos, y tomar mejores decisiones con base en un

conocimiento detallado del terreno donde opera el gobierno electrónico.

Existen pocos indicadores efectivos a nivel mundial y las prácticas internacionales aún no

han explorado lo suficiente este campo para prestar lecciones al gobierno de México. Sin

embargo, este tema operativo no debe dejarse de lado debido a que fortalece la

justificación de inversiones por medio de casos de negocio sólidos, permite una operación

más fluida con el Congreso para la autorización de presupuestos al simplificar el caso de

una inversión para demostrar claramente sus resultados y permite también evaluar el

desempeño de un proyecto o una iniciativa.

� Habilidades y capacitación de funcionarios públicos: México ha hecho algunos

avances en materia de capacitación de funcionarios públicos en el desarrollo de

capacidades técnicas para el uso de las TIC. Sin embargo, el desarrollo y la

implementación de proyectos estratégicos de e-Gobierno requiere más que el

conocimiento básico de la tecnología, también requiere de una formación sólida en los

conceptos de la administración pública, el marco legal, la negociación política de objetivos

y presupuestos, la gestión financiera y las atribuciones operativas de unidad administrativa.



Entre más funcionarios conozcan los riesgos, los costos, las oportunidades y el potencial

del gobierno electrónico, mejor estarán adaptados para desarrollar proyectos propios que

tomen en cuenta el funcionamiento integral de una administración pública.

� Desarrollo de contenidos y participación ciudadana: A pesar de que gran parte del

esfuerzo del gobierno se ha enfocado en la creación de puntos de acceso para que los

servicios de e-Gobierno lleguen a los ciudadanos, poco se ha hecho para involucrar a los

ciudadanos en el diseño de contenidos, el acomodo de los servicios y la perfilación de los

procesos en los cuales participan. El argumento del gobierno ha sido que los servicios han

sido “agrupados” bajo un rubro o perfil de ciudadano (p. ej. “estudiantes”).

Pero una cosa es agrupar servicios y otra cosa es adaptar y reestructurar el servicio para

responder a las necesidades de un grupo en particular. Asimismo, la participación de los

ciudadanos en el diseño de políticas públicas puede ser potenciada de manera

considerable por el uso de TICs.

Sin embargo, el gobierno de México no ha hecho más que digitalizar las herramientas

tradicionales de participación ciudadana (como enviar una queja o sugerencia por correo

electrónico), cuando en realidad se podrían estar haciendo avances enormes en involucrar

a los ciudadanos en los procesos de toma de decisiones públicas, el diseño de políticas

públicas, y los modelos de retroalimentación del gobierno. Todavía hay mucho camino que

recorrer, y entre más se involucre a los ciudadanos en el uso del e-Gobierno para

proveerles soluciones, mayor será su adherencia y su aprendizaje de esta herramienta.

� Definición de metadatos y esquemas: Un claro desafío, es que el orquestador de todo el

proyecto de e-Gobierno, pueda coordinar y centralizar el gran volumen de metadatos y

esquemas, que se comenzará a definir independientemente en cada dependencia, la

lógica indicaría que si una dependencia o Secretaría crea nuevos tipos de dato, metadatos

o esquemas, esta definición puede convertirse en la oficial y estándar, para el uso de todas

las demás dependencias del Gobierno 8.

Esto resulta poco recomendable, ya que al no analizar el problema global, ni al especificar

tipos de datos, metadatos y esquemas básicos, se dificulta la reutilización y un buen

modelamiento de los datos.

8 La independencia de definición de esquemas y metadatos por cada dependencia sólo es válida cuando no exista una

definición previa o la nueva sea incompatible con anteriores.



El hecho de que metadatos y esquemas se definan después de tener aplicaciones

funcionando y no antes como ocurre en experiencias internacionales como GovTalk [gov-

talk], deja abierta la pregunta de si éste camino dará los resultados esperados

[normaXML].

� Definición formal de servicios: Para automatizar el diseño, creación, acceso, consulta y

negociación de servicios en el e-Government, ellos deben tener una especificación formal.

A pesar de que para los servicios web existe un lenguaje de descripción de servicios

(WSDL), no todos los servicios que entregan las organizaciones gubernamentales usan o

usarán esta tecnología para proveerlos. Tampoco WSDL por sí solo especifica todo lo

necesario para definir completamente un servicio web para el uso posterior de esta

información.

¿Qué funciones básicas deben de tener los servicios, qué metadatos y descripciones

deben caracterizarlos, qué guías para la creación de interfaces y mensajes son necesarias,

y que funcionalidad entrega el servicio (con el propósito de no repetir servicios)? Son

definiciones que deben ser explicitadas para aprovechar de mejor manera el potencial de

los servicios web.

A pesar que esta tarea no es indispensable para un uso funcional de los Servicios, esto sí

limita su potencial y dificulta su administración y gestión. Por lo tanto, este problema

debería ser abordado primero definiendo guías para la creación, definición y desarrollo de

servicios para el e-Gobierno, para luego aplicarlo a los servicios disponibles y a la creación

de los futuros.

� Sistema de autenticación de usuarios para ciudadanos y SSO (Single Sign On): Hoy

en día existen servicios como el pago de impuestos que pueden realizarse en línea

ingresando con un usuario y clave entregada por la dependencia responsable del servicio,

lo cuál es un avance hacia la identificación de usuarios recurrentes a los mismos servicios

en común que pueden ser agrupados en un solo portal y accedidos a través de un SSO.

Single Sign On (SSO por sus siglas en inglés) es procedimiento de autenticación que

habilita al usuario para acceder a varios sistemas con una sola instancia de identificación,

es decir, sólo una vez se registran los datos y se tiene acceso a una o varias aplicaciones.

El desafío en el mediano plazo es tener una interfaz común de autenticación a todos los

servicios y en el corto plazo una forma de autenticarse ante cada organismo de gobierno

de la misma forma.



Este trabajo ha identificado al menos las siguientes preguntas que deben abordarse para

definir un esquema de autenticación completo y exitoso.

o ¿Qué tipos de autenticación estarán disponibles (usuario y clave, token, otro)?

o ¿Cual será la validez legal que tendrán los distintos tipos de autenticación en los

servicios?

o ¿Se debe usar una o varias claves? Por ejemplo si se usa una clave por servicio y

se quiere permitir un esquema de SSO, se pueden definir claves maestras.

o ¿Que institución tiene la autoridad para autenticar?

o ¿Existirá la posibilidad de que los ciudadanos puedan personalizar los servicios

que quieren utilizar mediante autenticación con su usuario y clave y cuales no?

o ¿Se permitirá que agentes de otros sistemas fuera del gobierno, como los bancos

puedan usar los servicios de autentificación del gobierno y viceversa?

� Coordinación en la definición de servicios por parte de dependencias de Gobierno:

Se debe procurar no repetir servicios y asegurar que los existentes no se contradigan en

su funcionamiento o sean inconsistentes. Este desafío tiene la misma vigencia que el de la

definición de metadatos y esquemas, en el sentido que se deben definir herramientas y

mecanismos para administrar la existencia, definición de funcionalidades y uso de los

servicios. Una posible solución a este problema puede ser el uso de un UDDI semántico

(directorio semántico de servicios web) como el presentado en [frez-ws-admin].

� Depósitos: El uso de depósitos que mantengan datos sobre ciudadanos ya sean públicos,

reservados o privados, datos sobre los procedimientos mismos del gobierno,

comunicaciones entre dependencias, u otros deben definir:

a) Propiedad/Autoridad: Si cada dependencia tiene acceso y administra sólo sus

propios depósitos:

o ¿Quién tiene la autoridad de generar datos y resúmenes?

o ¿Quién se ocupa de la corrección y actualización de información y de que

se propague a quienes corresponda?

o Si una dependencia obtiene información de otras, ¿Tiene ella la autoridad

para presentar tal información frente a terceras personas (dependencias u

organismos) como la fuente? (delegación de autoridad).

Ejemplo: Secretaría de Salud al obtener consolidados de nacimientos y

defunciones en Hospitales, y Secretaría de Hacienda al hacer el

seguimiento de documentos y requisiciones de presupuesto.



b) Centralización/distribución: Por temas de eficiencia, facilidad para actualización

de información, disponibilidad, entre otras:

o ¿Qué tipo de información debería centralizarse? Los datos de los procesos

o ciudadanos, la descripción formal de servicios, información para

autenticación?

o Si alguna dependencia necesita información confidencial obtenida por

otras dependencias, ¿Cuál es la mejor arquitectura en cuestiones de

seguridad? ¿Es escalable esta opción?

o ¿Es mejor mantener los depósitos en cada dependencia y crear los

canales de comunicación entre ellas, o crear BD centralizadas? ¿Es

escalable la solución?

� Mantenibilidad de estándares: Las leyes existentes y aquellas que puedan crearse con el

fin de tener una normatividad en el e-Gobierno en México pueden requerir modificaciones,

por ejemplo las normas de seguridad o exigencias sobre el documento electrónico, la firma

electrónica avanzada, las transacciones de información segura, etc.

Crear, mantener y actualizar estas definiciones y hacerlas compatibles con las existentes

requiere un esfuerzo del Gobierno y demás entidades relacionados [normaXML].

� Migración de Información: Debido a la existencia de sistemas computacionales que no

usan XML y debido a toda la documentación existente sólo en papel, se requiere una forma

de migrar esa información [normaXML].

Esta migración ya está en proceso mediante la digitalización de algunos documentos, sin

embargo, no todas las migraciones involucran pasar a un formato XML sino que algunas

corresponden a la obtención de imágenes digitales de los documentos.

Los desafíos consisten en:

o Comenzar a generar pronto la información en formato XML para no tener que

seguir migrando cada vez mayores cantidades de información.

o Hacer interoperar la información migrada con los servicios que se entregan o

desarrollarán en el futuro. Por ejemplo, agregando metadatos como un

identificador del folio y el trámite asociado a documentos digitalizados como

imágenes.

o Crear transformaciones sobre los depósitos de datos ya existentes para generar

documentos en XML (paso del modelo relacional, orientado a objetos, u otro, a

documentos en XML).



� Sumar al esfuerzo del e-Gobierno a todas las dependencias del Estado: Hacer

partícipes a todas las instituciones gubernamentales en el e-Gobierno, involucra la

consideración de todas ellas para el rediseño de procesos, entrega de servicios y

comunicación de información.

Para el caso de las instituciones con menos recursos o que no cuenten con la tecnología

adecuada tales como Municipios, Hospitales o Universidades, se debe elegir un modelo

donde a estas entidades también se les incorpore al mundo del e-Gobierno.

La definición de arquitectura, plataforma, software de aplicación, flujos documentales,

tecnologías, guías para desarrollo de servicios, metadatos y esquemas, deben ser

especificadas para reutilizar el conocimiento adquirido (replicar soluciones) y agilizar el

desarrollo del e-Gobierno.

Para esto, se deben realizar experiencias exitosas que dicten las pautas de desarrollo,

para lo cual los planes pilotos acotados que no tengan un alto riesgo debido a las

dimensiones del proyecto resultan una buena alternativa.

Como siguientes pasos en el desarrollo del e-Gobierno en México, se propone la

experimentación mediante planes piloto o proyectos de mediana envergadura por

encima del desarrollo de soluciones globales. Esto se fundamenta en los siguientes

puntos:

o A pesar de que existen desarrollos exitosos en otros países, no hay una gran

madurez en experiencias internacionales a manera de apoyar el desarrollo en

México.

o Un proyecto de gran envergadura involucra la coordinación de muchas

instituciones que agrega un factor de incertidumbre y complejidad, que podría ser

postergado luego de que se abordaran problemas anteriores como

interoperabilidad, estandarización de tipos de datos, entre otros.

o Durante el desarrollo de la solución se deben especificar un número no

despreciable de nuevas definiciones como esquemas XML, API de servicios y

metadatos. En México no existe mucha experiencia al respecto y no es claro que

este desarrollo pueda ser llevado a cabo en los plazos estipulados.

o Los puntos anteriores representan factores de incertidumbre que según la

experiencia de la Ingeniería de Software requieren ser disminuidos o eliminados,

antes de continuar con iniciativas tan complejas como lo es la implantación del e-

Gobierno.



2.2.7 Iniciativas principales para e-Gobierno en México.

El proyecto de e-Gobierno y de Innovación Gubernamental de la anterior administración (sexenio

de Vicente Fox) y por consiguiente de la administración actual, puede correr el riesgo de seguir un

ciclo de concepción, nacimiento, desarrollo y muerte. Existen varias dependencias que han sido

exitosas en materias de e-Gobierno tales como: el Servicio de Administración Tributaria (SAT), el

Instituto Mexicano del Seguro Social (IMSS), la Secretaría de Relaciones Exteriores (SER),

Nacional Financiera (NAFINSA), el Banco de Comercio Exterior (BCE), el Instituto de Fomento

Nacional a la Vivienda de los Trabajadores (INFONAVIT) y la Secretaría de la Función Pública

(SFP), por mencionar los casos más conocidos del ámbito Federal y sin tomar en cuenta el amplio

éxito que han tenido algunas administraciones estatales y municipales, sin embargo, su

consolidación y trascendencia más allá de los periodos presidenciales no está exenta de riesgos si

se toma en cuenta la dinámica sexenal de siempre que termina enterrando proyectos al final de

cada sexenio.

El 9 de diciembre de 2005 se publicó en el Diario Oficial de la Federación el Acuerdo

Intersecretarial para el Desarrollo del Gobierno Electrónico, cuya aspiración era establecer un

marco de gobernabilidad para las TIC en el Gobierno Federal. El acuerdo instaló un Comité

Intersecretarial compuesto por los secretarios de Estado de la Administración Pública Federal

(APF) de ese momento, y los comprometió a nombrar un responsable del gobierno electrónico en

sus respectivas Secretarías.

Estos a su vez pasarían a integrar un Consejo Técnico, que se encargaría de normar las políticas

relacionadas con el gobierno electrónico. Sin embargo, es posible encontrar algunas dificultades de

este acuerdo, pues al no tratarse de una ley federal ni de un decreto presidencial, se considera

insuficiente para continuar en operaciones una vez terminado el sexenio.

Dado que el acuerdo comenzó a operar hacia finales del primer trimestre del 2006 es posible

pensar que el siguiente sexenio no pueda consolidar y legitimar sus operaciones.



2.3 Experiencias internacionales

Según estudios internacionales [ONU 2005, 2004] y [accenture2004], existen países tales como

Estados Unidos, Australia, Canadá y Reino Unido, que muestran un buen índice en la efectividad y

eficiencia de sus políticas de e-Gobierno, alcanzando buenas calificaciones dentro de los niveles

de madurez del gobierno electrónico.

Para el caso de los Estados Unidos, Darrell West (2005,2006) ha seguido con detalle la evolución

de los portales gubernamentales, publicando anualmente un análisis de sitios web federales,

estatales y locales. Estos reportes no solo contienen las evaluaciones de los sitios de acuerdo a

diferentes variables de interés sino que describen cómo han cambiado y qué tipo de mejorías se

han llevado a cabo en el año inmediato anterior.

Este esfuerzo anual ha permitido a los desarrolladores y a quienes toman las decisiones de

contenidos de los sitios web gubernamentales que puedan comparar sus resultados, competir

entre ellos y mejorar a través de una medición imparcial, neutra y lo más objetiva y científica

posible. Lamentablemente en México no ha existido hasta el momento un esfuerzo similar.

A pesar de los avances del e-Gobierno en algunos países, existe un bajo nivel de coordinación

transversal entre las distintas dependencias de gobierno. Esto resalta la importancia de la

definición de estándares y especificaciones, que entreguen interoperabilidad y flexibilidad suficiente

para comunicar sistemas que fueron desarrollados bajo distintas definiciones.

Estudios análogos, pero enfocados desde el punto de vista técnico para el e-Gobierno, son

escasos. A continuación se nombran algunas de las experiencias internacionales más destacadas

en el tema.

2.3.1 Reach

Reach es una institución del gobierno de Irlanda, creada para desarrollar una estrategia capaz de

integrar los servicios públicos, y un framework para el gobierno electrónico [reach]. Para ello Reach

ha diseñado e implementando (parcialmente en algunos casos), un conjunto de iniciativas en pro

de la interoperabilidad y automatización, entre las cuales se encuentran:

Interoperability Framework: Define un marco de trabajo (framework) de interoperabilidad que

considera entre los tipos de interoperabilidad la semántica, tipos de datos, etcétera.



Inter-Agency Messaging Service (IAMS): El IAMS es un servicio de mensajería donde sistemas

intermediarios o también llamados brokers, intercambian mensajes con información de los

ciudadanos entre dependencias del Estado. El IAMS ha logrado interoperabilidad y automatización

entre distintas dependencias y permite el uso de mensajería a ciudadanos.

Lamentablemente su debilidad radica en el uso de protocolos cerrados (y no todos estándares)

para el intercambio de información, con una consecuente falta de extensibilidad e interoperabilidad.

Service Integration & Interoperability: Por un lado Reach ha desarrollado un conjunto de buenas

prácticas para desarrollar servicios que puedan ser integrados concentrado en la iniciativa llamada

Reach Interoperability Guides (RIGS), definiendo recomendaciones para creación y manejo de

documentos XML, estructura de los mensajes a enviar entre otras. Por el otro lado existe un portal

para el ciudadano con un conjunto de servicios a su disposición organizados según categoría

llamado Service Index. Esta iniciativa se asemeja a la de TrámitaNET y eMéxico en nuestro país

[tramitaNET].

Public Service Broker (PSB): 9 Es un sistema que hace las funciones de intermediario entre las

dependencias del gobierno y entre ellas y los ciudadanos, permitiendo llamar de manera estándar

a los servicios públicos. El PSB es también la definición de una arquitectura e infraestructura para

integrar tales servicios.

El PSB consta de 3 componentes principales:

� Una interfaz de usuario como portal con acceso a información y servicios.

� Un middleware que permite la integración de servicios, basado en XML y servicios web.

� Una capa que ejecuta los servicios al interior de cada dependencia y se comunica con el

broker.

9 Basado en experiencias existentes hasta Mayo del 2005, Irlanda.



2.3.2 GovTalk

Una de las experiencias internacionales más desarrolladas conceptualmente y referente al e-

Gobierno, es la llamada GovTalk [gov-talk] perteneciente al Gobierno del Reino Unido. El trabajo

de GovTalk se basa en la definición de un framework (marco de trabajo) para interoperabilidad

llamado Interoperability Framework for e-Government (e-GIF de ahora en adelante).

El e-GIF define políticas técnicas y requisitos para alcanzar la interoperabilidad y coherencia entre

sistemas del sector público. Entrega un framework de los estándares recomendados para el

intercambio de información en el gobierno.

La arquitectura del e-GIF se puede ver en la Figura 13 y a continuación se realiza una breve

descripción de sus componentes.

Figura 13: Arquitectura e-GIF. Figura tomada de GovTalk [e-gif, http://www.govtalk.gov.uk/].

Metadatos en el e-GIF (e-GMS, GCL): El Government Metadata Standard (e-GMS) [e-gms] se

puede ver como una extensión a Dublín Core [dublin-core], que define un conjunto de metadatos y

esquemas básicos que sirven de base para los servicios a desarrollar. Cada servicio particular

puede agregar nuevas restricciones o quitar las que no apliquen. Por su parte el Government

Category List (GCL) define una lista de categorías (valores) para cada elemento en el e-GMS.

Government Data Standard Catalogue (GDSC): Especifica los tipos y convenciones básicas para

los datos comunes a usar en todas las dependencias del estado, usando esquemas XML.

Por ejemplo para en el caso de México se establece que uno de los estándares para el CURP es,

que debe ser una cadena (String) de 15 caracteres conteniendo números y letras con restricciones

de negocio (nomenclatura) y que describan de manera única el registro de cada uno de los

habitantes del país.



Schemas: Define buenas prácticas y guías para esquemas XML junto con casos de estudio para la

creación de esquemas. Cabe recalcar que la especificación de datos, servicios etc. Se hace a

través de esquemas XML por lo que este componente de la arquitectura es esencial.

Technical Standards Catalogue (TSC): El Catalogo de Técnicas Estándar es una definición de

tecnologías específicas sobre las cuales se recomienda se creen los servicios y definiciones que

harán posible la interoperabilidad en el e-Gobierno, el catalogo contiene las políticas técnicas del

marco de trabajo para la interoperabilidad (e-GIF), tablas de especificaciones, un glosario y una

lista de abreviaturas. Por ejemplo se menciona que para la descripción de servicios web se

recomienda usar WSDL.

E-Services Development Framework (e-SDF): Este resulta el componente más interesante para

el modelo británico, ya que provee una metodología para utilizar especificaciones y estándares de

interoperabilidad de servicios electrónicos y para el intercambio de datos y mensajes en servicios

automáticamente en el sector público.

Para ello el e-SDF define un conjunto de componentes entre los cuales están el Modelo de

referencia para mensajes de gobierno, Government Message Reference Model (GMRM) que

define un modelo de datos para los mensajes a ser intercambiados entre servicios y el Modelo para

información común de gobierno, Government Common Information Model (GCIM) que define un

modelo de datos para especificar las actividades que forman la lógica de un servicio compuesto de

varias interacciones.

Finalmente, el e-SDF define además un marco de trabajo (framework) para el desarrollo de

servicios 10

(ver Figura 14) donde se nota como usa al GCIM, GMRM y los otros componentes para

definir formalmente un servicio y llegar desde la descripción lógica del mismo, hasta una

especificación de los mensajes y datos usando esquemas XML.

10

El Framework de desarrollo se puede ver como una adaptación del Rational Unified Process (RUP).



Figura 14: Framework del e-SDF para desarrollo de nuevos Servicios. Figura tomada de GovTalk [e-gif, http://www.govtalk.gov.uk/].

2.3.3 AGLS

El Australian Government Locator Service (AGLS) Metadata Standard [agls-35,

http://www.naa.gov.au/] del gobierno de Australia, busca etiquetar los recursos (como los servicios)

con metadatos, para que las personas puedan encontrarlos de manera efectiva y eficiente, es

decir, apunta a la interacción persona-máquina. Para ello define un conjunto de 19 elementos

descriptivos que utilizan las dependencias gubernamentales australianas basadas en el estándar

Dublin Core [Dublín-core].

Además entrega guías para decidir si un recurso necesita o no metadatos, define los procesos y

etapas que se deben seguir para crear vocabularios y esquemas XML



2.3.4 Organizaciones internacionales

W3C (WWW Consortium)

El Consorcio World Wide Web (W3C) es un consorcio internacional donde las organizaciones

miembro, personal de tiempo completo y el público en general, trabajan conjuntamente para

desarrollar estándares Web. La misión del W3C es:

Guiar la Web hacia su máximo potencial a través del desarrollo de protocolos y

pautas que aseguren el crecimiento futuro de la Web.

El W3C desarrolla Estándares Web y Pautas

El W3C trata de alcanzar su objetivo principalmente a través de la creación de Estándares Web

y Pautas. Desde 1994, el W3C ha publicado más de ciento diez estándares, denominados

Recomendaciones del W3C. El W3C también está involucrado en tareas de educación y

difusión, y en el desarrollo de software, sirviendo a su vez como foro abierto de discusión sobre

la Web. Para que la Web alcance su máximo potencial, las tecnologías Web más importantes

deben ser compatibles entre sí y permitir que cualquier hardware y software, utilizado para

acceder a la Web, funcione conjuntamente. El W3C hace referencia a este objetivo como

"interoperabilidad Web". Al publicar estándares abiertos (no propietarios) para lenguajes Web y

protocolos, el W3C trata de evitar la fragmentación del mercado y, por lo tanto, la

fragmentación de la Web.

El W3C es un Consorcio Internacional

Diferentes organizaciones, procedentes de diversos puntos del mundo y de campos muy

diferentes, forman parte del W3C con intención de participar en un foro neutral para la creación

de estándares Web. Los miembros del W3C y un grupo de expertos técnicos, han hecho

posible que el W3C sea reconocido a nivel internacional por su contribución en el desarrollo de

la Web. Los Miembros del W3C (testimonios), el personal y los expertos invitados trabajan

juntos para diseñar tecnologías, con el objetivo de asegurar que la Web continuará creciendo

en el futuro, adaptándose a la creciente diversidad de personas, hardware y software.

Entre las iniciativas globales del W3C se encuentra la de mantener sus asociaciones con

organizaciones nacionales, regionales e internacionales en todo el mundo. Estos contactos

ayudan al W3C a establecer una cultura de participación global en el desarrollo de la World

Wide Web. El W3C ha establecido una colaboración especialmente estrecha con otras



organizaciones que están desarrollando estándares para la Web o para Internet con intención

de facilitar el progreso. El documento sobre Participación Mundial en el Consorcio World Wide

Web resume los esfuerzos del W3C por ampliar su impacto internacional; para obtener más

información visite la página principal de relaciones internacionales.

OASIS

OASIS es uno de los consorcios que produce más especificaciones relacionadas con servicios

web. Los temas de las especificaciones tratan temas de seguridad, entrega confiable de mensajes,

notificación, descubrimiento e invocación y modelado de procesos de negocio.

OASIS también apuesta a la adopción de estándares y creación de patrones y guías con mejores

prácticas, enfocados a las necesidades particulares del e-Government. Algunos temas en este

ámbito son: interoperabilidad semántica, flujos de trabajo (workflows), servicios web, junto con los

otros estándares de OASIS.

A pesar de que las guías en temas de e-Gobierno están en constante actualización, las otras

especificaciones técnicas que ofrecen, resultan importantes debido a su madurez y alto soporte por

parte de la industria.

2.4 Otras experiencias de integración en México.

Existen otras organizaciones que no abordan explícitamente el problema del e-Gobierno, pero si

tecnologías o estándares que lo impulsan. Entre ellas están la W3C (World Wide Web Consortium)

que se menciono anteriormente y la WS-I (Web Services Interoperability Organization,

http://www.ws-i.org). Por un lado la W3C desarrolla recomendaciones Web y guías, entre las

cuales se encuentran XML, XML Schema, SOAP, WSDL y modelos sobre la arquitectura Web.

Por su parte, la WS-I crea, promueve y soporta protocolos genéricos para el intercambio de

mensajes de manera interoperable usando servicios web. Además desarrolla guías y prácticas

recomendadas, para implementar servicios web interoperables.



2.4.1 Experiencias ERP Telcel – Oracle.

Radio Móvil DIPSA -Telcel, una empresa de telefonía celular líder en el mercado de dicho ramo,

realizó a principios del año 2002 una serie de acciones con el propósito de colocar a la empresa en

la cúspide de las comunicaciones por vía celular, la entrada en México de la tecnología GSM para

celulares de 3ª generación provocó que la empresa buscara posicionarse como la primera en

incorporar celulares con cámara fotográfica, transmisión de datos, voz y multimedia, iniciando así

una gran campaña con la promoción de la nueva generación de celulares GSM.

Al interior de la organización, esto derivo en que se redefinieran estructuras organizacionales y que

las distintas áreas entraran en un proceso de mejora continua, con la incorporación de la

planeación estratégica y de la filosofía de la certificación ISO-9000, se definieron los pasos a seguir

para entrar todos en un proceso de mejora continua.

En los meses subsecuentes se definió una Misión, Visión, Metas y Objetivos en todos los niveles

organizacionales, que motivaron a toda la empresa a realizar procesos de calidad y buscar la

certificación ISO-9000 para poder tener un respaldo de su nueva política de calidad y posicionarse

mejor en el mercado.

En este contexto de entrar en un proceso de mejora continua, se tomó la decisión de reemplazar

los sistemas obsoletos o que en su momento representaban un dolor de cabeza, por el

mantenimiento que requerían y por la serie de problemas que traían arrastrando de tiempo atrás.

Dentro de los sistemas que se tomó la decisión de renovar se encontraba el sistema de NOMINA,

el cuál era un desarrollo hecho por un proveedor externo que en su momento implemento dicho

sistema en una plataforma UNIX, trabajando con Informix y lenguaje 4GL para las pantallas y la

operación.

Se lanzó así un concurso para la compra de un ERP el cuál dentro de sus módulos contemplara la

administración de todos los módulos que comprendía la nómina a su alrededor; después de varios

meses de presentaciones con distintos proveedores (ORACLE, PeopleSoft, Meta4, SAP, Unisys,

entre otros), el comité tomó una decisión y la ganadora fue PeopleSoft, sin embargo por razones

de mercadotecnia y debido a la compra de ORACLE de la mayoría de las acciones de PeopleSoft,

se decidió cambiar de última hora a ORACLE.

En un principio, el proveedor prometió cubrir un 80% de la operación de nómina, incluyendo la

administración de reclutamiento de personal, capacitación, administración de parque vehicular,

directorio activo de la empresa y 6 módulos más que tenían que ver con la administración de los



recursos humanos y empresariales, además de que en un plazo de 6 meses el sistema estaría

implementado a un 90% gracias a que su producto era totalmente adaptable, modificando pocos

módulos y en poco tiempo.

La implementación dio inicio a mediados del mes de Julio de 2004 con la promesa de que entraría

en producción a principios del siguiente año, sin embargo, al poco tiempo se comenzaron a aplazar

fechas debido a que los propios consultores de ORACLE determinaron que no eran factibles sus

fechas de entrega por la complejidad del negocio, la poca adaptación del sistema al entorno de las

demás áreas que pretendía cubrir, sumando además la poca experiencia de algunos consultores

en la implementación de ERP´s y su desconocimiento del negocio por completo.

La compra del equipo fue un gasto que pareció ser un gasto excesivo dado que la aplicación

requería de una infraestructura bastante robusta que no alcanzaba a cubrir la empresa con los

recursos que tenía.

De los puntos que se encontraron al corte de diciembre de 2006, se pudo resumir que el producto

no cubría más de un 30% del negocio de la empresa, a consecuencia principalmente de los

siguientes motivos:

� El producto resulta ser muy complejo de entender y usar.

� El producto requiere cambios en la organización de la compañía y procesos para su

instalación.

� La capacitación sobre el uso del producto resulta ser muy pobre para el usuario.

� La operación se volvió más lenta en comparación con el producto anterior (Informix 4GL).

Por otro lado se encontraron algunas ventajas como:

� Se tiene un solo sistema para el manejo de muchos procesos organizacionales.

� Se integran las funciones de varias aplicaciones.

� Reduce los costos de la gerencia

Esto no ha sido suficiente para el comité evaluador de la implementación que aún a fechas del

presente trabajo siguen en estatus de espera para poder pasar a un ambiente de producción. Para

arreglar estos problemas, las compañías a menudo pierden de vista el hecho de que los sistemas o

paquetes ERP no son más que unas representaciones genéricas de las formas típicas de hacer

negocio en las empresas. Mientras que la mayoría de los paquetes son exhaustivamente

integrales, cada industria tiene sus características que lo hacen único.

Esto demuestra un poco lo que se presento hacia el final del primer capítulo de este trabajo de

tesis, donde se menciona y se grafica en la figura 8 lo que se requiere para el éxito de un proyecto



ERP, conocimiento del sistema de ERP(que no se tuvo en este caso) y conocimiento detallado

sobre el proceso de negocio (el cuál no se presento por parte de los consultores de Oracle).

Si bien es posible rescatar que algunos de los procesos del área de Recursos Humanos se salvan

de la mala implementación del sistema ERP, también es importante mencionar que en el proceso

de adaptación, se hicieron trabajos de integración de otros sistemas (desarrollo de interfaces) para

poder solventar el problema que no pudo resolver el sistema ERP.

El desarrollo de dichas interfaces no requirió de mucha inversión, dado que la mayoría de ellas se

hicieron bajo el esquema de software libre de licenciamiento, con tecnologías como CORBA, COM

y servicios web.

Un caso en particular de las interfaces desarrolladas con servicios web, fue la del área de sistemas

corporativos que requirió de un servicio que al invocarse devolviera los datos principales de un

empleado tales como: número de empleado, nombre, puesto, sueldo mensual y antigüedad para

realizar procesos administrativos y organizacionales de la empresa.

En el caso particular de esta empresa privada, podemos ver que no siempre la implementación de

un sistema ERP resuelve todas las necesidades de integración de aplicaciones,

independientemente de las razones por las cuales no se tuvo éxito, cabe destacar el uso de otras

tecnologías que cubren en gran medida los requerimientos de integración de aplicaciones, a un

menor costo y con menos infraestructura de la que se pretende para un sistema tan complejo como

un ERP.

2.4.2 Experiencias ERP SAT – PeopleSoft

A principios del año 2005, el Servicio de Administración Tributaria (SAT) comenzó la

reestructuración de su plataforma tecnológica motivada por la implementación de las nuevas

políticas del gobierno electrónico y el ahorro de papel del entonces presidente Vicente Fox

Quesada. Así pues, se dio inicio al proyecto “PLATAFORMA tecnológica” para implementar un

portal único y más ágil para la administración tributaría, el cuál permitiría recaudar una mayor

cantidad de impuestos, al ser más flexible y más rápida en respuesta que una administración local.

Para tal proyecto, se lanzó la licitación para que fuera desarrollada la solución por un proveedor

que tuviera la capacidad de cubrir la mayor cantidad de negocio que tenía en ese momento la

dependencia. Finalmente el ganador resultó ser el ERP de la empresa PeopleSoft, que inicio de

inmediato sus actividades para poder llevar a cabo una pronta implementación comenzando a

interactuar con las áreas de negocio (Soluciones de Negocio y Asistencia al Contribuyente) de la



propia dependencia. En poco tiempo comenzaron a aparecer una gran cantidad de proveedores

para poder sacar adelante la “SOLUCION INTEGRAL SAT”, entre ellos, Jack Be México, Oracle,

Hewlett Packard, Documentum y otros más que en su momento intervinieron para el desarrollo del

producto.

Al poco tiempo, se definieron grupos de trabajo para interactuar de mejor forma entre la

dependencia y el proveedor, sin embargo, el proceso de integración no llevo un adecuado control,

lo cual derivó en una serie de retrasos por parte de los proveedores al argumentar que el negocio

era difícil de implementar de la misma forma a como ya estaba solucionado, dado que las

herramientas de desarrollo que se promovieron no tuvieron la adecuada medición del alcance que

tenían para solventar la operación tan robusta de la tecnología anterior.

Con estos inconvenientes, se optó por retrasar el proyecto y solventar la recaudación de impuestos

para los años 2006 y 2007 con las tecnologías y metodologías tradicionales, las cuales contaban

con un rendimiento comprobado en los ejercicios anteriores, sin embargo, se reanalizó la situación

que provocó el retraso en la salida de la “SOLUCION INTEGRAL” llegando a la conclusión de que

la mejor solución sería aquella que interactuara entre la robustez de la tecnología anterior y la

flexibilidad de las nuevas propuestas, es decir el desarrollo de interfaces.

Con este nuevo análisis de la situación se optó por la inclusión de servicios web para la interacción

entre dichas plataformas (la actual y la nueva) a fin de soportar una operación de gran tamaño, sin

dejar de lado la nueva propuesta de un portal único

Nuevamente la intención de citar el caso de un sistema de ERP que no prospero ahora en el sector

público, es citar el uso de tecnologías alternas que implican un menor gasto en recursos y un

aprovechamiento más óptimo de la infraestructura con la que cuentan las organizaciones.

Esto nos lleva de nuevo a ver que las soluciones alternas a los grandes productos para la

integración de aplicaciones, vuelven a ser tecnologías abiertas como los servicios web y

desarrollos hechos en casa (internamente hablando de la organización), que son mejor

implementados por el personal con experiencia y conocimiento del negocio.

Dejando de lado las razones por las cuales pueda fallar o no la implementación de un ERP u otro

producto comercial de alto costo, es posible ver que existen tecnologías alternas que han tenido

éxito en la solución de problemas muy particulares como el de la integración de aplicaciones, uno

de estos caminos alternos que han tenido éxito y gran aceptación es el uso de los servicios web.



Capítulo

3 Conceptos, Tecnologías de Información y Servicios Web

Este capítulo presenta las bases teóricas de las tecnologías usadas para resolver el

problema de la integración de aplicaciones, menciona los aspectos a tomar en

cuenta para determinar el uso o no de servicios web, y los conceptos necesarios

para entender el contexto bajo el cuál se puede trabajar una solución basada en

tecnologías alternas.



3 Conceptos, Tecnologías de Información y Servicios Web. 3.1 Conceptos Básicos El término Gobierno electrónico nace en la década de los 90 como una manera de describir el

quehacer del gobierno apoyado por las nuevas Tecnologías de Información y Comunicación (TIC)

en pro del incremento de la eficiencia y efectividad de las funciones gubernamentales

Es necesario enfatizar que la finalidad del gobierno electrónico, no es “tecnologizar” los procesos

existentes tal cual están hoy sino replantear los procesos y servicios del gobierno, con el fin de

mejorarlos y ponerlos al servicio del desarrollo de una nueva sociedad de la información. Para

mejorar la eficiencia y efectividad de los servicios que brinda el Estado, resulta importante

automatizar los procesos internos, las relaciones entre ellos y los procesos externos.

� El concepto de automatización, se define como la acción de automatizar una actividad por

parte de un sistema que se regula por sí mismo, eliminando la intervención de agentes

externos que constituyen la principal razón de errores en un proceso, como puede ser la

intervención de la mano del hombre.

� Automatizar. Aplicar a una industria máquinas o procedimientos automáticos [Diccionario

de la lengua española].

Para la definición de servicio podemos mencionar algunas fuentes para comprender mejor el

enfoque en el ámbito de los sistemas de información.

� En economía y mercadotecnia (marketing) un servicio es el equivalente no material de un

bien. La prestación de un servicio no resulta en posesión y así es como un servicio

se diferencia de proveer un bien físico.

� El servicio se define como un bien útil que presentan algunos establecimientos a cambio

de un costo. [INEGI. Recorrido por México, http://www.inegi.org.mx]

� Servicio, es el resultado generado por actividades en la interfaz entre el proveedor y el

cliente y por actividades internas del proveedor, con el fin de responder a las necesidades

del cliente [ISO-8402].



Entre las características propias de un servicio que permiten diferenciarlo de un producto está la

intangibilidad (es decir que un servicio no puede verse, probarse, sentirse, oírse ni olerse antes

de la compra), la heterogeneidad (dos servicios similares nunca serán idénticos o iguales), la

inseparabilidad (la producción y el consumo son parcial o totalmente simultáneos), la

perecibilidad (un servicio no se puede almacenar) y la ausencia de propiedad (los compradores

de un servicio adquieren el derecho a recibir una prestación, uso, acceso o arriendo de algo, pero

no la propiedad del mismo).

De esta manera la automatización de servicios implica que los procesos que componen el servicio

sean realizados de manera automática, sin la interacción de agentes externos para minimizar el

número de errores y tratar de que el servicio esté disponible la mayor parte del tiempo.

Es importante notar que para que exista la automatización de servicios en el Estado, es vital la

interoperabilidad de los sistemas heterogéneos (sistemas con diferencias tecnológicas y

propósitos variados) con que cuenta cada dependencia. Así resulta necesario definir formalmente

el concepto de Interoperabilidad.

� En el ámbito computacional, la interoperabilidad se asocia con la capacidad de comunicar

sistemas de manera que intercambien y compartan datos e información [e-gif].

Sin embargo, la interoperabilidad computacional no es la única existente. A partir del ejemplo

introductorio de la tesis se puede ver que para que el SAT, o cualquier otra dependencia de

gobierno puedan comunicarse con las demás entidades, deben existir acuerdos previos desde los

puntos de vista de la voluntad política, legal y gubernamental entre otros. Ello también forma parte

de la interoperabilidad necesaria para el éxito del servicio.

Una clara muestra de los pasos que se han dado en la actualidad para apoyar la definición eficaz

de protocolos, guías e implementación de aplicaciones interoperables, es la existencia de un

conjunto de organizaciones interesadas en promover la interoperabilidad.

Algunas de estas organizaciones son la Web Services Interoperability Organization (WS-I) [ws-i]

(interoperabilidad técnica) y la Organization for the Advancement of Structured Information

Standards (OASIS) [oasis] (interoperabilidad semántica y organizacional) que se mencionaron

anteriormente en este documento.



Una de las tecnologías de mayor auge que ha prometido ser quien brinde la mayor

interoperabilidad, es la de los servicios web.

NOTA: El titulo de este trabajo hace uso del término Web Services por que así es conocida la

tecnología de origen, sin embargo, para mayor entendimiento en el idioma español, se usará en la

mayor parte de la redacción la traducción al castellano como Servicios Web.

Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos

entre aplicaciones. Las aplicaciones de software desarrolladas en lenguajes de programación

diferentes y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para

intercambiar datos en redes de computadoras locales o bien a través de Internet. La

interoperabilidad se consigue mediante la adopción de estándares abiertos.

Los servicios web permiten tanto la ejecución de servicios simples, como la composición de ellos

para obtener aplicaciones más complejas y de mayor valor.

Esta tecnología está inmersa en el modelo de Arquitectura Orientada a Servicios (SOA por sus

siglas en inglés), que se basa en la idea de encapsular la lógica de las aplicaciones dentro de

servicios que interactúan mediante un protocolo de comunicación estándar.

La comunicación entre servicios usa además el envío de mensajes en formato estándar [soa-erl],

como lo muestra la figura 15, existe un intercambio de mensajes entre un proveedor y un cliente a

través de un intermediario (servicio web) que sirve como punto de enlace entre las dos entidades.

Figura 15: Modelo de funcionamiento de SOA.

La forma en que los servicios web realizan ésta comunicación entre aplicaciones no es nada

sencilla ni trivial, aún cuando su flexibilidad permite manejar una variada lista de protocolos de red

como FTP, HTTP, HTTPS, SMTP, etc.

Proveedor (Servidor)

Solicita servicio

Envía Respuesta

Recibe Solicitud

Recibe servicio

Información en General. BD, Archivos.

Cliente

Intermediario (Web Services)

App Java

App .NET

App B.D.

SOA



Para cada servicio, ya sea en el gobierno o en aplicaciones empresariales, existe una definición

formal del proceso que ellos encierran, que especifica la lógica del servicio. Éste sólo será exitoso

si es coordinado apropiadamente. [ws-choreography]

La coreografía de documentos [Eduardo René Rodríguez, Upiicsa, http://homepage.mac.com/eravila/formatos.pdf]

se refiere a la secuencia de intercambio de documentos y es la forma en como se responde a un

documento recibido utilizando otro documento como respuesta. El documento incluye información

acerca de los puntos terminales, esta información puede incluir:

� Las URLs a las que van dirigidos los mensajes que han sido enviados y,

� Las reglas del otro punto Terminal como los certificados digitales que serán usados para

asegurar los mensajes.

El proceso de intercambio de documentos puede darse de dos formas:

a) De forma directa.- Envío del documento y la respuesta a éste, como otro documento o

como confirmación de recepción (acuse de recibo).

b) Como proceso de negociación: Se intercambia una serie de documentos en los que se

solicitan productos o servicios y se responde con propuestas para cubrirlos hasta llegar a

un acuerdo.

Para asegurar el intercambio de documentos se deben asegurar garantías durante el proceso

transaccional, estas garantías se asemejan mucho a las que se presentan para un mecanismo de

seguridad de la información y son:

Integridad, Autenticidad, Privacidad y No Repudio.

La integridad asegura que los documentos no sufran alteración física del contenido durante el

proceso de intercambio.

La autenticidad garantiza que la identidad del remitente del documento sea determinada con

precisión.

La privacidad significa que los canales de comunicación por los cuales viajan los documentos,

sean aislados de fuentes externas mediante protocolos de encripción de datos como SSL (Secure

Socket Layer).

El No Repudio, da certeza de que los participantes de una transacción no puedan negar el origen

o existencia de un documento creado por ellos mismos.

También es necesario que el modelo de intercambio de documentos establezca reglas y

mecanismos a seguir para la resolución de problemas y condiciones de error que se presentan

durante el proceso de intercambio.



Los errores que se pueden presentar pueden ser genéricamente de cuatro tipos:

a) De transporte cuando el documento no alcanza el destino o bien se corrompe en el

camino.

b) En el documento, cuando el documento no coincide con las definiciones de DTD o en su

esquema semántico que se definió para dicho documento.

c) De procesamiento, cuando el documento no puede procesarse con éxito por problemas en

el equipo que lo recibe, ya sea por hardware o software.

d) De proceso de negocio, cuando semánticamente el documento es correcto pero no puede

ser procesado por algún motivo del propio negocio (validaciones de negocio).

La información de las reglas de negociación puede estar definida dentro de la misma

especificación de los servicios web, por ejemplo dentro del archivo WSDL (Web Service

Description Languages), la cual describe las reglas de comunicación y envió de mensajes entre

uno y otro servicio.

Si se desea lograr una automatización del proceso, se deben definir formas de comunicar y hacer

interoperar las distintas dependencias del gobierno a manera de permitir el flujo de información

(documentos) de una institución a otra.

Este flujo se define por los mensajes intercambiados, estado del proceso, documentos y los

agentes que manejan estos documentos. Esto representa lo que se conoce como un flujo

documental entre entidades conocidas (es decir que tienen un protocolo de comunicación

establecido entre ellas).

La definición del flujo documental, es clave en la definición de los servicios web para el gobierno

electrónico, ya que ella representa la médula espinal del proceso que se quiere modernizar

mediante la incorporación de TICs en el gobierno.

De esta manera, la definición y descripción del flujo de trabajo de los servicios web debe

especificar completamente tales flujos documentales, para definir los protocolos a usar en el

intercambio de documentos de una dependencia a otra.

Hasta este punto es importante diferenciar entre un flujo de trabajo que define la forma y el orden

en que se realizan los procesos, y el flujo documental que se refiere al intercambio de información

en un formato explicito como puede ser un mensaje XML vía HTTP, FTP, SMTP, etcétera.



Por otra parte debemos entender otros conceptos que son importantes dentro de los temas

relacionados a las tecnologías web utilizadas para el desarrollo de servicios web.

Ahora podemos entonces definir que un recurso representa cualquier objeto que tiene una

identidad. Algunos ejemplos de recursos son: servicios, agentes, documentos, imágenes, entre

otros.

� Un recurso web por su parte, es un recurso identificado por una URI [glosario], al que se

puede acceder mediante el protocolo HTTP [glosario].

Para describir todos estos recursos se usan metadatos, es decir, datos que describen datos, los

cuales permiten estructurar la información, en particular los metadatos abarcan desde los primitivos

tags o etiquetas intrínsecas de los recursos, hasta los metadatos de alto nivel que describen el

contenido de otros datos para diferenciarlos de los demás.

Dentro de los metadatos más primitivos están por ejemplo la sección del título de una página

HTML, o la etiqueta para marcar el encabezado de un capítulo. Esta forma de marcado básica es

fundamental para que cada recurso exista, pueda ser entendido y procesado.

Por su parte los metadatos de alto nivel, surgen luego de que los metadatos más básicos ya han

sido definidos y entregan una documentación y clasificación, la cuál permite no sólo especificar un

recurso de mejor manera sino además diferenciarlo de los otros.

Aplicaciones típicas de los metadatos de alto nivel son: uso para clasificaciones jerárquicas,

definición de tesauros y taxonomías.

En el campo de las Ciencias de la Información, un tesauro es una lista que contiene los "términos"

empleados para representar los conceptos, temas o contenidos de los documentos, con miras a

efectuar una normalización terminológica que permita mejorar el canal de acceso y comunicación

entre los usuarios y las Unidades de Información (Entiéndase unidad de información como:

biblioteca, archivo o centros de Documentación).

Aunque en la práctica tradicional se habla de uniterminos, en la actualidad se han efectuado

grandes variaciones dando incorporación a términos o descriptores compuestos, es decir,

descriptores que se componen de dos o más palabras.



<html>

<title> Metadatos de HTML </title>

<form> El cuerpo de un documento HTML para ejemplificar el uso de

etiquetas para describir datos

</form>

</html>

Ejemplo del uso de etiquetas o metadatos, para describir datos de un documento HTML.

De igual forma podemos ver el ejemplo de un documento XML:

<persona>

<nombre> Job </nombre>

<apellido paterno>Hernández</apellido paterno>

<apellido materno>Joffre</apellido materno>

<edad> 26 </edad>

</persona>

Ejemplo del uso de etiquetas o metadatos, para describir datos de un documento en formato

estándar de XML.



3.2 Definición de pautas.

A continuación se presentan las definiciones necesarias para entender la manera en que funcionan

las tecnologías utilizadas, primero se mencionan algunos principios básicos que rigen el desarrollo

de servicios, se describen brevemente las tecnologías sobre servicios usando servicios web en el

e-Gobierno, y finalmente se explica la forma de atacar los problemas relacionados con la

interacción aplicativa.

3.2.1 Definiciones y bases teóricas.

Las siguientes definiciones representan los principios básicos de este trabajo y permitirán entender

las acciones de comunicar, interoperar y automatizar los servicios para el Gobierno electrónico.

Principios

1) Unidad de información: Una unidad o token de información para los servicios web en el e-

Government, se define como un documento XML.

2) Descripciones: Las descripciones (metadatos, ontologías [glosario], propiedades, restricciones,

protocolos, etc.) de los recursos en la web, se especifican mediante unidades de información (es

decir, documentos con el formato de XML).

3) Comunicación: La comunicación entre sistemas heterogéneos en la web se hace mediante el

intercambio de mensajes. Los mensajes corresponden a documentos XML, que contienen

información y descripciones de los recursos.

4) Interoperabilidad y automatización: Para automatizar los servicios se requiere que ellos

interoperen. Para interoperar, los sistemas se deben comunicar cumpliendo los protocolos y

definiciones presentes en las descripciones de los recursos web en juego.

Para abordar este cuarto principio especificado en las Definiciones y Bases Teóricas

(interoperabilidad y automatización), se debe precisar que existen al menos 2 tipos de

interacciones en el marco de los servicios web: máquina-máquina y persona-máquina.

Interacción máquina- máquina: Este tipo de interacción se basa en la descripción de los

recursos existentes en la web, de manera que ellos puedan ser invocados, relacionados y

obtenidos de manera automática por algún sistema. Ejemplos de descripciones que se



ocupen de la interacción máquina-máquina son la definición de WSDL [wsdl], protocolos de

comunicación, entre otros.

Cabe recalcar que este tipo de interacción e interoperabilidad es posible gracias a XML,

que entrega un formato estándar para el intercambio de información (documentos).

Interacción persona- máquina: En el ámbito de los servicios web, las máquinas se

pueden comunicar mediante la definición de protocolos de comunicación, identificadores

únicos de recursos, etc.

Sin embargo, estos parámetros resultan poco convenientes para las personas, por lo que

se necesita una interfaz entre los mundos de personas y máquinas.

Tal interfaz es posible gracias a descripciones que vienen dadas por ejemplo con

aplicaciones como UDDI [uddi] o la clasificación de los servicios según taxonomías.

Un claro ejemplo de esto es el diccionario de metadatos de AGLS [agls-35], que permite a

los usuarios buscar, relacionar e invocar, los servicios disponibles gracias a las

clasificaciones definidas.

Otro concepto importante es una hoja blanca sobre el sito UDDI que utiliza la noción de las

maquinas de búsqueda web para ayudar a entender lo que es UDDI. Las máquinas de búsqueda

necesitan ser pobladas con URLs y con las palabras clave para permitir que se pueda buscar

información cuando se visite una máquina de búsqueda en particular.

El resultado de buscar en una máquina de búsqueda de sitios web es una lista de URLs. Algunas

de estás pueden ser relevantes para lo que se está buscando, pero otras pueden no serlo.

En una forma similar, los operadores UDDI (tales como Hewlett-Packard HP, IBM, SAP, y

Microsoft) proveen de un sitio web para que un usuario registre su negocio, servicio, y direcciones

de servicio. Se puede también tener aplicaciones registradas por si mismas a través del Protocolo

de Acceso Simple a Objetos SOAP (Simple Object Access Protocol) mensajes SOAP / XML. IBM,

SAP, HP, y Microsoft han lanzado un Registro de Negocios UDDI o UBR (UDDI Business

Registry), el cual es una implementación de la especificación UDDI.

También es importante mencionar que a pesar de que las pautas técnicas de esta tesis están

orientadas a las descripciones para la interacción máquina-máquina, se considera la interacción

persona-máquina.



3.2.2 Pautas de servicios web para el e-Gobierno.

Tomando como marco la escala de medición de madurez del gobierno electrónico que se presenta

en la sección 2.1.1, como parte de esta tesis, se definen las llamadas pautas técnicas de servicios

usando servicios web, orientadas a un Gobierno Electrónico Unificado (Pautas de ahora en

adelante).

Estas pautas definen los requerimientos de los servicios en el e-Gobierno, presentan las

ventajas del uso de la tecnología de servicios web en este contexto, muestran ejemplos mediante

casos de éxito haciendo uso de servicios web y finalmente entregan descripciones y metadatos

que permiten satisfacer los requerimientos de los servicios.

Esto será la base para desarrollar los servicios web y hacer posible la interoperabilidad y

automatización que se busca en pro de un gobierno electrónico unificado, llevando así a los

servicios web hasta su máximo potencial.

Las pautas son presentadas a lo largo de este trabajo, a través de ejemplos particulares, que

exponen conceptos y necesidades del e-Gobierno. En el capítulo 5, las pautas son estructuradas

como la definición de una sugerencia para el desarrollo de servicios en el gobierno electrónico

usando servicios web.

3.2.3 Bases usadas para definir pautas

Para la definición de las pautas, primero se estudió conceptualmente el problema del e-Gobierno,

que incluye: motivación, requerimientos que se busca satisfacer, particularidades del problema

comparado con otros, normativas, iniciativas nacionales e internacionales y la estrategia

planificada para su desarrollo.

Una vez comprendido el problema, se hizo un acercamiento a las necesidades concretas del e-

Gobierno, acudiendo y estudiando a instituciones relacionadas con el gobierno y los servicios que

ellas entregan.

Algunas de las instituciones estudiadas fueron: Servicio de Administración Tributaria (SAT),

Secretaria de Hacienda y Crédito Público (SHCP), Subsecretaria de Egresos, Oficialía Mayor,

Secretaría de Desarrollo Social, Banco de México y Secretaria de Gobernación (SEGOB).



De estas instituciones se escogieron algunos casos de éxito con ejemplos muy particulares y

acotados, para poder desarrollarlos a lo largo del trabajo.

Paralelamente a lo anterior - luego de una familiarización con la tecnología de servicios web – se

estudió más a fondo tal tecnología desde el punto de vista de las descripciones, protocolos

provistos, guías y especificaciones. Eso permitió conocer cómo era posible satisfacer las

necesidades de los servicios del e-Gobierno usando servicios web, así como las ventajas y

limitantes de esta tecnología.

Luego, progresivamente se desarrollaron los casos de éxito escogidos, describiendo formalmente

sus aspectos, para lo cual se usaron metodologías y técnicas de desarrollo tomadas de la

Ingeniería de Software y UML entre ellas.

A medida que se desarrollaron los casos de éxito, se descubrieron problemas, patrones comunes y

conceptos involucrados en la entrega de servicios y sus relaciones, lo que llevó a la definición del

marco en que se encuentran los servicios en el e-Gobierno y el contexto en que hacen su entrada

los servicios web para solucionar el problema.

El objetivo de presentar los casos de éxito, es el de impulsar el desarrollo de soluciones alternas a

la compra de productos que muchas veces no cumplen con las expectativas creadas por los

propios consultores.

El desarrollar servicios web al interior de las dependencias es un aliciente a demostrar que no es

necesario gastar grandes cantidades de dinero para actualizar la infraestructura actual de una

organización, e impulsar a la vez la expansión de una infraestructura gubernamental que permita

ofrecer mayores beneficios, mejores resultados, un mejor uso de los recursos del gobierno y sobre

todo impulsar la imagen de las instituciones como organismos más transparentes y menos

burocráticos.

Para esto, lo único realmente necesario es que las autoridades tengan la disposición para apoyar

el proyecto y permitir que la gente especializada en el negocio se involucre en el desarrollo de

nuevas soluciones con tecnología innovadora.

Si se logra hacer que todas las dependencias interactúen por lo menos con una aplicación en

común, se podrá demostrar que es posible hacer una integración aplicativa de todo el Gobierno

Federal.



3.3 Servicios Web

Para desarrollar servicios para el e-Gobierno efectivamente, se debe conocer la definición,

estructura y finalidad de los servicios. Las siguientes secciones entregan una visión general de

estas características y muestran el marco donde se insertan las pautas desde lo más general (flujo

documental), hasta lo más particular (requerimientos e implementación de los servicios).

3.3.1 Flujo Documental

Un flujo de trabajo es la automatización de un proceso de negocio en parte o su totalidad, durante

el cual, los documentos, la información y tareas, son pasados de un participante a otro, siguiendo

un conjunto predefinido de reglas [workflow-e-Gov].

Dentro del flujo de trabajo, es necesario definir un flujo documental que deberá especificar las

reglas para el intercambio de unidades de información (documentos XML), estos documentos que

contienen metadatos, deben estar respaldados por un esquema o plantilla que defina las

propiedades de dichos documentos y las particularidades de cada uno de las unidades a transmitir.

En Ingeniería de Software, se dice que un proceso de negocio es un conjunto de una o más tareas

interconectadas, las cuales colectivamente realizan o cumplen un objetivo de negocio,

normalmente dentro del contexto de una estructura organizacional que define roles funcionales y

sus relaciones [Shari Lawrence Pfleeger, Ingeniería de Software teoría y práctica].

La importancia que tiene el concepto de flujo documental para este trabajo, es que al modelar la

lógica de negocio (documentos, tareas, flujos de información y responsables), se obtiene una

definición formal de los procedimientos o trámites que forman la organización.

Esta definición formal de los trámites permitirá hacer “vistas” del procedimiento existente y

entregar servicios que creen, actualicen, modifiquen o lean instancias de estos procesos.



Por ejemplo, dado el flujo documental de las declaraciones del Servicio de Administración

Tributaria (SAT), sería posible hacer una vista sobre tal flujo que entregará todas aquellas

incidencias que cumplen con estar en un estado “al corriente”.

De esas incidencias, se puede conocer una lista de los contribuyentes que están al corriente en

sus pagos y declaraciones, lo que permitiría entregar un servicio de certificado de contribuyente

cumplido invocado, por ejemplo, por el Buró de Crédito o la Comisión Nacional Bancaria y de

Valores, para el otorgamiento de créditos y financiamientos tanto a personas físicas como morales.

3.3.2 Servicios

Un servicio se define como un recurso que provee valor regularmente intangible (por ejemplo la

información) al cliente del servicio.

Más específicamente, un servicio es un recurso abstracto que representa la capacidad de ejecutar

tareas que representan una funcionalidad coherente desde el punto de vista de quienes proveen y

solicitan el servicio.

Para poder ser usado, un servicio debe ser entregado por un proveedor de servicios [ws-arch].

Otra característica clave de los servicios, es que ellos representan una funcionalidad bien definida,

que es autocontenida y que no depende del contexto o estado de otros servicios.

Para el caso de los ciudadanos, los servicios en el e-Gobierno representan una vista del mundo

más directa, relacionada con la manera sobre como interactuar con el gobierno. Es por ello, que

esta vista debe ser abstraída del proceso interno o implementación [describingservices-nzgls].

Tal como un servicio puede ser abstraído como una “vista” de un flujo documental, éste también

puede ser abstraído como una vista lógica de aplicaciones, bases de datos, entre otras. De esta

manera, un servicio está definido según lo que hace, típicamente llevando consigo una operación a

nivel de la lógica del negocio.

Como se mencionó anteriormente, un servicio es un recurso que representa la capacidad de

ejecutar una tarea, pero los servicios pensados por si solos como una funcionalidad entregada, no

son suficientes.

Para aplicaciones que usan a los servicios como recursos, se necesita además de descripciones,

metadatos, ontologías y definiciones para encontrarlos, clasificarlos, compararlos y componerlos.



Por el mismo razonamiento, pero pensando en la lógica del servicio se deben describir cada uno

de los componentes del servicio (mensajes, agentes, documentos) y la interfaz con que se le

conoce (operaciones y semántica del servicio).

Se resalta que para el caso de las Arquitecturas Orientadas a Servicios que se basan en el uso de

servicios, las descripciones de éstos también resultan ser clave (ver sección 3.4).

Una forma particular de implementar servicios para el e-Government, es el uso de la tecnología

de servicios web, que basada en estándares de la web promete entregar una alta

interoperabilidad y flexibilidad para desarrollar servicios.

En la sección 3.6 (Tecnologías en servicios web) se analiza en detalle la tecnología, sus ventajas

y, por supuesto, las descripciones que son necesarias para la implementación de servicios.

3.4 Arquitectura Orientada a Servicios (SOA)

Una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés), es una forma de

arquitectura de sistemas distribuidos, que define el uso de servicios para satisfacer los

requerimientos de agentes. Una SOA se caracteriza por cumplir con las siguientes propiedades [ws-

arch]:

� Vista lógica: Los servicios son una vista lógica de aplicaciones, bases de datos, u otros,

definidos con base en lo que hacen, típicamente llevando consigo una operación a nivel de

la lógica de negocio.

� Orientada a mensajes: La definición formal de un servicio, se hace en base a los

mensajes que intercambian los agentes proveedores y consumidores.

� Orientado a descripciones: Un servicio es descrito por sus metadatos procesables

automáticamente. En la descripción sólo la información importante para usar el servicio

debe ser incluida.

� Granularidad: Los servicios tienden a usar pocas operaciones, con mensajes complejos y

largos (esto no es obligatorio)

� Orientado a redes: Los servicios tienden a ser orientados para ser usados en la red.

� Independencia de las plataformas: Los mensajes enviados y recibidos se encuentran en

formato estándar (XML es el ejemplo más claro).



3.5 Requerimientos de los servicios en el e-Gobierno

¿Qué deberían cumplir los servicios desarrollados en el e-Gobierno?

A continuación se abordan los requerimientos mínimos que deberían cumplir los servicios en el e-

Gobierno. Esto se basa en los aspectos mencionados en el capítulo 2 Organizaciones, e-Gobierno

y sus experiencias, además de la naturaleza de los servicios que son la cara visible del gobierno.

El problema no consta sólo en entregar servicios sino en resolver como deben ser construidos y

definidos de mejor manera, como hacerlos interoperar, como administrar y gestionar un gran

número de servicios, como definir, reutilizar y modularizar componentes, tipos de datos,

documentos y esquemas. Como abordar temas de privacidad en una dependencia o entre

dependencias, entre otros.

A continuación se lista un conjunto de requerimientos sobre el desarrollo de servicios para el e-

Gobierno que corresponden a las necesidades identificadas que debería satisfacer una solución al

respecto.

� Automatización de Servicios (automatizar el proceso)

Para que los servicios web sean automatizados se debe entregar una mayor expresividad y

significado a los metadatos que los describen mediante el uso de ontologías, definición de

conceptos, restricciones, propiedades y relaciones para describir un área de conocimiento y

realizar inferencias, facilitando así la automatización [herman-ws].

Es por ello, que para el caso de los servicios web, existen lenguajes como DAML-S [daml] y

OWL-S [owl-s], que permiten definir ontologías para los servicios.

� Interoperabilidad

La interoperabilidad resulta clave para la composición, invocación y automatización de los

servicios, debido a la heterogeneidad existente de plataformas, sistemas y aplicaciones. Para

hablar de una interoperabilidad completa y efectiva, se hace necesaria la definición de un

framework11

de Interoperabilidad.

11 La definición de framework(marco de trabajo) usada aquí es: “Estructura extensible para describir conceptos, tecnologías

y métodos necesarios para los procesos de diseño y construcción de un producto.”



Este framework se define como el conjunto de estándares, guías de trabajo y protocolos que

describen la forma en que los sistemas han acordado(o deberían acordar) interactuar entre sí.

[e-gif].

Algunos de los tipos de Interoperabilidad más relevantes se definen a continuación, de los

cuales la organizacional, semántica y técnica están basadas en [e-gif]:

� Interoperabilidad organizacional: Esta interoperabilidad tiene que ver con la definición

del negocio y procesos que lo hacen posible, donde las organizaciones que tienen

diferentes definiciones y estructuras de negocio, requieren interactuar.

� Interoperabilidad semántica: Se ocupa de que el significado y el manejo que se le da a la

información entre las distintas partes, sea consistente, preciso y bien definido, mediante el

uso de esquemas, modelos de datos o clases. La interoperabilidad semántica puede ser

analizada a nivel de interacción máquina-máquina o persona-máquina.

� Interoperabilidad técnica: Este tipo de interoperabilidad tiene relación con las

definiciones técnicas que permiten comunicar sistemas computacionales a nivel de redes,

middleware, datos, seguridad, entre otras. Esta interoperabilidad es posible gracias a la

posibilidad de intercambio de información de manera estándar que provee XML.

� Interoperabilidad política: Se refiere a la voluntad política de apoyo a la interacción entre

las partes, como forma de obtener mayor provecho para cada una de ellas.

� Interoperabilidad legal: La factibilidad de ciertos tipos de interacciones tecnológicas,

organizacionales, entre otras, se ven impedidas o limitadas por acuerdos o definiciones

legales. Por este motivo se debe tener especial cuidado con la Interoperabilidad legal

donde por ejemplo, la utilización de ciertos estándares de seguridad a nivel técnico pueden

ser obligatorios o restringidos por la ley, dependiendo de las leyes que se establecen sobre

todo para los documentos rubricados o firmados “digitalmente”.

Todo esto muestra que ciertos tipos de interoperabilidad deben ser resueltos, o al menos

identificados antes que otros.

Esta tesis se enfoca en la Interoperabilidad de carácter técnico y semántico, sin embargo, también

se recalca la gran importancia de considerar los otros tipos de interoperabilidad.



Definición previa de servicios y sus operaciones

Una de las primeras preguntas que se debe hacer para comenzar con la definición de servicios, es

el análisis sobre ¿qué servicios entregan un mayor impacto y valor a las dependencias y

ciudadanos? En este proceso se debe analizar la complejidad del servicio, frecuencia de uso,

dependencia de otros servicios y/o dependencias.

A pesar de que la definición de un workflow, donde se especifique formalmente todo el proceso en

una dependencia o secretaría sería ideal, existen casos donde ello no es posible ni óptimo. Es el

caso de Municipios de escasos recursos donde resulta de mayor utilidad tener un servicio

particular, que invertir tiempo y dinero definiendo todo el proceso.

Una definición previa de los servicios, permitirá invocar y componer servicios, además de procesar

e inferir sobre sus descripciones. Todo esto ayudará a una verdadera automatización de los

procesos. Una definición más exhaustiva sobre una propuesta para desarrollar servicios, se

presenta en los capítulos 4 y 5.

Permitir descubrimiento, consulta e invocación

Para el caso en que se cuente con un gran número de servicios disponibles a lo largo de las

distintas dependencias del Gobierno, surge la necesidad de buscar servicios más convenientes.

Esta búsqueda sería al menos por parte de:

� El Ciudadano (usuario) que realiza trámites y requiere saber ¿dónde? y ¿cómo? usar los

servicios finales disponibles, ya sea a través de una ventanilla única adaptada a sus

necesidades particulares, o a través del sitio web de alguna dependencia de gobierno

(organización).

� Empresas u otras dependencias de gobierno que necesitan buscar servicios finales,

intermedios o básicos comunes (por ejemplo validación del RFC de una persona). Este

descubrimiento requiere mucho más que metadatos que indiquen algunas clasificaciones

del servicio, según la dependencia que lo entrega o dentro de que área de negocios se

encuentra.

Si se busca una automatización real, se deben definir formalmente las capacidades y

restricciones de los servicios, su semántica, funcionalidad, metadatos que permitan

conocer quien es el responsable de él y como debe ser llamado.



Definiciones como éstas, permitirán inferencias más avanzadas que las actuales, como analizar

qué servicios se pueden componer con otros, cuales de los servicios existentes cumplen mejor una

política de privacidad o estándares de seguridad, entre otros.

Administración de descripciones

Como se ha mencionado, la descripción de los recursos permite recuperarlos, relacionarlos e inferir

nuevas definiciones. Algunas de estas descripciones son la definición de capacidades de un

recurso o la clasificación según alguna taxonomía.

Para el manejo de descripciones con volúmenes de información como los que maneja el gobierno,

se debe contar con herramientas que permitan: la creación, almacenamiento, consulta, asignación

(relacionar objetos) y administración de descripciones y recursos.

Estas herramientas van desde el rango de editores de documentos que permitan visualizar, firmar y

validar documentos, hasta las que permitan administrar los esquemas de los documentos de

gobierno, para evitar duplicidad o incompatibilidad de definiciones y permitir reutilización, así como

mecanismos de cifrado (encriptación) y firma electrónica, para asegurar la autenticidad de la

información [agls-35].

Administración y gestión de Servicios

Una vez que los servicios han sido desarrollados y pueden ser invocados por los clientes, surge la

necesidad de responder a preguntas como: ¿cuál es la frecuencia con que se usa?, ¿quién lo

utiliza? o ¿cuál es el desempeño del servicio?

Por ejemplo, algunas preguntas interesantes de responder pueden ser: ¿cuál es el precio promedio

del servicio de renovación de pasaportes o licencias?, saber si existe un servicio que permita

validar un domicilio o conocer la variación porcentual en el uso del servicio de la declaración de

impuestos en línea, o bien que pudiera existir un servicio que agilice el tramite para la jubilación de

los trabajadores del estado.

Tal como se ha mencionado, para ello se requieren herramientas acordes que basadas en las

descripciones de los servicios y en los resultados de su funcionamiento permitan: recolectar

información para tomar decisiones de futuros desarrollos, crear o modificar la definición de los

servicios, medir el nivel de madurez de los servicios entregados y evaluar el impacto de los

servicios.



Mecanismos de autenticación

El acceso a los servicios en línea plantea el desafío de asegurar un acceso confiable y seguro para

dependencias, empresas y ciudadanos. Mantener la privacidad de la información de los usuarios y

asegurar la identidad de quien realiza la operación, son temas que requieren de la definición de un

mecanismo de autenticación (firma electrónica y cifrado de la información).

La complejidad de este mecanismo dependerá del tipo de operaciones a realizar y éste debería ser

acorde con la posibilidad de usar la autenticación y delegación de permisos, o Single Sign On

(SSO) u otros mecanismos. La validez y los límites legales de los mecanismos de autentificación

también deben ser abordados.

Escalabilidad y extensibilidad

La definición de servicios debe permitir extender los dominios de aplicación existentes ya sea en el

ámbito del negocio, en temas de seguridad o metadatos. Es por ello que la extensibilidad de las

especificaciones que definen estos aspectos resulta clave. Además se debe permitir la inclusión de

definiciones en nuevos ámbitos que aparezcan según sea necesario.

Además de lo anterior, se debe permitir escalabilidad en el número de recursos e invocaciones,

descripción de recursos y complejidad de los servicios [wsa-req]. Para ello se deben utilizar las

herramientas correspondientes que permitan administrarlos de manera adecuada (editores XML,

administradores de metadatos, visualización de workflow).

Seguridad

La entrega de servicios involucra la interacción entre agentes de distintas dependencias y el

intercambio de mensajes con información. Para que tal interacción ocurra en un ambiente seguro

se necesita que cierta información sea tratada en forma confidencial, que se pueda asegurar la

integridad de los datos durante su transmisión, que se deba autenticar la identidad de agentes, que

se definan roles y el acceso a recursos.

La seguridad no sólo abarca temas de transmisión de información sino también políticas, respaldo

físico de datos, definición de medidas de contingencia, entre otras. Debido al enfoque de este

documento se hará hincapié sólo en lo correspondiente a seguridad en servicios web y los

estándares y definiciones existentes, que entregan soluciones a algunos de estos problemas.



Plataforma, arquitectura y componentes

Para entregar servicios que forman parte de una sola dependencia como aquellos que requieren

interactuar con agentes de otras dependencias, se debe contar con una plataforma y arquitectura

que soporte las soluciones entregadas por los servicios, que puedan leer las definiciones y

especificaciones definidas y basadas en ella permitan el funcionamiento de la lógica del servicio.

Por ejemplo, dada la definición de permisos de acceso a recursos, la identidad y política de

privacidad de un cliente, tal arquitectura debería decidir si un usuario puede acceder a un recurso.

Además debe encargarse de temas como la transmisión de mensajes, asegurar su entrega, definir

colas de mensajes, etc. También deben especificarse que componentes existirán como parte de la

arquitectura, como workflow, repositorio de permisos, autenticación u otros y cuales serán sus

dependencias y relaciones.

La plataforma que sea definida puede ser común a varias dependencias (asociando por sectores a

las dependencias del gobierno) o particular a alguna de ellas. Temas de escalabilidad,

reutilización, disponibilidad, seguridad y complejidad, son algunos de los factores a

considerar para analizar que alternativa es más eficiente y eficaz.

3.5.1 Particularidades de los servicios en el e-Gobierno.

¿Qué diferencía los servicios del Gobierno con los de una empresa cualquiera?

Tal como se mencionó, el concepto del e-Gobierno fue definido como: “una forma de describir el

quehacer del gobierno, apoyado por las nuevas tecnologías de información y comunicación (TIC),

a fin de cumplir con sus funciones eficiente y efectivamente”. A priori, esta definición no hace

referencia a ninguna particularidad que pudieran tener las necesidades del gobierno, lo que lleva a

cuestionar la verdadera necesidad del estudio y trabajo sobre el e-Gobierno como tal.

Primero hay que aclarar que el nacimiento del e-Gobierno nunca supuso el uso de nuevas y

revolucionarias tecnologías que fueran de uso exclusivo de éste, o que no se pudiera reutilizar todo

el conocimiento en desarrollo de servicios, aplicaciones y modelado de información obtenido en

otras áreas para usarlo en el gobierno.



Por el contrario, para cumplir efectiva y eficientemente con el quehacer del gobierno que resulta de

una administración de recursos, entrega de servicios de alta complejidad y manejo de grandes

volúmenes de información, se requiere reutilizar lo mejor del conocimiento actual.

Aclarado este punto la pregunta anterior sigue en pie, ¿Qué diferencía a los servicios y

necesidades del e-Gobierno con los de una empresa cualquiera?

Como primer punto, el enfoque social que tiene el gobierno comparado con el interés privado que

apunta hacia lo económico, define estrategias de desarrollo, prioridades y valores a los proyectos,

de una manera absolutamente distinta.

De aquí, por ejemplo, el gobierno puede priorizar un proyecto que implique beneficiar a un gran

número de ciudadanos, para lo cual necesitará un gran poder en infraestructura y alta complejidad

de desarrollo, pero no involucrará grandes ganancias económicas. Por otro lado, una empresa

podría preferir un proyecto de bajo impacto en el número de usuarios pero de alto valor por los

montos en juego y el respectivo beneficio económico.

Sin embargo, se podría argumentar que estos no son requerimientos técnicamente distintos, por lo

cual la pregunta inicial podría convertirse en la siguiente: ¿Qué diferencias técnicas existen entre

los servicios del gobierno y empresas cualesquiera, que hace necesario su estudio y no permiten

simplemente replicar las soluciones existentes?

Primero se puede decir que el volumen de documentos, transacciones e interacciones que maneja

el gobierno es mucho mayor al de las empresas. No obstante, se puede argumentar que siempre

es posible hallar una empresa lo suficientemente grande para que esto resulte comparable.

Por último, cabe recalcar que dadas las realidades de cada gobierno en particular y los puntos

anteriormente planteados, aún no existe evidencia que demuestre si todas las instituciones que

forman parte del gobierno serán capaces de entregar los servicios que se requiere, si será mejor

entregar autonomía de definición de servicios a cada institución, entre otros temas. Es por ello que

el estudio y análisis de la problemática del e-Gobierno resulta necesaria y fundamental.

El poder ofrecer a la población un portal que permita el acceso a la mayor parte de los servicios a

través de la web, es el principal objetivo de una arquitectura diseñada y basada en el uso de

tecnologías abiertas 12

, que permitan la comunicación entre dependencias y organismos públicos y

privados para mejorar la calidad de vida de los ciudadanos

12 Este punto además hace notar la utilidad de la tecnología de Servicios Web para solucionar el problema.



Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a

la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posible

definición, sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad

para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí

(mensajes) con el objetivo de ofrecer servicios. Los proveedores ofrecen sus servicios como

procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a

través de la Web [fuente: W3C http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb].

Los servicios web pueden realizar operaciones por si mismos, e incorporar otros servicios web

(composición de servicios). Esto permite completar y automatizar transacciones complejas y de alto

nivel. [frez-ws-admin].

Los servicios web son por definición recursos web [ws-arch], y como tales están identificados

por una URI (Uniform Resource Identifier, identificador uniforme de recurso, definido en RFC 2396).

Una URI es una cadena corta de caracteres que identifica inequívocamente un recurso (servicio,

página, documento, dirección de correo electrónico, enciclopedia, etc). Normalmente estos

recursos son accesibles en una red o sistema, son alcanzables usando los protocolos de la web y

además tienen el potencial de contar con descripciones (metadatos), para encontrarlos,

clasificarlos, compararlos, componerlos e inferir propiedades sobre ellos.

Como se mencionó en el capítulo 2, el gobierno electrónico tiene la necesidad de entregar

servicios (recursos) independientes del tipo de interacción, lo que convierte a los servicios web en

un excelente candidato debido a su naturaleza de recurso web, que lo hace independiente del

contexto que lo rodea.

3.6 Tecnologías en Servicios Web

Los servicios web están definidos, esencialmente por tres tecnologías, construidas sobre los

protocolos y estándares de la Web.

3.6.1 Extensible Markup Language (XML)

XML (eXtensible Markup Langauge, Lenguaje de Etiquetado Extensible) es un lenguaje de

etiquetado muy simple pero a la vez muy estricto, juega un papel fundamental en el intercambio de

una gran variedad de datos. Es un lenguaje muy similar a HTML pero su función principal es



describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la

lectura de datos a través de diferentes aplicaciones.

Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más

frecuentes por parte de los usuarios. XML sirve para estructurar, almacenar e intercambiar

información [fuente: W3C, http://www.w3c.es/divulgacion/guiasbreves/tecnologiasXML].

Entre las tecnologías XML disponibles se pueden destacar:

XSL (eXtensible Stylesheet Language): Lenguaje Extensible de Hojas de Estilo, cuyo objetivo

principal es mostrar cómo debería estar estructurado el contenido, cómo debería ser diseñado el

contenido de origen y cómo debería ser paginado en un medio de presentación como puede ser

una ventana de un navegador web o un dispositivo móvil, o un conjunto de páginas de un catálogo,

informe o libro.

Xpath (XML Path): Lenguaje de Rutas XML, es un lenguaje para acceder a partes de un

documento XML.

XLink (XML Link): Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos en

documentos XML para crear enlaces entre recursos XML.

XPointer(XML Pointer): Lenguaje de Direccionamiento XML, es un lenguaje que permite el acceso

a la estructura interna de un documento XML, esto es, a sus elementos, atributos y contenido.

XQL (XML Query Language): Lenguaje de Consulta XML, es un lenguaje que facilita la extracción

de datos desde documentos XML. Ofrece la posibilidad de realizar consultas flexibles para extraer

datos de documentos XML en la Web.

<?xml version="1.0" encoding="ISO-8859-1"?>

<libro>

<titulo></titulo>

<capitulo>

<titulo></titulo>

<seccion>

<titulo></titulo>

</seccion>

</capitulo>

</libro>

Ejemplo de un documento XML



3.6.2 Simple Object Access Protocol (SOAP)

SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos

objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos en formato

XML. SOAP fue creado por Microsoft, IBM y otros corporativos, está actualmente bajo el auspicio

de la W3C. Es uno de los protocolos utilizados en el desarrollo de servicios web.

SOAP entrega una definición basada en el estándar XML, que permite intercambiar información

estructurada (metadatos) entre distintos puntos de la red en un ambiente distribuido

descentralizado. Especificaciones que extienden de SOAP, permiten hacerse cargo de aspectos

como: correlación de mensajes o envío de mensajes a través de nodos intermediarios (proxy,

firewall), [fuente W3C SOAP v 1.2, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/].

Después de que algún usuario ha buscado la descripción WSDL (Web Service Description

Language) de un servicio web en la red utilizando UDDI (Universal Description, Discovery, and

Integration), este puede llamar a una o más operaciones en su servicio web usando SOAP.

SOAP es un protocolo basado en texto que utiliza el formato de codificación de datos de XML y de

los protocolos HTTP/SMTP para transportar mensajes. SOAP es independiente del lenguaje de

programación usado y/o de la plataforma sobre la cual está corriendo la aplicación.

XML es crucial para el intercambio de mensajes de información porque es un “lenguaje de

marcado de texto” fácil de extender, tiene un soporte considerable en la industria y es bien sabido

que es un lenguaje utilizado para la descripción de metadatos. El uso de HTTP (y otros como

SMTP, FTP y HTTPS) como protocolo de transporte permite la navegación a través de firewalls

usando el puerto 80. HTTP es también el protocolo de transporte más común y más usado en

Internet.

SOAP ha sido ampliamente aceptado por los más grandes vendedores de plataformas (plataform

vendors) de los negocios electrónicos (eBusiness). El estándar SOAP es ahora administrado por

W3C y la especificación en su versión 1.2 consiste de dos partes y una premisa (primer):

o Parte 0: Premisa (Primer)- Proveer un tutorial sobre las características de SOAP.

o Parte 1: Marco de Mensajes (Message Framework) - Describe la envoltura de SOAP y

el marco de la capa (binding) de transporte.

o Parte 2: Adjuntos: Describe adjuntos para la envoltura y marco de encapsulamiento

(envelope and binding framework).



3.6.3 Web Services Description Language (WSDL)

El Lenguaje de Descripción de un Servicio Web (WSDL), es una especificación basada en el

estándar XML, pensada para describir servicios disponibles, y los mensajes que ellos utilizan para

comunicarse a través de un conjunto de nodos en la red.

[fuente:W3C, WSDL, http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221/].

Para que un negocio descubra un servicio y pueda usarlo, el software de servicio web necesita

entender la sintaxis de la llamada y la estructura semántica, esto para poder realizar una llamada y

descubrir los servicios disponibles.

La especificación del lenguaje de descripción de un servicio web define a WSDL con un formato

XML para describir servicios de red como un conjunto de puntos terminales que operan sobre

mensajes que contienen documentación ya sea orientada a documento (document-oriented) u

orientada a procedimiento (procedure-oriented).

WSDL complementa a UDDI proporcionando una manera uniforme de describir las capas de

interfase y de protocolo de los servicios web.

La especificación WSDL también describe los siguientes elementos que un documento WSDL

utiliza en la definición de servicios de red:

o Tipos (Types) – Un contenedor para las definiciones de tipos de datos que utiliza un

tipo de sistema (como puede ser XSD).

o Mensaje (Message) – Una abstracción, definición “tipeada” (tipo) de los datos que

están siendo comunicados.

o Operación (Operation) - Una descripción abstracta de una acción soportada por el

servicio.

o Tipo de Puerto (Port Type) - Un juego abstracto de operaciones soportadas por uno o

más puntos terminales.

o Enlazado (Binding) - Un protocolo concreto y especificación para el formato de datos

para un tipo de puerto en particular.

o Puerto (Port) – Un punto Terminal aislado que está definido como una combinación de

una capa y una dirección de red.

o Servicio (Service) – Una colección de puntos terminales relacionados.



Figura 16. Tecnologías en Servicios Web. Figura tomada de W3C [web-design, http://www.w3.org/DesignIssues/].

A pesar de que se puede considerar a los formularios web o script CGI, como servicios web, en

este documento, el término servicio web es usado para referirse a aquellas aplicaciones que usan

al menos las tecnologías XML, SOAP y WSDL.

Existe una amplia lista de tecnologías que complementan a XML, SOAP y WSDL, según el dominio

y necesidades de las aplicaciones. Entre tales tecnologías están: tecnologías de seguridad, de

definición de transacciones y de entrega confiable.

Las tecnologías base más sus complementos, definen el modelo de capas levemente acoplado de

los servicios web, que se muestra en la Figura 16.

Este modelo de capas, resulta altamente extensible debido a la propia extensibilidad de las

tecnologías bases que lo conforman, y por ello permite la definición de nuevas tecnologías de

capas de más alto nivel, que especifiquen temas como coordinación de servicios, reglas de

negocio particulares a algún dominio, seguridad y administración de servicios.

3.6.4 Universal Description, Discovery and Integration UDDI.

La Descripción, Descubrimiento e Integración Universal UDDI (Universal Description, Discovery,

and Integration) es una especificación que permite a los proveedores registrar sus servicios web y

a los requisitantes encontrar los servicios web disponibles en la red y necesarios para satisfacer

sus requerimientos.

La especificación y varias páginas sobre el estándar UDDI están disponibles en el sitio web

http://www.uddi.org.



Una forma de entender como funciona UDDI es haciendo uso del concepto de máquinas de

búsqueda. Las máquinas de búsqueda necesitan ser pobladas con URLs (Uniform Resource

Identifier - Identificador Uniforme de Recurso) y con las palabras clave para permitir que se pueda

buscar información cuando se visite una máquina de búsqueda en particular.

El resultado de buscar en una máquina de este tipo, es una lista de URLs. Algunas de estás

pueden ser relevantes para lo que se está buscando, pero otras pueden no serlo.

En una forma similar, los operadores de UDDI (tales como Hewlett-Packard HP, IBM, SAP y

Microsoft) proveen de un sitio web para que un usuario registre su negocio, servicio y direcciones

de servicio. Se puede también tener aplicaciones registradas por si mismas a través del Protocolo

de Acceso Simple a Objetos SOAP (Simple Object Access Protocol), mensajes SOAP / XML.

IBM, SAP, HP, y Microsoft han lanzado un Registro de Negocios UDDI o UBR (UDDI Business

Registry), el cual es una implementación de la especificación UDDI.

UDDI dirige los sistemas buscando servicios confiables para la documentación que describe esos

servicios web. Soporta el estándar de búsqueda de páginas blancas de negocio, páginas amarillas

para búsqueda por tema y páginas verdes para la búsqueda de tipos de servicio, es decir, las

páginas verdes de búsqueda que permiten a un desarrollador encontrar los servicios que coinciden

con un tipo de servicio en particular.

Los clientes que acceden a un registro UDDI para localizar o buscar información o servicios

también utilizan mensajería SOAP (típicamente XML/HTTP).

No obstante en la literatura se ha difundido la Universal Description Discovery and Integration

Standard (UDDI) como parte de la tecnología de servicios web, aunque ésta no pertenece al

núcleo esencial de los servicios web sino que más bien resulta ser una aplicación que permite la

descripción y búsqueda de los servicios disponibles.

Por este motivo UDDI no es tratado aquí a detalle ya que no representa parte esencial como

componente de la tecnología pero podría implementarse como una solución más robusta para la

interacción entre aplicaciones de organizaciones públicas y privadas o cualquier combinación de

ellas.

Es clave resaltar que las descripciones resultantes de los servicios web formadas por las capas

bases y las de más alto nivel, dependen del modelo arquitectónico usado para observar la realidad

[ws-design, http://www.w3.org/DesignIssues/]. Es por ello, que a continuación se presentan los modelos

arquitectónicos más relevantes.



3.7 Modelos arquitectónicos

Existen varios modelos que permiten representar la arquitectura que involucran los servicios web,

es decir: sus componentes o conceptos, y las relaciones que hay entre ellos, desde distintos

puntos de vista, para así explicar un tema importante [ws-design][ws-arch]. Los 2 modelos

arquitectónicos más importantes propuestos por la W3C son [ws-arch, http://www.w3.org/TR/2004/NOTE-

wsarch-20040211/]:

Modelo Orientado a Mensajes (MOM): Este modelo se enfoca en los mensajes intercambiados

entre los distintos agentes en la web y su procesamiento. El MOM se ocupa de describir la

estructura y transporte de mensajes sin definir el significado ni la razón de por que están siendo

enviados mensajes.

Figura 17: Modelo arquitectónico orientado a mensajes. Figura tomada de [ws-design, http://www.w3.org/DesignIssues/]



Los diagramas definidos con una simbología estándar y universal se pueden considerar como un

modelo [ws-design, http://www.w3c.org/DesignIssues/], los conceptos y relaciones claves en este modelo

(ver Figura 17) incluyen los mensajes y su estructura, los agentes que los envían y procesan, la

dirección donde se encuentran destinatario y recipiente, la correlación de los mensajes, la forma de

transportar tales mensajes, entre otros.

Modelo Orientado a Servicios (SOM): Este modelo se enfoca en el servicio entregado por un

agente proveedor hacia uno que lo solicita y se compone de un conjunto de acciones a realizar

para cumplir con tal servicio.

A pesar que el SOM se basa en el MOM, el modelo orientado a servicios se ocupa primordialmente

de las acciones que involucra el servicio y no de los mensajes intercambiados.

Figura 18: Modelo arquitectónico orientado a servicios. Figura tomada de [ws-design, http://www.w3.org/DesignIssues/]



Los conceptos y relaciones claves en este modelo (ver Figura 18) son que el servicio es realizado

por un agente y usado por otro, los servicios son llevados a cabo gracias al intercambio de

mensajes entre agentes y a que la semántica de los servicios y las interfaces que éstos proveen

son definidas con metadatos.

El modelo orientado a servicios es el más complejo de todos y se debe a que modela casi

completamente el mundo real, esto es: La definición de la semántica de los servicios, la

pertenencia de los servicios a propietarios, los mensajes intercambiados, la definición de tareas y

acciones junto con su objetivo asociado.

3.8 Arquitectura de Servicios Web como descripción de servicios

La arquitectura de referencia entregada por la W3C [ws-arch, http://www.w3.org/TR/2004/NOTE-wsarch-

20040211/], identifica los componentes funcionales (mensajes, servicios, agentes), define las

relaciones entre ellas y establece un conjunto de restricciones sobre los componentes y sus

relaciones.

Según Tim Berners Lee [ws-design, http://www.w3.org/DesignIssues/WebServices.html], el trabajo referente a

esta arquitectura de servicios web puede ser dividido en dos partes: la descripción de servicios y

los protocolos de ejecución de los servicios. El énfasis de este trabajo está en la descripción de

servicios.

La descripción de los servicios viene detallada por el modelo orientado a servicios (SOM) junto con

el modelo orientado a mensajes (MOM), los cuales permiten definir los agentes participantes, la

descripción del servicio, la estructura de mensajes, entre otros.

La gran importancia que tiene la descripción de los servicios queda descrita por SOA (ver sección

3.4). Es por ello que resultan útiles algunas consideraciones sobre la descripción de los servicios

web y por supuesto, de todos los recursos web:

� Existen metadatos que son intrínsecos y otros extrínsecos a los recursos. Por ejemplo los

documentos cuentan con una estructura de capítulos, secciones y párrafo, que forma parte

de los metadatos propios del recurso.

También existen otros metadatos tales como fecha de creación, autores y clasificación

relacionados al recurso que no son indispensables para comprender su contenido. De esta

manera dependiendo de la naturaleza y uso de los recursos, puede convenir incrustar los



metadatos como parte de los recursos o manejarlos por separado. Si se decide incrustar

los metadatos hay que notar que no todos los recursos aceptan metadatos incrustados,

que puede resultar difícil administrar las actualizaciones de metadatos sobre los recursos.

Por su parte los metadatos extrínsecos entregan más flexibilidad de mantenimiento y

edición, resultan cómodos de administrar sobre todo si los recursos son de gran tamaño

(videos, imágenes, expedientes) ya que los metadatos usan poco espacio en general, pero

esto requiere tener depósitos o herramientas distintas para manejar recursos y otra para

metadatos [metadata-guide, http://www.oict.nsw.gov.au/pdf/4.4.34.AGLS_Gdl_v3.5.pdf ].

� Debido a que la descripción de recursos no sólo entrega herramientas a los ciudadanos

para entender e interactuar con el gobierno, sino que también al mismo gobierno para

analizar y gestionar su actividad, se deben definir metadatos que consideren la información

administrativa que se requiere sobre los recursos.

Esto permitirá contestar preguntas que ayuden a mejorar la gestión de las funciones

gubernamentales, lo cual resulta ser uno de los principios bases del e-Gobierno.

3.9 Guías para el uso de servicios web en servicios

Hasta aquí, este trabajo ha expuesto las necesidades de contar con servicios que permitan la

interacción entre dependencias para agilizar el desempeño de las actividades del gobierno y

organizaciones privadas (e-Gobierno), las formas en que se organiza su quehacer y la visión

abstracta del mundo para ciudadanos, empresas y otras dependencias de este quehacer, que

resultan ser los servicios.

Estos servicios los entregan los proveedores (dependencias de gobierno o empresas) basándose

en aplicaciones, bases de datos o flujos documentales y procesos de información bien definidos.

En este capítulo, se ha presentado una breve mirada sobre lo que es la tecnología de servicios

web. Ellos entregan una forma de implementar los servicios y en el resto del trabajo se presentan

algunas razones, guías, ejemplos, de por qué esta tecnología resulta adecuada para las

necesidades de INTEGRACIÓN DE APLICACIONES ORGANIZACIONALES por sobre otras

tecnologías, en qué circunstancias es más conveniente de utilizar y qué problemas o desventajas

puede traer consigo su uso.

A pesar de que existen otras tecnologías para computación distribuida, que permiten la

comunicación de sistemas en la red, tales como CORBA, COM+ o Java RMI, en comparación con



los servicios web ellas resultan limitadas, más caras o menos flexibles [orth-ws-framework, Günter, Orth.

The Web Services Framework].

Algunos de los problemas de tales tecnologías (CORBA, COM+, Java RMI) son:

� Su alta complejidad y alta inversión necesaria en arquitectura, licencias y soporte.

� Su funcionalidad está limitada a ciertos tipos de plataforma, lo que dificulta la

interoperabilidad entre sistemas heterogéneos.

� Utilizan protocolos cerrados, distintos formatos para mensajes y representación de datos.

� Existe la dependencia de un proveedor, Microsoft, Sun, IBM, CORBA, etc.

Es por que ello que el uso de la web con protocolos abiertos altamente extendidos como HTTP,

TCP-IP, SMTP, HTTPS, etc., formatos de mensajes y estructuras de datos basados en el estándar

XML, hacen a los servicios web una excelente alternativa para alcanzar comunicación e

interoperabilidad de sistemas heterogéneos [orth-ws-framework].

Esto último no implica que los servicios web sean el reemplazo obligado de otras

tecnologías de computación distribuida sino un valioso componente complementario que

permite interoperabilidad entre ellas y facilita la automatización.

Algunas guías sobre cuándo es conveniente usar servicios web y la arquitectura SOA se presentan

en los siguientes párrafos. Otras guías al respecto pueden encontrarse en el capítulo 13 de [soa-

erl, Erl, Tomas].

¿Cuándo es conveniente usar web services?

� Cuando los componentes de sistemas distribuidos corren sobre distintas

plataformas y productos.

Actualmente existen especificaciones para servicios web que permiten asegurar la

confiabilidad de entrega y que los mensajes enviados no sean modificados en su trayecto,

por lo que el aspecto de la velocidad en Internet puede solucionarse usando estas

especificaciones y una aplicación apropiada o interface (middleware).

Sobre la velocidad de transmisión, a pesar del tamaño extra que se paga por la

codificación de XML, existen soluciones como la compresión de XML o el caché de

respuestas13

que pueden mejorar la velocidad. Obviamente se necesita de más

procesamiento de la información enviada, por ejemplo para la encripción se debe pagar el

precio que involucra esta nueva operación.



� Cuando los componentes de sistemas distribuidos corren sobre distintas

plataformas y productos.

Gracias a la Interoperabilidad que entregan los servicios web y al gran soporte de la

industria de los protocolos asociados, de componentes de cualquier plataforma mediante

una simple llamada sobre HTTP estructurando su información con XML, puede

comunicarse con cualquier otra usando la tecnología de servicios web [ws-arch, W3C

http://www.w3.org/TR/2004/NOTE-wsarch-20040211/].

Así esta heterogeneidad de plataformas cuenta con un mecanismo de más alto nivel para

hacer conversar sus componentes, sin necesidad de modificar su lógica interna ni

estructura propia de cada plataforma.

Cabe recalcar que la utilidad de los servicios web en este caso, se ve cuando existe una

necesidad de comunicar estos componentes en sistemas heterogéneos (sobre todo en el

caso que se deban entregar funcionalidades como servicios).

Otra razón se aprecia cuando los distintos componentes no tienen acceso ni control sobre

los otros (casos en que distintos componentes están en diferentes dependencias).

Si los componentes se encuentran bajo el dominio de una misma unidad organizacional,

puede resultar más conveniente (aunque menos modular) no entregar funcionalidades

como servicios sino que por ejemplo, otorgar acceso directo a un depósito de datos que

utilice un componente mediante el uso de conectores especiales, Host to Host o Point to

Point, sockets, etc. Esto a su vez puede entregar más velocidad a la operación pero

perjudica la modularidad y el encapsulamiento.

13 Algunas de las propuestas para mejorar velocidades de transmisión son XOP (XML binary Optimizad Packaging) y XML

Binary Characterization.



� Cuando existe una aplicación que necesita dejarse accesible en la red y puede ser

encapsulada como un servicio.

No sólo una aplicación puede requerir ser accesible en la red sino que como ya se ha

mencionado, también puede ser información de un depósito de datos o flujo documental

[ws-arch, W3C http://www.w3.org/TR/2004/NOTE-wsarch-20040211/].

La utilidad de esta opción, es que no es necesario cambiar la lógica interna de la aplicación

para entregar el servicio sino que basta con crear un front-end que internamente llame a la

aplicación y externamente haga visible el resultado, mediante la definición de una forma de

llamado y una estructura para la información retornada (usando SOAP).

� Cuando existe un alto número de servicios que son reutilizados por distintas

fuentes.

Si las aplicaciones se pueden descomponer en partes independientes que se comunican

entre ellas, o utilizan funcionalidades comunes que pueden ser presentadas como

servicios, se puede alcanzar una alta modularidad y reutilización naturalmente.

Un punto interesante es que las fuentes que entregan los servicios se pueden encontrar

distribuidas y corriendo sobre distintas plataformas. Ejemplos de ello es contar con

componentes para autenticación, registro de operaciones, validación de datos o filtro de

mensajes.

� Cuando se requiere de descripciones formales.

Gracias a que WSDL forma parte de la tecnología de servicios web, inmediatamente se

cuenta con una definición formal de los servicios y sus interfaces. Esto no sólo permite

tener documentados y estandarizados los servicios que entrega una unidad o dependencia

sino que también permite la clasificación, búsqueda, comparación e inferencia, basados en

las definiciones de estos servicios.

Todas estas acciones abren un nuevo mundo en cuanto a la automatización de procesos y

la organización y representación formal del conocimiento, pueden entregar un mayor valor

final a los usuarios de los servicios, más que su mera funcionalidad.



� Cuando se requiere una alta accesibilidad.

Debido al alto soporte de los protocolos de la web y a la gran adopción de sus

tecnologías, el uso de servicios web permite una alta accesibilidad a sus recursos. Además

se debe tomar en cuenta en el caso particular de México su geografía, la cual dificulta

muchas veces la comunicación, pero gracias a protocolos maduros, extendidos y

soportados de la Web es viable y posible.

¿Cuándo no conviene usar servicios web o la arquitectura SOA? :

� Cuando se requiere una alta velocidad y se puede pagar el precio de contar con

sistemas acoplados.

En muchas aplicaciones, existen servicios críticos que exigen el más alto desempeño

posible. Ellas van desde juegos multi-jugador en línea, hasta aplicaciones en comercio

electrónico (e-commerce).

En aquellos casos donde un servidor suele recibir cientos de miles de requerimientos por

segundo, la rapidez de respuesta y el procesamiento son claves para brindar un buen o

mal servicio, el acoplamiento entre componentes y uso de formatos de datos no

estándares pero muy livianos, resulta ser una decisión de diseño más ventajosa.

Para tales casos la comunicación de los distintos componentes con servicios web, ya sea

por el uso de XML o llamadas HTTP, no asegura la rapidez y confiabilidad necesaria en

tales operaciones, por lo que esta tecnología no resulta ser la más conveniente.

Basándose en la posibilidad de que como en otras tecnologías los servicios web mejoren

en temas de desempeño usando compresión, abreviaciones o caché, además de la

aparición de mejores bibliotecas que implementen los servicios web y el mejoramiento del

hardware de procesamiento, habrá que evaluar en el futuro si la velocidad resultante es

suficiente para este tipo de aplicaciones.

� Cuando no se quiere dejar disponibles los servicios a través de la Web.

Cuando la comunicación de componentes no ocurre a través de la web sino al interior de

una organización (intranet), soluciones como la mensajería pueden resultar más

ventajosas, ya sea por desempeño o por contar con una API con funciones para

integración de aplicaciones, entre otras razones.



� Cuando algún aspecto de los Servicios Web no alcanza el consenso ni madurez

necesarios.

Actualmente a pesar de que la tecnología de los servicios web está altamente soportada y

aceptada, algunos aspectos como la seguridad se encuentran aún en proceso de mejora y

es por ello que ciertas especificaciones podrían no tener la madurez, acuerdo, ni soporte

necesario para cumplir con todos los requerimientos de algunas aplicaciones.

Un tema que requiere un mayor estudio y profundización, tiene que ver con la posible

ventaja o desventaja que puede resultar del uso de servicios web con respecto a los

costos.

A pesar de que según [orth-ws-framework, Günter, Orth. The Web Services Framework] “otras

tecnologías como CORBA, RMI o COM+ resultan limitadas, más caras y menos flexibles”

que los servicios web, ello no representa un estudio acabado, tan actualizado, ni considera

evaluaciones como la de Total Cost of Ownership (TCO).

El TCO calcula el costo total que implica la introducción de una solución dada, lo que

incluye infraestructura, desarrollo, mantenimiento y operación. Durante el desarrollo de

este trabajo14

no se encontró un buen estudio al respecto que avale si en temas de costos,

el uso de servicios web es comparativamente mejor que otras soluciones.

Sin embargo, existe la posibilidad de cuantificar el costo considerando varios aspectos que

se involucran en el desarrollo de una solución, haciendo un estudio de las herramientas

utilizadas durante el análisis, diseño, desarrollo e implementación (ciclo de vida del

desarrollo de software).

Tales herramientas pueden ser los mismos planes de trabajo, el análisis y cuantificación de

las horas-hombre invertidas, facturación de productos de software y hardware, evaluación

de costos de infraestructura y licencias, etc.

Este análisis de costos comprende más una actividad de la Ingeniería de Software y sería

un tema de tesis completo y muy extenso, pero lo que es importante resaltar en el aspecto

económico y tecnológico, es que los servicios web son un grupo de tecnologías y

protocolos de uso libre, soportados por organismos de fama y reconocimiento tecnológico y

mundial, flexibles en su implementación puesto que no dependen de una tecnología o

plataforma en especifico y que en muchas organizaciones han ofrecido grandes ventajas y

excelentes resultados como lo muestra a continuación el capitulo 4 de este trabajo.

14 Agosto 2006 - Junio 2007.



Capítulo

4 Casos de estudio y de éxito usando Servicios Web

Este capítulo se enfoca en la presentación de casos de éxito usando web services,

así como propuestas para desarrollar soluciones basadas en el uso de la tecnología

de los propios servicios web.

Se presentan a groso modo la función de estos servicios y los requerimientos que

se tomaron en cuenta para su análisis, diseño e implementación, aclarando que no

se presenta una documentación completa de cada uno de los casos, dado que este

documento se extendería demasiado.



4 Casos de estudio y de éxito usando Servicios Web.

A continuación se presentan 3 casos del uso de servicios web con distintos tipos de participantes,

interoperabilidad, comunicación e información. Los tres casos difieren en el uso que se le puede

dar a los servicios web para solucionar el problema.

El tomar casos de estudio o de éxito en diferentes ámbitos, busca obtener un conjunto de

necesidades, descripciones y definiciones que sean útiles para atacar la mayoría de los dominios

de la aplicación, aunque este proceso dificulta el hecho de encontrar patrones comunes, debido a

la naturaleza de cada uno de los problemas que se afrontan.

Para los casos 1 y 2 se define a groso modo el conjunto de requerimientos del problema para

luego identificar las descripciones (metadatos) que son necesarios para resolver tales

requerimientos.

Para un desarrollo más breve, los metadatos que se repiten en los distintos casos sólo son

nombrados en su primera ocurrencia.

En cada caso se identifican tecnologías, estándares y propuestas que implementan o describen

como resolver el problema. Además, se ofrecen referencias a descripciones que entregan más

detalles pero que quedan fuera del alcance de este trabajo por cuestiones de tiempo y tamaño de

este documento.

Los requerimientos han sido clasificados según el estándar de la ESA [estándar-esa, Engineering

Standard. European Spacial Agency] en funcionales, de verificación, seguridad, etc. Los metadatos

correspondientes a los requerimientos de los servicios, han sido clasificados según los 6

componentes más recurrentes identificados en todos los servicios analizados (ver Tabla 5).

Para el caso 3 se presenta un enfoque complementario a los Casos 1 y 2, presentando decisiones

de diseño, problemas, pasos y propuestas basados en la experiencia obtenida en el desarrollo de

servicios web para la Secretaría de Hacienda y Crédito Público por parte del tesista.

Cabe resaltar que el tema de seguridad se trata aquí con ejemplos que no incluyen el estándar

WS-Security, dado que su madurez sólo cubre una pequeña parte de los mensajes SOAP y la

inclusión de otros mecanismos de seguridad, que no son exclusivos del estándar.



Algunos de los mecanismos como la autenticación, el uso de certificados digitales, canales de

comunicación cifrados, análisis de vulnerabilidad de equipos (ataque de puertos en servidores) si

son tratados aquí y algunos forman parte del estándar WS-Security.

Herramientas como BEPEL de Oracle proporcionan flexibilidad para integrar en el modelado de

soluciones algunos de los mecanismos de seguridad mencionados anteriormente, sin mencionar

que forman parte de la familia de estándares para el desarrollo de servicios web.

Componente Descripción

Calidad de Servicio (QoS).

Antes de llamar a un servicio, el cliente y proveedor deben negociar variables como el uso de compresión, tipo de protocolo, encriptación, tamaño de archivos o número de caracteres por campo, etc.

Administración de Recursos.

Quién es dueño de los recursos debe caracterizarlos, permitir su búsqueda, invocación, edición, coordinación, etc. Dados los volúmenes de los recursos, son necesarias herramientas que permitan su fácil administración.

Autentificación y Validación.

Las personas, sistemas, servicios, mensajes, etc. deben autenticar su identidad y/o correctitud para ejecutar una acción o ser considerados válidos.

Seguridad. Se debe asegurar el envío, recepción, privacidad, integridad, etc. de los recursos. Para ello se pueden requerir operaciones sobre ellos, definición de restricciones, algoritmos y herramientas que implementen seguridad, etc.

Flujo Documental.

El flujo de documentos, coordinación de invocación de servicios, etc. Debe ser definido no sólo dentro del flujo de una institución del Gobierno sino como la visión de un flujo que atraviesa varias dependencias y sistemas.

Descripción de Recursos.

Los recursos deben estar caracterizados formalmente para poder buscar, acceder, inferir, etc. sobre ellos. Para ello deben existir operaciones comunes que permitan acceder a sus descripciones y entregar servicios sobre los mismos recursos. Ejemplo: validar políticas de privacidad de un cliente contra las que define un servicio.

Tabla 5: Clasificación de metadatos en los servicios en el e-Gobierno.

Los casos presentados en este capítulo no contemplan a fondo un análisis ni la documentación

completa de la solución, dado que el objetivo es enfocarse en la identificación de requerimientos y

la solución que pueda solventarlos mediante el uso de servicios web, identificando los beneficios

que pueda tener el uso de ésta tecnología.

Por tal razón se utilizan los modelos MOM y SOM (figuras 17 y 18 respectivamente) del capítulo 3

de este trabajo, para plasmar el modelo de una solución que resuelva la interacción y relaciones

entre agentes que intervienen en la entrega de uno o más servicios.

Un modelado más a detalle puede realizarse con herramientas como UML, BPEL, u otros que

detallen en más niveles las interacciones entre éstos agentes y sus relaciones, así como los

mensajes que deben intercambiarse a un nivel más bajo.

Sin embargo, este documento no tiene por objeto hacer un análisis profundo, ni un modelado de

los casos hasta sus niveles más bajos, puesto que hacerlo representa un documento muy extenso

y no es el objetivo primordial de este trabajo.



4.1 CASO 1. Servicio de Administración Tributaría (Inscripción al RFC).

El Servicio de Administración Tributaria (SAT), encargado de realizar la recaudación de impuestos

a nivel federal, cuenta con una gran variedad de sistemas para llevar a cabo su función. Su

arquitectura se compone de aplicaciones en lenguajes muy diversos y de sistemas operativos

incompatibles entre sí, soportando una operación muy importante para el gobierno federal debido a

su relevancia para la economía del país.

4.1.1 Descripción del Servicio

Para que un contribuyente pueda acceder a los servicios del Servicio de Administración Tributaria

(SAT de ahora en adelante), se requiere que primero cuente con su Registro Federal de

Contribuyentes (RFC en adelante) y una identificación electrónica. (Clave de Identificación

Electrónica Confidencial CIEC, o bien la Firma Electrónica Avanzada FEA también llamada FIEL

por el acrónimo de Firma Electrónica).

Una vez que esto ocurre, el contribuyente debe acudir por la vía tradicional a una administración

local del SAT para poder realizar el pago de sus contribuciones o bien realizar dicha operación a

través de Internet en el portal de la dependencia.

En esta tarea intervienen obviamente los gobiernos estatales, el gobierno federal, los ciudadanos y

los organismos que se encargan de la administración de los recursos financieros de la federación

como son la Secretaría de Hacienda y Crédito Público, la Tesorería de la Federación, el Banco de

México, etcétera, además de las administraciones locales que se encargan de brindar servicios a

los ciudadanos para facilitarles los medios para el pago de impuestos.

Este proceso es vital y por ende debe de ser un servicio optimizado de la mejor manera debido a

su importancia y volumen de usuarios a los que se les brinda el servicio.

La recaudación de impuestos debe ser un servicio fácil de usar para propiciar una mayor

recaudación, dado que entre más complicado sea el pago de impuestos la recaudación tiende a

ser un dolor de cabeza para los contribuyentes y por consecuencia una tarea en desuso.

Por otra parte se beneficia enormemente a la economía del gobierno federal, quien al contar con

un sistema de recaudación fácil, flexible, entendible y sobre todo ampliamente usado por los

contribuyentes, propicia una mayor recaudación de dinero disponible para el presupuesto y todos

los gastos del erario federal.



Para el caso de las transacciones electrónicas (pago de impuestos por medios electrónicos como

Internet), se requiere de la expedición de certificados y llaves publicas (mecanismos de la FEA),

éste mecanismo busca asegurar que un contribuyente realice su declaración a través de un

documento firmado electrónicamente con su FEA que brinde integridad, autenticidad, no repudio

de origen y confidencialidad a su declaración electrónica.

El servicio de Registro Federal de Contribuyentes (RFC), consiste en que una persona física o

moral puede llevar a cabo el registro de su clave para el pago de impuestos y que además sirve

para otros trámites que normalmente requieren de un identificador para cada persona, esto se

hace mediante la entrega de un documento llamado Cédula Fiscal, que contiene cierta información

para identificación de la persona (física o moral).

Hoy en día para que una persona pueda acceder a los servicios que ofrece el SAT se requiere que

cuente con su RFC, para lo cual se le piden ciertos documentos que se utilizan a lo largo de la vida

de un mexicano para identificación oficial y personal como pueden ser:

� Acta de nacimiento

� Identificación oficial:

o Credencial para votar del Instituto Federal Electoral (IFE en adelante).

o Cartilla del Servicio Militar (para el caso de los hombres, opcional para mujeres).

o Pasaporte

o Cédula Profesional

� Comprobante de domicilio. (En el caso de las personas morales, el domicilio de la empresa

que representan).

� Formato de pago.

� Clave Única de Registro Poblacional (CURP)

Una vez obtenido el documento de RFC, la persona puede realizar varios trámites y solicitar

servicios tanto públicos como privados y obtendrá el beneficio de contar con una identidad fiscal

sin duplicidades.



Trámites y/o servicios que requieren de este servicio:

1) Trámite 1: Inscripción al Registro Federal de Contribuyentes: El primer trámite que

debe realizar una persona “Física” 15

o bien “Moral” 16

, es el registro de su razón social

(RFC) para poder ser identificado fiscalmente. Los documentos que debe presentar ante la

administración local del SAT son los mencionados en el inicio de este apartado (4.1.1).

Figura 19: Trámite para solicitud de Registro al RFC, validación de documentos.

15

Persona física es un individuo (nombre y apellidos) con capacidad para contraer obligaciones y ejercer derechos. 16

Persona moral es una agrupación de personas que se unen con un fin determinado, por ejemplo, una sociedad mercantil, una asociación civil, sociedades anónimas, etc.

RFC física

Solicitud de inscripción al RFC con documentos (1)

Cédula RFC y tarjeta tributaria (6)

Validación de CURP y Acta de Nacimiento en Segob (2)

Respuesta de confirmación CURP (3)

Confirmación de datos del IFE (5)

Validación de identificación IFE y Domicilio (4)



Para el caso de la figura 19 se toma uno de los casos 17

en el que el contribuyente

presenta como identificación la credencial para votar con fotografía expedida por el

Instituto Federal Electoral (IFE), el acta de nacimiento y su CURP, de este modo el SAT

debe realizar la validación de dicha documentación.

2) Trámite 2: Solicitud de Facturas para deducción de impuestos: La deducción de

impuestos se hace a través de las declaraciones presentado los importes del Impuesto al

Valor Agregado (IVA) y del impuesto sobre la Renta (ISR), ambos requieren que una

factura contenga el desglose de ambos impuestos relacionados al contribuyente y su RFC,

así como la fecha. Estos documentos sirven para respaldar las deducciones de impuestos

al momento de realizar una declaración mensual o anual, según corresponda el régimen

del contribuyente (persona física o moral).

3) Trámite 3: Impresión de Facturas o Recibos de Honorarios: Para la impresión de las

facturas de los contribuyentes, las imprentas deben solicitar al SAT un folio de autorización

para la impresión de recibos de honorarios y facturas a fin de que la cédula fiscal aparezca

en dichos documentos, los cuales servirán de igual forma para la declaración y deducción

de impuestos.

La figura 20 ilustra el proceso para estos dos últimos trámites que podemos ver claramente

cuál es la relación que se tiene con el pago de impuestos y la declaración de los mismos,

es claro que estos dos trámites pueden ser aún más sencillos si pudieran automatizarse

las interacciones manuales entre una entidad y otra, recientemente se ha promovido

mucho la idea de contar con un sistema de facturas electrónicas, que minimicen el uso de

papel y la falsificación de documentos fiscales.

17 Los otros casos que podrían validarse, son cuando se presenta la cartilla del Servicio Militar, la cédula profesional o el

pasaporte en lugar de la credencial IFE, en cuyos casos se validaría con la dependencia que expidió dichos documentos (SEDENA, SEP o SRE respectivamente).



Figura 20: Trámites de impresión de facturas y/o recibos, y facturación de productos y servicios. 4) Trámite 4: Trámites bancarios; Los bancos y comercios normalmente utilizan sistemas

informáticos validando el RFC de sus clientes para poder identificarlos más fácilmente, por

una parte los bancos pueden obtener fácilmente las referencias bancarias y fiscales de una

persona a través de este dato, y por otro lado los comercios pueden hacer uso del RFC

para el otorgamiento de créditos, expedición de facturas, retención de impuestos y otros

servicios que deriven de su propia actividad comercial.

Algunos de los trámites bancarios que más tiempo requieren son la otorgación de créditos,

debido que a se solicita una investigación en Buró de Crédito (Comisión Nacional

Bancaria) por parte de los bancos, para validar que el RFC no esté publicado en la lista de

deudores de la banca comercial o defraudadores.

Solicitud de Impresión de facturas o recibos (1)

Folio para impresión (3)

Comercios

Facturación de productos o servicios brindados (4b)

RFC f1

Solicitud de folio de control (Internet) para Impresión de facturas o recibos con RFC (2)

Facturación de productos o servicios brindados (4a)

Declaración de impuestos retenidos (5)

Terceras personas (físicas o morales)

Imprenta (RFC) f2

Envío de declaración

Acuse de recibo de Declaración.



Dicha investigación tiene un costo para el cliente el cual debe esperar uno o varios días

para poder saber si es o no digno de crédito, sin embargo la publicación de su información

puede ser consultada fácilmente a través de la página del Buró de Crédito en Internet

(http://www.burodecredito.com.mx). Algunas de estas publicaciones representan una

violación a la ley del Secreto Bancario18

la cual debe también reformarse a fin de poder

facilitar la automatización de dichos trámites.

Figura 21: Solicitud de créditos y validaciones contra SHCP y Buró de Crédito.

Como se muestra en la figura 21, actualmente el trámite requiere todavía de papeles y de

autorizaciones que representan tiempo dinero y papeles, los cuales se pueden ahorrar o disminuir

con el simple hecho de poder disponer de cada uno de estos servicios de manera electrónica.

Dada la naturaleza de los servicios que hacen uso del RFC y de las múltiples organizaciones que

lo pueden requerir para entregar un servicio, se define una solución general que se ajusta a

cualquier institución que requiera saber o validar la información que una persona está presentando.

18 El Secreto Bancario es la ley que establece que la información financiera de las personas no debe ser pública ni

accedida si no es bajo una orden judicial de investigación financiera.

RFC f2

Banco

Buró de Crédito (Banca Comercial)

Solicitud de crédito (Hipotecario, mercantil, empresarial, etc)

Revisión de Estado Fiscal del RFC del solicitante.

Envío de datos validados por la SHCP al Banco.

Revisión de datos del RFC en el Buró de Crédito de la Banca Comercial.

Solicitud de crédito (Hipotecario, mercantil, empresarial, etc)

Otorgamiento o Rechazo de solicitud de crédito.



El servicio para obtener y hacer uso del RFC (con fines de identificación y aspectos fiscales) puede

ser ofrecido por el SAT e interactuar con otras dependencias de las siguientes formas:

� Servicio 1: Entregar un servicio web que devuelva un certificado digital que pueda ser

impreso (como sustituto de la cédula fiscal) y que tenga validez oficial con las medidas

de seguridad debidas, las validaciones de la documentación presentada para obtener

dicho documento, pueden hacerse de manera electrónica a través de servicios web

con otras dependencias como SEGOB y el IFE.

� Servicio 2: Entregar un servicio web de validación, que dado un RFC de un

contribuyente, más parámetros de certificado requerido (año, periodo, finalidad del

certificado, etc) permita certificar si un contribuyente está al corriente en impuestos, o

es digno de crédito dependiendo de su situación fiscal y legal.

� Servicio 3: Entregar un servicio web que reciba parámetros del certificado requerido, y

entregue una lista de todos los contribuyentes regulares que cumplen con tales

parámetros.

Los servicios descritos no resultan redundantes dados los requerimientos de todos los trámites que

usan éste servicio, donde por ley algunos de ellos deben contar con el certificado en papel

(dependencias de gobierno) y otros podrían manejarlo electrónicamente (empresas privadas).

4.1.2 Alternativa de solución.

Se tomará sólo el ejemplo del trámite 4 de la solicitud de un trámite bancario. La alternativa de

solución por parte del tesista se grafica en la figura 22.

Figura 22: Solicitud de crédito bancario, validando contra IFE y SHCP.

BANCO

Validación de IFE, RFC y domicilios de Solicitante y Fiador

Resultado de la Validación (OK / Neg)

Validación de RFC, situación y domicilio fiscal, FIEL de Solicitante y Fiador

Resultado de la Validación (OK / Neg)

IFE, RFC, FIEL

Fiador

Solicitante

IFE, RFC, FIEL

Formulario web Banco

Envió de respuesta y condiciones del crédito en base a validaciones (IFE, SAT)

Aceptación o rechazo del crédito otorgado

WS

WS

WS

WS



4.1.3 Especificación de Requerimientos de la solución.

Requerimientos funcionales.

RF101 Ingresar información del Contribuyente (RFC) y sus referencias personales. Descripción El contribuyente ingresa sus datos en el formulario de la institución bancaria,

usando un formulario web provisto por el Banco.

RF102 Validación de RFC y referencias personales. Descripción El contribuyente y sus referencias personales (personas físicas que conocen al

contribuyente) deben ingresar información que autentique su identidad. Esta autenticación debe ser válida para firmar el documento que posteriormente enviarán a través de un portal proporcionado para tal fin por la institución bancaria.

RF103 Negociación de petición a servicio entre cliente y proveedor. Descripción Se negocian los protocolos a usar entre los equipos del cliente y del proveedor del

servicio, capacidades disponibles, a través de un enlace desde el equipo cliente hasta el servidor por un canal seguro (uso de SSL, Secure Socket Layer)

RF104 Banco envía listado de referencias a validación con SAT e IFE etc. Descripción El Banco valida la información que está siendo capturada electrónicamente. Comentario El envío de un gran listado de referencias puede necesitar el envío de varios

mensajes para una sola operación.

RF105 Dependencias verifican datos de las referencias. Descripción Las dependencias IFE, SAT, SHCP, SEGOB, etc solicitan el certificado del RFC

tanto del solicitante de crédito así como de las referencias personales del contribuyente.

Comentario Recordemos que en el caso de las empresas privadas podría ser opcional el uso de documentos impresos en papel.

RF106 Institución Bancaria solicita resolución de información requerida. Descripción El Banco llama a un servicio en cada dependencia que contiene la información

requerida para validar los datos del solicitante así como sus referencias y estados fiscales.

Comentario Este proceso podría repetirse cuantas veces sea necesario para asegurar que los datos de las referencias y el solicitante están en orden.

RF107 Dependencias envían respuesta al banco incluyendo información requerida. Descripción La dependencia entrega la lista de solicitudes de información validadas para los

bancos que soliciten información de clientes (RFC) Comentario El envío de un gran listado de resoluciones puede necesitar el envío de varios

mensajes para una sola operación.

RF108 El cliente del banco solicita la resolución de su crédito por Internet. Descripción El cliente invoca un servicio en el banco para obtener la resolución del

otorgamiento de su crédito.



RF109 El banco confirma información y envía documentación para firma de contrato con el cliente.

Descripción El banco confirma información referente al cliente y envía documentación para aceptación del crédito que puede ser firmado electrónicamente por el cliente.

Comentario En caso de no ser digno de contrato, solamente se le avisa mediante correo al cliente el motivo de rechazo.

RF110 Negociación sobre las condiciones del crédito. Descripción Una vez aceptado el crédito, se negocia la cantidad y condiciones, así como la

forma de depósito y pago de manera electrónica a través del portal web de la institución bancaria.

RF111 Cancelación de la operación por error. Descripción En caso de recibir algún mensaje de error por algún servicio se debe terminar la

operación y restablecer el estado consistente anterior, para permitir posteriormente una operación de reintento.

Comentario El cobro por comisión puede o no aplicar dependiendo del banco y de los términos que indique en su portal.

RF112 Confirmación de éxito de la operación. Descripción Cada término de una operación debe contar con un mensaje que indique el éxito o

algún posible problema encontrado luego de ejecutar la operación.

Requerimientos de Verificaciones

RV201 Validar envío y recepción de datos y resolución. Descripción Para cada mensaje que involucra el envío de datos del RFC y la resolución, se

debe obtener una confirmación (con mensaje de regreso) de que el mensaje fue realmente enviado y recibido

Comentario Un acuse de recibo con firma digital del destinatario y folio que ampare la recepción es requerido.

RV202 Identificación y validación de personas (RFC). Descripción El contribuyente y sus referencias deben autenticar su identidad, de modo que el

envío del RFC sea válido como si hubieran firmado tal información con rubrica.

RV203 Identificación de sistemas computacionales (o sistemas de información). Descripción Las empresas (bancos y dependencias de gobierno), deben identificar su

participación en los flujos de información enviados.

RV204 Validación de mensajes y documentos recibidos. Descripción Las instituciones deben validar que los datos no hayan sido alterados y que

efectivamente fueron enviados por quienes dicen ser.

RV205 Validación de lógica de negocios. Descripción Se deben validar que las fechas de certificado sean válidas, tipos de datos y flujo

de mensaje corresponden a la API y se debe probar que las operaciones que se hicieron realmente se hicieron (auditabilidad).



RV206 Validación de compatibilidad de definiciones de políticas de privacidad Descripción El cliente debe validar sobre la descripción del servicio que sean compatibles las

políticas de privacidad (revisión de las leyes).

RV207 Validación de capacidades del servicio Descripción El cliente debe verificar que el servicio que llamará soporta las capacidades que el

requiere entre ellas encriptación, compresión, codificación de caracteres, no repudio, etc.

RV208 Validación de precondiciones y post-condiciones del servicio. Descripción Antes de invocar el servicio, el cliente y el servidor deben cumplir las

precondiciones descritas en la descripción formal del servicio. Análogo para verificación de post-condiciones.

Requerimientos de Seguridad

RS301 La información enviada, recibida y la comunicación entre los sistemas deben ser confiables.

Descripción Antes de invocar el servicio, el cliente y el servidor deben cumplir las precondiciones descritas en la descripción formal del servicio. Análogo para la verificación de post-condiciones.

Comentario Actualmente con los sistemas que cuenta Banco de México (IES) 19

para la autenticación de usuarios es suficiente para la implementación de seguridad en transacciones seguras.

RS302 Interacción entre agentes requieren autenticación. Descripción Todo agente que interactúe en un servicio cuya invocación requiere conocer la

identidad del cliente o proveedor, debe autenticar las partes en la llamada del servicio o asegurar que el agente ya fue autenticado previamente.

RS303 Manejar sesiones de servicio. Descripción Para autenticar interacciones que se encuentren dentro de un flujo de más de una

operación, se debe manejar sesiones en los servicios.

RS304 Políticas de privacidad. Descripción Al inicio del servicio debe acordarse la aceptación de las políticas de privacidad

sobre el uso de infraestructura e información por parte del cliente y el proveedor.

RS305 Privacidad de la información transmitida Descripción La información puede requerir no ser conocida por terceros. Comentario El uso de algoritmos de encripción y firmado de la información es necesario.

19 IES; es la Infraestructura Extendida de Seguridad que implementa Banco de México para las transferencias electrónicas

con el sistema SPEI (Sistema de Pagos Electrónicos Interbancarios), el esquema general de esta arquitectura se presenta en la sección de anexos



Requerimientos de Restricciones

RRS401 Tiempos de invocación a operaciones. Descripción Cada operación debe cumplir con tiempos definidos como máximo para la

transacción, time-out de llamado HTTP si corresponde, etc.

Requerimientos de Interfaces RI501 La interfaz de comunicación entre agentes en cada dependencia es

mediante servicios web. Descripción Se debe cumplir con la API de invocación definida para el servicio.

RI502 El ingreso de datos del cliente (RFC) y sus referencias se hace en el banco. Descripción El formulario web que brinda el banco es la interfaz de envío del RFC.

Requerimientos Operacionales RO601 El banco registra folio del servicio solicitado o verificaciones solicitadas. Descripción El banco almacena un registro de las operaciones solicitadas para dar

seguimiento además de implementar no repudio y auditabilidad. Comentario Esto por ejemplo puede ser útil para aclaraciones y para llevar un conteo en caso

de que se cobre por transacción excedente, además de confirmar la ocurrencia.

RO602 Uso de identificador de sesión. Descripción Para operaciones como envío de muchos RFC se puede usar identificador de

sesión para asegurar qué mensajes corresponden a una misma operación.

RO603 Banco y dependencias registran operaciones. Descripción Los bancos y las dependencias registran la información de las operaciones

realizadas (seguimiento y auditabilidad).

RO604 Uso de transacciones. Descripción Cuando se ejecuta un conjunto de operaciones que corresponden a una

operación atómica, se deben usar transacciones.

RO605 Composición de servicios. Descripción Las interacciones entre servicios que juntas forman un solo proceso, deben ser

especificadas formalmente (Se debe conocer el flujo de un trámite).

Requerimientos de Recursos RR701 Acceso a características de un recurso. Descripción Debe existir una forma de conocer el estado, identidad y características generales

y específicas de un recurso web, particularmente de un servicio web. Comentario Por ejemplo validar el flujo completo para un trámite que invoca a varios servicios.

RR702 Registro y administración de recursos. Descripción Para consulta, edición de descripciones, acceso, etcétera de recursos, debe

existir una interfaz común de administración. Comentario Para el caso de servicios puede ser una aplicación tipo UDDI mejorada, para

documentos una herramienta para administrar visualización, metadatos, etc.



4.1.4 Especificación de metadatos basados en requerimientos. A continuación se listan los metadatos necesarios para cumplir con los requerimientos presentados

anteriormente. Ellos están agrupados según los tipos de requerimientos presentados en la tabla 5

al inicio de este capítulo.

CALIDAD DEL SERVICIO (QOS) MD100 Resumen condiciones del servicio acordadas. Descripción El servidor y el cliente se envían un resumen firmado que resume y certifica las

condiciones acordadas del servicio. Soporte WS SOAP, Firma electrónica [firma electrónica], XML-Signature [xml-sig]. Comentario Para una lista más exhaustiva de las capacidades y restricciones que pueden ser

definidas para un servicio, revisar [ws-cc-workshop]. MD101 Negociación de condiciones de servicio. Descripción El cliente envía sus preferencias para ejecución del servicio (uso de compresión,

encriptación, archivos adjuntos, codificación, etc) al estilo de la negociación HTTP [rfc-http], y el proveedor retorna las capacidades soportadas y las restricciones que valdrán para la integración.

Soporte WS Uso de protocolo HTTP para la negociación, describir políticas con WS-Policy [ws-policy], DAMLS [daml] o OWL-S [owl-s], e implementar metaservicio para la negociación.

ADMINISTRACIÓN DE RECURSOS MD102 Propiedades de operaciones. Descripción Para las operaciones del flujo documental se deben almacenar propiedades de los

flujos tales como el timestamping (huella de tiempo), agente que lo solicitó, identificador de operación asociado, resultado de la operación.

Soporte WS SOAP [soap], WS-Choreography [ws-choreography], BPEL4WS [bpel4ws]

MD103 Registrar operaciones realizadas. Descripción Producto del llamado a las operaciones dentro del flujo documental, se debe

registrar las operaciones realizadas, agentes involucrados, mensajes, datos, etc. para su posterior administración.

Soporte WS Depósitos en general, aunque para almacenar documentos XML se debe considerar el uso de una base de datos XML nativa, relacional, estrategias de transformación de datos, etc.

AUTENTICACIÓN Y VALIDACIÓN MD104 Identificación para autenticarse ante sistema. Descripción Identificador único de un agente (persona, sistema, etc.) que se autentican ante

otro agente. Soporte WS WS-Federation [ws-federation], WS-Security [ws-security], Firma electrónica [firma

electrónica], SAML [saml]



MD105 Validación de mensajes enviados y recibidos. Descripción Los mensajes que intercambian el cliente y proveedor, deben estar descritos en el

servicio, y cumplir con la estructura definida. Soporte WS XML Schema [xml-schema], SOAP [soap], WSDL [wsdl].

MD106 Alcances de la autenticación. Descripción Un servicio puede utilizar identificadores de sesión para mantener autenticado a

algún agente por un tiempo dado o hasta que ocurra algún evento. Además un servicio puede delegar su autenticación a otro servicio siempre que las políticas lo permitan.

Soporte WS WS-Federation [ws-federation], WS-Security [ws-security], SAML [saml], Cookies.

MD107 Validación de precondiciones y postcondiciones. Descripción El servicio debe validar contra la definición formal de las precondiciones y

postcondiciones que la invocación es válida, basado en aserciones. Soporte WS BPEL4WS [bpel4ws], SAML [saml] Comentario Las precondiciones y postcondiciones son parte de la descripción del servicio.

SEGURIDAD MD108 No repudio. Descripción Identificador que permite implementar no repudio (el usuario ya debe estar

autenticado), registrando las operaciones, agentes involucrados. Soporte WS WS-Security [ws-security], XML Signature [xml-sig] Comentario Este identificador se puede obtener en el resumen de las condiciones del servicio

acordadas.

MD109 Entrega confiable Descripción Los mensajes que intercambian el cliente y el proveedor deben ser realmente

entregados, se debe asegurar su integridad y privacidad. Soporte WS WS-Security [ws-security], XML-Encryption [xml-encryption], XML-signature [xml-

sig], WS-Reliability [ws-reliability]

MD110 Procesamiento en los nodos. Descripción Se pueden definir instrucciones de procesamiento, que indiquen que nodos

deberían procesar los mensajes y de que forma. Soporte WS SOAP headers [soap], WS-Addressing [ws-addressing]



FLUJO DOCUMENTAL MD111 Definición formal del flujo documental. Descripción Para cada flujo de información entre agentes se deben especificar los mensajes,

agentes participantes, transacciones, etc. Soporte WS XML Schema [xml-schema], SOAP [soap], WSDL [wsdl], WS-Choreography [ws-

choreography], WS-Coordination [ws-coordination], BPEL4WS [bpel4ws]. Comentario Para revisar un modelo de datos con los metadatos ver [ws-choreography].

MD112 Resultado de operaciones. Descripción Para cada flujo invocado se debe conocer el resultado de la operación. Se

necesita un mensaje de respuesta de operación que contenga el código de retorno, descripción de la semántica del código. Además se debe entregar un resumen de la operación realizada, sea exitosa o no.

Soporte WS HTTP [rfc-http], SOAP [soap], WSDL [wsdl]. Comentario La definición del flujo documental debe considerar las acciones a tomar y los

responsables de ejecutarlas, en caso de retorno de algún código de error.

DESCRIPCIÓN DE RECURSOS (comunes, servicios, documentos) MD113 Estructura de documentos. Descripción Se debe definir la estructura de los documentos intercambiados. Soporte WS XML Schema [xml-schema] Comentario Se necesitan herramientas para administrar esquemas centralizadamente en el

Gobierno (capítulo de desafíos).

MD114 Descripción de políticas del cliente y del servicio. Descripción El cliente y el proveedor deben describir las políticas que los rigen, a modo de

poder automatizar el proceso de negociación y validar la compatibilidad de sus políticas.

Soporte WS WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s]

MD115 Descripción de capacidades y restricciones de servicios. Descripción Cada servicio describe formalmente sus restricciones y capacidades soportadas,

por ejemplo archivos adjuntos, compresión, o restricciones como fechas en que el servicio se encuentra disponible, límite de conexiones, etc.

Soporte WS WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s] Comentario Para una lista más exhaustiva de las capacidades y restricciones que pueden ser

definidas para un servicio, revisar [ws-cc-workshop]

4.1.5 Reflexiones sobre el caso 1 Problemas y necesidades encontradas

� Cuando los recursos generados por una institución bancaria son enviados a alguna

dependencia de gobierno a través de un intermediario, se debe asegurar confidencialidad y

la integridad de la información. Este tipo de procesos suceden cuando las dependencias de

gobierno involucradas en el flujo envían la resolución al banco.



� La transmisión de grandes volúmenes de información en servicios no es un tema resuelto.

Más allá de usar el estándar HTTP, FTP, etc. y compresión, debemos considerar en el

diseño algunos cuestionamientos como es: ¿Conviene definir transacciones (operaciones

atómicas) que llamen varias veces a un servicio o bien usar archivos adjuntos?

� Se debe usar un lenguaje para la definición formal de las capacidades, restricciones,

precondiciones, post-condiciones, políticas de privacidad, seguridad, etcétera sobre los

servicios. Idealmente este lenguaje debe ser computable y proveer inferencia. Ver [wscc-

workshop] para profundizar sobre capacidades y restricciones, para definición de políticas

ver [ws-policy], [ws-cc-workshop], para ahondar en temas de precondiciones y

postcondiciones ver [daml], [saml].

� Algunos servicios pueden requerir ser síncronos o asíncronos. En el caso que el banco

envía los RFC para obtener la resolución, el tiempo necesario para recibir la resolución

puede variar y ser muy grande. Es por ello que se puede definir un servicio asíncrono que

retorne la resolución o se puede definir un servicio en la dependencia de gobierno (SAT

por ejemplo), que retorna la resolución cuando es llamado. Esto último tiene la desventaja

que requiere ser manualmente llamado pero simplifica los tipos de interacciones.

Componentes o metadatos recurrentes

� Se necesita describir la comunicación de aplicaciones, repositorios, etcétera que permita

modelar la lógica del negocio, la cuál incluye transacciones, flujos condicionales, y más. La

idea es coordinar el uso de servicios web y otro tipo de tecnologías. Algunas tecnologías

que soportan estos requerimientos son: BPEL4WS [bpel4ws], WSChoreography [ws-

choreography] y WS-Coordination [ws-coordination].

� La autentificación de agentes (sistemas computacionales, personas, instituciones), es una

componente clave en toda interacción que requiere identificar a quien solicita y provee el

servicio. En el Caso 1, se puede requerir autenticar durante un flujo particular, mantener

vigente el estado autenticado de un agente o revocar la autentificación. Para ello se

pueden usar aserciones que indiquen el estado de autentificación de un agente (ver [saml]

para ahondar en el uso de aserciones en servicios web.)

� Para acordar las condiciones de invocación de un servicio se requiere un protocolo de

negociación de capacidades, restricciones, precondiciones, post-condiciones, políticas de



privacidad, seguridad, etcétera, entre el servicio y el cliente de manera similar a lo que

hace HTTP 1.1 hoy en día [rfc-http].

� Se deben especificar y verificar las operaciones y acuerdos que se realizaron y tomaron,

usando resúmenes de transacciones, operaciones, resultado de llamado a servicios,

registro de operaciones, etc. Es decir, se necesitan metadatos para comunicar resultado de

operaciones y acuerdos y una manera de almacenarlos.

� Se debe contar con descripciones de los recursos que interviene en los servicios, ya sean

documentos, imágenes o los mismos servicios. Estas descripciones van desde los

metadatos intrínsecos al recurso (por ejemplo estructura interna de un documento) hasta

descripciones que definan las políticas de acceso que lo rigen.

Aprendizaje y conclusiones

� A pesar de que el proceso del caso 1 es uno solo, existen distintos estados por los que

pasa en diferentes instituciones. Además, cada institución mantiene privadas las

definiciones de su lógica interna, modelos de datos, etcétera por lo cual no se puede

acceder a tal información desde otra institución. Es por ello que se debe coordinar la

definición del proceso completo y las interacciones de los servicios web como un flujo

documental de vistas sobre otros flujos documentales.

� Debido a los distintos tipos de trámites, la naturaleza de ellos y sus instituciones, para un

mismo servicio se debe proveer distintas operaciones de invocación. Por temas de

rendimiento, reutilización, legales, etcétera, en el caso 1 puede ser necesario crear los

servicios: Servicio 1, Servicio 2 o Servicio 3. Para definir cuales serán las operaciones que

debe definir un servicio, se debe analizar cuales son sus potenciales usos (en otros

trámites), que requerimientos tienen esos trámites y cuál es el costo-beneficio de elegir

cada uno.

� La integración de los privados en el e-Gobierno resulta altamente beneficiosa, ya que son

parte activa de una gran cantidad de servicios que entrega el gobierno. Para la integración

de instituciones privadas en el e-Gobierno se deben incluir mecanismos de autenticación

que permita que sus servicios sean usados seguramente desde los servicios del gobierno

o viceversa. Un ejemplo de ello puede ser el pago de un servicio cargándolo a la cuenta

corriente del cliente de algún banco.



� Para ejecutar exitosamente un servicio se debe verificar el cumplimiento de todas las

condiciones que define el cliente y proveedor de servicios, disponibilidad y estado del

servicio antes de la invocación, el cumplimiento del contrato en tiempo de ejecución y el

resultado al finalizar el servicio. Es decir, se deben validar todas las acciones y sus

condiciones. Para ello se deben describir formalmente todas estas características de los

recursos.

� Las descripciones de un servicio no tienen que estar necesariamente disponibles como

simples documentos, sino que también mediante la definición de servicios que entregan

información sobre el servicio, es decir, metaservicios. Así los metaservicios (servicios

sobre servicios) pueden usarse para entregar una API estándar de administración de

recursos.

� Dados los volúmenes, complejidad de modelo de datos, mantenimiento de metadatos,

etcétera de los recursos que maneja el gobierno en los servicios que entrega, se necesita

de herramientas para administración de recursos.

� Esta es una clara muestra del ofrecimiento de mejores servicios, que aún cuando se ha

avanzado mucho en la entrega de un servicio para la recaudación de impuestos más

amigable y fácil de usar, se puede mejorar aún más para incrementar la productividad de la

propia dependencia encargada de recaudar el dinero para el gasto público.

� Es cierto que a nadie nos gusta pagar impuestos, pero también es cierto que si TODOS

contribuyéramos de manera proporcional, la recaudación de impuestos sería más sencilla y

menos costosa, sin embargo el objetivo es tratar de mejorar los servicios para que más

gente contribuya y el peso de pagar impuestos recaiga sobre más personas para conseguir

las metas de vivir mejor y servir mejor.

4.2 Caso 2: Sistema de Pago Centralizado de Nómina Federal.

La Secretaria de Hacienda y Crédito Público (SHCP, Hacienda de ahora en adelante), se compone

de varios suborganismos que interactúan entre sí para poder llevar a cabo la administración de los

recursos recabados por el SAT a través de impuestos, a la vez que orquesta la erogación de

presupuestos para el manejo de la economía del país.



Algunos de los organismos que interactúan con Hacienda son la Tesorería de la Federación

(TESOFE), las Subsecretarias de Egresos y de Ingresos, el Banco de México, el Banco Mundial, la

Oficialía Mayor etc.

La secretaria de Hacienda en conjunto con algunos de estos organismos mencionados, se

encargan de proporcionar los recursos económicos a las demás dependencias de gobierno de

acuerdo al presupuesto otorgado a cada una en el presupuesto anual, el cuál se emite a finales de

cada año.

El pago de nóminas es una actividad que involucra una gran cantidad de procesos, tanto en las

dependencias como en el resto de los organismos e instituciones que participan en el flujo para el

pago de una quincena a los trabajadores del Estado.

En este caso se plantea una solución que se implementa por el tesista en los tiempos en que se

desarrolla este trabajo de tesis, esta solución realiza el pago de nóminas a nivel federal a través

del sistema SPEI (Sistema de Pagos Electrónicos Interbancarios) de Banco de México y del SIAFF

(Sistema Integral de Administración de Fondos Federales) de la SHCP, queda pendiente la parte

de automatizar la apertura de cuentas en las instituciones bancarias.


El proceso de generación de pago de nóminas es propio de cada una de las dependencias de

gobierno, el cálculo y la forma en que se lleva el control de incidencias por empleado es propio de

cada una de las aplicaciones de las dependencias, dado que varían en conceptos y prestaciones.

Una vez que las dependencias realizan el cálculo de su nómina se solicita a la Secretaria de

Hacienda que se asigne el presupuesto para el pago de dicha nómina (movimiento quincenal),

después se solicita a través de una Cuenta por Liquidar Corriente (CLC) en el sistema SIAFF, la

cantidad a depositar en el banco con el cual tiene convenio la dependencia para el depósito de

nómina de sus empleados, la Secretaria de Hacienda por su parte debe validar que la CLC

corresponda con el presupuesto asignado, para posteriormente retirar de la cuenta de la TESOFE

la cantidad indicada y depositar al banco correspondiente para el pago de la nómina de la

dependencia.

El banco por su parte realiza la distribución del pago hacia los cuentahabientes (empleados) de

acuerdo con el archivo de nómina que fue proporcionado por la dependencia.



Figura 23: Mecanismo semiautomático para pago de Nómina Federal

Este proceso en algunos momentos manual, representa un desfase en los tiempos de pago de

nóminas federales, ya que el proceso se debe realizar de 3 a 5 días anticipadamente debido a que

los procesos de validación dependen de un visto bueno (no automatizado) y que representa un

gasto innecesario, casos como este se presentan de igual forma en la iniciativa privada.

Para el caso de los depósitos y transferencias electrónicas, actualmente ya se cuenta con los

pagos electrónicos y las transferencias electrónicas entre instituciones de la Banca Comercial.

El Banco de México actualmente ofrece el servicio de SPEI (Sistema de Pagos Electrónicos

Interbancarios), que permite realizar pagos entre bancos de manera segura, fácil y confiable,

debido a que implementa mecanismos de seguridad altamente confiables y probados.

El servicio de pago de nóminas de los bancos, es un convenio por el cual la dependencia utiliza las

facilidades de algún banco para poder realizar el depósito de nómina a los empleados, sin

embargo esto obliga a que los empleados tengan que usar forzosamente los servicios de dicho

banco para poder disponer de su dinero.

Para que una persona (empleado) pueda acceder a los servicios que ofrece el banco debe realizar

el trámite de solicitar una cuenta de nómina en el banco y posteriormente proporcionar a la

dependencia el número de cuenta a fin de que se deposite el pago quincenal de su nómina.

VPN

Dependencias (SEP, SEGOB, SCT, etc)

Banco

SIAFF SHCP TESOFE

$$$

$ $ $

CLC

Archivo firmado y ensobretado



Una vez que se tiene la cuenta, el empleado debe solicitar a su banco la activación de los servicios

que desea utilizar (a través del portal web o por la vía telefónica).

Para realizar dicho trámite se requiere contar con los siguientes datos:

� Identificación oficial con fotografía.

� Comprobante de domicilio.

� Solicitud de apertura de cuenta.

Una vez obtenida la cuenta la persona puede comenzar a recibir sus pagos de nómina en dicha

cuenta, solicitar los servicios que ofrece el banco y obtener los beneficios de manejar su dinero sin

peligro de perdida física dado que la mayoría de los movimientos serán de manera electrónica.


Trámite 1: Solicitud de apertura de cuenta: El primer trámite que debe realizar una persona para

poder recibir depósitos de nómina es solicitar la apertura de su cuenta en el banco con el cual

tenga convenio la dependencia, debiendo presentar identificación, comprobante de domicilio y su

solicitud de apertura de cuenta.

Figura 24: Trámite para solicitud de Cuenta de nómina para depósitos de la dependencia.

Empleado

Dependencia

Banco Empleado del Banco

Documentos

Cuenta

Cuenta

$$

$$

1

2 5

4

3



Trámite 2: Servicio de pago de nóminas federales: Tal y como se mostró en la figura 23 de este

capítulo, el pago de la nómina federal se lleva a cabo mediante un proceso semiautomático, que

comienza con el envío del archivo de nómina de la dependencia hacia el sistema SIAFF de SHCP

el cuál realiza entre otras validaciones, que el presupuesto solicitado corresponda con el asignado

de acuerdo a las plazas presupuestadas, que la cuenta de la cual se va a retirar el dinero tenga

fondos suficientes para la transferencia al banco, etc. Y finalmente, la Tesofe realiza la

transferencia al banco que realiza la dispersión de los pagos hacia los empleados.

Tramite 3: Solicitud de reintegro de pagos no efectuados por el banco: Dado que los

movimientos de personal no son identificados inmediatamente en las dependencias, en parte

debido al desfasamiento del pago, se presenta el caso en que el pago no puede ser efectuado al

empleado debido a que la cuenta ya no existe, o a que hubo incidencias que no se afectaron en el

periodo, se retrasaron movimientos de personal, etcétera por ello, la dependencia debe exigir el

regreso del dinero que no fue depositado a través de la TESOFE, que realiza mediante un

documento la solicitud de devolución de saldos pendientes de liquidar al banco, dicho proceso

normalmente lleva implícito un procedimiento burocrático que retarda el regreso de dichos pagos,

que mientras tanto genera intereses a favor del banco.

Como se muestra en las figuras 23 y 24, estos trámites requieren todavía de papeles y de

autorizaciones que representan tiempo y dinero, factores que son muy importantes cuando se

habla de reducción de costos en los recursos del Estado.

Con base en todos los servicios que requieren del uso de los bancos para el pago de nóminas, se

propuso una solución general por parte de las áreas de tecnologías de SHCP y de Banco de

México que abarca la mayoría de los trámites y servicios que se necesitan para poder automatizar

los procesos para dicha actividad.

El servicio para poder realizar los depósitos de nómina e interactuar con las dependencias e

instituciones que se involucran en el proceso debe cumplir con los siguientes servicios generales:

� Servicio 1: Entregar un servicio web que devuelva un certificado digital a las dependencias,

para que puedan enviar sus archivos de nómina firmados y ensobretados de manera

segura a través de la VPN (Virtual Private Network, Red Privada Virtual) de la secretaria

de Hacienda.

� Servicio 2: Entregar un servicio web de solicitud de cuenta de nómina en el banco para

poder obtener los servicios de la institución financiera y poder proporcionar el número de

cuenta a la dependencia y poder obtener ya los depósitos de nómina.



� Servicio 3: Brindar un servicio web a la entrada del sistema SIAFF para procesar los

archivos que llegan de las dependencias, procesarlos, validarlos y posteriormente otro

servicio web que realice la transferencia hacia Banco de México para que a través del

sistema SPEI pueda realizar la dispersión de pagos hacia los bancos (sin importar de que

banco se trate).

Estos servicios se complementan para automatizar todo el proceso de pago de nóminas desde el

cálculo, los pagos electrónicos que se disparan desde las dependencias, hasta la dispersión de

pagos por parte del Banco de México.

4.2.2 Solución Desarrollada.

La solución resulta de la propuesta hecha para la SHCP haciendo uso de tecnologías disponibles

también en Banco de México y usando estándares J2EE, dicha solución se presenta en la figura

25.

Figura 25: Propuesta de solución para el pago de nóminas usando servicios web para automatizar el proceso.

Servicio Web

Dependencias (SEP, SCT, PGR,

SIAFF (SHCP)

SPEI (BANXICO)

Monitoreo web de pagos

Envío de archivos seguros

Procesamiento y validaciones SIAFF

Envío de pagos a SPEI

Dispersión de pagos hacia Bancos

$$ deposito en cuentas de empleados



Solicitud de apertura de cuenta por ServicioWeb

Envío de cuenta de depósito vía Servicio Web

Indica el uso de un Servicio Web.



4.2.3 Especificación de Requerimientos de la solución.


RF101 Ingresar información del empleado para solicitud de cuenta en banco. Descripción El empleado captura su información en el formulario web del banco con alguna

firma electrónica para validar su información

RF102 Validación de información y su certificado. Descripción El empleado debe ingresar información que autentique su identidad. Esta

autenticación debe ser válida como para firmar el documento de contrato que posteriormente enviará el banco para cerrar el proceso de apertura de cuenta.

RF103 Negociaciones de comunicación cliente-servidor (empleado-banco). Descripción El servicio web debe ser capaz de iniciar las validaciones de ancho de banda y

privacidad del canal de comunicaciones.

RF104 El banco envía al usuario (empleado) su número de cuenta. Descripción El banco valida la información del certificado y del solicitante para realizar

apertura de cuenta en la base de datos del banco Comentario El envío de muchas peticiones o solicitudes puede requerir el envío de muchos

mensajes para la operación.

RF105 El empleado envía su información y número de cuenta a la dependencia. Descripción La dependencia recibe a través de un servicio web el número de cuenta del

empleado junto con el certificado que le identifique para validar en su sistema de RH los datos del empleado.

Comentario Para algunos casos la ley podría exigir que exista una rúbrica, sin embargo aquí se propone el uso de certificados y firmas digitales.

RF106 Dependencia realiza proceso de pago de nómina interno. Descripción La dependencia realiza sus movimientos de corte para comenzar el cálculo de la

nómina quincenal, procesando las nuevas cuentas que llegan por el servicio web. Comentario El proceso puede repetirse varias veces a lo largo del cierre de nómina, esto con

el fin de poder realizar el cálculo de todas las incidencias y de validar los certificados que lleguen como parte de una nueva petición de cuenta de nómina.

RF107 Dependencia obtiene el archivo de nómina para envío a SIAFF (SHCP). Descripción La dependencia termina su cálculo de nómina y obtiene un archivo que contiene

la información del pago de nómina quincenal, se le aplican mecanismos de seguridad (firmado y ensobretado) y se envía al SIAFF a través de la VPN.

Comentario El envío de un gran número de archivos puede requerir una infraestructura con un canal de ancho de bando amplio para la rápida transferencia de archivos, además de un medio seguro como un canal seguro o cifrado con SSL( o bien una VPN)

RF108 El SIAFF procesa archivos que lleguen de las dependencias a través del WS. Descripción El sistema SIAFF a través de un servicio web que este escuchando peticiones,

será capaz de procesar dichos archivos una vez que los recupere en claro (verificación de firma y desensobretado).



RF109 Una vez validado y procesado el archivo de nómina se envía hacia SPEI. Descripción Una vez que el SIAFF ha validado totalmente el archivo con todas sus

dependencias (cuentas, presupuesto, aprobaciones, etc) se le aplican mecanismos de seguridad para el envío hacia Banco de México (SPEI)

Comentario En caso de no concluir satisfactoriamente el proceso de validación, se comunica a la dependencia si el archivo fue rechazado y las causas.

RF110 Recepción de archivos en Banco de México con SPEI. Descripción El Banco de México recibe peticiones para procesamiento de archivos a través de

un servicio web que recupera los archivos en claro (verificación de firma y desensobretado) y procede a realizar validaciones previas al envío.

RF111 Dispersión de pagos hacia los bancos con SPEI. Descripción Una vez validado el archivo, se envía un acuse de recibo a SIAFF para indicar

que se procederá a realizar la dispersión de pagos hacia las cuentas de los empleados en los bancos correspondientes.

Comentario En caso de que el archivo contenga errores, se procede a regresar el archivo y en el acuse de recibo se indican los motivos de rechazo.

RF112 Confirmación de depósitos en cuentas de empleados. Descripción El monitoreo de los pagos se puede hacer directamente desde la dependencia

hacia Banco de México, a través del portal APL-SPEI que sirve para el monitoreo de los pagos enviados hacia Banco de México.


RV201 Validar envío y acuse de recibo para solicitud de apertura de cuenta Descripción Para cada transacción entre cliente y servidor, se debe enviar un acuse de recibo

y confirmación sobre la apertura de la cuenta en banco. Comentario Un acuse de recibo con firma digital del destinatario y folio es lo recomendable.

RV202 Verificación de datos de cuenta habiente por parte del banco. Descripción El Banco deberá realizar las validaciones correspondientes de la información

enviada por el empleado, corroborando dicha información con las dependencias que implique (IFE, SEDENA, ARA, etc).

Comentario Lo mejor es que estas validaciones se realicen vía un servicio web por cada una de las dependencias involucradas en el flujo y validación de datos.

RV203 Identificar infraestructuras de cada una de las instituciones involucradas. Descripción Cada una de las dependencias y de los bancos debe realizar una revisión a su

infraestructura tecnológica a fin de soportar la operación del flujo completo.

RV204 Validación de cuentas y datos recibidos. Descripción Las dependencias deberán poder corroborar con los bancos a través de servicios

web la existencia de las cuentas y la disponibilidad para recibir transferencias electrónicas.



RV205 Validaciones de reglas de Negocio. Descripción Es importante validar que los datos de cada empleado correspondan con los

documentos electrónicos que se utilizan en el flujo, se debe validar que las fechas de certificado sean aún vigentes, que los tipos de datos y flujo de mensaje corresponden a las especificaciones para cada interfaz o bien para cada aplicación, y se debe probar que las operaciones que se realizaron, realmente se llevaron a cabo (auditabilidad).

RV206 Definir las políticas de seguridad a seguir y a implementar en su caso. Descripción Tantos los clientes como los servicios involucrados deben validar que los

mecanismos de seguridad implementados a lo largo del flujo corresponden de principio a fin con la política de seguridad definida para todo el proceso.

RV207 Validación de capacidades y disponibilidad de los servicios. Descripción Los clientes que se encuentren a lo largo del flujo deben validar que los servicios

que usarán, cuenten con la capacidad y disponibilidad necesarios para poder soportar la operación con grandes cantidades de transacciones, además de soportar los mecanismos de seguridad como encriptación, compresión, codificación de caracteres, no repudio, etc.

RV208 Validación de condiciones previas y finales de los servicios. Descripción Los clientes deben de validar que antes de invocar el servicio se cumplan las

condiciones necesarias para la operación, esto se puede consultar fácilmente en la definición del servicio, de igual forma esto es análogo para verificación de las condiciones finales del servicio.


RS301 La información enviada, recibida y la comunicación entre los sistemas deben ser confiables, utilizando mecanismos y medios seguros.

Descripción Antes de invocar los servicios los clientes deben asegurarse de cumplir con las especificaciones de seguridad de los servicios, como pueden ser el uso de encripción, firmas digitales, canales de comunicación cifrados, uso de VPN, etc.

Comentario La comunicación entre Banco de México y la SHCP actualmente dispone de una VPN con canales de comunicación cifrados y uso de la arquitectura IES de Banco de México para la transferencia de archivos de pagos.

RS302 Autenticar a cada una de las entidades involucradas en el flujo. Descripción Toda entidad que tenga interacción con un servicio del flujo, deberá requerir la

autenticación del cliente que está solicitando para acceder al servicio que usará.

RS303 Convenios y políticas de seguridad y privacidad. Descripción Cada una de las partes involucradas (cliente y servidor) deberán aceptar y cumplir

los convenios y políticas de seguridad y privacidad a fin de ser coherentes con el flujo y no sufrir desviaciones.

RS304 Confidencialidad de información que es transmitida. Descripción La información que se transmite no debe ni puede ser conocida por terceros no

involucrados en el flujo.



RS305 Realizar análisis de vulnerabilidad de equipos, escaneo de puertos que no utilizan las aplicaciones.

Descripción Antes de publicar un servicio en Internet o en cualquier red, se requiere determinar que puertos no son utilizados por las aplicaciones que interactúan a fin de reducir la vulnerabilidad de un equipo ante un ataque de penetración (PEN-TEST, Penetretion Test – Prueba de penetración).

Comentario Los puertos que son utilizados normalmente por los hackers, deben ser cerrados o bien filtrados a través de un firewall.


RRS401 Tiempos de invocación a operaciones y tamaño de archivos a transferir. Descripción Las operaciones que se realicen deben conocer los tiempos y tamaños límite de

operaciones y transferencia de archivos, a fin de cumplir con tiempos definidos como máximo para la transacción, time-out de llamado HTTP o de SFTP.

Requerimientos de Interfaces RI501 La interfaz de comunicación entre instancias en cada dependencia es

mediante servicios web. Descripción Se debe cumplir con la API de invocación definida para el servicio.

RI502 El ingreso de datos del empleado se hace en el banco y en la dependencia. Descripción El formulario web que brinda el banco es la interfaz de envío de solicitud de

apertura de cuenta, además del portal para seguimiento de pagos de SPEI en Banco de México.

Requerimientos Operacionales RO601 El banco guarda registro de la solicitud de apertura de cuenta. Descripción El banco almacena un registro de la operación solicitada por el empleado para dar

seguimiento posteriormente a quejas o inconformidades Comentario Esto es necesario, en caso de que la dependencia requiera validar información

sobre la cuenta aperturada por el empleado (cliente).

RO602 Uso de sesiones para identificar cada operación. Descripción Si por alguna razón la operación de solicitud de apertura no fuera exitosa, se

deben guardar en sesión los datos del usuario (empleado) que está solicitando el servicio.

RO603 Banco y dependencias guardan información y registro de la apertura Descripción Los bancos y las dependencias guardan registro e historial de las transacciones

sobre la cuenta para aclaraciones.

RO604 Uso de operaciones en volumen y transacciones. Descripción Las operaciones que llevan a cabo un gran número de operaciones o volumen

muy grande, es recomendable que utilicen transacciones para operaciones atómicas.



Requerimientos de Recursos RR701 Disponibilidad y acceso a las propiedades de un recurso. Descripción Sobre todo para el monitoreo de los pagos, debe existir una forma de conocer el

estado, identidad y características generales y especificas de un recurso web, particularmente de un servicio web.

Comentario Esto por ejemplo podría permitir validar el flujo completo definido para un trámite que invoca a varios servicios, como lo es el APL-SPEI para monitoreo de los pagos en Banco de México

RR702 Administración de los servicios y sus recursos. Descripción Cuando se desea consultar, editar características y acceder a recursos, se

requiere contar con interfaces que permitan conocer esta información de manera segura, a fin de tener un control sobre el flujo y los estados de la información, es decir la administración de la información y su auditabilidad.

4.2.4 Especificación de metadatos basados en Requerimientos. Nuevamente se listan los metadatos necesarios para cumplir con los requerimientos presentados

anteriormente para este caso. Se toma como referencia la tabla 5 al inicio de este capítulo para

poder agruparlos de acuerdo a su naturaleza.

CALIDAD DEL SERVICIO (QoS) MD100 Concentrado de condiciones acordadas. Descripción Para cada transacción, el servidor y el cliente se envían un acuse de recibo

firmado que resume y certifica las condiciones acordadas del servicio Soporte WS SOAP, Firma electrónica[firma electrónica], XML-Signature [xml-sig] MD101 Definición de capacidades para brindar servicio. Descripción Los proveedores de servicios deben asegurar que la disponibilidad y rendimiento

del servicio que ofrecen, no afectará en ningún momento la operación del proceso ni la interrupción del flujo.

Soporte WS

Uso de protocolo HTTP para la negociación, uso de SFTP (ftp seguro) para transferencias de archivos, canales de comunicaciones con ancho de banda suficiente y seguro, describir políticas con WS-Policy [ws-policy], DAMLS [daml] o OWL-S [owl-s] e implementar metaservicio para la negociación.

MD102 Monitoreo del flujo. Descripción Para las operaciones del flujo documental se debe poder auditar en cualquier

momento el estatus de la transacción, disponiendo de una interfaz que permita conocer al empleado y a la dependencia en que momento se encuentra la transacción.

Soporte WS SOAP [soap], WS-Choreography [ws-choreography], BPEL4WS [bpel4ws]



ADMINISTRACIÓN DE RECURSOS MD103 Mantener Registro de las operaciones realizadas. Descripción Producto del llamado a las operaciones dentro del flujo documental, se deben

registrar las operaciones realizadas, agentes involucrados, mensajes, datos, etc. para su posterior administración

Soporte WS Repositorios en general, aunque para almacenar documentos XML se debe considerar el uso de una base de datos XML nativa, relacional, estrategias de transformación de datos, etc.

AUTENTICACIÓN Y VALIDACIÓN MD104 Identificación para autenticarse ante sistema. Descripción Identificador único de un agente (persona, sistema, etc.) que se autentican ante

otro agente. Soporte WS WS-Federation [ws-federation], WS-Security [ws-security], Firma electrónica [firma

electrónica], SAML [saml]

MD105 Validación de mensajes enviados y recibidos. Descripción Los mensajes que intercambian el cliente y proveedor deben estar descritos en el

servicio y cumplir con la estructura definida Soporte WS XML Schema [xml-schema], SOAP [soap], WSDL [wsdl].

MD106 Alcances de la autenticación. Descripción Un servicio puede utilizar identificadores de sesión para mantener autenticado a

algún agente por un tiempo dado, o hasta que ocurra algún evento. También es posible que un servicio pueda delegar su autenticación a otro servicio, siempre que las políticas lo permitan.

Soporte WS WS-Federation [ws-federation], WS-Security [ws-security], SAML [saml], Cookies.

MD107 Validación de precondiciones y postcondiciones. Descripción El servicio debe validar contra la definición formal de las precondiciones y

postcondiciones que la invocación es válida, basado en aserciones. Soporte WS BPEL4WS [bpel4ws], SAML [saml] Comentario Las precondiciones y postcondiciones son parte de la descripción del servicio.

SEGURIDAD MD108 No repudio. Descripción El uso de certificados es un medio identificador que permite implementar no

repudio (usuario ya debe estar autenticado), registrando las operaciones, agentes, involucrados.

Soporte WS WS-Security [ws-security], XML Signature [xml-sig] Comentario Este identificador se puede obtener en el resumen de las condiciones del servicio

acordadas.

MD109 Entrega confiable. Descripción Tanto los archivos como los mensajes que intercambian el cliente y proveedor

deben ser realmente entregados, se debe asegurar su integridad y privacidad. Soporte WS WS-Security [ws-security], XML-Encryption [xml-encryption], XML-signature [xml-

sig], WS-Reliability [ws-reliability]



FLUJO DOCUMENTAL MD110 Definición formal del flujo documental. Descripción Para cada flujo de información entre agentes se deben especificar los archivos,

mensajes, agentes participantes, transacciones, cerificados a utilizar, mecanismos de seguridad, etc.

Soporte WS XML Schema [xml-schema], SOAP [soap], WSDL [wsdl], WS-Choreography [ws-choreography], WS-Coordination [ws-coordination], BPEL4WS [bpel4ws].

MD111 Resultado de operaciones. Descripción Cada invocación del flujo debe conocer el resultado de la operación. Si es

necesario, se puede implementar un mensaje de respuesta (acuse de recibo o aviso de transacción exitosa), es necesario tener un código de retorno o código de error según sea el caso, descripción de la semántica del código. Además se debe entregar un resumen de la operación realizada, sea exitosa o no.

Soporte WS Http [rfc-http], SOAP [soap], WSDL [wsdl]. Comentario La definición del flujo documental debe considerar las acciones a tomar y los

responsables de ejecutarlas en caso de retorno de algún código de error.

DESCRIPCIÓN DE RECURSOS MD112 Layout de formularios. Descripción Se debe definir el layout para los documentos que se vayan a capturar en los

formularios web de las entidades involucradas en el flujo. Soporte WS XML Schema [xml-schema] Comentario Definir políticas para la solicitud de datos y la manera en como se van a validar

dichos datos mediante servicios web en otras dependencias.

MD113 Estructura de archivos y documentos. Descripción Se deberá definir el layout para los archivos y la estructura de los documentos

intercambiados durante el proceso. Soporte WS XML Schema [xml-schema] Comentario Se necesitan herramientas para administrar esquemas centralizadamente en el

gobierno (capítulo de desafíos).

MD114 Descripción de políticas del cliente y del servicio. Descripción El cliente y proveedor deben describir las políticas que los rigen a modo de poder

automatizar el proceso de negociación y validar la compatibilidad de sus políticas (Legislación para dichas políticas).


MD115 Descripción de capacidades y restricciones de servicios. Descripción Cada servicio describe formalmente sus restricciones y capacidades soportadas,

por ejemplo archivos adjuntos, compresión o restricciones como fechas en que el servicio se encuentra disponible, límite de conexiones, etc.




4.2.5 Reflexiones sobre el caso 2 Problemas y Necesidades Encontrados

� Cuando se realiza el envío de información hacia el banco para la solicitud de apertura de

cuenta, así como el envío de la información de nómina desde la dependencia hasta su

destino final que es la cuenta del empleado, se debe asegurar mediante mecanismos de

seguridad como el firmado y cifrado de la información (mensaje) o bien mediante el cifrado

del canal (mediante SSL, Secure Socket Layer), que la información viaja de modo

confidencial asegurando integridad y no repudio de la información.

� De igual forma para la transmisión de grandes volúmenes de archivos desde las

dependencias hacia el sistema SIAFF de SHCP puede requerir de un ancho de banda

suficientemente grande, aun cuando se utilice compresión y SFTP, es por esto que se

requiere que los archivos firmados y ensobretados tengan un nivel de compresión bastante

alto.

� La definición de reglas de transferencia y de comunicación entre aplicaciones debe de ser

lo bastante flexible como para soportar cambios constantes en la definición de las mismas,

debido a que constantemente se sufren cambios por decretos o por leyes aprobadas que

modifican el flujo y las condiciones de la información.

Componentes o Metadatos Recurrentes

� Será necesario definir específicamente los tipos de comunicación, anchos de banda,

certificados para cifrado de canal de comunicaciones, espacio necesario en bases de datos

para el almacenamiento de las transacciones y su histórico, a fin de que el modelo de

datos y de la lógica de negocio sea más fácil de definir, lo cual ayudara a la

implementación de los servicios web y otras tecnologías que resolverán el problema de la

comunicación entre aplicaciones de distinta fabricación, ver WS-Choreography[ws-

choreography] y WS-Coordination [ws-coordination]

� Puede requerirse que durante el flujo de los documentos sea necesario realizar la

autenticación de las entidades que estén participando en una transacción, esto puede ser a

nivel de persona, de sistema, de institución o bien de documento, debido a que la

información que se maneja a lo largo de la operación es confidencial y puede requerir en

cualquier momento revisar el estado de autenticación.



� De igual forma que en el caso 1, puede presentarse que se requiera acordar las

condiciones de invocación de un servicio, dado que de igual forma se requiere un protocolo

de negociación de capacidades, restricciones, condiciones previas, condiciones finales,

políticas de privacidad, seguridad, etcétera, entre el servicio y el cliente de manera similar

a lo que hace HTTP 1.1 hoy en día [rfc-http].

� Dada la naturaleza de la operación del flujo puede que se necesiten metadatos para

comunicar resultado de operaciones y acuerdos y una manera de almacenarlos, con el

propósito de dar auditabilidad al proceso y asegurar la información de los empleados y que

pueda ser consultada en cualquier momento a través de una herramienta de monitoreo

(APL-SPEI por ejemplo).

� Es necesario contar con datos que describan los recursos que participan a lo largo de la

invocación de un servicio, los recursos pueden ser archivos transferidos, documentos,

imágenes, etc. Esta información o metadatos de los recursos pueden ser por ejemplo el

layout del archivo transferido, la estructura del documento enviado, el tamaño de una

imagen, o incluso datos del mismo servicio web que se está invocando.


� La definición general de este caso 2 implica por definición de proyectos que en el caso en

que intervienen 2 o más entidades en un flujo, es necesario definir un líder de proyecto

general, a la vez que se define uno para cada etapa del flujo. Como es de esperarse, cada

una de las entidades involucradas debe asegurar la privacidad de la información en su

entorno y sus dominios, a la vez que su lógica de negocio debe ser compatible con el resto

de la operación de las otras interfaces o bien de las propias aplicaciones a fin de mantener

una ecuanimidad, sobre todo al momento de utilizar “Reglas de Negocio” compartidas. Las

interacciones entre servicios web deben ser coordinadas explícitamente con la definición

de documentos que permitan que el flujo sea el mismo a través de cada una de las

dependencias por las cuales pasa el proceso.

� Dada la importancia de la operación (nómina federal), es necesario definir planes

alternativos de operación, previendo la caída de alguno de los puntos del flujo dado que

nada es seguro en esta vida, es necesario definir un plan de contingencia en cada uno de

los puntos críticos de la operación y de igual forma al interior de cada una de las

dependencias.



� Soluciones como ésta, resuelven de manera satisfactoria el problema de retrasos por

validaciones manuales, además de que implican un ahorro enorme en el uso de

tecnologías que proveen en algunas ocasiones instituciones bancarias como CECOBAN

(Centro de Control Bancario) y que suelen ser soluciones a la medida para una sola

aplicación, cerrando la puerta a flujos parecidos de otras dependencias, en el caso del

Gobierno Federal, encontramos muchas veces que las aplicaciones no suelen ser

pensadas para grandes cantidades sino que se casan con la solución para un solo flujo.

� Una correcta definición del problema y un análisis completo de la infraestructura de cada

dependencia o institución que se involucra en el desarrollo de una solución, son altamente

importantes al momento de definir el flujo de operación y de documentos, ya que amplia el

panorama de la solución y determina las expectativas esperadas al final de la solución, que

posteriormente se puede convertir en un ahorro al momento de implementar la solución

completa, estos aspectos no se incluyen en este documento debido a que la extensión del

mismo se incrementaría mucho más.

� Los grandes impedimentos para este tipo de soluciones no suelen ser las tecnologías sino

por el contrario las leyes que no dan validez jurídica ni moral al uso de medios electrónicos

como lo es este caso 2, dado que en algunos instantes es necesario definir antes la Ley o

Decreto que determine que no existirá ningún impedimento para el desarrollo de la

solución, esto es posible si se siguen los caminos adecuados para su formalización legal

ante las autoridades, pero eso significa generar acuerdos a niveles de alto mando.

� Este es un caso más donde podemos hablar de un “proceso de transparencia”, al disminuir

en gran medida la intervención de procesos manuales, ya que una de las principales

problemáticas presentadas era el pago de nóminas a trabajadores que no existían, las

validaciones que se hacen ahora en la SHCP, han disminuido en gran cantidad el número

de plazas inexistentes que recibían quincena tras quincena su pago sin siquiera saber

quién era el titular de dicha plaza.

� Otro factor importante a destacar aquí, es el uso de tecnologías propias del gobierno

federal y el ahorro de recursos al ya no depender directamente de los bancos para el pago

de nóminas, por otro lado el pago ahora se hace a través del Banco de México que

dispersa el depósito hacia las cuenta de los trabajadores, previamente validados en SHCP.



4.3 Caso 3: Sistema de Expedición de Pasaportes y/o Licencias.

Desde noviembre del 2004 los habitantes del Distrito Federal pueden realizar el pago de derechos

de pasaportes a través de Internet. La Secretaría de Relaciones Exteriores (SRE) puso en práctica

el programa que forma parte del Plan de Desarrollo del Gobierno Federal, de igual forma se

implementaron mecanismos para agilizar el trámite de solicitud de licencias en el gobierno del

Distrito Federal a través de Internet.

Dicho mecanismo permite realizar los pagos de manera fácil y ágil ya que se puede realizar desde

la página de Internet de los bancos con los cuales se tiene convenio.

El sistema permite de manera sencilla el llenado de formatos de tal suerte que los datos solicitados

como:

� Tiempo por el que va a requerir el pasaporte

� Costo

se llenan de manera automática, posteriormente se debe cubrir el importe correspondiente a través

de los medios electrónicos accesando a la página del banco en el cual se tenga una cuenta para

fondear el pago.

El cobro del servicio puede hacerse con cargo a su chequera, tarjeta de crédito o débito. Cada año

dos millones 400 mil personas solicitan un pasaporte [sre] 20

, y más de 900 mil solicitan licencias de

manejo [setravi] 21

, de ahí la importancia de agilizar dichos trámites vía Internet.

Actualmente el Estado de México ha realizado grandes esfuerzos en materia de gobierno

electrónico, ofreciendo cada vez más servicios a través de su portal web, disminuyendo la cantidad

de filas en las sucursales de la tesorería del estado y agilizando muchos de los trámites que eran

tardados y tediosos para la mayoría de la gente.

Nuevamente este caso es una solución alterna propuesta por el tesista para agilizar uno de tantos

trámites que pueden ser atendidos ofreciendo un servicio a través de medios electrónicos, la

propuesta genérica no especifica la tecnología para desarrollar los servicios web (J2EE, .NET,

PHP, etc.) dado que la misma tecnología no está amarrada a un diseño en especifico ni a una

plataforma o lenguaje en particular.

[sre] 20

- Fuente Secretaria de Relaciones Exteriores SRE www.sre.gob.mx

[setravi] 21

– Fuente Secretaria de Transporte y Vialidad




La solicitud de un pasaporte o bien de la licencia de manejo, son trámites que ocupan la mayoría

de las personas mayores de edad, sin embargo, no podemos dejar de lado los trámites para otros

casos como:

� Menores de edad ( pasaportes y licencias)

� Adultos de la tercera edad ( pasaportes y licencias )

� Discapacitados ( pasaportes y licencias )

� Transportistas ( pasaportes y licencias )

Sin importar la edad, los trámites pueden realizarse de acuerdo a las validaciones que para cada

uno corresponda.

Para éste caso se considera el proceso de solicitud de pasaportes, asumiendo que el caso de las

licencias puede resolverse de la misma manera ofreciendo así una solución equivalente a la del

pasaporte.

El trámite y los requisitos que deben cumplir los mexicanos mayores de edad para obtener un

pasaporte ordinario mexicano son los siguientes:

Acudir personalmente a una Delegación de la SRE u Oficina de Enlace: La expedición de

pasaporte es un trámite personal por lo que no puede llevarse a cabo por medio de un

representante legal o gestor, debiendo comparecer el interesado en cualquiera de las

Delegaciones u Oficinas de Enlace.

El siguiente paso es llenar la solicitud con tinta negra y letra de molde, ésta solicitud es llamada;

formato de Solicitud de Pasaporte Ordinario Mexicano (OP5) [figura 26].

Figura 26: Solicitud de pasaporte ordinario mexicano [OP-5].



Lo siguiente es Acreditar la nacionalidad mexicana mediante cualquiera de los siguientes

documentos:

1. Acta de nacimiento emitida y certificada por el Oficial del Registro Civil, o por los

Consulados o Secciones Consulares de las Representaciones Diplomáticas de México en

el Exterior;

2. Certificado de nacionalidad mexicana;

3. Declaratoria de nacionalidad mexicana;

4. Carta de naturalización;

5. Cédula de identidad ciudadana, emitida por la Secretaría de Gobernación conforme al

artículo 107 de la Ley General de Población.

De igual forma se debe presentar alguna identificación oficial como puede ser.

1. Credencial de elector;

2. Certificado escolar o en su defecto constancia del último grado de estudios (expedida con

una anterioridad no mayor a 30 días naturales), los cuales deberán contener fotografía con

sello oficial (el sello deberá incluir el número de incorporación a la SEP) de la institución

emisora sobre la misma y firma de quien los expide;

3. Cédula profesional;

4. Título profesional;

5. Carta de pasante que contenga fotografía y sello oficial sobre la misma de la institución

emisora y firma de quien la expide;

6. Credencial de servicios médicos de una Institución Privada o Pública de Salud o Seguridad

Social, con fotografía, sello sobre la fotografía y firma de quien la expide. No se aceptan

carnets de citas;

7. Credencial de trabajo de Dependencia o Entidad Gubernamental;

8. Credencial del INAPAM (Instituto Nacional de las Personas Adultas Mayores, antes

INSEN);

9. Credencial para jubilados y pensionados;

10. Carta de naturalización;

11. Declaratoria de nacionalidad mexicana;

12. Certificado de nacionalidad mexicana;

13. Cédula de Identidad Ciudadana, emitida por Secretaría de Gobernación conforme al

artículo 107 de la Ley General de Población;

14. Matrícula consular o

15. Cartilla del Servicio Militar Nacional liberada.



Se deben presentar tres fotografías a color tamaño pasaporte (4.5 x 3.5 cm.); de frente, fondo

blanco, cabeza descubierta, sin lentes o cualquier otra prenda que impida la plena identificación de

la persona y tomada con una anterioridad no mayor a 30 días de la tramitación del pasaporte.

Y por último presentar el pago de derechos: Antes de acudir a realizar el trámite en la delegación

de la SRE u Oficina de Enlace, se deberá haber realizado el pago de derechos mediante Hoja de

Ayuda, la cual se obtiene gratuitamente en Internet o en cualquiera de las Delegaciones y se

presenta para su pago en ventanilla bancaria o por el portal de Internet de los bancos autorizados.

Figura 27: Trámite para solicitar el pasaporte ordinario mexicano.

Para este proceso podemos apreciar en la figura 27, que sigue siendo necesario la presentación

de documentos de forma manual y por papel, aún cuando una parte del proceso se ha

automatizado (pago bancario), resulta ineficiente debido a que no se puede saber con certeza si

los papeles que se están presentado son auténticos y mas aún, si la persona que está solicitando

ya sea un pasaporte o una licencia de manejo, puede o tiene derecho a obtener dicho documento

con base en antecedentes penales 22

, médicos 23

, jurídicos, etc.

22 , 23

Habría que considerar una conexión o servicio web con bases de datos de la PGR y la Secretaria de Salud SSA.

Documentos de acreditación IFE, acta de nacimiento, fotografías, etc.

Solicitud (Formato)

Pago de derechos a través del portal del banco

Recibo de electrónico de pago

BANCO

Transferencia

Respuesta

Pasaporte

Entrega de Solicitud y pago de derechos

Entrega de documentación de acreditación



Viendo este esquema de trámites que pueden ser automatizados en un intervalo del 60 al 80 % de

su totalidad, es posible pensar en una solución que implemente mecanismos de autenticación

mediante firmas electrónicas, validación de documentos electrónicos que cuente con códigos de

barras como la credencial para votar del IFE, el RFC, la CURP, las huellas dactilares, etcétera,

todos ellos pueden ser representados como cadenas binarias de autenticación, que permitan

manejar un esquema de autenticación electrónica por cualquiera de los medios convencionales.

De aquí puede verse la necesidad de comunicación, que independientemente de la que se tiene

con el banco, deberá existir un servicio web que permita la interacción entre dependencias de

gobierno para poder llevar a cabo las validaciones adicionales a procesos que en principio parecen

ser muy simples.

Consideramos los siguientes documentos y su representación electrónica:

� Firma Electrónica (expedida por la dependencia que deba tener el control de toda la

población, en este caso la Secretaría de Gobernación o la misma que utiliza cualquier

contribuyente para realizar sus declaraciones al SAT).

� Credencial para votar del Instituto Federal Electoral (IFE) con un número de identificación y

una banda magnética.

� Clave Única de Registro de Población (CURP) con código de barras.

� Cedula de identificación Fiscal (RFC) de igual forma con código de barras.

� Lectores de huellas dactilares.

Si tomamos en cuenta que todos estos documentos pueden ser enviados a través de medios

seguros (canales cifrados, VPN, canales dedicados) por Internet, es posible pensar en una

automatización de los procesos burocráticos que implican una serie de validaciones por así

llamarlas “interdependencias”.


Trámite 1: Solicitud de licencia de manejo: Como ya se mencionó anteriormente, es posible

automatizar el trámite para la solicitud de licencias de manejo (cualquiera que sea su clase o tipo,

A, B, C , transportista, etc), la autenticación es un paso importante a superar, sin embargo, al igual

que el trámite del pasaporte puede automatizarse hasta en un 80% de su totalidad, el 20 %

restante puede ser insignificante si consideramos que el paso de las fotografías es un requisito

presencial, ya que no es confiable el envío de fotos digitalizadas, aún así los tiempos de espera y

de duración del proceso se pueden reducir enormemente.



Figura 28: Trámite para solicitar una licencia de conducir en el Distrito Federal.

Las figuras 27 y 28 muestran los trámites para solicitar un pasaporte y una licencia de conducir

respectivamente, como podemos ver, estos trámites requieren todavía de papeles y comparten un

flujo documental muy similar que además está automatizado solamente en un momento muy

especifico del flujo (la parte del pago de derechos en el banco), posteriormente podemos ver que el

trámite requiere de la presencia física de la persona para su realización.

Otros trámites que también tienen un flujo muy parecido y que requieren de la automatización

similar son:

� Trámites de Constitución de Sociedades.

� Trámites de Constitución de Fideicomisos.

� Trámite de Nacionalidad y/o naturalización

Estos trámites requieren de los servicios que ofrecen los bancos para el pago de derechos,

además de que en la mayoría de ellos, los documentos presentados en formato de papel son muy

parecidos o iguales, lo cual determina un flujo documental similar para todos ellos.

Licencia

Documentos IFE, acta de nacimiento, comprobante de domicilio.

Formato Universal Tes.

Pago de derechos a través del portal del banco

Recibo de electrónico de pago

BANCO

Transferencia

Respuesta

Entrega de formato y pago de derechos

Entrega de documentación requerida

Setravi



Una solución general para automatizar los procesos de la mayoría de estos trámites y servicios se

presenta en las próximas páginas, haciendo hincapié en el uso de los servicios web para una mejor

solución.

Los servicios que se requiere entregar para esta solución son:

� Servicio 1: Proveer de un portal único donde el usuario (solicitante) no tenga que navegar

en otra ventana para la realización del trámite, el cual le permita interactuar tanto con la

dependencia como con la institución bancaria que él elija, a fin de realizar su pago como si

fuera una ventanilla común y corriente reuniendo ambos servicios (el pago y la solicitud del

pasaporte).

� Servicio 2: Entregar un servicio web por dependencia (SHCP, SAT, SEGOB, IFE, PGR,

SSA, INEGI, ISSSTE, IMSS, etc) que permitan a la Secretaria de Relaciones Exteriores

validar los datos de la solicitud de pasaporte según corresponda el dato con la

dependencia.

� Servicio 3: Proporcionar un servicio web que permita al solicitante dar seguimiento a su

solicitud y así conocer el estado de su solicitud, en caso de que el proceso estuviera

detenido por alguna dependencia brindaría asesoría para poder entender el retraso y

resolverlo.

Estos servicios son una muestra de la capacidad que puede tener el uso de los servicios web, al

requerir interactuar entre aplicaciones o entre 2 o más dependencias para el intercambio de

información (mensajes), además permite plantear la posibilidad de disminuir el uso de papel (en

fotocopias y originales) sin contar la facilidad de los trámites y la rapidez con que pueden realizarse

sin la intervención de personas en la validación.

Este tipo de trámites son los que más llaman la atención por la sencillez que aparentan, sin

embargo, al realizar el análisis de los requerimientos resultan ser de los más complicados al

requerir interactuar con más de 1 entidad para llevar a cabo un proceso o flujo de información de

principio a fin, totalmente automatizado.



Banco del solicitante

10

11

12

1

2

3

7

6

9

8

5

4

4.3.2 Alternativa de solución.

La solución a este problema presenta una propuesta que a primera vista resulta ser sencilla, sin

embargo, como se menciona en el apartado anterior (4.3.1) resulta ser una solución que requiere

de la interacción entre más de 2 dependencias, que su vez muestra la importancia de estandarizar

las comunicaciones entre entidades para el intercambio de información (validaciones), el uso de

reglas bien definidas (definición del flujo) y con apertura de transacciones (gobierno- iniciativa

privada); en la figura 29 se grafica dicha solución haciendo hincapié en el uso de los servicios web

para el intercambio de información entre dependencias, tanto de gobierno como privadas y entre

aplicaciones distintas e incompatibles.

1

1 1

Figura 29: Alternativa de solución para el trámite de solicitud de Pasaporte.

Pasaporte

Pago electrónico

Datos del Solicitante

Documentos Electrónicos



Donde:

Representa un Servicio Web y el número asociado representa lo siguiente:

1. Servicio web que interactúa entre el o los bancos que poseen cuentas del solicitante y el

portal de la Secretaria de Relaciones Exteriores (SRE), su función será notificar del pago

realizado a través de medios electrónicos (esto asume que existe una instancia del portal

del banco dentro del portal de la SRE).

Internamente el portal de la SRE debería poder reconocer el folio que envía el banco hacia

el solicitante dentro del mismo portal sin solicitarlo de nuevo.

2. Servicio web que informe a Banco de México sobre el pago de derechos y cuyo saldo,

deberá ir a parar a la Tesorería de la Federación (TESOFE) la cual es parte de la

Secretaría de Hacienda y Crédito Público, quien finalmente recibe la notificación a través

de este servicio.

3. Servicio web que realiza la validación del pago hecho en el banco a través de los servicios

que ofrece el SAT, dicho pago debe corresponder con el que recibió a través de la SHCP

y/o el Banco de México. Adicionalmente dicho servicio deberá permitir realizar la validación

de la situación fiscal del solicitante por medio de la clave del RFC, este dato puede ser de

mucha utilidad para la detección de evasores fiscales.

4. Servicio web que interactúa entre el Banco de México y la SHCP (TESOFE

específicamente), éste servirá para la conformación de saldos e informes de

recaudaciones por pago de derechos de tramites gubernamentales.

5. Servicio web que valida los ingresos acumulados por parte del Banco de México y por otra

parte la justificación de la transacción del lado del SAT, dado que el solicitante puede o no

deducir impuestos a partir de dicho gasto.

6. Servicio web que valida la identidad, antecedentes y/o averiguaciones que pudiera tener en

contra el solicitante a través de los datos de credencial IFE, CURP, o incluso huellas

dactilares con medios biométricos, esto es de mucha ayuda en el caso de que el

solicitante pueda o no ser alguna persona buscada por la autoridad o con antecedentes

penales que no le permitan salir del país.

7. Servicio web que valida mediante el dato del Número de Seguridad Social (NSS) si la

persona padece algún mal cardiaco y amerite no pasar por detectores, o bien

enfermedades que le permitan exentar ciertas medidas de seguridad en aduanas y

aeropuertos, además de que en su pasaporte podría añadirse en automático sus

padecimientos y tratamientos médicos en caso de requerirse.

8. Servicio web que valide contra la dependencia de Salud que corresponda en este caso el

ISSSTE.

9. Al igual que el anterior, pero para el caso del IMSS y así mismo para las demás

instituciones medicas públicas o privadas.



10. Servicio web que permita validar contra el Instituto Federal Electoral (IFE) el número de

credencial y el domicilio del solicitante, así como otros datos adicionales que pueden

reforzar la autenticidad del documento de pasaporte.

11. Servicio web que asegura la validación del dato correspondiente a la Clave Única del

Registro e Población (CURP), el cual permite validar la nacionalidad, edad y entidad

federativa de nacimiento.

12. Servicio web que valida aquellos documentos expedidos por la Secretaria de Educación

Pública (SEP), que pueden ser validados mediante un folio o algún dato adicional como

código de barras, dentro de los documentos que se pueden presentar son:

� Certificados de primaria o secundaria o cualquier otro nivel escolar.

� Cedula Profesional.

� Credenciales expedidas por la misma dependencia a Profesores e Investigadores.

� Otros.

Como podemos apreciar, algunos de estos documentos cuentan hoy en día con un formato digital

fácilmente verificable contra la autoridad que los expide, aún cuando pareciera que algunos son

repetitivos o están de más, la realidad es que pueden servir como complemento o candado

adicional a algún otro documento presentado.

4.3.3 Especificación de requerimientos de la solución.


RF101 Ingresar información de la persona para solicitud de pasaporte. Descripción El solicitante debe capturar su información en el formulario web del la

dependencia (SRE) utilizando documentos en formato digital que permitan verificar su identidad de manera electrónica.

RF102 Realizar transacción con el banco sin salir del portal de la dependencia. Descripción El solicitante debe poder realizar su pago de derechos en el banco de su elección

(o en el que tenga cuenta) desde la interfaz de la dependencia (SRE), sin necesidad de salir del mismo portal utilizando medios electrónicos que aseguren la transacción con el banco.

RF103 Validación de datos e información de la persona. Descripción La persona que solicita un pasaporte, debe proporcionar documentos electrónicos

que puedan ser validados contra la dependencia que los expidió. Esta autenticación debe ser un proceso automático que permita interactuar con todas aquellas dependencias involucradas con la documentación que presenta la persona.

RF104 Negociaciones cliente-servidor, servidor–servidor. Descripción Los servicios deben permitir la comunicación entre aplicaciones de distintas

entidades (públicas o privadas) y a la vez interactuar con el usuario final.



RF105 La dependencia SRE, envía al solicitante un identificador para el seguimiento de su trámite.

Descripción La SRE realiza las validaciones pertinentes de acuerdo a la documentación electrónica presentada por el solicitante, al finalizar la recepción de la documentación se le asigna un folio o identificador del trámite a la persona para su posterior seguimiento.

Comentario La recepción de muchos documentos electrónicos debe ser un proceso optimizado, dado que la carga de documentos por vía web puede ser lenta si el tamaño del documento es muy grande y más si son muchos por persona.

RF106 La dependencia comienza la validación de la documentación electrónica. Descripción La SRE interactúa con las demás dependencias mediante el envío de peticiones

xml (mensajes SOAP), cada una de las involucradas en el proceso de validación debe implementar el buzón de peticiones correspondiente y resolver las peticiones bajo demanda o definiendo el esquema más conveniente, siempre estimando el mejor de los tiempos de respuesta.

Comentario La implementación de buzones para la recepción de peticiones puede ser una limitante de tiempo para la pronta respuesta a las validaciones, debe implementarse el mejor mecanismo para agilizar este paso del flujo documental.

RF107 Validación interna por dependencia. Descripción Cada dependencia involucrada en el flujo documental realiza el procesamiento de

peticiones (mensajes SOAP) provenientes de la SRE, el tratamiento hecho a dicha información deberá definirse como un estándar a seguir para cualquier dependencia que requiera la misma validación (publicación del WSDL) para el servicio.

Comentario Implementar un servicio web para la interacción con otras aplicaciones de la dependencia puede requerir un análisis más amplio antes de ofrecer servicios hacia el exterior de la organización.

RF108 Dependencia genera respuesta para SRE. Descripción Cada una de las dependencias realizará la entrega de una respuesta mediante un

mensaje en formato xml (soap), lo que servirá para devolver a la SRE el resultado de la validación.

Comentario En los casos en que por algún motivo el resultado no fuera favorable y el solicitante incurriera en alguna falta administrativa o penal, la dependencia debería de informar en un formato especial a la SRE el motivo por el cual se debe rechazar el otorgamiento del pasaporte, además de tomar acciones que correspondan a cada dependencia.

RF109 Dependencia recibe resultados de las validaciones de otras dependencias. Descripción La SRE recibe una a una las validaciones de cada una de las dependencias

involucradas, determinando en base a reglas de negocio si es posible otorgar el Pasaporte o no y bajo que condiciones (tiempo, restricciones, etc.)

RF110 Dependencia informa a solicitante a través de medios electrónicos del resultado.

Descripción Una vez que se ha recibido la información necesaria y que es posible otorgar el pasaporte, la dependencia debe informar al solicitante a través de correo electrónico o mensaje a celular sobre el resultado de su solicitud.

Comentario Los servicios otorgados por la dependencia no incluyen el servicio de SMS para celulares, esto sería un punto adicional que no tiene que ver con la solución de servicios web.



RF111 Generación de documento PASAPORTE. Descripción Una vez que la SRE cuenta con la información necesaria sobre el solicitante, es

posible generar en automático leyendas sobre el pasaporte que especifiquen la situación fiscal, médica y judicial del solicitante a fin de poder identificar cualquier problema que pudiera tener la persona tanto dentro como fuera del país.

Comentario La generación del documento puede hacerse al momento de recoger físicamente el pasaporte, aprovechando ahí mismo para tomar la fotografía y cotejar identidad con la foto anteriormente presentada.


RV201 Validar envío y acuse de recibo para solicitud de pasaporte. Descripción Para cada transacción entre cliente y servidor se debe enviar un acuse de recibo y

confirmación sobre la correcta recepción de los documentos (con un inventario de lo que se recibió para su cotejo).

Comentario Un acuse de recibo con firma digital del destinatario y folio para seguimiento.

RV202 Validación de pagos y datos de cuenta habiente por parte del banco. Descripción El banco deberá validar los datos del pago que desea realizar el solicitante

(número de cuenta, titular y saldo disponible). Comentario El portal de la SRE deberá contar con la interfaz correspondiente hacia cada uno

de los bancos disponibles.

RV203 Verificaciones sobre las tecnologías disponibles. Descripción Cada una de las dependencias y entidades involucradas deben revisar sus

tecnologías para cumplir con requerimientos de otras entidades involucradas.

RV204 Verificación de información requerida. Descripción Cada una de las dependencias deberá poder corroborar mediante procesos

automatizados (medios electrónicos), los documentos recibidos para verificación de identidad de la persona que está solicitando el pasaporte, todo esto a través de los servicios web implementados ya sea al interior o al exterior de la dependencia.

RV205 Validaciones de reglas de Negocio. Descripción Los documentos electrónicos utilizados para la autenticación de la persona que

esta solicitando el pasaporte, deberán traducirse a mensajes que contengan los valores electrónicos de cada uno de los datos que haya que validar, para esto, será necesario definir los respectivos documentos XML que habrán de ser su representación electrónica.

RV206 Verificaciones de seguridad de los documentos. Descripción Los documentos electrónicos deberán tener candados que permitan evitar la

falsificación electrónica de los mismos, tal y como se le aplican candados a los documentos en papel.

RV207 Verificación del número de documentos requeridos. Descripción Aún cuando los candados que se aplican al flujo de documentos parecieran ser

redundantes, es necesario definir el número de documentos validos a cumplir así como también habrá que definir el procedimiento a seguir en caso de alguna irregularidad en alguno de ellos.



RV208 Verificación de los estados del proceso. Descripción Para que la persona que está solicitando el documento de pasaporte pueda saber

el estatus de su solicitud, será necesario permitirle saber mediante un servicio web cuál es el estado que guarda su trámite, de ésta forma se asegura que la persona pueda saber en todo momento que ha pasado con su solicitud.


RS301 Los datos que se envían deberán guardar total anonimato, asegurando la integridad de los documentos enviados.

Descripción Dado que los datos que viajan a través del canal de comunicaciones son privados y el canal puede ser o no público, es necesario asegurar que la información viajará por medios seguros (canal cifrado) o protocolo HTTPS.

Comentario Los datos del solicitante son información confidencial que puede ser utilizada con fines maliciosos, como robo de identidad para transacciones bancarias y otros delitos que pueden repercutir gravemente en el desempeño de la solución.

RS302 Implementar mecanismos de autenticación por cada solicitud que se haga durante el flujo de trabajo.

Descripción Para asegurar que el flujo sea a través de transacciones seguras, deberá implementarse un mecanismo de autenticación por transacción, sin afectar el desempeño de la solución integral.

RS303 Acuerdos y políticas de seguridad Descripción Siempre que se utiliza un proceso automático y transacciones con información

confidencial, deben definirse los acuerdos y políticas de seguridad a seguir así como las medidas correctivas y preventivas en caso de contingencia.

RS304 Confidencialidad de información que es transmitida. Descripción La información que se transmite no debe, ni puede ser conocida por terceros no

involucrados en el flujo. Comentario Se requiere el uso de mecanismos de firmado y cifrado de información.


RRS401 Tiempos de invocación a operaciones y tamaño de archivos a transferir. Descripción Las operaciones que se realicen deben conocer los tiempos y tamaños límite de

operaciones y transferencia de archivos, a fin de cumplir con tiempos definidos como máximo para la transacción, time-out de llamado HTTP o de SFTP.

Requerimientos de Interfaces RI501 Interfaces de comunicación entre instancias en cada dependencia mediante

servicios web. Descripción Se debe cumplir con la API de invocación definida para el servicio



RI502 La captura de datos y documentos electrónicos debe ser mediante un solo

formulario de la dependencia, sin salir de el. Descripción El formulario web que ofrece la SRE para el envío de solicitud y de documentos,

debe contener todo lo necesario para que el solicitante no tenga necesidad de abrir otras ventanas para acceder a otras instancias involucradas en el flujo.

Requerimientos Operacionales RO601 La SRE guarda el registro de la solicitud y de los documentos enviados. Descripción La dependencia deberá almacenar un registro de la operación solicitada así como

de los documentos, los cuales deberán almacenarse en medios seguros con mecanismos de respaldo y de seguridad.

Comentario Esto permitirá que el solicitante pueda dar seguimiento a la solicitud, además de que en caso de requerir otro trámite posterior sus documentos ya están almacenados de manera electrónica y segura.

RO602 Uso de sesiones para identificar cada operación. Descripción Si por alguna razón la operación de solicitud se interrumpiera o tuviera que abrirse

nuevamente para seguimiento de la operación, se debe guardar en sesión los datos del usuario que está solicitando el servicio.

RO603 Tanto los bancos como las dependencias deberán coincidir en el número de

transacciones. Descripción Es necesario que los bancos almacenen de igual forma el registro de las

operaciones realizadas con la dependencia, para el cotejo de cobro de derechos y declaraciones de impuestos que pudiera hacer posteriormente el solicitante.

RO604 Soporte para gran número de transacciones. Descripción Dado que el pasaporte es un documento muy solicitado por los ciudadanos, es

necesario que se planifique la capacidad de procesamiento y de almacenamiento para poder soportar la operación ante la gran demanda que tendrá el servicio.

Requerimientos de Recursos RR701 Alta Disponibilidad (servicio disponible todo el tiempo con prioridad alta). Descripción Dado que el flujo documental puede requerir de alta disponibilidad de todos los

servicios, será necesario planificar la infraestructura que se requerirá para poder brindar el servicio la mayor parte del tiempo en línea, tanto el hardware (equipos y dispositivos de red) como el software (aplicaciones de las dependencias y servicios web) deberán contar con los recursos necesarios.

RR702 Definición de mecanismos para el soporte y la administración de los

servicios y sus recursos. Descripción Cuando se involucran muchas entidades en un mismo flujo de información, será

necesario definir quién será responsable de la administración de los recursos compartidos y de los mecanismos de soporte para mantener la operación en completo orden.



4.3.4 Especificación de metadatos basados en requerimientos. Los metadatos necesarios para cumplir con los requerimientos presentados anteriormente para

este caso se presentan a continuación.

CALIDAD DEL SERVICIO (QoS) MD100 Resumen de operaciones entre entidades. Descripción Siempre que se interactúa entre dos o más entidades en un mismo proceso

deberá quedar huella de cada una de las operaciones realizadas entre ellos, además de guardar registro de la operación se requiere del uso de confirmaciones y/o acuses de recibo.

Soporte WS SOAP, XML-Signature [xml-sig], sello digital. MD101 Evaluación de las capacidades para soportar la operación. Descripción Todas y cada una de las dependencias deberán asegurar que los servicios que

ofrecen estén disponibles todo el tiempo, además de que los tiempos de respuesta sean los mínimos en comparación con lo de otras dependencias.

Soporte WS

Implementación de sistemas de alta disponibilidad (esquema de replicación) y depuración de los tiempos con la tecnología de servicios web, mensajes SOAP, etc.

ADMINISTRACIÓN DE RECURSOS MD103 Definición de Roles y Funciones para administrar recursos. Descripción Como ya se menciono en otro apartado, se requiere contar con un área que se

encargue de la administración de los recursos que comparten las dependencias durante el tiempo que dura el flujo de documentos, esto permitirá continuar con los procesos de la administración como la planeación y el control de recursos.

Soporte WS Los contenedores de información en común así como los servicios web y sus publicaciones WSDL o UDDI, serán un factor importante para el caso de la administración y el control del inventario de los recursos.

AUTENTIFICACIÓN Y VALIDACIÓN MD104 Uso de documentos electrónicos para la autenticación. Descripción El uso de firmas electrónicas y sellos digitales será un factor muy importante en el

manejo de transacciones seguras, aunado a la seguridad de los canales de comunicación.

Soporte WS Firma electrónica [firma electrónica], sellos digitales, SAML [saml]

MD102 Auditoría de los procesos. Descripción Para asegurar una correcta y optima función y determinar niveles de servicio en el

desempeño, será necesario auditar constantemente los procesos automatizados y las soluciones que se detecten obsoletas en algún momento para poder mantener una operación con el mejor de los desempeños.

Soporte WS SOAP [soap], WS-Choreography [ws-choreography].



MD105 Autenticación y no repudio de los mensajes. Descripción Tanto los mensajes que se envían como los que se reciben deberán implementar

mecanismos de no repudio y de validación de autenticidad, a la vez que se debe cumplir con los las especificaciones de los servicios de las dependencias.

Soporte WS WSDL [wsdl], XML, SOAP.

MD106 Validación previa y posterior al envío de mensajes. Descripción Cada uno de los servicios deberá optar por el esquema que desee a fin de

restablecer el estado previo de una solicitud en caso de error, o bien de guardar registro de cada uno de los cambios que sufra el servicio a lo largo del tiempo.

Soporte WS BPEL4WS [bpel4ws], SAML [saml] Comentario Las condiciones previas y posteriores se especifican en el WSDL del servicio

SEGURIDAD MD107 Información confidencial y aseguramiento del No repudio. Descripción Las firmas digitales (FIEL o FEA), así como el uso de certificados permitirán

implementar mecanismos de seguridad confiables a fin de que las personas no puedan negar el origen de la documentación enviada, de igual forma el asegurar que la información no será vista por nadie más durante el viaje entre dependencias.

Soporte WS WS-Security [ws-security], XML Signature [xml-sig]

MD108 Relevancia del documento infalsificable. Descripción El implementar estos mecanismos de seguridad y de firmado de la información,

permite establecer el documento de pasaporte como un documento de muy alto nivel de seguridad y confiabilidad, al no permitir casos de falsificación y reducir el número de operaciones fraudulentas con dicho documento.

FLUJO DOCUMENTAL MD109 Definición formal del flujo documental. Descripción Para el intercambio de mensajes y documentos electrónicos entre dependencias

se deben especificar los formatos de los mensajes, las operaciones a realizar y el conjunto de resultados esperados sin dejar de lado los mecanismos de seguridad.

Soporte WS XML Schema [xml-schema], SOAP [soap], WSDL [wsdl], WS-Choreography [ws-choreography], WS-Coordination [ws-coordination].

MD110 Documento Final. Descripción Una vez que se ha conseguido validar todos y cada uno de los documentos

enviados para la expedición de pasaportes, se debe definir el flujo a seguir para la generación de dicho documento partiendo de que las validaciones pueden ser o no satisfactorias, a la vez que la generación del documento deberá incluir algunos candados electrónicos derivados del uso de documentos electrónicos para su expedición.

Soporte WS http [rfc-http], SOAP [soap], WSDL [wsdl], sellos digitales, firmas electrónicas. Comentario La definición del flujo documental debe considerar las acciones a tomar y los

responsables de ejecutarlas, en caso de retorno de algún código de error.



DESCRIPCIÓN DE RECURSOS MD111 Definición de Formatos y traducción a documentos XML. Descripción Se debe definir una estructura para los archivos (documentos) que serán enviados

para validación, además de que se deberá especificar y unificar la manera de traducirlos a mensajes XML para su validación.

Soporte WS XML Schema [xml-schema] Comentario Definir políticas para validación de datos y la manera en como se van a validar

mediante servicios web en otras dependencias.

MD112 Definición de políticas entre servicios. Descripción Cada uno de los servicios debe auto describirse usando WSDL, a fin de que los

demás servicios involucrados puedan invocar el servicio correspondiente sin errores y de manera estandarizada.

Soporte WS WS-Policy [ws-policy]

MD113 Estructura de archivos XML. Descripción Se deberá definir el layout para los archivos y la estructura de los documentos

intercambiados durante el proceso, de igual manera para los mensajes SOAP intercambiados.

Soporte WS SOAP, XML Schema [xml-schema]

MD114 Capacidades, restricciones de servicios, contingencias. Descripción Cuando los servicios sean lanzados de manera productiva, deberán especificarse

limitantes y alcances a fin de establecer un esquema de trabajo óptimo, sin olvidar los esquemas de contingencia en caso de que algún servicio no esté disponible


4.3.5 Reflexiones sobre el caso 3 Problemas y Necesidades Encontrados

� Se requiere definir con exactitud los mecanismos a utilizar para el envío de los documentos

de manera electrónica a fin de que puedan ser validados (una conversión a XML), para que

puedan ser capturados en el portal de la dependencia y que puedan ser enviados de

manera segura para evitar robo de información, asegurar la confidencialidad y evitar el

repudio de la información enviada.

� El envío de muchas solicitudes hacia el portal requiere de la implementación de sesiones y

buzones de entrada para la recepción de grandes volúmenes de información electrónica,

además de evitar transacciones atómicas, es decir, permitir a la persona que solicita un

pasaporte que la captura de sus datos y documentos pueda ser en distintos momentos

asíncronos (por eso el manejo de sesiones).



� La información que se traduce en documentos XML para su validación, deberá

implementar mecanismos de seguridad como firmado y cifrado de los datos para evitar que

los mensajes puedan ser interceptados en el transcurso de la transacción.

� La expedición de documentos oficiales por Internet sería un gran avance al hacer uso de

firmas digitales para dar mayor credibilidad a un documento “electrónico”, por una parte se

hace un ahorro enorme en el uso de papel, se disminuyen los tiempos de entrega y de

espera para solicitar un documento de esta índole.

Por otro lado se brindan mejores servicios, se incrementa la productividad al interior de las

dependencias de gobierno y se dan muestras de procesos realmente transparentes al ya

no depender de una persona que atiende en una ventanilla, solicitando papelería en

ocasiones innecesaria y otras ocasiones solicitando dinero para poder realizar trámites que

por ley son gratuitos.

Componentes o Metadatos Recurrentes

� Para el caso de la solicitud de pasaportes será indispensable analizar todos y cada uno de

los servicios a implementar, revisar si existen elementos recurrentes en cada uno de ellos y

que puedan ser compartidos a fin de optimizar la solución.

� El medio físico de comunicación puede requerir que se defina una arquitectura de enlaces

por VPN con el propósito de asegurar las comunicaciones entre dependencias, lo cual

puede ser evaluado previamente para evitar gastos innecesarios.

� El almacenamiento de los datos y de los documentos electrónicos puede requerir de la

compra de muchos equipos o bien de compartir recursos para compensar el gasto, dado

que la información que se almacena puede requerir de mucho espacio o bien almacenarla

de manera comprimida para optimizar recursos de almacenamiento.

� La implementación de los servicios web y otras tecnologías deberá definir claramente los

flujos a seguir y como se intercambiarán los mensajes y documentos, cumpliendo con las

reglas de coreografía de documentos WS-Choreography [ws-choreography] y WS-

Coordination [ws-coordination].

� La definición de protocolos a utilizar entre las dependencias deberá garantizar un óptimo

desempeño del intercambio de mensajes, los protocolos seguros como HTTPS Y SFTP

normalmente consumen muchos recursos de memoria y un gran ancho de banda, por lo



que sería recomendable implementar comunicaciones seguras mediante redes virtuales

privadas (VPN) o canales dedicados cifrados, el costo puede ser elevado, pero comparado

con la tecnología que se tendría que comprar para otras soluciones (por ejemplo un ERP)

resulta incluso más barato si consideramos que también se deben pagar licencias por

productos de marca.

� Las transacciones entre dependencias requerirán de mecanismos de auditabilidad, por lo

que el flujo debe ser respaldado todo el tiempo con registros que especifiquen cada una de

las transacciones realizadas.


� La administración y las responsabilidades del mantenimiento a la solución completa

requieren que sean actividades compartidas por todas y cada una de las dependencias, ya

que la definición del flujo completo debe de mantener coherencia con las demás entidades

involucradas, los cambios que se realicen afectarán a más de una entidad por lo cual las

definiciones y cambios que se hagan deberán estar centralizados en un solo lugar, de ahí

deberán tomar las demás entidades involucradas la información necesaria para aplicar los

cambios.

Nuevamente la seguridad representa un factor muy importante al tratarse de un flujo de

información que maneja datos confidenciales. Las interacciones entre servicios web deben

ser coordinadas explícitamente con la definición de documentos, los cuales permitan que el

flujo sea el mismo a través de cada una de las dependencias por las cuales pasa el

proceso.

� Sin importar si el documento de pasaporte puede o no definirse como un servicio de alta

disponibilidad y por consecuencia de alta importancia, debe tomarse en cuenta que los

parámetros de calidad establecen que los servicios web deberán contar con esquemas de

alta disponibilidad del servicio, además de contar con esquemas de contingencia para el

caso en que no pueda mantenerse la operación.

� La mayoría de los trámites gubernamentales como pueden ser la solicitud de documentos

oficiales (CURP, IFE, Cartilla Servicio Militar, Pasaporte, Licencias) y otros documentos

como testamentos, escrituras, son candidatos a poder resolver sus respectivos flujos

administrativos de manera electrónica, presentando siempre la misma característica de

validaciones manuales reemplazadas por validaciones electrónicas, así como firmas



electrónicas y sellos digitales que aseguren que este tipo de documentos pueden tener la

misma validez oficial, como cualquier documento que actualmente es utilizado por

cualquier persona física y/o moral sin importar el lugar en el que radique físicamente.

� Soluciones como las presentadas aquí dejan ver que es posible generar los servicios

necesarios para llegar a un Gobierno Electrónico, el cual permita tener acceso a la mayoría

de los servicios y productos que ofrece el gobierno.

Sin embargo la tecnología no es suficiente para obtener dicho logro ya que primero se

deben romper las barreras políticas y burocráticas, además de legitimar la apertura de los

servicios a través de medios electrónicos.

Una vez concluido el análisis y la propuesta de solución a estos problemas, es posible identificar

los pasos en común que se deben seguir para poder llevar a cabo una integración de aplicaciones

y definir los servicios que se requiere para llegar a tal objetivo.

A continuación se hace un resumen de estos pasos identificados a manera de enunciados y

preguntas, los cuales serán explicados con mayor detalle en el siguiente capítulo como producto

final de este trabajo de tesis.

1. Definir y acotar el problema: ¿Quienes intervienen?, ¿A quien afecta el problema?,

¿Para quién estará disponible la solución?

2. Identificar necesidades de los clientes (ciudadanos o empresas) para después

definir el o los servicios que se desarrollarán.

3. Tener claras las prioridades de e-Gobierno y variables para su evaluación. ¿Qué

impacto social tendrá?, ¿Qué impacto económico?, ¿Qué valor entrega al cliente?,

¿Cuál es la complejidad?, ¿Experiencia y madurez en ese tipo de soluciones?

4. ¿En que consisten los servicios?, describir interacciones, proveedores,

consumidores y centralizadores de información, ¿cuales son los flujos

documentales?, ¿estructura y orden de los mensajes? Uso de UML para el modelado

o BEPEL para un modelo basado en servicios web.

5. Alternativas a los flujos documentales (vistas, repositorios, o alguna alternativa de

baja complejidad).

6. Definir requerimientos de software (recursos, descripciones sobre los recursos,

interacciones, restricciones y capacidades de los sistemas, aspectos de seguridad y

requisitos que se deben cumplir con las tecnologías existentes).

7. Identificar los servicios comunes (autenticación, registro de operaciones,

administración, manejo de recursos) ventajas de modularizar y reutilizar código y

funciones, patrones recurrentes.



8. Describir recursos (servicios, documentos, mensajes, repositorios, etc), identidad,

accesibilidad mediante protocolos web, propiedades.

9. Descripción formal de servicios (modelo de datos, API´s, secuencia y esquemas de

mensajes, capacidades y restricciones de los recursos), documentos con xml

schema, mensajes MOM, API´s, flujos documentales, coordinación y coreografía de

servicios, semántica del servicio, políticas del servicio.

10. Analizar tecnologías disponibles que satisfacen requerimientos de servicios.

11. Administración de recursos.

12. Definir arquitectura.

13. Implementación.



Capítulo

5

Recomendaciones para desarrollo de Servicios Web.

Este último capitulo presenta la propuesta obtenida a partir del estudio de los casos

prácticos y de la forma en que se atendió cada uno de ellos, extrayendo los pasos y

características en común que se encontraron para conformar los pasos del producto

final de este trabajo.



5 Recomendación para desarrollo de Servicios Web

5.1 Pasos recomendados.

A continuación se presenta una secuencia de pasos recomendados para el desarrollo de servicios

en el e-Gobierno usando la tecnología de servicios web, esta propuesta se basada en la

experiencia obtenida durante este trabajo y el desarrollo de soluciones por parte del tesista en

distintas organizaciones.

Para ello se entrega un conjunto de pasos ordenados, que según el modelo de desarrollo utilizado

puede ser abordado en cascada, iterativamente, o bien omitiendo algunos aspectos menores.

El orden de estos pasos es importante sin embargo, existen tareas que se pueden desarrollar en

paralelo, modificar el orden de ejecución o simplemente omitirse, dependiendo de las necesidades,

conocimientos de los realizadores y complejidad del problema. Cada paso considera las salidas o

productos que deberían obtenerse al final de su realización. Los productos obtenidos como

consecuencia de todos estos pasos, entregan las definiciones necesarias para comenzar con la

implantación de los servicios utilizando servicios web haciendo uso de patrones de diseño

comunes al estándar J2EE de Java, [patrones J2EE], [uml y patrones], [utilización de UML].

Paso 1 Establecer dominio y alcance del problema

Descripción: Lo primero que hay que hacer es definir y acotar el problema que se busca resolver.

Para ello se debe analizar qué recursos (instituciones, personas, sistemas, documentos, etc)

intervienen en el flujo, a quién afecta el problema, y para quien(es) se dejará disponible una

solución.

Productos: Definición del problema. Recursos que intervienen en el problema (instituciones,

personas, documentos etc.) como consumidores, mediadores o proveedores de la solución y

visibilidad que tendrá la solución.

Paso 2 Determinar necesidades a satisfacer y servicios a brindar

Descripción: Dada la definición del problema se deben identificar las necesidades de los

ciudadanos, empresas, clientes, etc, para luego ver que servicios se desarrollarán a fin de

satisfacerlas.

Productos: Se obtendrá el listado de necesidades que deben satisfacerse para solucionar el

problema y una breve descripción informal de servicios propuestos como solución para el

problema.



Paso 3 Determinar impacto, costo y valor de los servicios

Descripción: Para elegir los servicios que en definitiva serán desarrollados, se deben tener claras

cuales son las prioridades definidas para el gobierno electrónico y que variables se tomarán en

cuenta en su evaluación. Este análisis debe considerar el impacto social y económico, costo y valor

que entrega el servicio a dependencias y ciudadanos (proveedores y clientes), cuál es la

complejidad, experiencia y madurez de tecnologías en el desarrollo de ese tipo de servicios, cuál

es el volumen de información manejado y las dependencias y problemas existentes.

Para ahondar en como valorar económicamente servicios web ver [ws-worth], la visión desde el e-

Gobierno para la correcta elección de servicios a entregar se trata en [egov-roadmap].

Productos: Servicios que serán desarrollados debido al impacto, costo y valor que generan.

Paso 4 Describir formalmente los flujos documentales

Descripción: Luego de identificar los servicios que se desarrollarán, se debe definir precisamente

en que consisten ellos. Para ello se deben describir interacciones, proveedores, consumidores y

centralizadores de información, dependencia de agentes y servicios, distribución de la información,

etc.

Además, los flujos documentales deben describir todos los aspectos que considera la interacción

entre agentes, tales como la estructura y orden de mensajes, responsables, eventos, estados de

los documentos, etc. [patrones de diseño con J2EE].

Para ver un ejemplo del modelo de datos que involucra un flujo documental usando servicios web

ver capítulo 3 sección 3.1 [ws-choreography].

Para modelar estos flujos se puede utilizar lenguajes de modelado como UML o lenguajes para

modelado de procesos de negocios como BPEL.

Productos: Descripción formal de flujos documentales (actores, roles, relaciones, documentos,

estados, interacciones, etc.). Un ejemplo de cómo presentar este producto se encuentra en la

descripción del servicio para los Casos 2 y 3.

(Secciones 4.1.1 y 4.2.1 respectivamente).

Paso 5 Alternativa a flujos documentales

Descripción: Tal como se mencionó en la sección 3.3.2, los servicios pueden entenderse como

una vista abstracta de flujos documentales, aplicaciones, repositorios, etc. A pesar de que la

definición de un workflow donde se especifique formalmente todo el proceso que involucra un



trámite resulta muy útil, existen casos donde ello no es posible ni óptimo, ya sea por baja

complejidad o por temas de costos.

Un ejemplo de ello es el Caso 2, donde el servicio entregado corresponde a una vista sobre un

repositorio de datos (nómina informativa) y no sobre un flujo documental.

Productos: Vistas sobre aplicaciones, repositorios, etc., que serán presentados como parte del

servicio. Esto involucra estructura de la información a presentar, recursos y agentes que participan.

Un ejemplo de cómo presentar este producto se encuentra en la descripción del servicio para el

caso 3 (sección 4.3.1).

Paso 6 Definir requerimientos de software sobre servicios

Descripción: Tanto para el caso en que se describan formalmente flujos documentales, como en

el que los servicios sean el producto de vistas sobre aplicaciones, repositorios, etc., se deben

definir formalmente los requerimientos de software de los servicios.

Esto ayudará a definir: los recursos, las descripciones sobre los recursos, interacciones,

restricciones y capacidades de los sistemas, verificaciones, aspectos de seguridad y los requisitos

que deben cumplir las tecnologías disponibles.

Para la descripción de requerimientos de software se puede usar el esquema presentado en el

estándar de la ESA [estandar-esa]. Este paso, es una importante entrada para la definición de la

arquitectura de la solución.

Productos: Lista de requerimientos de software y su descripción. Un ejemplo de cómo presentar

este producto se encuentra en los casos 1 y 2 en las secciones 4.1.3 y 4.2.3 respectivamente, el

nivel de detalle de los diagramas de modelado, depende de la profundidad que se desee para

mayor entendimiento.

Paso 7 Identificación de servicios comunes

Descripción: Al tener definidos los requisitos de los servicios en el paso 6 y posteriormente al

tener las definiciones del paso 8, es posible identificar un conjunto de recursos que son comunes a

los servicios o resultan recurrentes para algún patrón de interacción dado.

Algunos ejemplos de estos servicios comunes son autenticación, registro de operaciones,

administración y manejo del estado de los recursos. Esto no sólo entrega las ventajas de

modularizar y reutilizar funcionalidades, encontrar patrones recurrentes en el diseño que aceleran

el desarrollo, etc., sino también fomenta la estandarización en pro de una más efectiva y eficiente

interoperabilidad.



De esta manera es posible definir metaservicios, es decir, servicios sobre los servicios que podrían

estar centralizados en una dependencia (por ejemplo autenticación de identidades en el Registro

Federal de Contribuyentes RFC) o ser entregados como componentes reutilizables.

Los metaservicios pueden ser generalizados a servicios sobre cualquier tipo de recursos (servicios,

documentos, repositorios, etc.). Un ejemplo de la definición de componentes o descripciones

comunes a los servicios se encuentra en los casos 1 y 2 en las secciones 4.1.5 y 4.2.5

respectivamente. Para ahondar más sobre metaservicios para administración de recursos, ver el

capítulo 3.9 de [ws-arch].

Productos: Listado de servicios comunes.

Paso 8 Describir recursos

Descripción: Tal como se ha mencionado el concepto de recurso es usado para referirse a

servicios, documentos, mensajes, repositorios, etc. Como recursos web ellos cuentan con

características comunes tales como su identidad, accesibilidad mediante protocolos de la web, la

descripción de sus propiedades, etc., y por otra parte con ventajas como el alto soporte existente lo

cual resulta en una satisfacción de las necesidades de e-Gobierno (ver sección 3.3).

Basado en los requerimientos de software descritos en el paso 6 se encuentra un conjunto de

restricciones, capacidades, permisos, representaciones, etc., sobre los recursos que son

necesarios describir para entregar autenticación, validación, seguridad, calidad de servicio, etc.

Además, pensando en las características que se desearía tener al momento de administrar los

recursos (ver paso 11 y sección 3.8), se deben incorporar metadatos que permitan tal acción.

Estas descripciones pueden ser metadatos intrínsecos o extrínsecos a los recursos y facilitar la

interacción persona-máquina o máquina-máquina. Consideraciones a tomar en cuenta sobre la

elección de metadatos intrínsecos o extrínsecos se presentan en la sección 3.8 de este trabajo.

Para los metadatos extrínsecos existen algunas iniciativas como AGLS [agls-35], e-Government

Metadata Standard [e-gms], que describen los recursos web enfocados en el e-Gobierno. Estos

metadatos permiten clasificación, búsqueda y una mejor interoperabilidad ya que entregan

descripciones mínimas comunes a todos los recursos.

Una guía basada en AGLS que explica el uso de metadatos extrínsecos y consideraciones al

momento de crear metadatos con respecto a su aplicabilidad, proceso de administración, entre

otros, se encuentra en [metadataguide].

Para la interacción máquina-máquina es necesario usar lenguajes formales computables por

máquinas que tengan una semántica definida. Para ello XML no es suficiente (ver [guidelines-peltz])

por lo que existen alternativas como DAML-S [daml], OWL-S [owl-s], RDF [rdf] para caracterizar,



procesar e inferir o por otra parte, tecnologías como SOAP [soap], WSDL [wsdl], WS-Choreography

[wschoreography], SAML[saml], entre otras, las cuales definen su gramática y semántica para

descripción y procesamiento.

Estos metadatos permiten interoperabilidad, automatización, razonamiento e inferencia sobre las

descripciones. Para revisar los conceptos y relaciones que intervienen en la descripción de

recursos web ver el capítulo 3, sección 3.1 de [ws-arch] y el modelo arquitectónico orientado a

recursos (ROM).

Productos: Descripción de recursos para interacción persona-máquina y máquina-persona.

Paso 9 Descripción formal de servicios

Descripción: Luego de que todos los servicios involucrados han sido identificados, se debe

describirlos formalmente mediante: modelo de datos, API de operaciones disponibles, secuencia y

esquemas de mensajes, capacidades y restricciones de los recursos.

Como este paso corresponde a uno de los objetivos principales de este trabajo, es descrito en más

detalle a continuación. Para las descripciones se han usado los conceptos que aparecen en los

modelos arquitectónicos definidos en [wsarch] de MOM, POM y SOM (ver sección 3.7).

Productos: Especificación de componentes, descripciones, interacciones que intervienen en los

servicios. Se debe obtener una especificación formal de los elementos 9.1 al 9.6.

Elemento 9.1 Documentos

Descripción: Se debe definir la estructura de los documentos y las restricciones de tipos de datos

que lo rigen (usando XML Schema). Para diseñar la estructura y restricciones (modelo de datos)

que rigen los documentos se debe buscar en los tipos de datos ya definidos (para lo cual se debe

considerar el uso de herramientas de administración para los recursos y metadatos), ocupándose

que ellos sean consistentes con las nuevas definiciones y reutilizando las estructuras que

corresponda. Algunas guías para el diseño de esquemas XML relacionadas con gobierno

electrónico se pueden encontrar en [schema-design].

Elemento 9.2 Mensajes

Descripción: Pensando en el caso en que los documentos son transmitidos como parte de una

comunicación, diremos más precisamente que ellos son mensajes. Como se vio en la sección

4.3.5, según la decisión de diseño tomada los mensajes pueden incorporar datos y metadatos



relacionados con la lógica del negocio, instrucciones de procesamiento sobre nodos de la red,

direccionamiento en caso de errores, etc.

Además, al ser los mensajes un tipo de documentos también deben describir la estructura y las

restricciones de ellos. Ver [soap] para más detalles sobre mensajes en comunicaciones con

servicios web, [soap-attachment] para el manejo de archivos adjuntos en la transmisión de mensajes,

[ws-addressing] para direccionamiento de nodos en caso de errores y Message Oriented Model

(MOM) [ws-arch] para conocer los conceptos y definiciones que caracterizan a los mensajes.

Elemento 9.3 API y operaciones

Descripción: Para cada servicio existe un conjunto de operaciones permitidas, las cuales pueden

ser invocadas usando una API de servicios web descrita mediante WSDL [wsdl].

Tal descripción se ocupa de definir estructura, correlación y orden de los mensajes, protocolos de

transporte, dirección del servicio, entre otras.

La definición de las operaciones y API que se dejará disponible depende de consideraciones de

diseño que deberían tomar en cuenta al menos los siguientes aspectos: utilizar las salidas de los

pasos 1 a 3 para conocer las necesidades de servicios, revisar si existe alguna restricción sobre el

desempeño que debería tener; considerar que operaciones muy generales pueden resultar

complejas, costosas de mantener y entregar pobre rendimiento.

Pero por el contrario operaciones muy específicas pueden resultar simples, pero de pobre

reutilización, abarcan pocos casos y puede ser complejo administrar demasiadas operaciones.

Por ello se recomienda el uso de operaciones más bien generales y el uso de operaciones

particulares especializadas para los casos que requieran condiciones especiales para un servicio

crítico; considerar que tipo de invocación se hará si al estilo Remote Procedure Call (RPC) o

Document-Style para lo cual existen algunas guías en [guidelines-peltz].

Un ejemplo de consideraciones de diseño sobre este ítem se encuentra en la sección 4.3.

Elemento 9.4 Flujos documentales, coordinación y coreografía de servicios

Descripción: Los flujos documentales pueden ser simples o compuestos, ocurrir dentro de una

dependencia (unidad) o entre varias de ellas, ser síncronos o asíncronos, conservar o no el estado

de la interacción, etc.

Algunas guías para decidir que esquema utilizar se encuentran en [guidelines-peltz]. Para los flujos

documentales se debe especificar la comunicación de aplicaciones, repositorios, etc., que modela

la lógica de negocio la cual incluye transacciones, flujos condicionales, etc.



La idea aquí es coordinar el uso de servicios web y otro tipo de tecnologías para la entrega de

servicios para crear servicios más complejos y de mayor valor.

Algunas tecnologías que soportan estos requerimientos son: BPEL4WS [bpel4ws], WS-

Choreography [ws-choreography] y WS-Coordination [ws74coordination].

En el caso de que el servicio no sea la abstracción de un workflow definido para algún trámite, se

deben especificar al menos las fuentes de información, aplicaciones, recursos y agentes en juego,

más la lógica de negocio que hay de por medio en el servicio como por ejemplo, la actualización de

registros en un repositorio.

Elemento 9.5 Semántica del servicio

Descripción: La semántica de un servicio entrega una descripción formal de acciones que realiza,

funcionalidad que entrega, restricciones que lo afectan, que reglas se cumplen, etc.

La definición formal de esta semántica entrega una forma de interoperar, inferir y automatizar

procesos.

Algunos ejemplos son: la validación de flujos de servicios, consulta de recursos según sus

propiedades, encontrar compatibilidad de políticas entre agentes, negociación de las condiciones

que regirán la interacción entre cliente y proveedor del servicio, etc.

Para definir la semántica de servicios web es posible usar lenguajes formales computables por

máquinas como DAML-S [daml], OWL-S [owl-s] o RDF [rdf].

La definición de la semántica de servicios no es un tema resuelto ya que no existe una alta

madurez ni consenso al respecto. Una discusión sobre cómo, qué considerar y qué tecnologías

existen para representar la semántica de servicios web referente a capacidades, restricciones,

precondiciones, postcondiciones, políticas, entre otras, se puede encontrar en [ws-cc-workshop].

Elemento 9.6 Políticas del servicio

Descripción: Las políticas que define un servicio permiten conocer los permisos, obligaciones,

restricciones, ámbito de validez, etc. que rigen al servicio y los agentes que intervienen en él.

A pesar que las descripciones de cada recurso permiten la especificación de una política particular

para cada servicio debido al volumen de recursos y sus propiedades comunes, resulta razonable el

uso de plantillas de políticas, roles y grupos de usuarios que puedan ser asignados a agentes y

recursos.



Así se podrá validar y restringir las interacciones en que ellos participan. De este modo en vez de

ser necesario realizar inferencias sobre las políticas de un recurso y un agente cada vez que se

llama a un servicio, se pueden tener relaciones precalculadas que entreguen la validez de la

interacción requerida.

El modelo arquitectónico orientado a políticas define los conceptos y relaciones que intervienen en

la definición de políticas para recursos web. Una discusión sobre definición de políticas para

servicios web se puede encontrar en [ws-cc-workshop].

Paso 10 Analizar tecnologías disponibles que satisfacen requerimientos de servicios

Descripción: Antes de decidirse a usar la tecnología de servicios web se debe analizar si ello es lo

más conveniente dadas las necesidades del servicio.

En el caso de que los servicios web sea la tecnología elegida se debe recordar que existen

algunos aspectos que aún no se encuentran maduros o con gran soporte de la industria, tales

como el uso de archivos adjuntos, definición de políticas, algunos aspectos de seguridad, etc.

Para una detallada definición de seguridad en servicios web y su madurez actual ver [selman-ws] y

para algunas guías básicas sobre seguridad ver [guidelines-peltz].

El desempeño es otro factor crítico para los servicios web, el cual está determinado por el tamaño

de los mensajes intercambiados que pagan el precio por la extrema codificación de XML, las

características de HTTP que no aseguran el orden ni la llegada de los mensajes y el

procesamiento XML propio de SOAP [ws-challenges-sol].

Sin embargo, el desempeño puede ser mejorado usando llaves de sesión o caché de XML.

Cabe resaltar que la falta de madurez de algunas tecnologías no es necesariamente un

impedimento para el desarrollo de servicios web con estas características, pero si alerta de la

necesidad de encapsular los aspectos que aún no han sido acordados.

Por ejemplo un servicio de validación podría indicar, si se puede o no invocar al servicio de registro

de RFC o de pasaporte de una persona, casos 1 y 3 respectivamente, dadas las políticas de

privacidad definidas por un cliente y el servicio de registro del RFC y de solicitud del pasaporte.

La idea es que para el cliente resulte transparente la invocación al servicio de validación, sin

importar si las políticas fueron definidas con WS-Policy [ws-policy] u otra tecnología.



Todo esto se resume en dos necesidades para el desarrollo de servicios usando servicios web:

(1) El uso de descripciones independientes de la lógica interna del servicio, adjuntas como

descripciones de recursos.

(2) El uso de meta-servicios como interfaz común de administración de los recursos y sus

descripciones.

Por otra parte, hay que notar que debido al importante soporte de la industria y la academia, es de

esperar que las tecnologías de servicios web en la mayoría de sus ámbitos alcance consenso y

madurez en muy poco tiempo.

Productos: Lista de tecnologías a usar para cubrir los requerimientos de los servicios.

Paso 11 Administración de recursos

Descripción: Debido a la complejidad y volumen de los recursos manejados en el e-Gobierno,

más las necesidades de edición, consulta, reutilización de recursos, se necesitan herramientas

para administrar tanto los recursos particulares de una dependencia, como los comunes a varias

de ellas.

Para ello se debe contar con descripciones de recursos suficientemente ricas (ver paso 2), que

hayan sido pensadas con el fin de editar, actualizar y eliminar recursos o alguna de sus partes y

además responder las preguntas requeridas en la administración tales como: ¿Cuál es la política

de privacidad de este servicio?, ¿Qué servicios tienen políticas de privacidad compatibles?,

¿Cuáles esquemas XML ya definidos tienen que ver con un tema dado?, ¿Dónde están ubicados?,

¿Son compatibles entre si?, ¿Cuántos servicios proveen capacidad de compresión de mensajes?,

¿Qué servicios están integrados con servicios de privados?, ¿Se encuentra disponible en este

instante el servicio de autentificación de RFC?.

El modelo orientado a administración de servicios [ws-arch], define los conceptos y relaciones que

intervienen en la definición de servicios de administración para recursos Web.

Productos: Lista de preguntas que se quiere contestar con la administración de recursos y el

diseño y desarrollo de metaservicios y herramientas para lograrlo.

Paso 12 Definir arquitectura

Descripción: Un punto no abordado en este trabajo pero que también debe definirse, es la

definición de arquitectura a nivel físico, plataformas de desarrollo, servidores de aplicaciones, si

existirá una plataforma común de desarrollo como el portal e-México, etc.



Esta arquitectura debe satisfacer los requerimientos planteados para los servicios en la sección

3.5, más los particulares que necesiten servicios específicos.

Algunas guías, patrones de diseño relacionados con arquitecturas orientadas a servicios se

encuentran en [guidelines-peltz] y [soa-erl].

Productos: Especificación de la arquitectura que soportará la entrega de servicios.

Paso 13 Implementación

Descripción: Ya que se tiene un diseño completo de la lógica del servicio, descripciones de los

recursos, herramientas y plataforma, la implementación de los servicios usando servicios web

resulta más directa.

Según cada proveedor de servidores de aplicaciones, editores, marco de trabajo (framework) de

desarrollo, etc., existen patrones, recomendaciones, tutoriales y otros elementos para facilitar el

desarrollo de servicios usando servicios web.

Algunos de los framework, bibliotecas o kits de desarrollo para el desarrollo de servicios web, son:

Axis de la fundación Apache, BEA, IBM, Microsoft .NET, Perl SOAP Lite y PHP5 SOAP, BPEL,

JavaWS.

Independientemente del proveedor, los tipos de desarrollo de servicios web pueden ser

clasificados según la existencia del servicio y/o su interfaz [orth-ws-framework], lo que se resume en la

Tabla 6.

Productos Implementación de los servicios.

Nueva Interfaz del Servicio Interfaz del Servicio Existente

Nuevo Servicio Web Green-field Top Down

Servicio/Aplicación existente Bottom-Up Meet in the middle

Tabla 6: Tipos de desarrollo para Servicios Web



Conclusiones

Como resultado de la aplicación de la propuesta y de la observación de los casos

de éxito propuestos, se obtienen una serie de conclusiones que se listan en el

siguiente capitulo, resumiendo las experiencias y resultados obtenidos.



Conclusiones

Ámbito y alcance del e-Gobierno (e-Government):

El e-Gobierno trae consigo preguntas sobre su alcance y ámbito. Éste involucra un tema muy

amplio debido al alto número de actores, necesidades, complejidades de trámites e

interdependencias.

El e-Gobierno también requiere de un trabajo en diversas áreas, tales como: administración,

análisis, gestión, semántica, infraestructura y tecnologías.

Ambiente del e-Gobierno en México hoy:

El número de desarrollos de servicios para el gobierno ha ido en aumento en un número

importante de dependencias debido a la definición de leyes y decretos, la mayoría de esos

servicios entrega información a ciudadanos, marca avances hacia la modernización del Estado y la

automatización de tareas en el gobierno.

Ello sumado a la complejidad asociada al desarrollo de servicios, requiere que primero se entienda

el problema que se está abordando, su marco de trabajo respectivo, que se entregue una

propuesta que guíe el desarrollo, que se formalice, distribuya y aproveche la experiencia de los

desarrollos y que se puedan replicar las soluciones exitosas.

Alertar de la necesidad de guías y metodologías:

Hasta hoy, el esfuerzo desplegado en el e-Gobierno se ha enfocado principalmente en la entrega

de información, reingeniería de procesos y desarrollo de aplicaciones para satisfacer las

necesidades de ciudadanos por parte del gobierno.

Sin embargo, se ha dejado de lado un tema importante, así como el gobierno apuntó a la

estandarización de sus sitios web, se debe alertar que para el desarrollo de servicios – que es un

tema mucho más complejo que los sitios web - se requieren pautas, propuestas y metodologías

que guíen, sistematicen, formalicen y profesionalicen el desarrollo de servicios en el gobierno.

El no hacerlo podría acarrear problemas de interoperabilidad, mayores costos de desarrollo o

pérdida de dinero al invertir en cosas que no funcionen, deficiente uso del conocimiento y

experiencia adquirida.

Independencia y estandarización para interoperabilidad:

A pesar de que hay una base común ya definida (principios del buen gobierno) e instituciones de

coordinación, el nivel de independencia de definición de servicios, esquemas, metadatos, etc. de

cada dependencia es importante.



Es por ello, que se necesita profundizar más en la definición de guías para estandarizar los

presentes y futuros diseños, desarrollos e implantaciones.

Cabe destacar que esto no busca que todos los servicios pierdan su valiosa heterogeneidad que

los caracteriza, sino que busca acordar puntos básicos para funcionar correctamente, permitir

interoperar y establecer una base que permita desarrollos mejor controlados, mejor

interoperabilidad, mejor administración y una mejor gestión.

Importancia del estudio y trabajo en el e-Gobierno:

Las necesidades y problemas que plantea el e-Gobierno tienen puntos en común y otras tantas

particularidades comparados con las instituciones privadas.

Las coincidencias deben ser aprovechadas y se debe obtener experiencia de la industria y

proyectos exitosos en el gobierno y en las empresas privadas, las diferencias requieren que se

trabaje mediante un esfuerzo multidisciplinario para diseñar y llevar a cabo las soluciones que

satisfagan los requerimientos restantes.

Este punto aclara que realmente es razonable y necesario pensar en el desarrollo de grupos de

trabajo para llevar adelante el e-Gobierno, desde el gobierno, la industria y la academia.

Obtención de información:

A nivel global existe gran cantidad de información sobre el e-Gobierno e internacionalmente se ha

avanzado bastante en el área. Sin embargo, son escasos los trabajos que hasta hoy han abordado

el problema técnico que hay detrás.

En el caso de México existe menos información aún, donde por ejemplo, debido a temas de

confidencialidad de procesos del gobierno, proyectos como PLATAFORMA (Solución Integral SAT)

y el Sistema Nacional e-México no han podido ser mayormente estudiados y desarrollados.

Además, a la fecha de realización de este trabajo (2008) no existen aún catastros de servicios,

mayoritariamente existe información informal y una escasa centralización de ella. Es por ello que

se debe avanzar en líneas como las del proyecto de e-México visto como un portal que de acceso

a la ciudadanía a los servicios ofrecidos por el gobierno, la instalación de los Centros Digitales

(Telecentros) y así desarrollar la cultura informática en aquellos que no tienen acceso a Internet en

sus comunidades.

Para aquellos que desconocen los beneficios que puede haber en un solo portal del gobierno, esto

permitirá extender el conocimiento, permitir un análisis de la situación actual, gestionar y definir las

estrategias futuras.



Riesgos por plazos de desarrollo y experiencia existente:

Uno de los grandes impulsores del gobierno electrónico en México ha sido la legislación vigente al

respecto, que ha fijado hitos y plazos a las dependencias gubernamentales para cumplir con la ley.

Sin embargo, esta legislación puede convertirse en un problema si se piensa que para incluir al

aparato estatal completo, reestructurar procedimientos, implementar servicios y permitir que ello

sea mantenible, escalable, extensible y obviamente de alta calidad, tales plazos parecen algo

optimistas.

A ello se suma la poca experiencia nacional e internacional que avale tales plazos, lo que introduce

un gran factor de riesgo para el desarrollo exitoso de servicios de alta complejidad que requieren

de tiempo, madurez y un proceso de aprendizaje adecuado.

Integración de dependencias al e-Gobierno y propuestas de desarrollo:

Un importante desafío hoy es integrar a la mayor cantidad de instituciones (públicas y privadas) al

esfuerzo del e-Gobierno. Eso incluye dependencias con desiguales accesos a infraestructura,

tecnologías, presupuesto y conocimiento.

En relación a la integración con respecto al conocimiento de las dependencias, la entrega

extensiva de Pautas, casos exitosos, metodologías y propuestas de desarrollo, permitirá romper la

brecha existente y dar más posibilidades de progreso a todas las instituciones.

Sin embargo, no todas las dependencias hoy en día tienen tiempo, dinero ni prioridades, como

para enfocarse a temas como la simplificación de trámites, modelado de flujos documentales o

entrega de servicios integrados.

Frente a esta diversidad, se debe habilitar la posibilidad de una integración paulatina, que

considere el desarrollo de los trámites de mayor valor para los ciudadanos y no buscar

simplemente cumplir con la normativa existente, con riesgo de concretar proyectos no exitosos, de

baja calidad, poco extensibles o inútiles.

Como alternativa ante este escenario está el desarrollo de grandes plataformas como e-México

que busca integrar los servicios del gobierno mediante una infraestructura común. A pesar que en

otros países esta estrategia ha funcionado con éxito, ello ha implicado un esfuerzo importante a lo

largo de los años y no resulta en absoluto evidente que ello pueda ser logrado con el tiempo,

conocimiento, requerimientos y capacidad de desarrollo presentes en la actualidad.

Es por ello que se cree absolutamente indispensable que como trabajo inmediato se creen

experiencias a escalas mucho menores, donde el riesgo esté más acotado, que permitan predecir

de mejor manera en los siguientes desarrollos los tiempos y resultados a obtener.



Así se propone particularmente un trabajo exhaustivo en Municipios que se caracterizan por tener

un funcionamiento, estructura y necesidades de servicios similares a los de un gobierno, pero a

mucho menor escala.

Cumplimiento de requerimientos de los servicios en el e-Gobierno:

Mediante el desarrollo de casos de estudio en el gobierno, el estudio del problema del e-Gobierno

y la tecnología de servicios web, se ha comprobado que los servicios web satisfacen las

necesidades identificadas en los servicios del gobierno (caso 2 de este documetno), y que son una

valiosa componente arquitectónica para interoperabilidad, integración, desarrollo de servicios y

administración.

Ventajas de tecnología de Servicios Web:

Los servicios web ofrecen grandes beneficios, utilidad y potencial como tecnología para la entrega

y desarrollo de servicios para el e-Gobierno.

Esta aseveración también es válida al comparársele con otras tecnologías existentes, aunque ello

no implica que para todo escenario los servicios web sean la mejor solución, ni que todos los

sistemas existentes deban migrarse a tal tecnología.

Además, el hecho de que los servicios web sean recursos Web, trae consigo grandes beneficios -

altamente útiles dadas las particularidades del Gobierno - entre los cuales están: flexibilidad,

soporte, interoperabilidad de información y sistemas heterogéneos, accesibilidad, y posibilidad de

ser descritos formalmente para clasificación, administración e inferencia.

Especificación de metadatos y propuesta de desarrollo:

Dados los requerimientos identificados en los servicios para el e-Gobierno, este trabajo define un

conjunto de componentes mínimas (autentificación, metaservicios, registro de operaciones),

metadatos sobre los distintos recursos (documentos, mensajes, servicios) y una propuesta de

desarrollo.

Esta propuesta, a pesar de ser breve, resulta altamente útil ya que explica cómo abordar el

desarrollo de próximos servicios usando la tecnología de servicios web, desde su concepción hasta

la implementación, entregando referencias a temas que se deben abordar en más profundidad, y

características particulares de la tecnología de servicios web.

Los metadatos definidos permiten la especificación de aspectos relacionados con calidad de

servicio, descripción y administración de recursos, autentificación, validación, seguridad y flujo

documental.



Desafíos técnicos del e-Gobierno en México:

Existe un conjunto de desafíos planteados en este trabajo que debe abordar el gobierno Mexicano

en el corto y mediano plazo.

Entre ellos están la definición de los servicios y componentes básicos de autentificación (SSO-

Single Sign On), definición de preferencias de los ciudadanos sobre los servicios (trámites más

realizados ante las dependencias de gobierno), definición de políticas, capacidades y restricciones

sobre servicios, consulta de información de trámites, administración de recursos y herramientas

para manejo de metadatos y esquemas.

Complementar experiencia de este trabajo con experiencia en dependencias:

A pesar de que en México aún no existe una basta experiencia en el uso de la tecnología de

servicios web para la entrega de servicios, ya existen suficientes iniciativas exitosas que permitirían

complementar, corregir y mejorar la propuesta de solución presentada en este trabajo.

En los próximos desarrollos a realizar, se debe ayudar a formalizar el conocimiento y la experiencia

obtenida en la creación de servicios, los procesos involucrados y las buenas prácticas de

desarrollo.

Todo esto requiere una discusión transversal y no necesariamente dentro de una dependencia que

entregue las guías básicas de desarrollo, para que posteriormente cada institución pueda extender

o personalizar las definiciones presentadas según sus necesidades.

Explorar nuevos beneficios de Servicios Web:

Este trabajo presentó la tecnología de servicios web como una potente herramienta al momento de

interoperar, comunicar y automatizar servicios, pero no se trató tan intensivamente desde el punto

de vista del modelo de desarrollo de aplicaciones, flexibilidad, la natural modularidad o la

reutilización que entrega.

A pesar de que estas características se presentan en la literatura sobre la tecnología de servicios

web, resultaría muy interesante comprobar como ello se comporta en un ambiente como las

escuelas de gobierno (consulta de calificaciones), los servicios de bibliotecas, la solicitud de

pasaportes y licencias de conducir, pagos de tesorería y trámites relacionados con los trabajadores

del estado como pensiones y jubilaciones, todo esto ayudaría a mejorar la propuesta de solución y

a presentar opciones alternas de desarrollo.

Uso de semántica en el e-Gobierno:

La descripción formal de recursos permite su clasificación, búsqueda, actualización, administración

y gestión. Para ello se ha propuesto el uso de metaservicios como una capa lógica de más alto

nivel.



Además, las descripciones pueden ser potenciadas, por ejemplo, mediante el uso de ontologías

particulares para el e-Gobierno, sin embargo, por la inmadurez actual en la creación, uso,

mantenimiento y evolución de ontologías, antes de seguir con una nueva capa de abstracción al

respecto, se considera prudente comenzar con la descripción formal de recursos y el uso de

metaservicios.

Aprovechar la experiencia internacional y sumarse al esfuerzo global:

Una de las características comunes de las experiencias internacionales con respecto al e-

Gobierno, tiene que ver con la cooperación, apertura y presentación de las guías, especificaciones,

decisiones y casos de estudio de cada Gobierno.

A pesar de que en México se han estudiado iniciativas internacionales, aún se puede avanzar

mucho más en la colaboración para el exitoso desarrollo del e-Gobierno (proyecto e-México), por lo

que se puede proponer generar una política de cooperación internacional en el tema y mantener

canales de información a la comunidad internacional y público en general de la estrategia

mexicana.

Los gobiernos y las empresas privadas deben voltear a ver los grandes beneficios que

pueden traer consigo organizaciones operando como grandes fábricas de servicios,

interconectadas entre si para lograr una gran máquina proveedora de productos y servicios

llamada GOBIERNO ELECTRÓNICO, sin olvidar la independencia de la iniciativa privada.

El incremento de la “productividad” al interior de las organizaciones, los objetivos de “servir

mejor” para “vivir mejor” y “hacer la vida de las personas más fácil”, son factores que

propician una mejor imagen de las mismas organizaciones, al hacerlas más “competitivas” y

generando procesos que dejan ver la “transparencia” de sus “operaciones y servicios”.

Integración de aplicaciones corporativas mediante Web Services Glosario

UPIICSA - IPN

Glosario

1. Agente: Programa computacional que actúa en nombre de una persona u organización.

Un Agente Web corresponde a un programa computacional que es accesible vía Web.

2. API: Application Program Interface. Interfaz de programación de aplicaciones.

3. Attachment, Atachado: Palabra utilizada para describir un recurso que reside dentro de

otro.

4. Auditability (Auditabilidad): Mecanismo que permite probar que las operaciones

registradas realmente fueron realizadas, derivado del termino “auditar”.

5. B2B - Business to Business (Negocio a Negocio).

6. Calidad de Servicio (QoS, Quality of Service): Parámetros no funcionales sobre los

servicios que definen tiempo de respuesta, disponibilidad, confiabilidad, entre otros.

7. CCD: Centro Comunitario Digital.

8. COM Component Object Model: Arquitectura de software para construir aplicaciones

basadas en componentes.

9. COMPRANET: Compras por Internet, portal gubernamental.

10. CONACYT: Consejo Nacional de Ciencia y Tecnología, México.

11. CORBA Common Object Request Broker Architecture: Protocolo interoperable de

computación distribuida orientada al objeto.

12. Coreografía, Choreography: Definición de la secuencia y condiciones, bajo las cuales

múltiples agentes cooperan intercambiando mensajes para realizar una tarea.

13. CRM (Customer Resource Mannagement): Sistema de administración de recursos de

clientes.

14. CURP: Clave Única de Registro de Población

15. Dublin Core: Iniciativa de metadatos para la Web.

16. e-GIF Interoperability Framework for e-Government: Framework para la

interoperabilidad en el e-Government definida por GovTalk.

17. e-Government: Gobierno electrónico

18. ERP (Enterprise Resource Planning): Sistema de Planeación empresarial de recursos.

19. FEA: Firma Electrónica Avanzada, también llamada a veces FIEL.

20. FIEL: Acrónimo para Firma Electrónica.

21. FTP (File Transfer Protocol): Protocolo de Transferencia de Archivos.

22. GRP (Government Resource Planning): Sistema de Planeación de recursos

gubernamentales.

23. HTML (Hipertext Markup Language): Lenguaje de marcado de hipertexto (para páginas

web).

24. HTTP (Hipertext Transfer Protocol): Protocolo para la transferencia de hipertextos,

protocolo más usado en Internet.


UPIICSA - IPN

25. IFAI: Instituto Federal de Acceso a la Información.

26. IFE: Instituto Federal Electoral.

27. IIMAS: Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas.

28. IMSS: Instituto Mexicano del Seguro Social

29. INAFED: Instituto Nacional para el Federalismo y Desarrollo Municipal.

30. INAPAM: Instituto Nacional de las Personas Adultas Mayores.

31. INEA: Instituto Nacional para la Educación de los Adultos, ahora INAPAM.

32. INEGI: Instituto Nacional de Estadística, Geografía e Informática, México.

33. INFONAVIT: Instituto de Fondo Nacional de la Vivienda para los Trabajadores.

34. Internet – International network; red de computadoras internacional.

35. ISSSTE: Instituto de Seguridad Social al Servicio de los Trabajadores del Estado.

36. ITESM: Instituto Tecnológico de Estudios Superiores de Monterrey.

37. Java: Lenguaje de programación orientado a objetos.

38. LFTAIPG: Ley Federal de Transparencia y Acceso a la Información Pública

Gubernamental.

39. Mensaje: Unidad básica de información enviada de un agente de Servicios Web a otro.

40. MOM (Message Oriented Model): Modelo arquitectónico de Servicios Web orientado a los

servicios.

41. OASIS (Organization for the Advancement of Structured Information Standards):

Consorcio de empresas para la creación de estándares en tecnologías de información.

42. Ontología: El término ontología en informática hace referencia al intento de formular un

exhaustivo y riguroso esquema conceptual dentro de un dominio dado, con la finalidad de

facilitar la comunicación y compartir la información entre diferentes sistemas. Esta es la

diferencia, aunque toma su nombre de una analogía con el significado filosófico de la

palabra ontología, donde se dice que la ontología es el estudio del ente en cuanto a tal. Por

ello es llamada la teoría del ser, es decir, el estudio de las cosas: qué es, cómo es y cómo

es posible. La Ontología se ocupa de establecer las categorías fundamentales o modos

generales de ser de las cosas.

43. ONU: Organización de las Naciones Unidas.

44. PGR: Procuraduría General de la República, México.

45. RDF (Resource Description Framework): Lenguaje para la descripción de recursos.

46. RFC: Registro Federal de Contribuyentes

47. RMI (Remote Method Invocation): Protocolo que permite a objetos Java comunicarse

remotamente.

48. RPC (Remote Procedure Call): Protocolo de llamada a procedimientos remotos.

49. SAT: Servicio de Administración Tributaria.

50. SCT: Secretaría de Comunicaciones y Transportes.

51. SEDESOL: Secretaría de Desarrollo Social, México.


UPIICSA - IPN

52. SEGOB: Secretaría de Gobernación, México.

53. SEP: Secretaría de Educación Pública, México.

54. SHCP: Secretaría de Hacienda y Crédito Público, México.

55. SISI: Sistema de Solicitudes de Información.

56. SMTP (Simple Mail Transfer Protocol): Protocolo de Transferencia de Correo Simple.

57. SOA: Arquitectura Orientada a Servicios (Service Oriented Architecture)

58. SOA: Service Orientede Arquitechture; Arquitectura Oritentada a Servicios Web

59. SOAP (Simple Object Access Protocol): Protocolo de transmisión de mensajes basado

en XML.

60. SOM (Service Oriented Model): Modelo arquitectónico de Servicios Web orientado a los

mensajes.

61. SPEI: Sistema de Pagos Electrónicos Interbancarios de la banca comercial, México.

62. SPF: Servicio Profesional de Carrera de la administración pública federal de México.

63. SRE: Secretaría de Relaciones Exteriores.

64. SSA: Secretaría de Salud y Asistencia.

65. SSL (Secure Socket Layer): Capa de Conexión (socket) Segura.

66. SSO (Single Sign On): Firmado una sola vez (mecanismo de autenticación).

67. TESOFE: Acrónimo para Tesorería de la Federación.

68. TI (Technology Information): Tecnologías de la Información.

69. TIC (Technology Information and Communication): Tecnologías de la información y

Comunicación.

70. UDDI (Universal Description, Discovery and Integration): Directorio de Servicios Web.

71. UIA: Universidad Ibero Americana.

72. UML (Unified Modeling Language): Lenguaje Unificado de Modelado.

73. UNAM: Universidad Nacional Autónoma de México.

74. UNÍX: Sistema operativo de laboratorios Bell.

75. URI (Uniform Resource Identifier): identificador uniforme de recurso.

76. URL(Uniform Resource Locator): Localización uniforme de un recurso.

77. VPN (Virtual Private Network): Red Privada Virtual

78. W3C (World Wide Web Consortium): Consorcio de la Web (www).

79. Web – Termino para referirse a un ambiente de trabajo de Internet

80. Web Services: Servicios Web.

81. WorkFlow: Flujo de Trabajo.

82. WS (Web Services); Servicios Web.

83. WSDL (Web Service Description Language): Lenguaje de descripción de capacidades

de Servicios Web.

84. XML (Extensible Markup Language): Lenguaje de etiquetado extensible.

85. XML Schema: Esquema XML.

Integración de aplicaciones corporativas mediante Web Services Relación de Figuras

UPIICSA - IPN

Relación de Figuras INTRODUCCION

Página Figura.

vi Figura 1. Trámites realizados en el portal del SAT.

vii Figura 2. Uso de un solo portal para todos los trámites públicos y privados.

CAPITULO 1

Página Figura.

6 Figura 3. Conceptualización de un conjunto de aplicaciones como una caja negra

7 Figura 4. Interacción manual entre aplicaciones de una misma organización.

8 Figura 5. Interacción automatizada entre aplicaciones de la organización.

9 Figura 6. Proceso / validación Manual

9 Figura 7. Proceso / validación Automatizada

12 Figura 8. Éxito de un proyecto ERP.

CAPITULO 2

Página Figura.

22 Figura 9. Estructura del eGobierno México (política del Buen Gobierno)

24 Figura 10. Esquema de integración de aplicaciones entre secretarias (Portal único)

32 Figura 11. Comité de Interoperabilidad

33 Figura 12. Número de usuarios de Internet en México

46 Figura 13. Arquitectura e-GIF

48 Figura 14. Framework del e-SDF para desarrollo de nuevos Servicios.

CAPITULO 3

Página Figura.

58 Figura 15. Modelo de funcionamiento de SOA.

81 Figura 16. Tecnologías en Servicios Web. Figura tomada de [web-design]

83 Figura 17. Modelo arquitectónico orientado a mensajes. Figura tomada de [ws-design]

84 Figura 18. Modelo arquitectónico orientado a servicios. Figura tomada de [ws-design]

Integración de aplicaciones corporativas mediante Web Services Relación de Figuras

UPIICSA - IPN

Relación de Figuras CAPITULO 4

Página Figura.

97 Figura 19. Trámite para solicitud de Registro al RFC, validación de documentos.

99 Figura 20. Trámites de impresión de facturas y/o recibos, y facturación de productos y servicios.

100 Figura 21. Solicitud de créditos y validaciones contra SHCP y Buró de Crédito.

101 Figura 22. Solicitud de crédito bancario, validando contra IFE y SHCP.

113 Figura 23. Mecanismo semiautomático para pago de Nómina Federal

114 Figura 24. Trámite para solicitud de Cuenta de nómina para depósitos de la dependencia.

116 Figura 25. Propuesta de solución para el pago de nóminas usando servicios web para automatizar el proceso.

128 Figura 26. Solicitud de pasaporte ordinario mexicano [OP-5].

130 Figura 27. Trámite para solicitar el pasaporte ordinario mexicano.

132 Figura 28. Trámite para solicitar una licencia de conducir en el Distrito Federal.

134 Figura 29. Propuesta de solución para el trámite de solicitud de Pasaporte.

Integración de aplicaciones corporativas mediante Web Services Relación de Tablas

UPIICSA - IPN

Relación de Tablas

Página Tabla 18 TABLA 1. Evolución de las aproximaciones a la evaluación del gobierno

electrónico.

26 TABLA 2. Estados con los mejores puntajes totales. 29 – 30 TABLA 3. Clasificación a nivel mundial, fuente: “Índice Global de Preparación para

el Gobierno Electrónico” de la ONU.

31 TABLA 4. Comparación de las posiciones obtenidas en los reportes del 2006, 2005 y 2004 para América Latina y El Caribe. Fuente: Informes del Global Information Technology Report de años anteriores.

94 TABLA 5 Clasificación de metadatos en los servicios en el e-Gobierno. 158 TABLA 6. Tipos de desarrollo para Servicios Web.

Integración de aplicaciones corporativas mediante Web Services Bibliografía

UPIICSA - IPN

Bibliografía Libros:

[Shari Lawrence Pfleeger] Pfleeger Lawrence, Shari. Ingeniería de Software, teoría y práctica, primera edición México 2002. Addison Wesley. Capitulo 4, “La determinación de los requerimientos”, páginas 156 a la 205. [utilización de UML] Stevens, Perdita et al Pooley Rob. Utilización de UML en Ingeniería del Software con Objetos y Componentes, ultima reimpresión 2003 Madrid España, Addison Wesley. Parte III Estudio de casos, capítulo 17 Simulación de eventos discretos, páginas 213 a la 232. [uml y patrones] Larman, Craig. UML y Patrones, Una introducción al análisis y diseño orientado a objetos y al proceso unificado. 2ª Edición 2004 Madrid España, Prentice Hall.

Capítulo 5 “Comprensión de los requisitos”, páginas 39 a la 41. Capítulo 7 “Identificación de otros requisitos”, páginas 80 a la 100.

[seguridad Informática] J. Firtman, Sebastián. Seguridad Informática, las amenazas y vulnerabilidades más peligrosas, al desnudo, 1ª edición Buenos Aires, Argentina, MP Ediciones. Capítulo 5 “Amenazas”, páginas 84 a la 102 Capítulo 6 “Vulnerabilidades”, páginas 104 a la 119.

Otros textos:

Introduction to Digital Government Research in Public Policy and Management S.S. Dawes (In Chen, H., et al. eds., Digital Government: E-Government Research, Case

Studies, and Implementation. Springer), versión PDF 2006, revista ZDNet en línea.

New Models of Collaboration for Delivering Government Services: A Dynamic Model Drawn from Multi-National Research S.S. Dawes and O. Eglene (In Bhattacharya, Moonmoon, ed., E-Collaboration: An

Introduction, Hyderabad, India: Icfai University Press), versión PDF del líbro, IEEE 2005. Interorganizational Information Integration: A key enabler for digital government T.A. Pardo, and G.K. Tayi (Government Information Quarterly, Volumen 24, Capítulo 4, Páginas 691-715)

Ligas y documentos en la red:

1. [accenture2003] Accenture, e-Government LeaderShip: Engaging the Customer. Abril 2004. http://www.acenture.com

2. [accenture2004] Accenture, e-Government LeaderShip: High Performance, Maximum Value. Mayo 2004. http://www.acenture.com

3. [agls-35] Australian Government Locator Service Standard (AGLS). http://www.oict.nsw.gov.au/pdf/4.4.34.AGLS_Gdl_v3.5.pdf

4. [bpel4ws] Andrews, T. et al. Business Process Execution Language for Web Services. Versión 2003. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel


UPIICSA - IPN

5. [daml] Martin D. DAML-S Semantic Markup for Web Services. DARPA Agent Markup Language. http://www.daml.org/services/daml-s/0.9/daml-s.html

6. [describing-services-nzgls] Roberts, Jhon. Describing services for a metadata driven portal. Capítulo 6. http://www.e-government.govt.nz

7. [dublin-core] Dublin Core Element Set. Version 1.1. Reference Description. Dublín Core Metadata Initiative http://dublincore.org/documents/dces/

8. [e-gif] European interoperability framework for pan-European e-Government services. Versión 6.0. Abril 2004. http://www.govtalk.gov.uk/

9. [e-gms] Cabinet Office. e-Government Metadata Standard. Version 3.0. 2004. http://www.govtalk.gov.uk/documents/eGovMetadataStandard%2020040429.pdf

10. [eGobiernoMéxico] Iniciativa del gobierno mexicano para implementar gobierno electrónico, http://www.e-mexico.gob.mx/wb2/eMex/eMex_gob

11. [e-gov-roadmap] RoadMap for e-Government in the developing world. 10 Questions e-Governments leaders should ask themselves. The Working group on e-Government in the developing World. Abril 2002. http://unpan1.un.org/intradoc/groups/public/documents/CARICAD/UNPAN008526.pdf.

12. [eMéxico] Portal informativo sobre la iniciativa e-México, http://www.emexico.gob.mx 13. [estandar-esa] ESA Software Engineering Standard. European Spacial Agency. Febrero

1991. 14. [firma electrónica] Estándar para el manejo de firma de documentos de manera electrónica.

http://www.inegi.gob.mx/inegi/contenidos/espanol/ciberhabitat/comercio/firma/index.html http://www.sat.gob.mx/sitio_internet/e_sat/tu_firma/ http://www.sat.gob.mx/sitio_internet/e_sat/oficina_virtual/108_4591.html http://www.firma-electronica.unam.mx/

15. [frez-ws-admin] Frez Pulgar, Rodrigo. Sistema de administración de Servicios Web a nivel semántico. Santiago de Chile 2004. Memoria para título de Ingeniero Departamento de Ciencias de la Computación de la Universidad de Chile, biblioteca virtual http://www.dcc.uchile.cl/1877/channel.html.

16. [Gil-Garcia] Gil-García, J. R., & Luna-Reyes, L. F. (2003). Towards a Definition of Electronic Government: A Comparative Review. In A. Mendez Vilas et al. (Ed.), Techno-legal Aspects of the Information Society and New Economy: An Overview. Badajoz, Spain: Formatex.

17. [gob-psee] Plataforma integrada de Servicios del Estado: un proyecto unificador. Presentación de caso. PRYME. Thierry de Saint Pierre. http://www.e2g.gov.cl

18. [gov-talk] Cabinet Office, Sitio Web de Govtalk http://www.govtalk.gov.uk 19. [guidelines-peltz] Peltz, Crhis. Best Practices for Web Services Development. Invent Online

Seminar. Noviembre 2002. http://www.presentationselect.com/hpinvent/archive.asp?eventid=40 20. [herman-ws] Herman, Ivan. Current Development at W3C, and the Semantic Web. W3C

Talk. Seúl, Corea, 24 de Junio del 2004. http://www.w3.org/2004/Talks/0624-Seoul-IH 21. [INEGI] Recorrido por México, http://www.inegi.org.mx 22. [InfoWorld-Mercado Arceo] Mercado Arceo, Claudia. “Gobierno y TI: se reduce la brecha

digital”, http://www.iworld.com.mx/iw_Opinions_read.asp?IWID=61

23. [ISO-8402] Iso 8402, Términos generales. http://ver.megared.net.mx/~jccz/iso8402.html

24. [normaXML] Gutiérrez, Claudio et al. e-Government in Chile, and the adoption of XML as standard: Experiences, Challenges and Perspectives. Workshop on E-Government, DEXA 2005 http://www.in3.cl

25. [oasis] Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org

26. [onu2002, 2005, 2004] DPEPA-ONU. “Benchmarking E-Government:A Global Perspective; Assessing the Progress of the UN Member States”, New York, Mayo 2002

27. [orth-ws-framework] Günter, Orth. The Web Services Framework: A Survey of WSDL, SOAP and UDDI. Master’s Thesis, Information System Institute, Distributed System Group, Vienna University of Technology. Vienna 21 de Mayo del 2002.

28. [owl-s] Martin, David. OWL-S Semantic Markup for Web Services. Versión 1.0. Diciembre 2003. http://www.daml.org/services/owl-s/1.0/owl-s.html


UPIICSA - IPN

29. [metadata-guide] NSW Government Department of Commerce. NSW AGLS Metadata Guideline. Draft. Versión 3.5. Mayo 2003.

30. http://www.oict.nsw.gov.au/pdf/4.4.34.AGLS_Gdl_v3.5.pdf 31. [Ramiro Rodríguez] “Tesis ERP en la administración de proyectos de construcción”, base

de datos en línea de la biblioteca digital ITESM. ITESM Cd. México 2003. 32. [rdf] Manola, Frank and Miller Eric. RDF Primer. W3C Recommendation. Febrero 2004.

http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ 33. [reach] REACH agency , Gobierno de Irlanda http://www.reach.ie/ 34. [rfc-http] Fielding, R. et al. Hypertext transfer Protocol – HTTP/1.1. 1999. Capítulo 12.

Content Negotiation. http://www.w3.org/Protocols/rfc2616/rfc2616.html 35. [saml] Cantor, Scot et al. Assertions and Protocols for the OASIS Security Assertion

Markup Language (SAML) V2.0 . OASIS Standard, 2005. 36. [Sandoval 2006, Política Digital] Sandoval Almazán, Rodrigo. “Evaluaciones de los

portales web estatales en México”, ITESM-Campus Toluca. Publicadas por la revista Política digital, http://rsandov.blogs.com/metagobierno/2006/07/index.html , http://www.nl.gob.mx/?P=acercade, http://www.politicadigital.com.mx.

37. [schema-design] Hunter, Robin. e-Government Schema Guidelines for XML. Versión 3.1. Enero 2004. http://www.govtalk.gov.uk/documents/schema-guidelines-3_1(1).pdf

38. [SEDESOL] Página web de la Secretaria de Desarrollo Social, México http://www.sedesol.gob.mx

39. [selman-ws] Selman, José. Aspectos de Seguridad para Servicios Web. Santiago de Chile 2005.Memoria para título de Ingeniero Departamento de Ciencias de la Computación de la Universidad de Chile.

40. [SFP] Secretaría de la Función Pública, México. http://www.funcionpublica.gob.mx/ 41. [sinim-encuesta] Resultado de Encuesta tecnológica Municipal, Sistema Nacional de

Indicadores Municipales http://www.sinim.cl/ 42. [soa-erl] Erl, Tomas. Service-Oriented Architecture. A Field Guide to Integrating XML and

Web Services. 43. [soap] Gudgin, Martin. Et al. SOAP Version 1.2 Part 1: Messaging Framework. W3C

Recommendation. June 2003. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 44. [soap-attachment] Bosworth A. et all. SOAP UIT Attachments. Versión 0.61. 2003

http://dev2dev.bea.com/webservices/SOAP_Messages_Attachments.csp 45. [tramitanet] Trámites y servicios para la ciudadanía, http://www.tramitanet.gob.mx 46. [uddi] Publicación de Web Services en la red.

http://www.w3schools.com/WSDL/wsdl_uddi.asp 47. [web-design] Tim Berners-Lee, Design Issues - Architectural and philosophical points,

W3C. http://www.w3.org/DesignIssues/ 48. [workflow-e-Gov] Verginadis, G and Mentzas, G. (2004) ‘A light modeling framework for e-

Government service workflows’, Electronic Government Vol. 1, No 4, pp.420-438. 49. [ws-arch] Web services architecture description, W3C.

http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ 50. [ws-addressing] Box, Don. Et al. Web Services Addressing. W3C Member Submission.

Agosto 2004. http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ 51. [ws-arch] Haas, Hugo. Web Services Architecture, W3C Working Group Note. Febrero

2004. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ 52. [ws-addressing] Box, Don. Et al. Web Service Addressing. W3C Member Submission.

Agosto 2004. http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ 53. [ws-cc-workshop] W3C Workshop on Constraint and Capabilities for Web Services.

Octubre 2004. http://www.w3.org/2004/09/ws-cc-program.html 54. [ws-coordination] Storey, T. et al. Web Services Coordination. 2004. ftp://www6.software.ibm.com/software/developer/library/WS-Coordination.pdf 55. [ws-challenges-sol] Brajesh De, Web Services - Challenges and Solutions, Wipro

Technologies. 56. [ws-choreography] Web Services Choreography Model Overview. W3C Working Draft.

2004. http://www.w3.org/TR/2004/WD-ws-chor-model-20040324/


UPIICSA - IPN

57. [ws-design] Berners Lee, Tim. Design Issues in Web Services. Notas personales. http://www.w3.org/DesignIssues/WebServices.html

58. [wsdl] W3C, Lenguaje de Descripción de Servicios Web. http://www.w3.org/TR/wsdl 59. [ws-federation] Shewchuk, J. Web Services Federation Language (WS-Federation). Julio

2003. http://ftpna2.bea.com/pub/downloads/WS-Federation.pdf 60. [ws-i] Web Services Interoperability Organization (WS-I) http://www.ws-i.org/ 61. [ws-performance] Java Performance Tuning. Web Services Performance Tips. Mayo 2005.

http://www.javaperformancetuning.com/tips/webservice.shtml 62. [ws-policy] Web Service Policy Framework and Web Services Policy Attachment.

Septiembre 2004. http://schemas.xmlsoap.org/ws/2004/09/policy/ 63. [ws-reliability] Iwasa Kazunori, et al. Web Services Reliable Messaging TC. WS-Reliability

1.1. Agosto 2004. http://docs.oasis-open.org/wsrm/2004/06/WS-Reliability-CD1.086.pdf 64. [ws-security] Web Services Security v1.0 (WS-Security 2004). OASIS. Marzo 2004.

http://www.oasis-open.org/specs/index.php#wssv1.0 65. [ws-worth] Wiederhold, Gio. What are Web Services Worth ?. 2005. http://wwwdb.stanford.edu/pub/gio/2005/WebWorth1.pdf 66. [wsa-req] Web Services Architecture Requirements. W3C Working Group Note. Febrero

2004. http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211 67. [xml] Bray, Tim. Et al. Extensible Markup Language (XML) 1.1. W3C Recommendation.

Febrero 2004. http://www.w3.org/TR/2004/REC-xml11-20040204/ 68. [xml-encryption] XML Encryption Syntax and Processing. W3C Recommendation.

Diciembre 2002. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ 69. [xml-schema] FallSide, David C. XML Schema Part 0: Primer Second Edition. W3c

Recommendation. Octubre 2004. 70. [xml-sig] Eastlake, D. XML Signature Syntax and Processing. W3C Recommendation.

2002. http://www.w3.org/TR/xmldsig-core/

Integración de aplicaciones corporativas mediante Web Services Anexos

UPIICSA-IPN

ANEXO A RESUMEN

Infraestructura Protocolo IES (Banxico)

ARC

AGENCIA REGISTRADORA CENTRAL

BD

Contiene claves

publicas propias

AR2

(BANXICO)

AR3

(SFP)

AGENCIA REGISTRADORA

AR1

(SAT)BD

Contiene certificados

digitales propios

ARA

SPEI

AGENCIA REGISTRADORA APLICATIVA

AC1 AC2 AC3

Crea certificados

digitales mediante

claves pública y

privada

AGENCIA CERTIFICADORA

Interfaz de

comunicación con la

IES

SISTENA DE PAGOS ELECTRONICOS

INTERBANCARIOS

BD

Contiene certificados

digitales

ANEXO B

ANEXO C

Infraestructura de solución para SIAFF-SPEI

1. Comunicación mediante Aplicación Web para recepción de archivos de nómina.

2. Validaciones de seguridad en archivo de nómina con protocolo IES en TESOFE.

3. Validaciones de negocio en archivo de nómina en TESOFE.

4. Comunicación TESOFE – SPEI mediante Arquitectura J2EE (JMS, Web Service).

5. Validaciones de seguridad en archivo de nómina con protocolo IES en BANXICO.

6. Dispersión de nómina en los bancos.

7. Módulo de consultas y/o rechazos hacia las dependencias (Histórico de SIAFF).

8. Módulo de consultas en línea hacia el SPEI.

VPN SIAFF

Firewall

FRONTEND

(Histórico de SIAFF)

IES

Service Provider (J2EE)

(JMS, WEB SERVICE)

6

BANCOS

5

4

INTERNET

TESOFE

SPEI - BANXICO

1

2

3

DEPENDENCIAS DE

GOBIERNO

7

NSIAFF

FRONTEND (Consulta en línea SPEI)

Firewall

8

instituto politÉcnico nacional - virtual.sepi.upiicsa.ipn.mx · capitulo 2 antecedentes,...

Documents