scieee Science in your language
[es] (orig)

Inclusión de un repositorio de datos fijos en un sistema de tesorería bancaria

Abstract

La Tesorería de una entidad bancaria se enmarca dentro del negocio de banca de inversión (también denominada banca mayorista o corporativa) así como otros negocios tales como el de fusiones y adquisiciones, financiación de proyectos, préstamos sindicados o banca transaccional global. Pero, sin duda alguna, la Tesorería, o simplemente área de mercados, es una pieza fundamental dentro de la estructura de la banca de inversión de un banco. La Tesorería de una Entidad está en constante comunicación con todos los departamentos, tanto internos como externos. Es por ello que todo el mundo financiero se mueve en torno a las acciones y decisiones que se llevan a cabo en la Tesorería. El área de la tesorería bancaria maneja, a su vez, grandes cantidades de datos para poder gestionar las operaciones, la contratación de productos y las confirmaciones y liquidaciones. Actualmente, en la mayoría de entidades financieras, los datos están siendo gestionados por distintos aplicativos. Cada uno de estos aplicativos está desarrollado en distintos lenguajes de programación como COBOL, C++, Java... Esto supone costes y pérdidas de tiempo para las entidades a la hora de implementar intercambios de información entre las aplicaciones. El trabajo de fin de grado se centra en la definición de una arquitectura de aplicativo capaz de gestionar los datos fijos utilizados dentro de la tesorería bancaria e integrarlo dentro de una arquitectura orientada a servicios (SOA). Estos datos están en constante crecimiento en función de las necesidades de los consumidores. Se implementará un aplicativo de ejemplo para validar la arquitectura propuesta, que sea capaz de manejar las entidades de datos más importantes a gestionar dentro de la tesorería, como son: • Contrapartidas, que comprenden: • Atributos generales • Contratos • Diccionarios • Contactos • Confirmaciones • Datos regulatorios • Instrucciones de liquidación • Estructura interna, que comprende: • Portfolios • Grupos • Oficinas • Convenios de mercado, que comprende: • Índices • Divisas • Calendarios • Unidades Geográficas

Read accessible full text

Inclusión de un repositorio de datos fijos en un sistema de tesorería bancaria

Author: López-Laguna Ortiz, Óscar
Year: 2017
Source: https://docta.ucm.es/bitstreams/d6e131db-0f61-4799-b4b7-9b0f598ad474/download
Uni e sidad Complu ense de Mad id
Facul ad de In o má ica
Inclusión de un eposi o io de da os ijos en un sis ema de
eso e ía banca ia
Alumno: Ósca López-Laguna O iz
Di ec o es de p oyec o: José Luis Risco Ma ín
Josué Pagán O iz
T abajo de Fin de G ado
G ado en Ingenie ía del So wa e
Sep iemb e de 2017
2
Índice gene al
Palab as cla e 5
Resumen 7
1. In oducción 11
1.1. Mo i ación ..................................... 11
1.2. Obje i os ...................................... 12
2. Visión Gene al 15
2.1. PHP......................................... 15
2.2. MySQL ....................................... 16
2.3. XAMPP....................................... 17
2.4. SOA (Se ice O ien ed A chi ec u e) . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1. Bene icios.................................. 19
2.4.2. Se iciosWeb ............................... 20
2.4.3. ESB (En e p ise Se ice Bus) . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.4. WSO2.................................... 25
2.5. SoapUI ....................................... 26
3
4ÍNDICE GENERAL
3. Plan de abajo 27
3.1. AplicaciónWeb................................... 27
3.2. Basededa os .................................... 29
3.3. Se icioWeb .................................... 30
3.4. SOA......................................... 31
4. Solución 33
4.1. P o o ipo Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. P o o ipoBasedeDa os............................... 43
4.3. P o o ipoSe icioWeb............................... 46
4.4. Inco po ación p o o ipo a SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Conclusiones 51
Bibliog a ía 55
Ag adecimien os 57
Au o ización de di usión 59
Palab as cla e
Palab as cla e en Español
Teso e ía banca ia
Da os ijos
SOA
SOAP
Se icio Web
WSO2
Keywo ds in English
Bank’s easu y
Fixed da a
SOA
SOAP
Web se ice
WSO2
5

6Palab as cla e
Resumen
Resumen en Español
La Teso e ía de una en idad banca ia se enma ca den o del negocio de banca de in e sión
( ambién denominada banca mayo is a o co po a i a) así como o os negocios ales como el de
usiones y adquisiciones, inanciación de p oyec os, p és amos sindicados o banca ansaccional
global. Pe o, sin duda alguna, la Teso e ía, o simplemen e á ea de me cados, es una pieza unda-
men al den o de la es uc u a de la banca de in e sión de un banco.
La Teso e ía de una En idad es á en cons an e comunicación con odos los depa amen os,
an o in e nos como ex e nos. Es po ello que odo el mundo inancie o se mue e en o no a las
acciones y decisiones que se lle an a cabo en la Teso e ía. El á ea de la eso e ía banca ia maneja,
a su ez, g andes can idades de da os pa a pode ges iona las ope aciones, la con a ación de
p oduc os y las con i maciones y liquidaciones.
Ac ualmen e, en la mayo ía de en idades inancie as, los da os es án siendo ges ionados po
dis in os aplica i os. Cada uno de es os aplica i os es á desa ollado en dis in os lenguajes de p o-
g amación como COBOL, C++, Ja a... Es o supone cos es y pé didas de iempo pa a las en idades
a la ho a de implemen a in e cambios de in o mación en e las aplicaciones.
El abajo de in de g ado se cen a en la de inición de una a qui ec u a de aplica i o capaz
de ges iona los da os ijos u ilizados den o de la eso e ía banca ia e in eg a lo den o de una
a qui ec u a o ien ada a se icios (SOA). Es os da os es án en cons an e c ecimien o en unción de
las necesidades de los consumido es.
7
8Resumen
Se implemen a á un aplica i o de ejemplo pa a alida la a qui ec u a p opues a, que sea capaz
de maneja las en idades de da os más impo an es a ges iona den o de la eso e ía, como son:
Con apa idas, que comp enden:
•A ibu os gene ales
•Con a os
•Dicciona ios
•Con ac os
•Con i maciones
•Da os egula o ios
•Ins ucciones de liquidación
Es uc u a in e na, que comp ende:
•Po olios
•G upos
•O icinas
Con enios de me cado, que comp ende:
•Índices
•Di isas
•Calenda ios
•Unidades Geog á icas
Summa y in English
The Bank’s easu y is amed unde he in es men banking business, aka wholesale ban-
king o global co po a e banking, so do o he a eas as me ge s and acquisi ions, p ojec unding,
syndica ed loans o global ansac ional banking. Howe e , i is p e y clea ha he T easu y De-
pa men , o he Ma ke s a ea, plays a key ole wi hin he o ganiza ion o he in es men banking
business o any bank en i y.
Resumen 9
The T easu y depa men is in close and cons an communica ion wi h he es o depa men s,
bo h in e nally and ex e nally. The e o e, all he decisions and ac ions aken by he Bank’s easu y
ha e a di ec impac on he inancial wo ld. Besides, he T easu y depa men handles a g ea
amoun o da a in o de o manage ope a ions, con i ma ions, paymen s and he p ocu emen o
p oduc s.
Nowadays, mos o he bank en i ies manage hei ixed da a h ough se e al applica ions,
each o hem using di e en p og amming languages: COBOL, C++, Ja a... This di ec ly causes
losses in money and ime whene e he en i ies implemen an exchange o in o ma ion be ween
applica ions.
This inal deg ee p ojec ocuses on he design o an applica ion a chi ec u e able o manage
all he ixed da a needed by he Bank’s easu y and on i s in eg a ion in o a se ice o ien ed
a chi ec u e (SOA). The men ioned da a g ows cons an ly gea ed owa ds he consume s’ needs.
In o de o alida e he p oposed SOA, an applica ion will be c ea ed showing how i is able o
manage he mos impo an ixed da a used by he Bank’s easu y:
Coun e pa ies, comp ising:
•Gene al a ibu es
•Ag eemen s
•Dic iona y
•Con ac s
•Con i ma ions
•Regula o y da a
•Se lemen ins uc ions
In e nal s uc u e, comp ising:
•Po olios
•G oups
•O ices
16 CAPÍTULO 2. VISIÓN GENERAL
Además de es os mo i os, ambién se ha decidido u iliza PHP debido a las siguien es ca ac-
e ís icas de las que dispone:
Es e lenguaje de p og amación, pe mi e ealiza aplicaciones web dinámicas con ácil acce-
so a in o mación almacenada en bases de da os.
Tiene una g an conec i idad con el sis ema de ges ión de bases de da os MySQL.
Se puede expandi su po encial incluyendo módulos.
Es lib e, po lo que se puede usa sin cos e alguno.
Aunque uno de sus incon enien es es que al se un lenguaje in e p e ado, es ela i amen e más
len o que lenguajes de bajo ni el. Debido a que la aplicación a ealiza es un eposi o io de da os,
no se p e é a u u o que aya a eque i sc ip s complejos que puedan alen iza la aplicación, po
lo que es e no se ía un g an incon enien e.
2.2. MySQL
Den o de la g an a iedad de ges o es de bases de da os exis en es, ales como O acle, JDBC,
MongoDB, MySQL..., de los que se podía elegi pa a ealiza el p oyec o, se ha decido usa
MySQL.
Figu a 2.2: Logo MySQL.
MySQL es Open Sou ce, po lo cual cumple con los obje i os p opues os pa a la ealización
del p oyec o. Además iene muy buena compa ibilidad con el lenguaje de p og amación elegido
pa a ealiza la aplicación, PHP.

2.3. XAMPP 17
Alguna de sus o as ca ac e ís icas impo an es po las que se ha elegido son:
Sopo a una g an can idad de da os, po lo que es pe ec a pa a almacena odos los da os
ijos que puede ene una en idad banca ia.
Funciona en múl iples pla a o mas, acili ando su in eg ación en los sis emas de las en ida-
des inancie as.
O ece g an segu idad, po lo que puede almacena los da os sensibles de los que puede
dispone una en idad banca ia, ales como da os iscales o cuen as.
Una de las azones más impo an es pa a su elección, es que es uno de los ges o es de bases de
da os más ex endidos y iene un amplio subconjun o del lenguaje SQL. Es o acili a á su expansión
en caso de se necesa io y educi á cos es al con a p obablemen e con gen e con conocimien os
pa a ges iona la.
2.3. XAMPP
Se ha u ilizado pa a la ealización del p oyec o el paque e XAMPP. Es e paque e es el que se
ha u ilizado pa a lanza la aplicación web po se de so wa e lib e y con ene odo lo necesa io
pa a ello.
Figu a 2.3: Logo XAMPP.
El paque e XAMPP con iene:
El se ido web Apache: Se ido de HTTP de código abie o mul ipla a o ma.
In é p e e de lenguaje PHP. Se ha explicado el mo i o de su elección en la Sección 2.1.
18 CAPÍTULO 2. VISIÓN GENERAL
El ges o de base de da os MYSQL. Se ha explicado el mo i o de su elección en la Sección
2.2.
2.4. SOA (Se ice O ien ed A chi ec u e)
Pa a es e p oyec o es necesa io ealiza el eposi o io de da os ijos de al mane a que se pueda
inco po a den o de una a qui ec u a o ien ada a se icios (SOA). Es o es debido a que a día de
hoy, las g andes emp esas, en las que es án incluidas las en idades banca ias, u ilizan es a a qui-
ec u a pa a la comunicación en e sus aplica i os. Pa a en ende un poco mejo es a a qui ec u a
y el po qué las g andes emp esas es án usándola, en es e apa ado se a a explica en qué consis e
y sus p incipales ca ac e ís icas.
La a qui ec u a SOA, como su p opio nomb e indica, es un es ilo de a qui ec u a que es á
basada en la o ien ación a se icios. La o ien ación a se icios implica una o ma de pensa sob e
cómo implan a los se icios de un negocio pa a que puedan comunica se de o ma luida unos
con o os. Un se icio es una ac i idad ealizada den o de un negocio; en el caso que nos compe e
de las en idades inancie as, un ejemplo de se icio puede se la ealización de ans e encias.
El obje i o p incipal de la a qui ec u a SOA es hace que cada aplica i o den o de una emp esa
sea capaz de p esen a los se icios que o ece de una mane a adecuada, que pe mi a usa sus
capacidades de o ma homogénea.
En una a qui ec u a SOA cada sis ema debe b inda se icios a desconocidos, po lo que debe
cen a se en las capacidades que o ece y no en quién a a ecibi las. De es a o ma se pueden
c ea unciones que sean u ilizables po dis in os clien es, únicamen e conociendo la desc ipción
del se icio pa a pode u iliza lo.
2.4. SOA (SERVICE ORIENTED ARCHITECTURE) 19
Po es os mo i os, las a qui ec u as SOA es án o madas po se icios de aplicaciones dé-
bilmen e acoplados y al amen e in e ope ables. Es os se icios que o ecen sus uncionalidades,
pe enecien es a una emp esa, suelen se se icios web (Sección 2.4.2), los cuales se conec an
unos con o os gene almen e a a és de un bus de da os, denominado ESB (Sección 2.4.3), po el
cual lui á la in o mación en e ellos.
2.4.1. Bene icios
Exis en una se ie de bene icios po los cuales las emp esas es án adop ando es a a qui ec u a;
en la Figu a 2.4 se pueden ap ecia los 5 p incipales:
Figu a 2.4: P incipales bene icios al u iliza a qui ec u a SOA.
Reu ilización: g acias a la a qui ec u a SOA es posible ealiza nue os p ocesos de nego-
cio eu ilizando uncionalidades de aplica i os ya exis en es que han sido expues os como
se icios web. De es a o ma se consigue gana iempo y educi cos es an e nue os eque-
imien os de negocio, dado que eesc ibi una aplicación o pa e de ella no se ía la mejo
opción a segui .
20 CAPÍTULO 2. VISIÓN GENERAL
In e ope abilidad: en la a qui ec u a SOA se u ilizan p o ocolos es ánda es que pe mi en
que se icios y clien es se pongan de acue do sob e la mane a en la que comunica se, e-
niendo de es a o ma un mecanismo de comunicación que elimina las limi aciones que se
puedan gene a al in en a comunica se en e di e en es pla a o mas o di e en es lenguajes
de p og amación u ilizados en los aplica i os.
Escalabilidad: en gene al, una a qui ec u a es más escalable si añadi una nue a unidad de
capacidad iene meno cos e que en o as.
Den o de la a qui ec u a SOA, una nue a unidad de capacidad se ía equi alen e a ag ega
un nue o se icio web den o de un sis ema, con un nue o p oceso de negocio, pa a que
in e ac úe con o os se icios.
Dado que los se icios web no ienen es ado, es deci que no necesi an almacena la in-
o mación de la sesión cada ez que se les in oca, la complejidad que da ag ega nue os
se icios web es bas an e baja.
Flexibilidad: dado que en la a qui ec u a SOA los dis in os aplica i os que o man pa e de
ella es án cen ados en los se icios que o ece, aunque alguno de es os aplica i os se mo-
di ique, no es necesa io ealiza ningún cambio en los demás aplica i os que se comunican
con él, ya que no se modi ica á la o ma en la que es os se comunican en e ellos.
E iciencia en cos e: como en la a qui ec u a SOA se eu ilizan las uncionalidades de o os
aplica i os ya exis en es, es o educe de mane a muy signi ica i a los cos es de acome e
nue os p oyec os den o de las emp esas, ya que educe la in e sión en in aes uc u a y
educe la necesidad de adqui i nue o so wa e especializado.
2.4.2. Se icios Web
Un se icio web po sí mismo no iene po qué pe enece a una a qui ec u a SOA. Pa a que
un se icio web se pueda conside a que o ma pa e de una a qui ec u a SOA debe se capaz de
cumpli con los bene icios expues os an e io men e en la Sección 2.4.1.
2.4. SOA (SERVICE ORIENTED ARCHITECTURE) 21
Los se icios web, son se icios que se comunican en e aplicaciones u ilizando un conjun-
o de p o ocolos y es ánda es. Dis in as aplicaciones so wa e c eadas en dis in os lenguajes de
p og amación y ejecu adas sob e cualquie pla a o ma, pueden u iliza los se icios web pa a in-
e cambia da os en edes de o denado es como in e ne .
La comunicación se ca ac e iza po el in e cambio de mensajes XML y po se independien es
del p o ocolo de comunicación. Pa a log a es a independencia, el mensaje se en uel e de mane a
ap opiada pa a cada p o ocolo g acias al p o ocolo de anspo e SOAP (Sección 2.4.2).
El lenguaje de Desc ipción de los Se icios Web (WSDL) (Sección 2.4.2), exp esado en XML,
desc ibe cómo accede al se icio, de qué unciones dispone, qué a gumen os necesi a y qué de-
uel e cada uno.
WSDL (Web Se ices Desc ip ion Language)
WSDL es un o ma o del XML que desc ibe la in e az pública de los se icios web. En él
se desc ibe cuáles son los equisi os del p o ocolo y cómo in e ac ua con los se icios de los
que dispone el se icio web. Las ope aciones y los mensajes que sopo a se desc iben de mane a
abs ac a y se ligan después al p o ocolo conc e o de ed y al o ma o del mensaje.
WSDL es como un con a o en e el p o eedo del se icio y el clien e, en el que el p o eedo
del se icio indica:
Qué unciones se pueden llama .
Qué ipos de da os u ilizan las unciones.
Qué ipo de anspo e se usa á pa a el en ío y ecepción de los mensajes (en es e p oyec o
se usa á SOAP (Sección 2.4.2)).
Cómo accede a es os se icios.

22 CAPÍTULO 2. VISIÓN GENERAL
SOAP (Simple Objec Access P o ocol)
SOAP es un p o ocolo simple pa a el in e cambio de in o mación es uc u ada en un en o no
dis ibuido y descen alizado. Especi ica cómo dos obje os en di e en es p ocesos pueden comu-
nica se a a és del in e cambio de XML.
G acias a que SOAP usa XML iene la en aja de que las pe sonas pueden en ende lo con
acilidad, pe o a la ez es un incon enien e po que los mensajes son más la gos.
La es uc u a de un mensaje SOAP iene las siguien es pa es:
En elope (obliga o ia): aíz de la es uc u a. Es la pa e que iden i ica al mensaje SOAP
como al.
Heade : pe mi e en ia in o mación ela i a a cómo p ocesa el mensaje.
Body (obliga o ia): con iene la in o mación ela i a a la llamada y la espues a.
Faul : con iene in o mación sob e posibles e o es que se hayan podido p oduci du an e el
p oceso del mensaje y el en ío.
Figu a 2.5: Es uc u a de un mensaje SOAP.
En la Figu a 2.5 se puede e cómo queda ía es uc u ado un mensaje SOAP con las p incipales
pa es En elope, Heade y Body complemen adas.
2.4. SOA (SERVICE ORIENTED ARCHITECTURE) 23
2.4.3. ESB (En e p ise Se ice Bus)
Un ESB (en español Bus de Se icio Emp esa ial) es un modelo de a qui ec u a so wa e
que se enca ga de ges iona las comunicaciones en e dis in os aplica i os de una emp esa. Es
deci , es un pun o cen al donde se ges ionan odos los se icios expues os po las aplicaciones
de la emp esa (sin impo a en qué pla a o mas se encuen en) y sob e la cual se pueden cons ui
aplicaciones que ap o echen las uncionalidades expues as po los demás aplica i os.
Un bus de se icio emp esa ial p opo ciona una capa de abs acción que se cons uye sob e
una implemen ación de un sis ema de in e cambio de mensajes de emp esa. Es a capa de abs ac-
ción pe mi e a los expe os en in eg ación explo a el alo del en ío de los mensajes sin ene que
esc ibi código. En la Figu a 2.6 se puede e un ejemplo de cómo a ios aplica i os de una em-
p esa queda ían in e conec ados a a és del ESB (mos ado como una ube ía po la que ci cula ía
la in o mación), compa iendo de es a o ma la in o mación en e odos ellos.
Figu a 2.6: Ejemplo de un En e p ise Se ice Bus (ESB).
Un ESB no implemen a po sí mismo una a qui ec u a SOA, sino que es una he amien a
que p opo ciona las ca ac e ís icas necesa ias pa a implemen a una. El ESB a a de aisla el
acoplamien o en e el se icio solici ado y el medio de anspo e.
24 CAPÍTULO 2. VISIÓN GENERAL
Algunas de las unciones más impo an es que debe de ene un ESB son:
In ocación: que si a de sopo e pa a p o ocolos de anspo e sínc ono y asínc ono.
En u amien o: que sea capaz de en ia el mensaje al des ino co ec o basándose en no mas,
con enidos, polí icas...
Mediación: que con enga adap ado es, que sea capaz de ealiza ans o maciones de p o-
ocolos.
T ansmisión de mensajes: que p ocese los mensajes, los ans o me y los mejo e.
Co eog a ía de p ocesos: que implemen e p ocesos de emp esa complejos.
O ques ado de se icios: que coo dine múl iples se icios p esen ados como un único
se icio ag egado.
P ocesamien o de e en os complejos: que in e p e e e en os, los co elacione y empa eje
pa ones.
O os se icios de calidad: que sea segu o, con en egas con iables y que adminis e las
ansacciones.
Adminis ación: que sea capaz de moni o iza , audi a , egis a , media . Que enga una
consola de adminis ación.
Además un ESB se debe ca ac e iza p incipalmen e po :
Se capaz de in e ope a en e aplicaciones c eadas en dis in os sis emas y con dis in os
lenguajes de p og amación.
Uso gene al de XML.
Facilidad pa a la ans o mación de o ma os y alo es de da os, en e el se icio emiso y
el aplica i o ecep o .
Validación de esquemas pa a la emisión y la ecepción en los aplica i os.
2.4. SOA (SERVICE ORIENTED ARCHITECTURE) 25
Di isión y combinación de múl iples mensajes.
Encolamien o y e ención de mensajes si las aplicaciones no es án empo almen e accesi-
bles.
2.4.4. WSO2
WSO2 es una compañía dedicada al desa ollo de aplicaciones open sou ce en ocadas en p o-
ee una a qui ec u a o ien ada a se icios.
Pa a es e p oyec o se ha decidido u iliza sus se icios dado que es open sou ce, que es uno de
los más po en es del me cado y que con iene un paque e de he amien as con el que pode lle a a
cabo una a qui ec u a SOA de mane a sencilla.
WSO2 se ha ins au ado como una de las he amien as pa a el desa ollo de a qui ec u as SOA
más ex endidas; po ejemplo se ha ins au ado en es uc u as IT an complejas como Ebay, que
lle a a cabo más de 1000 millones de ansacciones dia ias.
Algunos de los p oduc os más des acados de la pla a o ma WSO2 son:
WSO2 API Manage : es una solución comple a que si e pa a ges iona los se icios de
publicación a e ce os, ga an izando la segu idad de la in o mación y educiendo los iempos
de in eg ación.
WSO2 Iden i y Se e : es un p oduc o que pe mi e ges iona los p o ocolos y c edenciales
de acceso a los ecu sos y se icios co po a i os a a és de un único pun o de ges ión.
WSO2-IS p opo ciona los p o ocolos de acceso más u ilizados en el me cado, como puede
se OAu h2.
WSO2 En e p ise Se ice Bus: es el ESB que p opo ciona WSO2. Es un p oduc o de
WSO2 que se enca ga de ges iona la o ques ación de se icios y accesos a ecu sos en los
p ocesos de negocio. WSO2-ESB acili a la in eg ación de odos los p oduc os de WSO2.
32 CAPÍTULO 3. PLAN DE TRABAJO

Capí ulo 4
Solución
En es e capí ulo se explica á la o ma en la que se ha ealizado el p oyec o eniendo en cuen a
los equisi os an e io men e mencionados en el Capí ulo 3.
4.1. P o o ipo Aplicación Web
Pa a el p o o ipo de la aplicación web se ha decidido c ea dis in os módulos en PHP de al
o ma que se cumpla con los equisi os p opues os en la Sección 3.1. El módulo p incipal que
ejecu a á el p o o ipo y que se enca ga á de edi ecciona hacia los o os módulos según las op-
ciones elegidas es el a chi o index.php (se encuen a en el ma e ial adjun o con la en ega de es a
memo ia). Quedando inalmen e el p o o ipo con las siguien es uncionalidades:
El p o o ipo iene una en ana de login, mos ada en la Figu a 4.1, en la cual los usua ios
deben me e sus da os pa a pode accede . Es a en ana es a implemen ada en el a chi o
login.php (se encuen a en el ma e ial adjun o con la en ega de es a memo ia). Como ya
se especi icó an e io men e en la Sección 3.2, el al a de usua ios se lle a á a cabo desde el
se icio écnico que queda á a ca go del aplica i o, po lo que den o de es e p o o ipo pa a
pode accede se ha gene ado el usua io admin con con aseña admin.
33
34 CAPÍTULO 4. SOLUCIÓN
Figu a 4.1: Pan alla pa a inse a usua io y con aseña pa a accede a la aplicación.
Una ez den o de la aplicación se e, como mues a la Figu a 4.2, un menú de cabece a en
el cual el usua io pod á elegi el da o ijo con el que quie e abaja ; ac ualmen e pa a es e
p o o ipo sólo es á la opción de las unidades geog á icas. Es e menú pe manece á cons an-
emen e en pan alla. También se han incluido dos opciones a iba a la de echa, una de ellas
pa a en a en la edición del pe il y o a pa a ce a la sesión. Es e menú se ha implemen ado
en el a chi o heade .php.
Figu a 4.2: Pan alla de cabece a pa a selecciona con qué da o ijo abaja .
Una ez seleccionado el ipo de da o con el que se quie e abaja , apa ece un menú, que
se llama á a pa i de aho a menú geo uni . Es e menú, mos ado en la Figu a 4.3, se ha
implemen ado en el a chi o heade GeoUni .php con las siguien es opciones:
•Búsqueda de una unidad geog á ica, con la cual pod emos localiza odas las unidades
geog á icas simila es a lo que se inse e.
•Un bo ón donde se pod á accede a una nue a pan alla pa a ealiza una nue a al a de
una unidad geog á ica.
•Un bo ón con el que se mos a á el lis ado comple o de unidades geog á icas almace-
nadas.
4.1. PROTOTIPO APLICACIÓN WEB 35
Figu a 4.3: Pan alla desde la cual ealiza búsquedas de Unidades Geog á icas o da de al a una
nue a.
Si se elige la opción de busca una unidad geog á ica desde el menú geo uni , se mos-
a á un lis ado con las unidades geog á icas que engan el iden i icado in e no simila al
que se ponga en el ecuad o de búsqueda. Se llama á a es a pan alla a pa i de aho a me-
nú consul a. Es a pan alla, mos ada en la Figu a 4.4, se ha implemen ado en el a chi o
busca GeoUni .php.
Figu a 4.4: Pan alla que mues a las unidades geog á icas encon adas; en es e caso, buscando po
ESP.
Como se puede e en la Figu a 4.4, una ez encon ada la unidad geog á ica mues a sus
alo es: nomb e de la unidad (su iden i icado in e no), desc ipción de la unidad, ipo de
unidad y es ado. El es ado se usa á pa a sabe si la unidad geog á ica es á ope a i a o ha
sido eliminada.
36 CAPÍTULO 4. SOLUCIÓN
A la de echa de la in o mación de la unidad geog á ica inse ada exis en 3 bo ones con los
cuales se pod á abaja con ella:
•El bo ón de consul a, con el cual se pod á accede a la in o mación de la unidad geo-
g á ica y a odos sus iden i icado es.
•El bo ón pa a edición, con el cual se pod á edi a la unidad geog á ica y sus iden i ica-
do es y ambién se pod á añadi nue os. Es e bo ón sólo es a á accesible si la unidad
geog á ica se encuen a ac i a.
•El bo ón de bo a , con el cual se ealiza á un bo ado lógico de la unidad geog á ica
dejándola en es ado inac i o. Es e bo ón sólo es a á accesible si la unidad geog á ica
se encuen a ac i a.
Pulsando el bo ón de consul a den o del menú consul a, se mos a án los da os de la
unidad geog á ica. Es e menú, mos ado en la Figu a 4.5, se ha implemen ado en el a chi o
consul a GeoUni .php.
Figu a 4.5: Pan alla de consul a de los da os de una unidad geog á ica.
4.1. PROTOTIPO APLICACIÓN WEB 37
Como se puede ap ecia en la Figu a 4.5, se e que la unidad geog á ica iene 2 iden i ica-
do es, uno de ellos in e no (el del aplica i o DATOS_FIJOS) y uno ex e no pe enecien e en
es e caso al aplica i o a.
Pulsando el bo ón edi a den o del menú consul a, apa ece á una pan alla con los da os de
la unidad geog á ica, en la que se pod á ealiza modi icaciones sob e la misma. Se llama á
a es a pan alla a pa i de aho a menú edición. Es a pan alla, mos ada en la Figu a 4.6, se
ha implemen ado en el a chi o geoUni .php.
Figu a 4.6: Pan alla pa a edi a los da os de una unidad geog á ica, incluyendo edición y al a de
iden i icado es.
Una ez den o del menú edición, como se puede obse a en la Figu a Figu a 4.6, si se
quie e modi ica la in o mación de la unidad geog á ica sólo se end án que ealiza los
cambios necesa ios en los ecuad os accesibles y pulsa el bo ón de edi a unidad geog á ica.

38 CAPÍTULO 4. SOLUCIÓN
En el caso de los iden i icado es, se pod á e sus in o maciones: iden i icado , aplica i o
al que pe enece y su es ado. A la de echa de la in o mación de cada iden i icado apa ecen
dos bo ones pa a edi a y elimina , menos en el caso del iden i icado in e no, el cual pa a
modi ica lo hab ía que modi ica el nomb e de la unidad geog á ica y pa a elimina lo, hab ía
que elimina la unidad geog á ica.
Debajo del lis ado de iden i icado es hay un bo ón con el cual se pueden da de al a nue os
iden i icado es.
Accediendo a la edición de un iden i icado desde el menú edición, apa ece á un menú
con el cual se pod á modi ica los da os del mismo. Es e menú, mos ado en la Figu a 4.7,
se ha implemen ado en el a chi o geoUni Id.php.
Figu a 4.7: Pan alla de edición del iden i icado de una unidad geog á ica.
Una ez den o de la edición del iden i icado , como se puede obse a en la Figu a 4.7, si
se quie e modi ica la in o mación sólo se end á que ealiza los cambios necesa ios en los
ecuad os accesibles y pulsa el bo ón de edi a iden i icado de unidad geog á ica.
Pulsando el bo ón de elimina iden i icado den o del menú edición, se ealiza á un
bo ado lógico del mismo.
4.1. PROTOTIPO APLICACIÓN WEB 39
Den o del menú edición, si se pulsa sob e el bo ón pa a da de al a un nue o iden i icado ,
apa ece á una pan alla pa a ealiza el al a. Es a pan alla, mos ada en la Figu a 4.8, se ha
implemen ado en el a chi o geoUni Id.php.
Sólo hab á que ellena los campos y pulsa sob e el bo ón de al a. No se pod á da de al a
un iden i icado con un nomb e pa a un aplica i o ex e no ya almacenado.
Figu a 4.8: Pan alla de al a de un iden i icado pa a una unidad geog á ica.
Como se puede obse a en la Figu a 4.8, po de ec o, y al se un al a, siemp e se pond á el
es ado como ACTIVE.
Pulsando el bo ón del lis ado comple o desde el menú geo uni , se mos a á un lis ado con
odas las unidades geog á icas almacenadas. Es e lis ado con end á la misma in o mación
pa a cada unidad geog á ica y las mismas opciones sob e ellas que el menú consul a. Es a
pan alla, mos ada en la Figu a 4.9, se ha implemen ado en el a chi o busca GeoUni .php.
40 CAPÍTULO 4. SOLUCIÓN
Figu a 4.9: Pan alla con el lis ado comple o de unidades geog á icas.
Pulsando sob e el bo ón bo a de alguna de las unidades geog á icas desde el menú
consul a, se ealiza á un bo ado lógico de la unidad geog á ica y sob e su iden i icado
in e no, inac i ando los dos.
Pulsando sob e el bo ón de al a de unidad geog á ica den o del menú geo uni , se ac-
cede á a una pan alla desde la cual se pod á ealiza un al a de una unidad geog á ica. Es a
pan alla, mos ada en la Figu a 4.10, se ha implemen ado en el a chi o geoUni .php.
Pa a ealiza el al a sólo hab á que ellena los da os y pulsa sob e el bo ón de al a. Dando de
al a una unidad geog á ica nue a, ambién se da á de al a au omá icamen e su iden i icado
in e no. No se pod á da de al a una unidad geog á ica con un nomb e ya almacenado.
4.1. PROTOTIPO APLICACIÓN WEB 41
Figu a 4.10: Pan alla de al a una nue a unidad geog á ica.
Como se puede obse a en la Figu a 4.10, po de ec o, y al se un al a, siemp e se pond á
el es ado como ACTIVE.
Pulsando sob e la opción de edi a pe il, accesible desde odas las pan allas, se accede a un
menú en el cual se pod á modi ica los da os de usua io. Es e menú, mos ado en la Figu a
4.11, se ha implemen ado en el a chi o pe il.php.
Pa a ealiza la modi icación sólo hab á que modi ica los da os y pulsa sob e el bo ón
edi a .
48 CAPÍTULO 4. SOLUCIÓN
Viendo como de uel e co ec amen e el xml:
Lis ing 4.2: De olución ge GeoUni IdIn
1<SOAP-ENV:En elope SOAP-ENV:encodingS yle="h p://schemas.xmlsoap.o g/
soap/encoding/" xmlns:SOAP-ENV="h p://schemas.xmlsoap.o g/soap/
en elope/" xmlns:xsd="h p://www.w3.o g/2001/XMLSchema" xmlns:xsi="
h p://www.w3.o g/2001/XMLSchema-ins ance" xmlns:SOAP-ENC="h p://
schemas.xmlsoap.o g/soap/encoding/">
2<SOAP-ENV:Body>
3<ns1:ge GeoUni IdInResponse xmlns:ns1="u n: uncionesGeoUni ">
4< e u n xsi: ype="xsd:s ing">[{"0":"3","Id":"3","1":"2","
geouni _id":"2","2":"ES"," alo ":"ES","3":"a","aplica i o"
:"a","4":"INACTIVE","es ado":"ACTIVE"}]</ e u n>
5</ns1:ge GeoUni IdInResponse>
6</SOAP-ENV:Body>
7</SOAP-ENV:En elope>
4.4. Inco po ación p o o ipo a SOA
Pa a inco po a el p o o ipo gene ado a la a qui ec u a SOA, en es e caso ep esen ada po el
se de he amien as WSO2, explicado en la Sección 2.4.4, se ha enido que subi el se icio web
del p o o ipo a la he amien a WSO2 API Publishe , pa a ello se ha enido que u iliza la u l que
gene a el a chi o WSDL (h p://localhos /SOA/s c/geoUni Se ice.php?wsdl).
Una ez subido el se icio web al ges o de aplicaciones, cualquie o o aplica i o puede co-
nec a se a él y ealiza le pe iciones SOAP ges ionadas a a és de la he amien a WSO2 En e p ise
Se ice Bus, que hace las eces del ESB en es a a qui ec u a SOA.
Pa a comp oba que el p o o ipo de se icio web es aba co ec amen e subido, se ha u iliza-
do la he amien a WSO2 API S o e, desde la cual cualquie aplica i o se puede susc ibi a las
aplicaciones publicadas y ealiza le pe iciones de p ueba.

4.4. INCORPORACIÓN PROTOTIPO A SOA 49
Se ha usado pa a la p ueba la misma pe ición SOAP usada en las p uebas del se icio web con
la he amien a SoapUI, den o de la Sección 4.3.
Figu a 4.12: Da os de en ada y salida en la pe ición de p ueba en WSO2.
En la Figu a 4.12 se puede obse a en la caja "Cu l"la pe ición ealizada al se icio web y en
la caja "Response Body"la espues a de uel a. Compa andola con la espues a dada en la Sección
4.3, se e que es co ec a.
De es a o ma queda comp obado que el se icio es á in eg ado co ec amen e den o de la
a qui ec u a SOA y que cualquie aplica i o ex e no puede ealiza pe iciones al p o o ipo c eado.
50 CAPÍTULO 4. SOLUCIÓN
Una ez el aplica i o ha quedado in eg ado den o de la a qui ec u a SOA, si necesi a inco -
po a cualquie nue a uncionalidad o modi ica alguna de sus uncionalidades ya exis en es, sólo
se á necesa io modi ica el p opio aplica i o y no se á necesa io modi ica ninguna de la aplica-
ciones que es én conec adas a él.
Siendo una a qui ec u a de aplica i o implemen ada pa a inco po a se a la a qui ec u a SOA,
se pod án i incluyendo poco a poco los demás aplica i os de da os ijos exis en es en las en idades
inancie as de o ma sencilla, ya que es al amen e ac ualizable y escalable, educiendo así cos es
y iempos a u u o.
Conclusiones
Conclusiones en Español
A a és de los pasos que se han ido ealizando en es e p oyec o, se ha is o cómo in eg a
un eposi o io de da os ijos pa a la eso e ía banca ia de una en idad inancie a a una a qui ec u a
SOA.
El p o o ipo inal gene ado ha quedado bien in eg ado den o de WSO2, la he amien a pa a
a qui ec u a SOA elegida, y se ha desa ollado cumpliendo con las necesidades pa a pode se in-
eg a co ec amen e con más aplica i os den o de ella. Quedando de es a o ma un p o o ipo de
eposi o io de da os ijos que a u u o se pod ía expandi con nue os módulos de da os e inclui se
den o de una a qui ec u a SOA eal de una en idad.
T as la ealización del p o o ipo inal, se ha podido obse a que la mayo di icul ad de im-
plemen a aplicaciones pa a una a qui ec u a SOA den o de una en idad, adica en el cambio que
hay que ealiza en la o ma de pensa a la ho a de c ea las. Pa a c ea aplicaciones den o de una
a qui ec u a o ien ada a se icios hay que, además de pensa en las p opias uncionalidades de
la aplicación a c ea , pensa en cómo o ece odos sus se icios a odos los aplica i os ex e nos
que puedan llega a necesi a los en el u u o, y no gene a es os se icios pa a un sólo aplica i o
ex e no.
51
52 Conclusiones
En la ac ualidad, los aplica i os de las g andes emp esas es án desa ollados sin ene en cuen a
la a qui ec u a o ien ada a se icios. Además, ienen una g an a iedad de aplica i os desa ollados
en di e en es lenguajes de p og amación y desplegados en dis in as pla a o mas. Es os hechos
suponen g andes pé didas de iempo y de dine o pa a las emp esas cada ez que quie en ealiza
comunicaciones en e los di e en es aplica i os.
Es e p oyec o demues a que la u ilización de una a qui ec u a SOA en g andes emp esas es
una de las mejo es mane as pa a in e comunica las aplicaciones in e nas de una en idad, p odu-
ciendo pa a es as un g an aho o de iempo y dine o al c ea aplicaciones o ien adas a o ece sus
se icios a e ce os y siendo es as al amen e eu ilizables y ac ualizables.
Conclusions in English
Thanks o his p ojec I ha e lea n how o in eg a e a ixed da a eposi o y in o SOA a he
Bank’s T easu y a any inancial en i y.
The designed p o o ype is pe ec ly in eg a ed in o WSO2, he SOA oolki chosen o his
p ojec . Besides, i has been de eloped acili a ing i s in eg a ion wi h mo e applica ions wi hin
his a chi ec u e. As a esul , his ixed da a eposi o y is easily expanded wi h addi ional modules
and could be included in a SOA o any cu en en i y.
Wi h he de elopmen o he p o o ype I ealized ha he mos challenging aspec o imple-
men ing applica ions o SOA wi hin an en i y is he p ocess- hinking o c ea ing hem. When
c ea ing applica ions o SOA i is impo an no only planning hei own unc ions, bu also o e-
ing a wide ange o po en ial se ices use ul o all he u u e ex e nal applica ions o be c ea ed
– and no only o one single ex e nal applica ion.
Nowadays, he ixed da a o he big companies a e de eloped wi hou a SOA a chi ec u e.
Besides, hey p esen a g ea ange o applica ions ha use di e en p og amming languages and
a e displayed wi hin a ied pla o ms. As a esul , he en i ies su e losses in money and ime
whene e hey implemen an exchange o in o ma ion be ween applica ions.
Conclusiones 53
The pu pose o his p ojec is o show ha he use o SOA is one o he bes solu ions o
in e connec di e en in e nal applica ions wi hin an en i y. These applica ions a e clien o ien ed
and easily eusable and upda ed; his yields impo an sa ings in ime and money, especially o
big companies.

54 Conclusiones
Bibliog a ía
[1] D. WOODS, T. MATTERNS,“En e p ise SOA : Designing IT o Business Inno a ion",
O’Reilly Media, 2006.
[2] J. BLOOMBERG, R. SCHMELZER,“Se ice O ien o Be Doomed! : How Se ice O ien a-
ion Will Change You Business", Wiley, 2006.
[3] E. NEWCOMER, G. LOMOW,“Unde s anding SOA wi h Web Se ices", Addison-Wesley,
2005.
[4] THOMAS ERL,“Se ice-O ien ed A chi ec u e. A ield Guide o in eg a ing XML and Web
Se ices", P en ice Hall, 2004.
[5] G. ALONSO, F. CASATI, H. KUNO, V. MACHIRAJU,“Web Se ices. Concep s, A chi ec u-
es and Applica ions", Sp inge , 2004.
[6] YOAN ARLET CARRASCOSO PUEBLA, ENRIQUE CHAVIANO GÓMEZ,“A qui ec u a de
so wa e pa a el módulo de in en a io del ERP cubano", Uni e sidad de las Ciencias In o -
má icas, Cuba, 2008.
[7] DONNIE ROCK,“C ea un webse ice básico con PHP y SOAP" :h ps://donnie ock.
com/2013/01/17/c ea -un-webse ice-basico-con-php-y-soap/, Donnie-
ocK, 2013.
[8] ETHAN CERAMI,“Web Se ices Essen ials: dis ibu ed applica ions wi h XML-RPG, SOAP,
UDDI & WSDL.", O’Reilly Media, 2002.
55
56 Bibliog a ía
[9] ERIC NEWCOMER,“Unde s anding Web Se ices: XML, WSDL, SOAP AND UDDI",
Addison-Wesley, 2002.
[10] JAMES SNELL, DOUG TIDWELL, PAVEL KULCHENKO,“P og amming Web Se ices wi h
SOAP", O’Reilly Media, 2001.
[11] DAVID A. CHAPPELL,“En e p ise Se ice Bus", O’Reilly Media, 2004.
[12] WSO2 API MANAGER,“WSO2 API Manage Documen a ion" :h ps://docs.wso2.
com/display/AM210/WSO2+API+Manage +Documen a ion/
[13] WSO2 ENTERPRISE SERVICE BUS,“WSO2 En e p ise Se ice Bus Documen a-
ion" :h ps://docs.wso2.com/display/ESB500/WSO2+En e p ise+Se ice+
Bus+Documen a ion/
Ag adecimien os
G acias a José Luis Risco Ma ín del depa amen o de A qui ec u a de Compu ado es y Au o-
má ica po su colabo ación y ayuda a la ho a de ealiza el p oyec o.
57