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

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