TSIGE 2017 AplicacionesEmpresariales Extendido

Taller de Sistemas de
Información Geográficos
Empresariales
Aplicaciones Empresariales y GIS

Motivación
Aplicación
Aplicación
Empresarial
Empresarial
Aplicación
Aplicación
Sistema Empresarial
Empresarial
Sistemadede
Información
Información Aplicación
Aplicación
Geográfica
Geográfica Empresarial
Empresarial
Aplicación
Aplicación
Empresarial
Empresarial
INCO - Facultad de Ingeniería – Montevideo, Uruguay 2

Agenda
 Aplicaciones Empresariales
 Middleware
 SOA y ESB
 Arquitectura y Tecnologías GIS
 Alternativas de Integración

Taller de Sistemas de Información
Geográficos Empresariales
Aplicaciones Empresariales
Una Aplicación Empresarial es una
aplicación de software desarrollada para
administrar las operaciones, activos y
recursos de una empresa
Algunos ejemplos:
o Contabilidad
o Seguimiento de envíos
o Servicio al cliente
o Nómina de empleados

Las aplicaciones empresariales tienen en
general las siguientes características:
o Involucran persistencia de datos
o Se manejan grandes cantidades de datos
o Existen varias interfaces de usuario, para
distintos tipos de usuario
o En general se deben integrar con otras
aplicaciones
o Se accede a los datos de forma concurrente

El proceso de desarrollo de una aplicación
empresarial involucra al menos:
o Programadores de aplicaciones
o Administradores de base de datos
o Diseñadores de interfaz de usuario
o Integradores de aplicaciones

La creación y mantenimiento de las
aplicaciones presenta varias complejidades:
o Administración
o Mantenibilidad
o Escalabilidad
o Interoperabilidad
o Seguridad
o Confiabilidad
o Accesibilidad y Usabilidad
o Internacionalización
Arquitectura en Capas (Layers)
“Layers” es un estilo arquitectónico que
comúnmente se utiliza para las Aplicaciones
Empresariales
En este esquema las capas más altas utilizan
servicios definidos por las capas más bajas
Esta división lógica entre capas
de funcionalidad pueda basarse
en distintas responsabilidades

Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0

Capa de presentación
o Contiene la funcionalidad responsable de gestionar
la interacción del usuario con el sistema
o Actúa como puente entre el usuario y la lógica de
negocio

Capa de negocio
o Implementa la funcionalidad central de la aplicación
o Encapsula la lógica de negocio relevante para la
aplicación
o Consiste en componentes,
los cuales exponen
(en algunos casos)
interfaces para que otros
utilicen

Capa de acceso a datos

o Provee acceso a los datos almacenados en las
fronteras de la aplicación, así como a los datos
expuestos por otros sistemas de información a los
que se tiene conexión
o Los componentes en la capa
de negocio hacen uso de los
datos provistos por estos
componentes

Arquitectura Física (Tiers)
Las capas antes presentadas pueden estar

ubicadas en la misma locación física (tier) o en
diferentes locaciones físicas
Si se encuentran en locaciones físicas
diferentes, existen fronteras físicas que deben
ser tomadas en cuenta en el diseño

Deployment No Distribuido
Este enfoque minimiza el número de

servidores requeridos
Minimiza el impacto en performance
inherente a la comunicación entre capas de
diferentes lugares físicos
Sin embargo, compartir el mismo hardware,
puede impactar la performance, por ejemplo,
al acceder a recursos compartidos

Deployment Distribuido
Este enfoque permite configurar el hardware

según las necesidades de cada capa
Esto permite ajustar las necesidades de
escalabilidad según cada capa de la aplicación
Sin embargo, el uso de componentes
distribuidos, impacta la performance a la hora
de realizar llamadas remotas entre diferentes
locaciones físicas

Deployment Distribuido (N-Tiers)
Cliente / Servidor
2-Tier
3-Tier
N-Tier

Cliente / Servidor

3-Tier

4-Tier

Integración de Aplicaciones
Integración de Aplicaciones Empresariales
(EAI) es la tarea de hacer que aplicaciones
desarrolladas de forma independiente trabajen
de forma conjunta con el fin de compartir
datos y procesos de negocio

Al integrar Aplicaciones Empresariales
surgen varios desafíos:
o Las redes no son confiables
o Las redes son lentas
o Las aplicaciones son diferentes
 a nivel de lenguajes de programación, formato de
datos, etc
o El cambio en las aplicaciones es inevitable

Históricamente se han utilizado distintos
enfoques para la integración:
o Transferencia de archivos
o Base de datos compartida
o Invocación de procedimientos remotos
 Comunicación sincrónica
o Mensajería
 Comunicación asincrónica
o A nivel de Interfaz de Usuario

Plataformas de Desarrollo
Empresarial
Existen plataformas que facilitan el desarrollo
e integración de aplicaciones empresariales
Las mismas brindan soluciones a varios de

los problemas presentados
Permiten que el desarrollador se concentre

en los aspectos relevantes para el negocio

Plataformas de Desarrollo
Empresarial
.Net Framework
Java Enterprise Edition

.NET Framework
Es un Framework desarrollado por Microsoft
Incluye
o Una biblioteca de clases orientada al
programador a fin de facilitar los problemas
típicos de programación
o Una maquina virtual que administra la ejecución
de programas escritos para esta plataforma

.NET Framework
La biblioteca de clases provee una gran
variedad de funcionalidades, entre las que se
incluyen
o Interfaz de usuario
o Acceso a datos
o Conectividad
o Aplicaciones web
o Seguridad

.NET Framework
Los programas escritos para el framework
.NET ejecutan en un ambiente de software
que administra los requerimientos de dicho
programa
Este ambiente de ejecución, se denomina
Common Language Runtime

Common Language Runtime
Otros servicios que provee
o Seguridad
o Manejo de memoria
o Control de excepciones
o etc

.Net Framework
1. ASP.NET / ASP.NET MVC

2. AJAX
3. WPF
4. Silverlight
5. WCF 1 2 3 4
6. WS*
13
7. Workflow Foundation 5 6
8. Datatypes 7
8 9
9. Datasets
10. ADO.NET
11. LINQ 10 11 12 5
12. Entity Framework / NHibernate

13. Membership
14. SQL Server
14

Java Enterprise Edition
Definición de Sun Microsystems
o Java Enterprise Edition (Java EE) define el
estándar para el desarrollo de aplicaciones
empresariales distribuidas, basadas en
componentes, utilizando un modelo de múltiples
capas.

Independencia del proveedor
La plataforma promueve la construcción de
sistemas independientes de la plataforma
o Heredado de Java
La especificación es abierta, puede ser
implementada por cualquier proveedor
Éste deberá cumplir dicho estándar
o Hay procesos de certificación
o No implica que sólo debe soportar lo que el
estándar establece

Servidores Java EE
 Representa el ambiente en el que ejecutan los
componentes Java EE
 Estos componentes se denominan componentes
server-side o componentes de aplicación JEE
 Pueden tomar la forma de
o Componentes web (JSP / Servlets / JSF)
o Componentes de negocio (EJB)
 Estos componentes ejecutan en un runtime
denominado contenedor

Servidores Java EE

Contenedores Java EE
Los componentes web y de negocio, existen
y ejecutan dentro de contenedores
Los componentes de aplicación JEE nunca
interactúan directamente entre sí
o utilizan protocolos y métodos del contenedor para
interactuar entre ellos y con servicios de la
plataforma
o este rol de intermediario le permite al contenedor
inyectar servicios requeridos por los
componentes

Contenedores Java EE
Un contenedor permite a los componentes
interactuar con los servicios brindados por el
servidor de aplicaciones
o Seguridad
o Acceso a datos
o Transacciones
o Acceso a recursos
o Comunicaciones

Componentes

Java EE
1. Java Server Faces
2. Flex
3. Granite
4. AJAX
5. JAX-WS 1 2 3 4
6. WS*
7. jBPM 5 6
8. EJB3
7 8
9. Java Persistance API
10. Hibernate
9 10
11. PostgreSQL
11

Middleware
Middleware
 Middleware es una capa de software distribuida, situada
entre el sistema operativo y las aplicaciones, diseñado
para manejar la heterogeneidad y complejidad inherente
a los sistemas distribuidos
Aplicación Distribuida Aplicación Distribuida

HOST 1
HOST 2
MIDDLEWARE API MIDDLEWARE API
Middleware Middleware
S.O. API S.O. API
Sistema Operativo Sistema Operativo
RED
Middleware
El rol principal del middleware es facilitar la
tarea de diseñar, programar, y administrar
aplicaciones distribuidas
Provee un ambiente de programación
distribuido simple, consistente e integrado

Evolución Middleware
Semantic Management of Middleware. Ramesh Jain. Amit Sheth. Springer 2006.

Message Oriented Middleware
Los MOMs proveen comunicación
asincrónica a través de mensajes, utilizando
colas de mensajes para su almacenamiento
temporal
G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and

Deploying Messaging Solutions. Addison-Wesley Professional, October 2003.
Message Oriented Middleware
El principal objetivo de un MOM es
transportar mensajes desde el equipo
remitente al equipo receptor de una manera
confiable
Algunos Patrones de Mensajería
o Point to point
o Request – Response
o Request – Callback
o Publish - Subscribe

Application Servers
Los servidores de aplicaciones proveen
mecanismos para manejar toda o la mayoría
de las interacciones entre los componentes
de una aplicación distribuida
Proveen varias tecnologías de middleware
(MOMs, etc) junto con el concepto de
contenedor, que brinda un entorno de
ejecución para los componentes de una
aplicación

Application Servers
En general se puede encontrar soporte para
seguridad, transacciones, administración de
aplicaciones y recursos, y balanceo de carga
Proveen una solución completa para la
construcción e integración de aplicaciones
empresariales

Web Services
Un Web Service es una aplicación de
software identificada por una URI, cuyas
interfaces y formas de acceso pueden ser
definidas, descriptas y descubiertas como
artefactos XML, y soporta la interacción
directa con otros componentes de software
utilizando mensajes basados en XML,
intercambiados a través de protocolos
basados en internet
http://www.w3.org/TR/ws-desc-reqs/#definitions

Primera Generación de WS
Universal Description,
Discovery and Integration Web Services
(UDDI) Description Language
(WSDL)
Publish
Find
WSDL
FTP, SMTP, etc.
HTTP
Simple Object
SOAP
Access Protocol
(SOAP)
SOAP
Provee una forma estándar de estructurar
mensajes utilizando XML
Define mecanismos para utilizar distintos
protocolos de transporte para el envío de
mensajes
Especifica un modelo de procesamiento que
indica cómo se deben procesar los mensajes

Mensaje SOAP
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault> ... </soap:Fault>
</soap:Body>
</soap:Envelope>

WSDL
Lenguaje basado en XML que permite
describir la interfaz y otras características de
un Web Service
Un documento WSDL puede dividirse en dos
partes:
o descripción abstracta
o descripción concreta

WSDL – Descripción Abstracta
La descripción abstracta describe de forma
general la estructura de la interfaz del Web
Service, que incluye operaciones, parámetros y
tipos de datos abstractos
Los cuatro elementos XML que componen la
descripción abstracta son:
<wsdl:types>
<wsdl:message>
<wsdl:portType>
<wsdl:operation>

WSDL – Descripción Concreta
La descripción concreta asocia a una
descripción abstracta una dirección de red
concreta, un protocolo de comunicación y
estructuras de datos concretas
Los tres elementos XML que componen la
descripción concreta son:
<wsdl:binding>
<wsdl:service>
<wsdl:port>

UDDI
Especificación que provee una forma
estándar de publicar y descubrir Web
Services
UDDI define
o un modelo de datos para almacenar información
de servicios y negocios
o interfaces para utilizar el registro UDDI
 Inquiry
 Publish

UDDI – Modelo de Datos
Developing Java Web Services. Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh. Wiley Publishing. 2003.
Segunda Generación de WS
Surgen como forma de abordar
problemáticas comunes en contextos
empresariales
Se les conoce como WS-*
Cada una aborda una problemática
específica:
o Seguridad, Transacciones, Mensajería, etc

Estándares Avanzados de WS
http://www.innoq.com/soa/ws-standards/poster/

WS-BPEL
Web Services Business Process Execution
Language es un lenguaje para “orquestar”
Web Services
WS-BPEL es un lenguaje de flujo basado en
XML para la especificación formal de
procesos de negocio y protocolos de
interacción de negocio

WS-BPEL

Mensajería – WS-Addressing
WS-Addressing (WS-A) provee un
mecanismo estándar para direccionar
mensajes y Web Services
Define dos construcciones básicas
o endpoint reference
 Address, Reference Parameters, Metadata
o addressing properties
 To, From, ReplyTo, FaultTo,
 Action, MessageID, RelatesTo
 ReferenceParameters

Metadata – WS-Policy
Define un modelo abstracto, independiente
del dominio, que permite describir
características, requerimientos y
capacidades de un Web Service
Delega a otras especificaciones la definición
de políticas particulares a un dominio.
o WS-SecurityPolicy
o WS-ReliableMessagingPolicy

Transacciones en WS
Transacción Atómica: WS-AtomicTransaction
o Propiedades ACID
o Corta Duración
o Ambiente seguro
o Diseñado principalmente para dar soporte a la
interoperabilidad
Actividad de Negocio: WS-BusinessActivity
o Larga Duración
o Se define un mecanismo de compensación

Seguridad en WS
Alternativas
o Seguridad a nivel de trasporte
o A través de HTTPS
o Tecnología madura y existencia de expertos
o Seguridad a nivel de mensaje SOAP
o WS-Security

WS-Security
Define un conjunto de extensiones SOAP
para brindar seguridad a nivel de mensaje
 Se especifica cómo:
o utilizar XML Signature en mensajes SOAP
o utilizar XML Encryption en mensajes SOAP
o incluir Tokens de Seguridad en mensajes SOAP

Especificaciones de WS
Actualmente la tecnología de Web Services
está basada en un gran número de
especificaciones que:
o en general, son propuestas por la industria
 Microsoft, IBM, Oracle, etc.
o son estandarizadas por distintas organizaciones
 W3C, OASIS, etc.
o son implementadas por distintos proveedores
 Apache, JBoss, Sun, Microsoft, IBM, Oracle, etc.

WS-Trust
Microsoft Corporation. Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services
Enhancements (WSE) 3.0. 2005. http://msdn.microsoft.com/en-us/library/aa480545.aspx
Web Services REST
REST (REpresentational State Transfer)
o Estilo arquitectónico para sistemas de hipermedia
distribuidos
o Todo es tratado como recursos que se identifican
por URIs
o Toma ventaja de los verbos HTTP
 GET, POST, PUT, DELETE

Web Services REST
La intención de una llamada a un RESTful
Service, se obtiene del verbo HTTP
o GET (recuperar), DELETE (eliminar)…
Verbo HTTP Significado en términos de CRUD (Create, Read, Update, Delete)
POST Crear un nuevo recurso a partir de los datos de la solicitud.
GET Leer un recurso.
PUT Actualizar un recurso a partir de los datos de la solicitud.
DELETE Eliminar un recurso.
Java Web Services: Up and Running, 1st Edition. Martin Kalin. O'Reilly. 2009
Web Services REST
De este modo las URIs actúan como
identificadores de recursos y los métodos
HTTP como verbos que especifican
operaciones sobre los mismos
Verbo HTTP / URI Significado en términos de CRUD
POST emps Crear un nuevo empleado a partir de los datos de la solicitud.
GET emps Leer una lista de todos los empleados.
GET emps?id=27 Leer el empleado 27.
PUT emps Actualizar la lista de empleados con los datos de la solicitud.
DELETE emps Eliminar la lista de empleados.
DELETE emps?id=27 Eliminar el empleado 27.
Java Web Services: Up and Running, 1st Edition. Martin Kalin. O'Reilly. 2009
Web Services REST

SOA y ESB
Orientación a Servicios
Computación Orientada a Servicios
o paradigma que basa el diseño de aplicaciones en
servicios para dar soporte al desarrollo ágil y
flexible de aplicaciones distribuidas en ambientes
heterogéneos
Un Servicio es una entidad de cómputo que
expone una funcionalidad de negocio y es:
o autónoma
o independiente de la plataforma
o puede ser descrita, publicada, descubierta y
combinada
Orientación a Servicios
Principios
o Standardized Service Contracts
o Service Loose Coupling
o Service Abstraction
o Service Reusability
o Service Autonomy
o Service Statelessness
o Service Discoverability
o Service Composability
http://www.soaprinciples.com/
Arquitectura Orientada a Servicios
Arquitectura Orientada a Servicios

o forma lógica de diseñar sistemas de software
para proveer servicios a través de interfaces
públicas y descubribles

Service Oriented Architecture
M. Papazoglou, Web Services: Principles and Technology, 1st ed. Prentice Hall,
September 2007.
Service Oriented Architecture
Si bien los principios de SOA no dependen
de una tecnología en particular, los Web
Services se han convertido en el mecanismo
preferido para su implementación
Actualmente, la forma más común de proveer
una infraestructura de integración
administrable, para Web Services y SOA, es
a través de un ESB

Capa de Servicios

Enterprise Service Bus (ESB)
Un ESB es una plataforma de integración
basada en estándares que combina
mensajería, Web Services, transformación de
datos, y ruteo inteligente, para conectar y
coordinar de forma confiable la interacción de
un gran número de aplicaciones a través de
empresas con integridad transaccional

79
En lugar de interactuar directamente las
aplicaciones se comunican enviando
mensajes a través del ESB
Los mensajes que fluyen a través del ESB
son en general mensajes XML
80
3
2

Funcionalidades de ESB
Conectividad / Adaptadores
Transformación de Mensajes
Ruteo Intermediario
Flujos de Mediación
Mensajería Asincrónica
Monitoreo y Administración
Otras…

Conectividad y Adaptadores
Permiten satisfacer un requerimiento de
integración común conocido como conversión
de protocolo (protocol switch).
Este requerimiento se da cuando dos
aplicaciones que necesitan integrarse no
manejan un protocolo de comunicación común.
INCO - Facultad de Ingeniería – Montevideo, Uruguay (Rademakers and Dirksen 2008)

83
83
Transformación de Mensajes
Los ESBs también incluyen capacidades de
transformación de mensajes.
Estas capacidades posibilitan, por ejemplo,
que aplicaciones que utilizan distintos
formatos o modelos de datos puedan
comunicarse.
(Rademakers and Dirksen 2008)

84
Ruteo Inteligente
El ruteo inteligente permite determinar
dinámicamente el destino de un mensaje
(seleccionando de varios destinos posibles)
RUTEO
Basado en contenido, contexto, balanceo de

carga, etc
85
Monitoreo y Administración
Los ESB incluyen funcionalidades de
monitoreo que proveen valores para distintas
métricas
o tiempos de respuesta,
o cantidad de mensajes procesados por servicio,
o errores en la invocación de servicios, etc
Esto permite detectar:
o cuellos de botella,
o incumplimiento de requerimientos de calidad de
servicio, etc
86
Arquitectura y Tecnologías GIS

Arquitectura y Tecnologías GIS
En las últimas décadas el Software GIS ha
pasado de ser un software “standalone” de
escritorio, a tener la típica arquitectura en
capas de las aplicaciones empresariales

GeoDBMS
 Un GeoDBMS da soporte al almacenamiento
y consulta de objetos geográficos.
 El enfoque común es extender un DBMS con
elementos geográficos:
o Tipos
o Funciones
o Metadatos
SELECT r.nombre, ST_LENGTH(r.geom) AS longitud

FROM Calles r WHERE r.codigo=223;
GeoDBMS
 Las extensiones geográficas a un DBMS deben
cumplir con el estándar Open Geospatial
Consortium (OGC) conocido como:
o Simple Features Standard, SQL Option
 Algunas extensiones SFS son:
o Oracle Spatial
o PostGIS
o MySQL Spatial Extensions
o ESRI ArcSDE

Map Server
 Un Servidor de Mapas es un componente de
SW que generalmente se ejecuta sobre un
Servidor Web o Servidor de Aplicaciones
 Su objetivo principal es proveer a clientes de
Internet mapas generados
dinámicamente (a partir de
datos vectoriales o raster)

Map Server
 La tendencia actual es que los servidores de
mapas implementen estándares de Web Services
geográficos (de la OGC):
o Web Map Service (WMS)
• proveen mapas sólo lectura
o Web Feature Service (WFS)
• acceso y manipulación de objetos
geográficos (protocolos basados
en XML)

Map Viewer
 Un Map Viewer es una aplicación cliente que
despliega un mapa en una interfaz de usuario
o en general son aplicaciones Web-based que
obtienen mapas desde Map Servers (ej. via WMS)
 Ejemplos
o Google Maps
o OpenLayers

Map Editor
 Un Map Editor permite además crear mapas,
modificar objetos, realizar geo-procesamiento
avanzado
 Son generalmente aplicaciones desktop pero
hay alternativas Web-based
 Se pueden comunicar con
Map Servers (vía WMS o WFS)
o con geo-databases (vía SQL)
 Ejemplos: gvSIG, QGIS

Alternativas de Integración
Escenarios de Integración
GIS Aplicación Empresarial

Alternativas de Integración
 Integración a nivel de Base de Datos
 Integración a nivel de Servicios
 Integración a nivel de Interfaz de Usuario

Integración a nivel de BD

 Utilizar un database-link
o Es posible vía las capacidades de algunos DBMS
o productos de terceros (ej. dblink)
o Este mecanismo permite acceder a una BD
externa a través de vistas
 Utilizar mecanismos de ETL
o Se deben implementar mecanismos para extraer
información del a BD empresarial y
almacenarla en la geo-DB
o Definir periodicidad de carga

 ¿database-link vs ETL?
 ¿es siempre posible este enfoque?

Integración a nivel de Servicios
 Los servicios geográficos tienen interfaces
bien conocidas, por lo que invocarlos desde
aplicaciones empresariales no presenta
mayores desafíos

 El principal desafío es proveer datos
provenientes de aplicaciones de negocio a
través de interfaces geográficas
 La problemática se da porque:
o Muchos clientes (ej. Map Viewers) están
diseñados para consumir sólo WS Geográficos
o Los Map Servers proveen poco soporte para
consumir servicios externos (ej. WS SOAP)
 ¿Qué alternativas hay?

 Un posible enfoque es desarrollar un
componente que consuma ambos servicios,
integre los datos y los provea a través de una
interfaz geográfica
 La obtención de datos y
la integración es
trasparente tanto para el
cliente como para el
Map Server

 Una alternativa para implementar el
componente de integración es aprovechar los
mecanismos que brindan los ESBs

 Otra posible problemática de integración es
cómo utilizar un WS Geográfico en un
proceso WS-BPEL
 Habría que brindar una interfaz SOAP para el
WS Geográfico
o Para esto existe una recomendación del OGC
 Se podría también utilizar los mecanismos de
los ESBs para implementar esta conversión

Integración a nivel de UI
 Las organización están notando los
beneficios de agregar mapas a sus
aplicaciones existentes
 Una posible alternativa es agregar un Map
Viewer a la UI de las aplicaciones
empresariales

Escenarios de Integración

 Dada la heterogeneidad tecnológica, muchas
veces la mejor opción es utilizar un viewer
basado en javascript (ej. OpenLayers)
 Si una organización no tiene su propio
dataset geográfico, podría utilizar mapas de
propósito general (ej, google maps)

 Otro posible escenario es enriquecer los
datos brindado por un Map Viewer con datos
de Negocio
 En este caso, se puede utilizar la integración
a nivel de servicios descripta previamente
 Si esto no es posible, la integración se debe
hacer a nivel del cliente
o Qué problemáticas presenta esta solución?

Tecnologías GIS Empresariales
 Varias tecnologías empresariales están
siendo extendidas para tener soporte
geográfico
 Algunos Ejemplos:
o Soporte en BD (postgis, etc)
o Hibernate Spatial
o GeoMajas
o GeoFaces

Referencias
 G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing,
Building, and Deploying Messaging Solutions. Addison-Wesley
Professional, October 2003.
 J. McGovern, O. Sims, A. Jain, and M. Little, Enterprise Service
Oriented Architectures: Concepts, Challenges, Recommendations
 D. Chappell, Enterprise Service Bus. O'Reilly Media, Inc., July 2004.
 M. Papazoglou, Web Services: Principles and Technology, 1st ed.
Prentice Hall, September 2007.
 G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services, 1st
ed. Springer, October 2003.
 M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann.
"Service-oriented computing: State of the art and research
challenges", Computer, vol. 40, no. 11, pp. 38-45, 2007.
 The SOA Source Book
 http://www.opengroup.org/soa/source-book/intro/
Referencias
 Rienzi, B., Sosa, R., Foti, P., González, L.: Benefits and challenges
of using geographic information systems to enhance social security
services. (2010).
 Bruno Riezi, Laura González: Towards an ESB-Based Enterprise
Integration Platform for Geospatial Web Services. (2013).

TSIGE 2017 AplicacionesEmpresariales Extendido

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TSIGE 2017 AplicacionesEmpresariales Extendido

Caricato da

Copyright:

Formati disponibili

Taller de Sistemas de

Aplicaciones Empresariales y GIS

INCO - Facultad de Ingeniería – Montevideo, Uruguay 2

INCO - Facultad de Ingeniería – Montevideo, Uruguay 3

INCO - Facultad de Ingeniería – Montevideo, Uruguay 5

INCO - Facultad de Ingeniería – Montevideo, Uruguay 6

INCO - Facultad de Ingeniería – Montevideo, Uruguay 7

INCO - Facultad de Ingeniería – Montevideo, Uruguay 9

Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0

INCO - Facultad de Ingeniería – Montevideo, Uruguay 11

INCO - Facultad de Ingeniería – Montevideo, Uruguay 12

Capa de acceso a datos

INCO - Facultad de Ingeniería – Montevideo, Uruguay 13

Las capas antes presentadas pueden estar

INCO - Facultad de Ingeniería – Montevideo, Uruguay 14

Este enfoque minimiza el número de

INCO - Facultad de Ingeniería – Montevideo, Uruguay 15

Este enfoque permite configurar el hardware

INCO - Facultad de Ingeniería – Montevideo, Uruguay 16

INCO - Facultad de Ingeniería – Montevideo, Uruguay 17

Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0

Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0

Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0

INCO - Facultad de Ingeniería – Montevideo, Uruguay 21

INCO - Facultad de Ingeniería – Montevideo, Uruguay 22

INCO - Facultad de Ingeniería – Montevideo, Uruguay 23

Las mismas brindan soluciones a varios de

Permiten que el desarrollador se concentre

INCO - Facultad de Ingeniería – Montevideo, Uruguay 24

INCO - Facultad de Ingeniería – Montevideo, Uruguay 25

INCO - Facultad de Ingeniería – Montevideo, Uruguay 26

INCO - Facultad de Ingeniería – Montevideo, Uruguay 27

INCO - Facultad de Ingeniería – Montevideo, Uruguay 28

INCO - Facultad de Ingeniería – Montevideo, Uruguay 29

1. ASP.NET / ASP.NET MVC

12. Entity Framework / NHibernate

INCO - Facultad de Ingeniería – Montevideo, Uruguay 30

INCO - Facultad de Ingeniería – Montevideo, Uruguay 31

INCO - Facultad de Ingeniería – Montevideo, Uruguay 32

INCO - Facultad de Ingeniería – Montevideo, Uruguay 33

INCO - Facultad de Ingeniería – Montevideo, Uruguay 34

INCO - Facultad de Ingeniería – Montevideo, Uruguay 35

INCO - Facultad de Ingeniería – Montevideo, Uruguay 36

INCO - Facultad de Ingeniería – Montevideo, Uruguay 37

INCO - Facultad de Ingeniería – Montevideo, Uruguay 38

Aplicación Distribuida Aplicación Distribuida

INCO - Facultad de Ingeniería – Montevideo, Uruguay 41

Semantic Management of Middleware. Ramesh Jain. Amit Sheth. Springer 2006.

G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and

INCO - Facultad de Ingeniería – Montevideo, Uruguay 44

INCO - Facultad de Ingeniería – Montevideo, Uruguay 45

INCO - Facultad de Ingeniería – Montevideo, Uruguay 46

INCO - Facultad de Ingeniería – Montevideo, Uruguay 47

FTP, SMTP, etc.

INCO - Facultad de Ingeniería – Montevideo, Uruguay 49

INCO - Facultad de Ingeniería – Montevideo, Uruguay 50

INCO - Facultad de Ingeniería – Montevideo, Uruguay 51

INCO - Facultad de Ingeniería – Montevideo, Uruguay 52

INCO - Facultad de Ingeniería – Montevideo, Uruguay 53

INCO - Facultad de Ingeniería – Montevideo, Uruguay 54

INCO - Facultad de Ingeniería – Montevideo, Uruguay 56

INCO - Facultad de Ingeniería – Montevideo, Uruguay 57

INCO - Facultad de Ingeniería – Montevideo, Uruguay 58

INCO - Facultad de Ingeniería – Montevideo, Uruguay 59