Dezvoltarea unei aplicații COBOL – JAVA – WEB pe mainframe COORDONATOR ȘTIINȚIFIC LECT [630746]
UNIVERSITATEA DIN BUCUREȘTI
FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ
LUCRARE DE LICENȚĂ
Dezvoltarea unei aplicații COBOL – JAVA – WEB pe mainframe
COORDONATOR ȘTIINȚIFIC
LECT. DR. MUREȘAN CLAUDIA
STUDENT: [anonimizat] SILVIU
BUCUREȘTI
2017
1
Cuprins
Generalități 4
Capitolul I – Introducere 4
Mediul de lucru 4
IBM Power system 4
IBM i 4
DB2 5
Rational Application Developer for Power System 5
WebSphere Application Server 8.5 6
Rational Team Concert 7
Tehnologii folosite 9
JAVA 9
JT400 9
JAVA EE 10
Servlets 12
JSP 12
EJB 13
Java EE Connector Architecture 14
Web Services 15
Java Database Connectivity 16
COBOL 17
COBOL ILE 21
REST 22
Jython 23
XML 23
XSD 24
PCML 25
jQuery 25
Bootstrap 26
Capitolul II – No ț iuni teoretice 27
XML Databases 27
Design Patterns 30
Façade Pattern 30
Singleton Pattern 34
SOA 38
2
Capitolul III – Aplica ț ia server 41
Context 41
Caracteristici 42
Înregistrarea clienților în baza de date 42
Expunerea modulelor COBOL prin server 42
Modulul transfer de fonduri 43
Pagina web client 43
Pagina web testare 44
Implementare 44
Utilizare wizard framework JT400 44
SEPA.java 47
SEPAInput.java 48
SEPAResult.java 48
SEPAServices.java 48
SEPA Structures 48
iseries.programcall.base 48
Pagina de test 49
Clientul Web 49
Scripturi de configurare 49
Capitolul IV – Concluzie 50
Capitolul V – Bibliografie 51
Capitolul VI – Anexe 53
Diagrama topologică 53
Scripturi Jython 58
Instalarea unei aplica ț ii 58
Dezinstalarea unei aplica ț ii 58
Pornirea unei aplica ț ii 59
Oprirea unei aplica ț ii 59
Instalare adaptor 60
Dezinstalare adaptor 61
3
Generalități
Capitolul I – Introducere
Era calculatoarelor din secolul 19 a început cu mașinării de tip mainframe. Principalele
companii care produceau calculatoare de tipul mainframe în perioada 1950 ș i 1970 erau: IBM ,
Burroughs , UNIVAC, NCR, Control Data, Honeywell, General Electric ș i RCA. Calculatoarele
mainframe erau folosite de companii mari pentru a calcula cantită ț i mari de informa ț ii în domenii
precum: contabilitate, bancar, statistică ș i altele. În anii următori, calculatoarele de tip mainframe
au evoluat atât în puterea de procesare, cât ș i în tipul problemelor ce le rezolvă.
1. Mediul de lucru
1.1. IBM Power system
IBM Power system reprezintă un calculator mainframe de mijloc ‘midrange’. Acest
sistem cuprinde două arhitecturi diferite, iSeries sau AS/400 , având ca sistem de operare OS/400
ș i pSeries rulând IBM AIX ș i Linux ce au fost unite sub denumi rea de Power4 în 2001/2002.
Programele ce se execută pe acest sistem nu au contact direct cu partea hardware ci comunică cu
Technology Independent Machine Interface (TIMI) , o interfață special construită ca un strat de
comunicare bidirecțională între partea software ș i partea hardware . Avantajul acestei tehnologii
reprezintă independența programelor față de partea hardware . Drept exemplu ne putem referi la
anul 1995 când sistemul de atunci a schimbat procesorul pe 48 biți CISC (IMPI) pe un procesor
pe 64 biți RISC (PowerPC) , fără a avea impact față de programele existente scrise în COBOL . [1]
1.2. IBM i
IBM i este sistemul de operare al mașinii mainframe IBM Power Systems, redenumit în
2008 din i5/OS. În 1988 a apărut sub numele de ‘ AS/400 ’. Încă de la începuturi sistemul de
operare era unul bazat pe obiecte, comparativ cu sistemul Unix unde totul este reprezentat pe
fi ș iere. Sistemul de operare include ș i un sistem de managemen t al al bazelor de date rela ț ionale
4
DB2/400 . Accesul în sistem se făcea prin terminale fizice de tipul IBM 5250 (Fig. 1). În prezent
sistemul se accesează prin protocolul TELNET , folosind unul din programele ‘Personal
Communicator’ sau ‘Putty’. [2]
Fig 1. Terminal IBM 5250 [1]
1.3. DB2
DB2 este un sistem de gestiune al bazelor de date ce suportă relația dintre obiecte, precum
ș i structuri non-rela ț ionale ca JSON ș i XML. Limbajul de interogare folosit de acest sistem este
SQL. Baza de date DB2 se poate administra prin linia de comandă sau prin interfață. Prin linia
de comandă se pot executa cu ușurință scripturi de configurare în mod automat. DB2 suportă
interogare prin SQL dar ș i prin XQuery ș i are o implementare nativă pentru a menține în
memorie fișierele de tip XML, diferită de tipul clasic CLOB . DB2 suportă triggere, obiecte mari
( LOBs – large objects) , funcții definite de utilizator ( user-defined functions ) ș i tipuri distincte
( distinct types) încă de la versiunea 6.[3]
1.4. Rational Application Developer for Power System
Mediul de dezvoltare (IDE) – Integrated Development Environment , Rational Application
Developer for Power Users este un program ce se bazează pe platforma Eclipse . Cu ajutorul lui
programatorul dezvoltă aplica ț ii Java Standard Edition (Java SE) si Java Enterprise Edition (Java
EE). Pe lângă aceste funcții, Rational Application Developer for Power Users contine ș i aplicații
ajutătoare în construirea unor produse bazate pe tehnologia OSGi, Service Component
Architecture (SCA), Web 2.0 ș i XML. Cuvântul ‘for Power System’ se referă la modulul ajutător
în dezvoltarea ș i mente nan ț a aplica ț iilor pe IBM i.[4]
5
1.5. WebSphere Application Server 8.5
WebSphere Application Server (™) versiunea 8.5.5 este o soluție oferită de compania
IBM, un software framework ș i un middleware pe care se pot instala aplicații Java Web. WAS
este construit pe standarde precum JAVA EE, XML, Web Services. Această aplica ț ie se poate
instala pe următoarele platforme: Windows, AIX, Linux, Solaris, IBM i ș i z/OS .
Ahitectura aplica ț iei se împarte în următoarele categorii :
● Aplica ț ii
Executarea de aplica ț ii reprezintă principala abilitate a serverului. Aceste aplica ț ii pot fi
de următoarele tipuri: Java Platform, Enterprise Edition, Portlet, Session Initiation Protocol,
OSGi, Batch, Business-level.
● Containere
Containerele oferă suport de execu ț ie aplica ț iilor. Ele reprezintă zone bine definite în
ma ș ina virtuală Java, care con ț in cod specific unor anumitor tipuri de aplica ț ii. Un exemplu de
container îl reprezintă web container care procesează servlets , pagini JSP , precum ș i alte obiecte
de tipul server-side . Alt container cunoscut ș i foarte des utilizat este cel de Enterprise JavaBeans
(EJB) ce con ț ine toate serviciile necesare pentru managementul obiectelor de acest tip.
● Aplica ț ii server
Fiecare produs din familia de programe WebSphere Application Server are la baza sa o
aplica ț ie server, adică o platformă pe care aplica ț ii bazate pe limbajul Java se pot executa.
Această platformă oferă servicii precum: conectarea la baza de date, suport pentru mai multe fire
de execu ț ie, precum ș i managementul lucrului. Există aplica ț ii server singulare ș i independente,
dar ș i aplica ț ii server distribuite pe sisteme hardware diferite. Se pot defini ș i configura
următoarele aplica ț ii server: WebSphere Application Server, Generic server, On-demand router,
PHP server, WebSphere MQ server, WebSphere proxy server, Web server, Community Edition
server .
● Profile
Mediul de lucrul al fiecărei aplica ț ii, incluzând fi ș ierele de configurare, este men ț inut sub
un director numit profiles având un nume unic. În acest folder există automat fi ș ierele de
configurare pentru server precum ș i fi ș ierele necesare aplica ț iei ce urmează să fie instalată.
6
● Noduri
Un nod reprezintă un grup administrativ de aplica ț ii server utilizat pentru a facilita
configurarea ș i operare a sistemului. Se pot crea mai multe noduri, iar o aplica ț ie de sine stătătoare
are un singur nod. Folosind Network Deployment se pot configura mai multe servere ce au mai
multe noduri ș i sunt conectate la un singur server central de administrare. (Fig 1.6 Diagrama
Administrare WebSphere Application Server)
Fig. 1.6 Diagrama Administrare WebSphere Application Server
● Celule
O celulă este o grupare de noduri ce asigură administrarea unui singur domeniu.
Configurările făcute în celulă se aplică tuturor nodurilor din interior, dacă nodul nu are o
configurare separată a sa. În partea dreaptă a figurii de mai sus se observă clar apartenen ț a mai
multor noduri la o singură celulă. [5]
1.6. Rational Team Concert
Rational Team Concert este un program construit pe platforma IBM Jazz™ ce oferă un
mediu de colaborare comun. Comunicarea între membrii unei echipe este îmbunătățită deoarece
7
prin portalul web sau cel integrat în Rational Application Developer , membrii echipei pot crea,
vedea ș i comenta sarci ni. Fiecare sarcină are un status, un flow, timp de rezolvare ș i alte
informa ț ii relevante ș i reutilizabile în rapoarte.
Rational Team Concert con ț ine de asemenea ș i un sistem de versionare a surselor sub
forma unor Streamuri.
Colaborarea este punctul cheie al aplica ț iei deoarece fiecare sarcină cuprinde mai multe
păr ț i pornind de la estimare, categorie ș i importan ț ă, până la comentarii, notificări, fi ș iere,
precum ș i legături cu alte pagini.
Se pot crea u ș or rapoarte ș i informa ț ia e prezentată ș i împăr ț ită ș i în func ț ie de clasa
utilizatorului : Dezvoltator, Manager de Proiect, Tester, Parteneri, ș i altele.[6]
8
2. Tehnologii folosite
2.1. JAVA
Java este un limbaj de programare dezvoltat de Sun Microsystems în 1995 preluat
ulterior în 2009 de către Oracle odată cu achizi ț ionarea Sun Microsystems. Java este unul dintre
cele mai utilizate limbaje de programare, existând aproape 9 milioane de utilizatori în lume. În
contextul actual, este utilizat în special în dezvoltarea ș i livrarea con ț inutului pe internet. Java
este sigur, rapid ș i de el depind accesarea anumitor aplica ț ii sau website-uri. Este similar cu C++,
dar spre deosebire de acesta, elimină detaliile care pot cauza erori de programare. Textul din
codul sursă e compilat într-un format de tip bytecode care apoi este executat de un interpretor
Java. Acest limbaj de programare poate rula pe aproape orice calculator ș i poate fi descărcat
gratuit de pe site-ul www.java.com . [7]
2.2. JT400
Librăria JT400 este cunoscută ș i sub numele IBM Toolbox for Java ș i înglobează
un
set de programe open source ajutătoare în a dezvolta aplica ț ii în Java prin care se interconectează
cu sistemul IBM i. API se poate folosi pentru următoarele opera ț ii :
● Apelare programe COBOL, RPG ș i altele
Orice program IBM I se poate apela. Parametrii sunt trimiși din programul scris în Java ș i
după execuție este primit răspunsul tot prin parametrii.
● Access baza de date DB2 prin JDBC
Modulul JDBC este scris folosind specificațiile JDBC 4.2 ș i se pot executa toate operațiile
de creare, citire, scriere ș i modificare la nivel de celulă.
● Access la DataQueue
Se pot accesa ambele tipuri de DataQueue , cele cu cheie unică ș i cele secvențiale.
Înregistrările pot fi adăugate ș i sterse î ș i însă ș i crearea obiectelor de tipul DataQueue este
posibilă.
● Access la fi ș iere IFS files
9
Integrated File System ( IFS) reprezintă fișierele fizice de pe mainframe ș i se pot accesa
ușor prin API librăriei. Clasele din Java pot citi sau scrie într-un fișier, pot lista conținutul unui
director ș i alte comenz i de sistem ș i lucruri cu fișiere.
● Comenzi
Toate comenzile neinteractive ale sistemului IBM I se pot executa din Java. Rezultatul
executării comenzii este întors în modulul Java unde a fost apelat.
Această librărie u ș urează munca programatorilor ș i oferă un wizard pentru a crea web
services direct dintr-o sursă a unor programe COBOL aflate pe IBM I . [8]
2.3. JAVA EE
Java Platform Enterprise Edition este o platformă pentru dezvoltarea ș i implementarea
programelor software ale companiilor mari. Face parte din familia de platforme Java compusă din
:
● Java Platform Standard Edition – Java SE
● Java Platform Micro Edition – Java ME
● Java Platform Enterprise Edition – Java EE
Versiunea curentă ș i stabilă este Java EE 7.
10
Fig. 2.3 Modulele EJB
Specificațiile JAVA EE se pot clasifica în următoarele grupuri :
● Stratul de prezentare
Informația prezentată este de obicei sub forma unei pagini HTML, dar există ș i
posibilitatea ca datele să fie returnate sub forma JSON (JavaScript Object Notation ) sau XML
(eXtensible Markup Language) ce sunt consumate de un proces AJAX (Asynchronous JavaScript
and XML) ce pot modifica doar părți dintr-o pagină HTML. Clasele din acest strat sunt de obicei
executate într-un container Web ș i acest container are managementul său în server ( Tomcat ,
WebSphere ).
Din această categorie fac parte Java Servlet, Java Server Pages, Java Server Faces.
● Stratul de logică
În zona aceasta se găse ș te cod necesar logicii de business. Apelarea unei părți din logică
vine din stratul de prezentare.
Din această categorie face parte Enterprise Java Beans, Java Messaging Service .
11
● Stratul de integrare
API din acest strat este necesar comunicării cu mediul extern sau o altă aplica ț ie externă
sistemului. Un exemplu este accesul către o bază de date sau către alte servicii.
Din acest grup fac parte Java Database Connectivity (JDBC), Java Persistent API (JPA),
Java Connector Architecture (JCA), Web Services . [9]
2.3.1. Servlets
Servlet este o clasă de program Java care extinde capabilită ț ile unui server ș i este utilizat
în special cu protocolul HTTP. Avantajele sale constă în performan ț a rapidă ș i posibilitatea de
combinare cu CGI ( Common Gateway Interface ). Există 3 etape care stau la baza ciclului de via ț ă
al unui servlet: init(), service() ș i destroy(). Astăzi servlet a ajuns la versiunea 3.1, având în spate
9 update-uri. Ea este definită în Java Specification Request (JSR) si necesită Java Standard
Edition 7 . O aplica ț ie de tip servlet nu poate rula decât într-un servlet containe r, acesta utilizând
comunicare bidirec ț ională trimi ț ând mesaje din aplica ț ie către utilizator ș i invers. Pentru
accesarea aplica ț iilor tip servlet utilizatorii folosesc browsere web precum Mozilla Firefox,
Google Chrome sau Internet Explorer, după cum se poate observa în imaginea de mai jos. [9]
Fig. 2.3.1 Diagrama comunicare Servlet
2.3.2. JSP
Java Servlet Pages a fost dezvoltat în 1999, în acela ș i an devenind disponibilă ș i versiunea
1.1. JSP este un mix între HTML ș i cod Java. JSP permite codului Java să se întrepătrundă cu
HTML rezultând o pagină care este compilată ș i executată pe un server ș i care con ț ine Java
12
bytecode . În afară de codul HTML, JSP con ț ine ș i tagurile <% %> unde codul Java este pus.
Ultima versiune a acestui program este JSP 2.2, însă cea mai utilizată ș i cea mai recunoscută este
2.1 deoarece con ț ine Expression Language ș i multe alte îmbunătă ț iri fa ț ă de versiunea 2.2
precum cea care rezolvă bug-uri. [9]
2.3.3. EJB
Enterprise Java Beans 1.0 a fost introdusă în 1998 de către Sun Microsystem devenind
rapid populară printre dezvoltatorii de aplica ț ii. Ea reprezintă o arhitectură bazată pe componente
care dezvoltă, livrează ș i între ț ine aplica ț ii enterprise în mediul de produc ț ie. Este componenta
principală din J2EE ( Java 2 Enterprise Edition ) ș i împreună oferă suport mult mai bun
aplica ț iilor enterprise bazate pe web. Printre caracteristicile EJB-urilor amintim că pot fi
customizate la momentul livrării editând fi ș ierul de configurare deployment descriptor , con ț in
logică de business ce operează pe datele companiei ș i pot fi incluse într-o aplica ț ie diferită fără a
fi nevoie schimbarea codului sursă sau recompilarea datelor. [10]
Tipurile de beans din EJB sunt:
● session beans care sunt împăr ț ite în stateless session beans ș i stateful session
beans
● entity beans fiind împăr ț ite în bean-managed persistance ș i container-managed
persistance
● message driven beans
13
Fig. 2.3.4 Tipuri de EJB
2.3.4. Java EE Connector Architecture
Java EE Connector Architecture, abreviat JCA, este o tehnologie Java de arhitectură ce se
folose ș te pentru a conecta diferite platforme printr-un API comun. Versiunea 6 de Java EE
suportă versiunea 1.6 de JCA. Java EE Connector Architecture define ș te un set securizat,
scalabil ș i tranzacțional de mecanisme ce fac legătură între o aplica ț ie Java Enterprise ș i alte
sisteme enterprise information system (EIS) .
Principalele funcționalități ale modului pentru versiunea 1.6 sunt :
● Connection management contract – acest lucru facilitează accesul către un manager de conexiuni
aflate într-un pool care ulterior se conectează la sistemul EIS. Prin acest sub-modul de punte se
pot conecta mulți clienți folosind resursele în mod scalabil.
● Transaction management contract – managerul de tranzacții asigură propagarea tranzacției către
resursele sistemului EIS. Nu este nevoie de un manager de tranzacții extern.
● Security contract – facilitează accesul securizat către EIS. Acest contract reduce riscurile de
securitate către sistemul EIS, oferă suport pentru un mediu securizat al aplica ț iei ș i protejează
informațiile valoroase.
● Lifecycle management contract – este un contract ce asigură aplicației server controlul asupra
duratei de viață a resurselor dintr-un adaptor. Un exemplu de mecanism este atunci când aplicația
server poate inițializa resursa adaptor în momentul în care aceasta este instalată sau când este
pornită. Resursa adaptor este notificată în sens invers de către aplicația server atunci când un
eveniment de oprire sau dezinstalare se întâmplă.
● Work management contract – implică permisiunea resurselor unui adaptor să monitorizeze
endpoints, să apeleze componentele unei aplicații. Acest lucru se realizează prin interfața
Work , aplicația server crează thread-uri ce sunt executate de server sub același manager.
● Generic work context contract – facilitează controlul contextului unei instan ț e de tip
Work ce a fost executată de către aplicația server.
● Transaction inflow contract – permite managerului de resurse să propage o tranzacție
importată către o aplica ț ie server. În același timp se asigură proprietățile ( Atomicity ,
Consistency, Isolation, Durability ) – ACID ale tranzacției importate.
● Security work context – implică accesul unei resurse adaptor să mențină o conexiune
securizată atunci când este creată o instanță de tip Work gata de execuție de către
WorkManager.
14
● Message inflow contract – asigură transmiterea de mesaje în mod asincron între resursele
adaptor ș i aplic ația server.
● Common Client Interface (CCI) – este un standard API ce simplifică codul Java care face
accesul între componentele JEE ș i sistemele EIS. Fiecare sistem EIS are un Adaptor
special creat, dar care urmează standardul.
● Service Provider Interface (SPI) – este un standard API care înglobează mangementul
tranzacțiilor, securității ș i conexiunilor unei aplicații server. [12]
Fig. 2.3.4 Diagrama J2EE Adapter
2.3.5. Web Services
Web Services fac parte din Java EE 6 ș i sunt aplica ț ii pentru client ș i servere care
comunică prin intermediul HyperText Transfer Protocol (HTTP) al interfa ț ei World Wide Web
(WWW). Ele oferă modalită ț i de interoperabilitate aplica ț iilor de software ce rulează într-o
varietate de platforme ș i frameworks . Prin intermediul Web Services se ajunge la rezultate
deosebite ș i cu plus valoare.
Există două tipuri de Web Services:
● “Big” Web Services – folosesc mesaje XML care urmăresc procesul SOAP ( Simple
Object Access Protocol ), limbaj XML ce define ș te arhitectura unui mesaj ș i message formats .
Astfel de sisteme con ț in o descriere machine-readable a opera ț iunilor oferite de către service.
“Big” Web Services se adresează cerin ț elor avansate de QoS ce se regăsesc de obicei în
enterprise computing .
● RESTful Web Services – sunt potrivite pentru scenarii de integrare simple ș i ad-hoc. Pot fi
15
integrate mai u ș or cu HTTP decât SOAP ș i nu necesită mesaje XML sau defini ț ii WSDL
service–API. Dezvoltarea de RESTful Web Services este ieftină, iar pentru a reduce complexitatea
acestora, poate fi utilizat un development tool precum NetBeans IDE. Acest tip de services
u ș urează scrierea de aplica ț ii ce aplică majoritatea sau chiar toate constrângerile tipului REST,
precum loose coupling , scalability ș i architectural simplicity .[12]
2.3.6. Java Database Connectivity
Java Database Connectivity (JDBC) este o interfa ț ă de programare de aplica ț ii care
define ș te modul în care un client poate accesa o bază de date. A fost creată în 1997, iar în prezent
a ajuns la versiunea 4.2. JDBC permite existen ț a multiplelor implementări ș i utilizarea lor de
către aceea ș i aplica ț ie. Conexiunile sale permit crearea ș i executarea de statements , precum cele
de update de la SQL: CREATE, INSERT, UPDATE ș i DELETE. Reprezentările acestora de
către JDBC sunt realizate cu ajutorul următoarelor clase:
● statement – este trimis către serverul bazei de date de fiecare dată
● preparedstatement –
● callablestatement – utilizat pentru executarea de stored procedures în baza de date
Conexiunile JDBC sunt de obicei administrate prin intermediul unui connection pool . [13]
În exemplul următor se va vedea cum poate fi folosită această interfa ț ă:
public void connectareLaBazaDeDate (String utilizator, String parola) {
Connection con = DriverManager.getConnection(
"jdbc:myDriver:myDatabase" ,
utilizator,
parola);
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery( "SELECT a, b, c FROM TableTest" );
while (rs.next()) {
int x = rs.getInt( "a" );
String s = rs.getString( "b" );
float f = rs.getFloat( "c" );
}
}
16
2.4. COBOL
COmmon Bussiness Orientate Language este un limbaj de programare apărut în anii 1950
ș i e prescurtat prin acronimul COBOL. Acest limbaj este folosit pentru a dezvolta aplica ț ii pe
mainframe. Sintaxa este apropiată limbajului natural în limba engleză.
Când a fost dezvoltat COBOL, tehnologiile cu care suntem obișnuiți nu existau ș i astfel
pentru crearea unui program era nevoie de un formular special unde se scria programul care era
transformat în foi de tipul punch card .
Fig. 2.4.a Punch Card COBOL
Fazele de execuție necesare dezvoltării unei aplica ț ie COBOL :
● Scrierea programului sursă
Pentru a scrie un program sursă COBOL folosim Source Entry Utility (SEU) , un program
instalat pe sistemul de operare AS400 . Acesta are o interfață special pregatită ce corespunde cu
standardul COBOL de scriere a codului. SEU conține ș i un analizator de sintaxă util pentru a
semnaliza erori încă de la scrierea programului fără a-l compila.
● Compilarea programului
17
Atunci când programul e complet ș i corect sintactic, îl putem compila folosind comanda
de sistem Create COBOL Program (CRTCBLPGM) . În urma aceste ac ț iuni, un obiect program
executabil ce conține limbaj apropiat sistemului, o să fie generat.
● Etapa de debugging a programului
Sistemul de operare oferă funcții ce se pot folosi pentru debug precum: test library,
breakpoints, traces . Și se poate urmări execuția programului linie cu linie precum ș i se poate
interoga informația din variabilele existente în program, la momentul dat.
● Executarea programului
Un program COBOL se poate executa în mai multe moduri, unul dintre acestea este prin
apel făcut dintr-un program scris în limbajul CL sau dintr-un alt program COBOL ori prin apel
direct de către utilizator. Atunci când execuția programului s-a încheiat, sistemul oferă controlul
entității care a apelat programul în cauză.
Fig. 2.4.b Formular program COBOL
Limbajul de programare are o structură strictă legată de aranjarea codului în pagină, astfel
încât primele 6 coloane reprezintă identificarea liniei începând cu 000001. Pe coloana 7 se pune
caracter special care face linia respectivă sa fie comentată sau nu. Limbajul nu permite comentarii
18
pe linii multiple. Programul actual începe de la coloana 8 până la 11 reprezentând Area A ș i de la
11 la 72 reprezentând Area B . Zona începând de la coloana 73 până la 80 este folosită în mod
special pentru identificarea programului ș i nu se scrie cod în zona respectivă.
Limbajul COBOL are 4 mari diviziuni în ierarhia sa :
● IDENTIFICATION DIVISION
Conține informații despre program necesare compilatorului. Principalul cuvânt
cheie obligatoriu este PROGRAM-ID reprezentând numele programului. Alte cuvinte cheie din
această secțiune sunt AUTHOR , DATE-WRITTEN .
● ENVIRONMENT DIVISION
În această secțiune este descris mediul unde programul va funcționa. Astfel sunt
izolate aspecte ale programului precum DECIMAL-POINT IS COMMA ce se pot schimba cu
ușurință atunci când programul rulează pe alt mediu ș i e necesar să fie schimbat punctul zecimal.
Secțiunea este împarțită la rândul ei în două sub-secțiuni:
❖ CONFIGURATION SECTION
Aici se pot configura aspecte legate de virgula numerelor ob ț inute prin comanda
DECIMAL-POINT IS COMMA care specifică clar că numărul 1.234,56 este corect, iar
DECIMAL-POINT IS POINT va avea același număr reprezentat ca 1,234.56.
SYMBOLIC CHARACTERS este opțiunea prin care poți spune sistemului să ofere nume
unor caractere ce nu se pot afișa precum ENTER, linie nouă, TAB.
❖ INPUT-OUTPUT SECTION
În această secțiune sunt scrise fișierele bazei de date sau a unor fișiere fizice, precum ș i
modul de acces.
19
IDENTIFICATION DIVISION.
PROGRAM-ID. ConfigurationSection.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
DECIMAL-POINT IS COMMA.
SYMBOLIC CHARACTERS ESC CR LF
ARE 28 14 11.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT StockFile ASSIGN TO "C:\Data\Stock.dat"
ORGANIZATION IS SEQUENTIAL.
● DATA DIVISION
În această secțiune este descris modul în care se lucrează cu datele ș i variabilele de sistem.
❖ FILE SECTION
Aici este descris modul în care datele ajung la program ș i pleacă din program prin acces
la dispozitive periferice de stocare date precum cititoare de carduri, hard disks, CD-uri, DVD-uri,
benzi magnetice.
❖ WORKING-STORAGE SECTION
În acestă sec ț iune se află descrierea variabilelor folosite în program. Orice variabilă
poate fi de tipul alfanumeric ( PIC X) , alfabetic ( PIC A) sau numeric ( PIC 9) . Variabilele se pot
scrie în mod ierarhic punând cifre intre 01 ș i 49 înaintea ei. Ierarhia seamănă cu ce există în
struct din limbajul C/ C++ ș i poate conține toate tipurile de date .
WORKING-STORAGE SECTION.
01 Student.
02 IdStudent PIC 9 ( 4 ).
02 NumeStudent
03 Prenume PIC X( 10 ).
03 NumeFamilie PIC X( 10 ).
02 DateNastere
03 Aa PIC 9 ( 4 ).
03 Ll PIC 99.
03 Zz PIC 99.
02 IdCurs PIC X( 3 ).
02 NotaLicenta PIC 9 V99.
20
Student
IdStude
nt NumeStudent DataNastere Id
Curs Nota
Licen
ta Prenume NumeFamilie Aa Ll Zz
1 2 3 4 S i l v i u M a t e i 1 9 9 2 0 1 2 3 L 4 5 9 6 7
Înregistrarea Student este compusă din mai multe subcomponente ce pot fi referențiate
independent. Putem afișa data nașterii folosind următorul cod: DISPLAY DataNa ș tere ș i va afișa
1920123. Comanda DISPLAY Student va afișa întreaga informație existentă în toate
subcomponentele variabilei pe un singur rând (completat cu spațiu ș i 0 acolo unde căsuțele din
memorie sunt libere pentru caractere, respectiv numere) : ‘1234Silviu Matei
19920123L45967’.
❖ LINKAGE SECTION
Programele COBOL pot avea parametrii ș i aceștia se descriu în zona aceasta de cod.
Cuvântul cheie folosit este USING.
LINKAGE SECTION.
01 ValueToAdd PIC 99.
PROCEDURE DIVISION USING ValueToAdd.
❖ REPORT SECTION
În zona aceasta se pot defini raportări din diferite fișiere ș i modul cum acestea vor arăta.
● PROCEDURE DIVISION
Această secțiune de cod cuprinde majoritatea programului. Con ț ine partea logică de business a
programului.[15]
2.4.1. COBOL ILE
COBOL ILE este o extensie a limbajului COBOL ș i a fost dezvoltat să îmbunătățească
performanța programării modulare. Acest nou modul aduce un nou compilator, un nou translator
optimizat ș i facilități de legături ( binding) . Rezultatul compilării nu este doar un simplu obiect ci
21
un modul. Un modul conține proceduri ce pot fi apelate ca puncte de intrare cu parametrii sau nu,
ș i nu este executabil, în schimb fiecare modul conține programe. Un program are un singur punct
de intrare ș i e apelat dinamic. În modul pot exista diferite programe scrise în diferite limbaje de
programare. Acest sistem este observat ș i în alte sisteme de operare :
ILE Windows Linux
După compilare *.MODULE *.obj *.o
Bind prin copiere *.PGM *.exe *
Bind prin referință *.SRVPGM *.dll *.so
2.5. REST
Representational State Transfer este un stil arhitectural ce ajută la crearea, men ț inerea,
recuperarea ș i ș tergerea de resurse. Este bazat pe standardele web ș i protocolul HTTP ș i a fost
prima oară descris în anul 2000 de către Roy Fielding. Metodele HTTP utilizate de către
arhitectura REST sunt:
● PUT – creează o nouă resursă
● GET – define ș te reading acces al resursei fără efecte adeverse
● POST – updatează o resursă existentă sau creează una nouă
● DELETE – ș terge resursa.
Mesajele transmise sunt în format XML sau JSON. Arhitectura acestul stil impune
scrierea serviciilor în resursa URL. Fiecare modul este independent și nu menține o sesiune a
sistemului. Folosind modulele independent, se pot reutiliza cu ușurință.
Principalele caracteristici ale acestui stil reprezintă :
● Arhitectură orientată spre client
Separarea entităților precum datele și interfața de utilizare reprezintă un pas important
pentru portabilitatea aplicației. Acest lucru permite separarea pe componente ce se pot dezvolta
independent.
● Statelessness
22
Fiecare cerere făcută de un client către server este independentă și conține suficiente
informații pentru a furniza un rezultat. Sesiunea unui client nu este reținută și utilizată în partea
aceasta de cod ci mutată de exemplu într-o bază de date.
● Sistem de cache
Clienții pot să păstreze în memoria internă răspunsurile anumitor cereri. De aceea
resursele REST trebuies definite clar ca fiind permise să rămână în memoria clienților sau nu.
Utilitatea memoriei cache determină un apel în minus către server și implicit salvează timp
deoarece citirea din memoria locală este mai rapidă.
● Sistem modular
Modularitatea sistemului oferă posibilitatea apariției de straturi adiționale, de exemplu un
strat de securitate interpus între client și server ce validează autenticitatea și siguranța datelor.
● Interfa ț ă unifor mă
O arhitectură REST trebuie să conțină resursa identificată în cerere, exemplu direct în
URI format de cerere. Este importantă folosirea metadata atașată cererii. Fiecare mesaj conține
suficiente informații ce pot exista și în tipuri media din internet ( MIME type ).[16]
2.6. Jython
Jython este un limbaj de programare bazat pe limbajul Python, dar care e capabil să ruleze
pe o ma ș ină virtuală Java. Pe principalele module mo ș tenite din Python în limbajul Jython
se pot include ș i clase Java. Odată compilat acesta este transformat în Java bytecode. Se
folose ș te în mod special ca un limbaj de configurare pentru următoarele servere[17] :
● JBoss
● wsadmin – WebSphere Application Server
● ZK
● DMelt
2.7. XML
XML ( eXtensible Markup Language ) a fost creat pentru stocarea ș i transportul de date ș i
este un program ce define ș te un set de reguli pentru codarea documentelor într-un format ce poate
fi descifrat atât de persoane, cât ș i de calculatoare. Design-ul XML pune accent pe simplicity ,
generality ș i usability ș i, de ș i se focusează pe documente, limbajul este utilizat preponderent
pentru reprezentarea de structuri de date arbitrare precum cele utilizate în web services .
23
Prin intermediul XML au fost dezvoltate multiple documente precum RSS , Atom , SOAP ,
SVG ș i XHTML . Key constructs ale acestui limbaj sunt:
● characters : un document XML este un ș ir de caractere
● processor ș i application : primul analizează macheta ș i trimite informa ț ia
structurată către application
● markup ș i content : reprezintă cateegoriile în care sunt împăr ț ite caracterele
dintr-un document XML
● tag : este o machetă care începe cu < ș i se termină cu > ș i este de 3 feluri:
start-tag , end-tag ș i empty-element tag
● element : este o componentă logică din document care fie începe cu un start-tag ș i
se termină cu un end-tag de acela ș i fel, fie este formată doar dintr-un
empty-element tag .
● attribute : este un markup construct ce consistă într-o pereche nume-valoare care
există într-un start-tag sau un empty-element tag
● XML declaration : oferă informa ț ii despre documente.
Există două versiuni de XML, prima fiind dezvoltată în 1998 (XML 1.0), iar a doua în
2004 (XML 1.1).[18]
2.8. XSD
XSD (XML Schema Definition) este o recomandare a World Wide Web Consortium
(W3C) care specifică modul în care trebuie descrise elementele dintr-un document XML. De
asemenea XSD poate fi utilizat ș i pentru generarea de documente XML care sunt tratate drept
obiecte de programare. Schema este o reprezentare abstractă a caracteristicilor unui obiect ș i a
rela ț iilor sale cu alte obiecte. XSD Schema este interrela ț ia dintre atributele ș i elementele unui
obiect XML. Procesul creării acesteia presupune analiza structurii documentului ș i definirea
fiecărui element structural.
24
Printre avantajele utilizării XSD fa ț ă de XML men ț ionăm: Document Type Definition
(DTD) ș i Simple Obje ct XML (SOX). De asemenea, printre dezavantaje amintim complexitatea
acestuia, lipsa unui format descriptiv matematic ș i faptul că oferă suport limitat content-ului
unordered . [19]
2.9. PCML
PCML reprezinta acronimul pentru Program Call Markup Language , acesta este un XML
generat dintr-o sursa Cobol prin care se exportă structura parametrilor de intrare din programul
Cobol. Această structură se poate folosi în programe Java u ș urând lucrul cu date deoarece este o
rela ț ie 1 la 1 între parametrii programului COBOL ș i aplica ț ia Java unde se pot completa
parametrii după regulile din fi ș ierul PCML.[20]
Parametrii pot fi de următoarele tipuri principale: char, int, packed, zoned, float, byte,
struct . Fiecare există într-o structură definită prin atributul usage ca fiind:
● inherit – proprietatea usage este moștenită de la nodul părinte structurii; dacă
acesta nu există va avea proprietatea inputoutput
● input – acesta indică elementele din structură; se folose ș te doar pentru intrare în
programul apelat
● output – proprietatea inversă celei de input prin care se specifică faptul că
parametrii sunt folosiți la rezultatul apelului
● inputoutput – reprezintă structura în care elementele sale sunt populate atât din
exterior înainte să fie apelat programul COBOL , cât și în interiorul programului
COBOL alterând informația în interior.
2.10. jQuery
jQuery este un framework cross-platform web ce ajută dezvoltatorii să creeze aplicații
web client mult mai ușor. Necesitatea apariției unui astfel de framework a apărut ca o consecință
a diferitelor implementări din programele browser existente: WebKit, Gecko, Microsoft .
Acest framework poate selecta elemente DOM, management de evenimente, apeluri
AJAX sau poate crea animații. Fiecare componentă este descrisă în framewrork pentru toate
25
tipurile de browser existente, astfel programatorul folosește librăria fără a se preocupa cu
variațiile de la fiecare browser.[21]
Un exemplu de a avea gradient în CSS pentru mai multe tipuri de browser :
cod CSS Browser
-webkit-gradient WebKit verbose
-webkit-linear-gradient ;
webkit-radial-gradient WebKit după revizie standard
linear-gradient ; radial-gradient W3C CSS3 standard
-ns-linear-gradient ; -ms-radial-gradient Microsoft implementare W3C standard
filler ; -ms-filler Microsoft propria implementare
-moz-linear-gradient ; -moz-radial-gradient Mozilla implementare
-o-linear-gradient ; -o-radial-gradient Google WebKit
Principalele principii de dezvoltare ale framework-ului jQuery :
● Eliminarea incompatililităților versiunilor diferite de browser (cross-browser )
● Separarea codului JavaScript de codul HTML
● Claritate și funcții înlănțuite
● Extensibilitatea prin atașarea de noi plugin-uri.
Ultima versiune stabilă este 3.2.1 publicată pe 20 martie 2017.
2.11. Bootstrap
Bootstrap este un framework pentru design pagini web open-source ce cuprinde cod
HTML și CSS sub forma unor template-uri pentru componente precum butoane, formulare,
tabele. Fiecare componentă în parte este descrisă pentru toate tipurile de browsere existente,
facilitând scrierea unui design corss-browser. [22]
Versiunea stabilă 3.3.7 a fost publicată pe 25 iulie 2016 și are următoarele caracteristici:
● Design responsive – fiecare componentă descrisă cu ajutorul framework-ului este
independentă de ecranul pe care este afișat deoarece designul odată scris se
adaptează rezoluției ecranului. Programatorii scriu un singur design și obțin pagini
26
care se comportă asemănător chiar și pe platforme mobile. Ajustarea
componentelor este dinamică în pagină.
● Componente reutilizabile
● Integrarea cu jQuery – preia o parte din componentele existente în librăria jQuery
pentru componente adiționale precum carousels, dialog boxes, tooltips . De
asemenea extinde și alte funcționalități precum funcția de auto-complete .
27
Capitolul II – No ț iuni teoretice
1. XML Databases
IBM DB2 9 pentru Linux, UNIX ș i Microsoft Windows marchează o nouă etapă
în
evolu ț ia serverelor de date. IBM este lider în industria de data management datorită dezvoltării de
tehnologie inovativă. Aceasta transformă modalitatea prin care informa ț ia XML este administrată
pentru pentru a ob ț ine maximum return în timp ce XML este integrat cu u ș urin ț ă cu relational
data . Astfel, data services ating nivele noi prin reducerea costurilor, livrarea de agilitate mult mai
bună ș i îmbunătă ț irea de business insight. Astfel, DB2 9 devin e un ingredient esen ț ial a
infrastructurii information-as-a-service .
Tehnologia XML a devenit universală în toate sectoarele ș i toate domeniile, făcând apel la
versatilitatea ș i neutral itatea cu care face schimb de date prin intermediul diverselor device-uri,
aplica ț ii ș i sisteme de la diferi ț i vendori. Aceste caracteristici împreună cu u ș urin ț a cu care
această bază de date în ț elege natura self-describing , abilitatea de a manevra date structurate,
semi-structurate sau nestructurate ș i suport pentru Unicode, au reu ș it să transforme XML într-un
standard universal pentru schimb de date.
Astăzi, fiecare companie întâlne ș te XML într-o formă sau alta deoarece cantitatea de date
XML cre ș te din ce în ce mai rapid. De altfel, conform unor studii, acest tip de date cre ș te de două
ori mai rapid decât cea tradi ț ională, factorii fiind: industria XML-based ș i standarde de date, SOA
(Service-oriented Architecture) ș i Web Services, tehnologii 2.0 precum XML feeds ș i syndication
services .
Aproape fiecare industrie are multiple standarde bazate pe XML ș i există, de asemenea,
numeroase standarde cross-industry . Mai jos pute ț i găsi câteva câteva exemple de astfel de
standarde:
● ACORD – XML pentru Industria de Asigurări (http://www.acord.org/)
● FPML – Produse Financiare ( http://www.fpml.org/ )
● HL7 – Sănătate ( http://www.hl7.org/ )
28
● IFX – Schimb Financiar Interactiv ( http://www.ifxforum.org/ )
● IXRetail – Standard pentru Retail Operation ( http://www.nrf-arts.org/ )
● XBRL – Business Reporting / Accounting ( http://www.xbrl.org/ )
● NewsML – Ș tiri / Publica ț ii (http://www .newsml.org/).
Aceste standarde facilitează scopurile precum schimbul de informa ț ii dintre jucători
diferi ț i din aceste industrii ș i intermediari, defini ț iile datelor pentru opera ț iuni în desfă ș urare ș i
specifica ț ii legate de documente. Din ce în ce mai multe companii adoptă acest standarde XML
pentru a se men ț ine competitive, pentru a îmbunătă ț i eficien ț a, pentru a comunica cu parteneri
sau supplieri ș i pentru a rezolva task-uri zilnice.
Framework-urile ș i deployment-urile services-based se bucură de o popularitate în
cre ș tere, demonstrând capacitatea de a integra sisteme, de a permite reutilizarea de resurse ș i de a
răspunde rapid la condi ț iile schimbătoare de pia ț ă, astfel permi ț ând companiilor să
economisească bani ș i să î ș i îmbunătă ț ească competitivitatea. În arhitecturile services-based,
consumatorii ș i provid erii de servicii schimbă informa ț ii prin intermediul mesajelor, ce se rezumă
la XML. Astfel, XML poate oferi suport în SOA precum se poate observa în figura de mai jos. În
acest fel, hotărârea de a vedea informa ț iile drept servicii ș i de a adopta mediile SOA ajută la
cre ș terea XML-ului.
Syndication este considerată inima Web 2.0, următoarea genera ț ie de Internet. Feed-urile
Atom ș i RSS pot fi găsite din abunden ț ă pe Internet, permi ț ând utilizatorului să se aboneze la ele
ș i să fie la curent cu toate schimbările legate de Web content, precum ș tiri, articole, site-uri
enciclopedice ș i fi ș iere audio ș i video. Contentul pentru aceste feed-uri este restituit întrucât
29
documentele XML pot con ț ine link-uri, rezumate, articole întregi ș i chiar fi ș iere multimedia
precum podcasturi. Feed-urile syndication ș i web transformă internetul, astfel că noi modele de
business apar mereu în jurul acestor tehnologii. Drept consecin ț ă, date XML există acum doar în
companiile care adoptă standardele XML sau care implementează SOA, dar ș i virtual pe fiecare
desktop conectat la Internet.
Având în vedere faptul că standardele XML devin din ce în ce mai răspândite,
determinarea de a adopta tehnologii tip syndication ș i medii SOA face ca mult mai multe date
XML să fie generate zilnic sub formă de feed-uri web, purchase orders , transaction orders sau
financial trades . Astfel, documente ș i date XML devin lucruri de valoare în business con ț inând
informa ț ii importante precum detalii ale clien ț ilor, date de tranzac ț ie ș i documente opera ț ionale.
Cre ș terea asset-urilor XML prezintă provocări ș i oportunită ț i companiilor. Când aceste date sunt
valorificate, iar valoarea informa ț iilor este eliberată, poate fi tradusă în oportunită ț i pentru
organiza ț ii de a eficien tiza opera ț iunile, a oferi insight ș i a deveni agile.
Pe de altă parte, în timp ce datele XML devin din ce în ce mai decisive pentru opera ț iunile
unei companii, apar provocări ce ț in de securitatea, men ț inerea, cercetarea ș i împărtă ș irea datelor
XML. În func ț ie de utilizare, acestea pot avea nevoie ș i de update, revizuire ș i integrare cu date
tradi ț ionale. Toate aceste task-uri trebuie rezolvate cu seriozitate, disponibilitate ș i să poată fi
permise de către asset-urile datelor tradi ț ionale. De aceea, pentru a dezvălui adevăratul poten ț ial
al datelor XML, este nevoie de storage ș i servicii de management similare cu ce DB2 a oferit
pentru date rela ț ionale .[23]
30
2. Design Patterns
a. Fa çade Pattern
Acest pattern oferă o interfa ț ă unificată unui set de interfa ț e dintr-un subsistem. Façade
Pattern , în timp ce ascunde complexitatea subsistemului, arată puterea acestuia printr-o interfa ț ă
u ș or de utilizat. Este cel mai des implementată pentru următoarele scopuri ș i situa ț ii:
● oferă acces simplu ș i unificat la un sistem bine determinat de back-end
● creează API public pentru clase, precum un driver
● oferă acces coarse-grained pentru serviciile disponibile, care pot fi întâlnite combinate
● reduce transportul pe rețea. Façade face multe apeluri către subsistem, în timp ce clientul
remote face un singur apel
● încapsulează detaliile unei aplica ț ii pentru securitate ș i simplitate.
Uneori, aceste façade sunt implementate ca un singleton abstract factories .
A ș a cum poate fi văzut în diagrama de mai jos, façade pattern oferă o interfa ț ă simplă
unui sistem de bază. Astfel, încapsulează complicata logică granulară.[24]
31
Nu este complicată implementarea façade pattern- ului. Orice metodă care oferă acces
u ș or către un circuit complicat poate fi considerată o modalitate de implementare a façade
pattern -ului. Aceasta poate fi decuplată de către client, ea permi ț ând implementării să fie
schimbată fără a afecta modul în care clientul accesează serviciile acestui pattern. Clientul nu
cunoa ș te detaliile din spatele acestor metode. Pe el îl interesează doar să ob ț ină serviciile de care
are nevoie.
Printre beneficiile façade pattern amintim:
● reducerea în cuplare deoarece clientul nu ș tie nimic despre subsistem
● cre ș terea men ț inerii în stare de func ț ionare ș i a flexibilită ț ii când sunt necesare schimbări
● reutilizarea func ț ionabilită ț ii deoarece încurajează reutilizarea de controls ș i fine-grained
logic
● consisten ț a execu ț iei serviciului prin invocarea aceleia ș i metode de fiecare dată
● reducerea complexită ț ii de business logic prin gruparea metodelor asemănătoare ș i
invocarea lor cu ajutorul uneia singure
● centralizarea securită ț ii ș i managementului de transacti on control
● implementării de pattern-uri care pot fi testate.
Spre deosebire de alte pattern-uri, Java EE nu oferă o implementare built-in acestei
metode. Se utilizează stateful sau stateless EJB, care oferă avantajul de a accesa u ș or alte EJB de
care façade ar avea nevoie. Pentru a demonstra implementarea cu ajutorul de stateless beans ,
trebuie avut în vedere faptul că există 3 EJB-uri precum în schema de mai jos, dar cu
func ț ionalită ț i atât diferite, cât ș i corelate: ServiciuClienti, ServiciuCredit ș i
ServiciuContabilitate.
package com.exemplu.facade;
import javax.ejb.Stateless;
@Stateless
public class ServiciuClienti {
public long getClient ( int sessionID) {
// prea clientul logat
return 100005L ;
32
}
public boolean verificaId ( long x) {
// verific ă dac ă Id clientului e corect
return true ;
}
}
package com.exemplu.facade;
import javax.ejb.Stateless;
@Stateless
public class ServiciuCredit {
public boolean verificaCreditPermisiune ( long id, double suma) {
// verific ă dac ă clientul poate împrumut ă suma descris ă
return true ;
}
}
package com.exemplu.facade;
import javax.ejb.Stateless;
@Stateless
public class ServiciuContabilitate {
public boolean iaCredit ( double suma) {
// verific ă daca se poate imprumuta suma
return true ;
}
public boolean seteazaBalantaClient ( long id, double suma) {
// seteaz ă noua sum ă în contul clientului
return true ;
33
}
}
Aceste EJB services pot fi grupate într-o colec ț ie logică de func ț ionalită ț i corelate, pentru
a forma o implementare a façade pattern , a ș a cum poate fi observat mai jos:
package com.exemplu.facade;
import javax.ejb.Stateless;
import javax.inject.Inject;
@Stateless
public class ServiciuBancarFacade {
@Inject
ServiciuClienti serviciuClienti;
@Inject
ServiciuCredit serviciuCredit;
@Inject
ServiciuContabilitate serviciuContabilitate;
public boolean iaCredit ( int sessionId, double suma) {
boolean result = false ;
long id = serviciuClienti.getClient(sessionId);
if (serviciuClienti.verificaId(id)){
if (serviciuCredit.verificaCreditPermisiune(id, suma)){
if (serviciuContabilitate.iaCredit(suma)){
result =
serviciuContabilitate.seteazaBalantaClient(id, suma);
}
}
}
return result;
}
34
}
Façade poate invoca alte façade în alte subsisteme, care, în schimb, vor încapsula propria
logică ș i propriul flow. De aici putem deduce unul dintre beneficiile utilizării de façade : o
ierarhie simplificată de method calls . Există una pentru fiecare subsistem, iar aceste subsisteme
comunică între ele prin intermediul unui façades .
b. Singleton Pattern
Pattern-ul Singleton se referă la un template de clasă din programarea orientată pe obiecte
ce asigură în mod sigur existența unei singure instanțe a clasei în cauză pe toată durata de viață a
sa. Această singură instanță se referențiază global și se poate utiliza oriunde în aplicație. [24]
Singleton este folosit pentru următoarele situații :
● Pentru a accesa date împărțite pe întreg domeniu al unei aplicații precum date de
configurare
● Pentru a prelua și înregistra resurse ce sunt necesare în aplicație, dar rămân statice pe
parcursul ei precum driver JDBC
● Pentru a crea o singură instanță de clasă care scrie în log
● Pentru a face managementul unei case ce implementează Factory Pattern
● Pentru a crea un obiect facade în cazurile în care e necesar doar unul.
Designul acestui pattern este ușor de utilizat și înteles, dar abuzul său într-o aplicație
semnifică un design arhitectural greșit care poate fi îngreunat de memorie plină deoarece garbage
collector nu eliberează memoria la timp.
Pentru a crea o clasă singleton este necesar în primul rând să ascundem constructorul
clasei respective folosind cuvântul cheie private înaintea constructorului. Apoi următorul pas este
să avem o metodă care crează instanța și o returneză celui care o cere. E necesar ca această
metodă să fie statică pentru a asigura accesul prin corpul clasei ClasaSingleton.getInstance() .
package com.exemplu.singleton;
public class ClasaSingleton {
35
private static ClasaSingleton instanta;
private ClasaSingleton () {}
public static ClasaSingleton getInstance () {
if (instanta== null ){ // nu exista in acest moment
instanta= new ClasaSingleton();
}
return instanta;
}
}
Implementarea de mai sus nu este corectă din punct de vedere al siguranței pe thread -uri.
Astfel există posiblitatea ca la un moment dat să apară două obiecte de tipul ClasaSingleton ,
lucru ce distruge proprietatea fundamentală de a avea o singură instanță în orice moment.
O soluție a problemei amintite anterior este folosirea cuvântului cheie synchronized atunci
când instanța este cerută, respectiv creată. Astfel se obține o prelucrare atomică și se asigură
existența unei singure instanțe.
package com.exemplu.singleton;
public class ClasaSingleton {
private static ClasaSingleton instanta;
private ClasaSingleton () {}
public static synchronized ClasaSingleton getInstance () {
if (instanta== null ){ // nu exista in acest moment
instanta= new ClasaSingleton();
}
return instanta;
}
}
Implementarea de mai sus este sigură din punct de vedere al thread- urilor dar nu este cea
mai performantă implementare din punct de vedere al vitezei de acces. Cuvântul cheie
36
synchronized blochează accesul concomitent al mai multor thread -uri și astfel există posibilitatea
ca aplicația să fie îngreunată din această cauză.
O simplă soluție este de a scoate crearea instanței în momentul cererii și de a avea instanța
creată atunci când clasa este preluată în memorie. Acest lucru nu necesită folosirea cuvântului
synchronized . Instanța este creată de către JVM .
package com.exemplu.singleton;
public class ClasaSingleton {
private final static ClasaSingleton instanta = new ClasaSingleton();
private ClasaSingleton () {}
public static ClasaSingleton getInstance () {
return instanta;
}
}
O altă metodă poate fi prin crearea unui bloc static. Acest lucru duce la o inițializare
întârziată deoarece blocul static este apelat înaintea constructorului clasei.
package com.exemplu.singleton;
public class ClasaSingleton {
private static ClasaSingleton instanta = null ;
static {
instanta = new ClasaSingleton();
}
private ClasaSingleton () {}
public static ClasaSingleton getInstance () {
return instanta;
}
}
37
O altă implementare populară este și verificarea dublă a existenței clasei. Verificarea se
face folosind cuvântul cheie synchronized doar daca obiectul este null . Astfel se economisește
timp deoarece clasa va returna instant instanța sa și nu va intra în partea de cod semaforizată daca
nu e nevoie.
package com.exemplu.singleton;
public class ClasaSingleton {
private static ClasaSingleton instanta;
private ClasaSingleton () {}
public static ClasaSingleton getInstance () {
if (instanta== null ){ // verificare 1
synchronized (ClasaSingleton.class) {
if (instanta== null ){ // verificare 2
instanta= new ClasaSingleton();
}
}
}
return instanta;
}
}
38
3. SOA
SOA este acronimul de la service-oriented architecture ș i reprezintă o metodologie
folosită în dezvoltarea software. Așa cum obiectul este în centrul paradigmei programării
orientate pe obiecte, SOA e bazată pe conceptul de servicii ( services), astfel că un serviciu
reprezintă o aplica ț ie ce este invocată de alte aplicații.
Conceptul a fost adus din viața reală. Ca exemplu putem men ț iona momentul când o
persoană își dorește să î ș i mobileze locuința. Ea va căuta firme specializate în creare de mobilă
apoi va contacta firma respectivă ș i vor stabilii detaliile. Același scenariu se poate aplica ș i unei
aplicații software. Astfel, o companie poate avea un program care prelucrează cereri de mobilă la
comandă, care va prelua informațiile de la client ș i va căuta într-un registru de firme care execută
mobilă la comandă. În funcție de anumite criterii (preț, timp de execuție) serviciul alege din lista
de firme găsită pe cel mai potrivit ș i îl va returna clientului care a făcut cererea.
În acest scenariu se identifică trei participanți :
● Service Requestor: o aplica ț ie care are nevoie de business
● Service Broker: un registru cu toate serviciile disponibile
● Service Provider: o aplica ț ie care implementează o funcție de business.
Toți participanții se îmbină în scenariu în felul următor: un service provider implementează un
serviciu ș i îl publică către service broker . Un service requestor caută în registru serviciul ce îl
interesează ș i odată găsit se va crea o legătură ce ușurează invocarea serviciului.
Arhitectura SOA are câteva caracteristici descrise astfel :
● Implementarea SOA se poate face în moduri diferite
SOA reprezintă o arhitectură ș i ca orice arhitectură definește principii de design pentru a
construi o componentă software. Implementarea componentei se poate face în funcție de
necesități. Putem lua ca exemplu o analogie cu acțiunea de a construi fundația unei case. Poți
folosi un excavator pentru asta sau poți folosi o simplă lopată. În acela ș i fel există ș i soluții
diferite în implementarea SOA.
Un set de standarde recunoscut este Web services ș i acestea reprezintă cea mai bună cale
de a implementa SOA, dar nu e ș i unica, putându-se folosi ș i tehnologii precum CORBA , . NET
sau REST .
39
● Există avantajul decuplării între modulele unei aplicații mai mari
Unul dintre punctele cheie ale acestei arhitecturi îl reprezintă aplicațiile ce au diferite
unități funcționale numite servicii ( services ) ce comunică printr-o interfață bine definită. Interfața
este definită neutru ș i independent față de serviciile care trec prin ea, de sistemul de operare, de
limbajul de programare în care a fost scris serviciul. Această independență oferă tuturor
serviciilor posibilitatea comunicării în mod uniform ș i universal indiferent de sistemul pe care se
află.
Acest concept de a avea o interfață neutră ce nu e strâns legată de o implementare
particulară este cunoscută drept loose coupling între servicii. Beneficiile se observă în timp atunci
când sistemul va avea abilitatea ș i agilitatea să supraviețuiască schimbărilor de evoluție a fiecărui
serviciu în parte.
Interfața nou creată reprezintă un nou strat funcțional în soluția finală ș i beneficiile sale
sunt mai importante decât dezavantajul de a avea un nou strat funcțional.
● Se pot folosi în continuare aplicații existente
Se dorește să se refolosească codul dintr-o aplica ț ie sau logica de business, dar acest lucru
nu este întotdeauna ușor, ș i reprezintă o adevărată provocare în cazul aplicațiilor monolit ce
necesită modernizare. În aceste cazuri termenul de refolosire a codului rămâne limitat la ‘a
schimba partea hardware, recompilează ș i continuă să folosești aplicația’.
Arhitectura SOA promite în continuare utilizarea aplicației existente, dar, în același timp,
permite ș i pregătirea migrării ș i chiar o perioadă de timp în care aplicația veche ș i cea nouă
func ț ionează concomit ent până când totul e gata migrat.
40
● Implementarea unor servicii de calitate
Atunci când în soluția de business se lucrează cu un partener extern, sau alte operații de
care aplicația nu are control, trebuies definite reguli de obicei sub forma unor contracte
service-level agreements ș i operational policies . De asemenea securitatea este foarte importantă
pentru companie ș i e foarte important să ai încredere că toate serviciile ș i procesele de business se
execută conform termenilor agreați. De aceea arhitectura SOA oferă securitate, mesaje de
încredere, tranzacții. [25]
41
Capitolul III – Aplica ț ia server
1. Context
Aplicația BBank reprezintă un mini sistem bancar, clienții fiind înregistrați în sistemul
AS400 prin interfa ț a scrisă într-un program COBOL . Baza de date este de tipul DB2 aflată pe
mainframe AS400. Folosind PCML, aplicația expune programe de logică scrise în COBOL pe
server WebSphere urmând să fie folosite pentru alte aplicații externe.
Aplicația este modulară ș i fiecare modul este independent. Astfel se pot înlocui module cu
alte tehnologii sau se pot scrie noi module cu un alt scop decât cel existent.
Logica aplica ț iei scrisă în COBOL rămâne neschimbată ș i timpul conversiei programelor
existente în COBOL este redus. Expunerea către tehnologii noi sau alte aplicații externe se face
folosind framework JT400.
WebSphere este instalat pe mainframe, iar aplicația EAR se instalează pe acest sistem.
2. Caracteristici
a. Înregistrarea clienților în baza de date
Înregistrarea clienților se face prin programul COBOL printr-o fereastră interactivă unde
se introduc date precum nume, prenume, adresă, țară, limbă etc.
Există două tipuri de clienți, persoane fizice și persoane juridice, și fiecare relație are
atașată un cont curent.
b. Expunerea modulelor COBOL prin server
Orice program COBOL poate fi apelat dintr-un program Java. Pentru acest lucru este
nevoie ca obiectul COBOL să fie compilat cu un compilator ILE ș i tipul programului să fie
CBLLE .
După compilarea cu succes, în fișierul QPCML o să existe un membru cu același nume ca
programul COBOL compilat anterior, dar cu extensia fișierului .PCML. Acest fișier PCML este
42
exportat prin FTP către mediul de programare unde folosind framework-ul JT400, se generează
cod ajutător în apelarea programului COBOL.
Dacă programul COBOL are parametrii descriși în Linkage Section , atunci fișierul PCML
generat conține structura parametrilor în funcție de numele ș i lungimea fiecăruia.
Exemplu PCML :
< pcml version = "4.0" >
<!– COBOL program: SEPA –>
<!– created: 25/05/17 14:55:21 –>
<!– source: LIBRARY/QCBLLESRC(SEPA) –>
< program name = "SEPA" path = "/QSYS.LIB/LIBRARY.LIB/SEPA.PGM" >
< struct name = "PARMCONNECT" usage = "inputoutput" >
< data name = "LANGUAGE" type = "char" length = "1" usage = "inherit" />
< data name = "AGENCE" type = "char" length = "15" usage = "inherit" />
< data name = "DEPART" type = "char" length = "8" usage = "inherit" />
< data name = "USERID" type = "char" length = "10" usage = "inherit" />
</ struct >
< struct name = "PARMINPUT" usage = "inputoutput" >
< data name = "AMOUNT" type = "char" length = "16" usage = "inherit" />
</ struct >
< struct name = "PARMOUTPUT" usage = "inputoutput" >
< data name = "TRANSACTION-NUMBER" type = "char" length = "9" usage = "inherit"
/>
< struct name = "PERRPARAM" usage = "inherit" count = "10" >
< data name = "P-ERR-TYPE" type = "char" length = "1" usage = "inherit" />
< data name = "NUM-ERREUR" type = "char" length = "6" usage = "inherit" />
</ struct >
< data name = "MSG-END" type = "char" length = "100" usage = "inherit" />
< data name = "P-REPONSE" type = "char" length = "1" usage = "inherit" />
</ struct >
</ program >
</ pcml >
Clasele create prin modulul Program Call Bean Wizard generează clase getter ș i setter
pentru fiecare din structurile fișierului PCML.
c. Modulul transfer de fonduri
Modulul transfer de fonduri este expus mediului extern ca Web Service și comunică prin
43
SOAP. Web Service creat primește doi parametrii primul conținând informații necesare
identificării departamentului și al doilea parametru reprezintă datele business necesare
transferului de fonduri. Ambii parametrii sunt fișiere XML.
Informațiile din parametrii sunt validate de schema XSD a fiecărei componente. Dacă
totul este ok, informațiile sunt prelucrate și se pregătesc datele necesare programului logic scris în
COBOL . Datele sunt transmise prin popularea claselor generate cu ajutorul fișierului PCML și a
frameworkului JT400.
d. Pagina web client
Clientul web reprezintă o interfață scrisă în HTML, ce afișează o listă de tranzacții care au
probleme de business precum data operației este în trecut, suma transferată depășește limita
maximă admisă și altele.
Înterfața oferă posibilitatea vizualizării tranzacției sub o formă ușor de în ț eles unei
persoane angajată în bancă specializată pe produsul în cauză. Astfel se pot efectua ușor
modificări în limita permisiunilor astfel încât tranzacția să fie reluată și integrată cu succes.
e. Pagina web testare
Pentru a simula un sistem extern ce apelează serviciul web al modului de transfer de
fonduri, am creat o pagină web, proiect separat, care facilitează testarea.
3. Implementare
a. Utilizare wizard framework JT400
Pentru a genera clasele necesare apelului către un program COBOL, e necesar să se
creeze un proiect prin Wizard Program Call Bean . Acesta se execută deschizând meniul File ->
New -> Other Projects, iar în căsuța de căutare se scrie ‘ Program Call Bean’ .
44
Următorul ecran conține date despre parametrii descriși în fișierul PCML, numele
programului COBOL și librăria unde acesta se află și alte opțiuni. Structura parametrilor este
descrisă sub forma unui arbore în mod ierarhic.
45
Următorul ecran descrie modurile de generare a claselor în funcție de necesități. Astfel se
pot genera doar ‘Java application’ reprezentând simple clase cu tot ce e necesar pentru un apel
simplu de program COBOL . Dacă se dorește extinderea funcționalității atunci putem bifa și
opțiunile ‘Web services’ și ‘Use PCML’ pentru o modularizare mai bună a claselor generate.
Atunci când butonul Finish se apasă, în proiect vor exista următoarele clase și pachete
generate:
src \ defaultPCW .config
src \ com \ exemplu \ generare \ pcml \ SEPA .java
src \ com \ exemplu \ generare \ pcml \ sepa .pcml
src \ com \ exemplu \ generare \ pcml \ SEPAInput .java
src \ com \ exemplu \ generare \ pcml \ SEPAResult .java
src \ com \ exemplu \ generare \ pcml \ SEPAServices .java
src \ com \ exemplu \ generare \ pcml \ sepa \ parmoutput_structures \ PARMOUTPUTPERRPARAM
.j
ava
src \ com \ exemplu \ generare \ pcml \ sepa_structures \ PARMCONNECT .java
src \ com \ exemplu \ generare \ pcml \ sepa_structures \ PARMINPUT .java
src \ com \ exemplu \ generare \ pcml \ sepa_structures \ PARMOUTPUT .java
src \ iseries \ programcall \ base \ AbstractProgramCallBean .java
src \ iseries \ programcall \ base \ AS400Connection .java
src \ iseries \ programcall \ base \ ConnectionFactory .java
src \ iseries \ programcall \ base \ Constants .java
src \ iseries \ programcall \ base \ IConnection .java
46
src \ iseries \ programcall \ base \ IConnectionFactory .java
src \ iseries \ programcall \ base \ JcaAS400Connection .java
src \ iseries \ programcall \ base \ LogonSpec .java
src \ iseries \ programcall \ base \ Messages .java
src \ iseries \ programcall \ base \ Messages .properties
src \ iseries \ programcall \ base \ PooledAS400Connection .java
src \ iseries \ programcall \ base \ RuntimeContext .java
src \ iseries \ programcall \ base \ Util .java
Structura claselor generate:
i. SEPA.java
Această clasă extinde clasa AbstractProgramCallBean și conține referințe către toți
parametrii descriși în parametrii programului COBOL . Aici se crează un RuntimeContext ce
conține informații legate de adresa sistemului mainframe, nume utilizator și parolă necesară
connectării în sistem, librăria programului.
47
După ce se preiau informațiile despre context, se creează o conexiune ce va avea un job în
sistemul AS400, se prelucrează datele parametrilor din fiecare membru al claselor descris în
pachetul com.exemplu.generare.pcml.sepa_structures și
com.exemplu.generare.pcml.parmoutput_structures și apoi programul COBOL este apelat.
Clasa generată conține cod ce prelucrează erorile ce pot apărea după apel. Astfel toate
mesajele rezultate din sistemul AS400 sunt afișate în consolă.
Dacă apelul a fost făcut cu succes, rezultatul este adus în parametri de tip output sau
input-output în funcție de cum sunt descriși în fișierul PCML.
Programatorul poate intervenii și altera structura existentă după bunul plac.
ii. SEPAInput.java
SEPAInput înglobează toți parametrii descriși în PCML ca entități. Pentru fiecare în parte
există setter și getter, dar și o metodă de ajutor ce convertește informațiile existente în parametrii
în format XML. Această clasă este referențiată și creată de programator și reprezintă punctul de
intrare a parametrilor ce urmează să fie transmiși către programul COBOL.
Clasa se poate extinde direct către un Web Service fiind deja serializabilă.
iii. SEPAResult.java
Acestă clasă este asemănătoare clasei SEPAInput.java , care, la rândul ei, are setter și
getter pentru parametrii programului COBOL, dar ea este populată de către clasa generată
SEPA.java după apelul COBOL . Parametrii descriși în această clasă există dacă sunt de tipul
output sau input-output în fișierul PCML.
iv. SEPAServices.java
Clasa aceasta este generată în mod special pentru a fi refolosită în clase Web Service, ce o
vor apela. Parametrul metodei necesită informațiile de intrare înglobate în clasa SEPAInput și
oferă rezultatul sub forma clasei SEPAResult , dar și sub formă de XML.
v. SEPA Structures
Fiecare structură a fișierului PCML va genera o nouă clasă sub forma unei ierarhii până
când se ajunge la structuri de bază de tipul char, number .
48
Astfel în fiecare clasă există getter și setter pentru fiecare parametru în parte în funcție de
tipul de bază string, BigDecimal, integer .
vi. iseries.programcall.base
Clasele generate în acest pachet reprezintă nucleul librăriei și orice generare de programe
prin Wizard Program Call Bean va rezulta în creerea acestui pachet. Astfel acest pachet poate
exista indepedent în alt proiect, fără să influențeze datele specifice claselor ce îl apelează.
b. Pagina de test
Pagina de test a fost creată special pentru a simula un mesaj din exterior către server
prin apel de Web Service. La ini ț ializarea paginii, se vor citi din fișierele de configurare
informațiile legate de adresa server-ului unde se află instalată aplicația ce urmează să fie testată.
Din fișierele de configurare, sunt preluate toate modulele business descrise.
Pagina e compusă din selectarea serviciului ce urmează să fie testat, trei zone mari de text,
primele utilizate drept parametrii, iar al treilea se va completa cu rezultatul apelului.
Utilizatorul selectează produsul ales, completează parametrii apoi apasă butonul Call și
asteaptă raspunsul.
c. Clientul Web
Clientul Web este realizat utilizând tehnologia HTML , jQuery și Boostrap . Pagina web
realizează apeluri către un servlet. Prima pagină o reprezintă pagina de Login precum și
selectarea mediului de lucru, a băncii și a server-ului.
După logare cu succes, utilizatorului îi este afișat un tabel cu tranzac ț iile din sistem ce nu
sunt integrate și necesită acțiune manuală.
Utilizatorul are posibilitatea să aleagă să reîncerce integrarea tranzacției sau să o repare.
Acest lucru se activează prin apăsarea mouse-ului click dreapta pe orice celulă din tabel și va
apărea un meniu contextual. Acest meniu este compus din opțiunile Resubmit, Modify și Delete.
Opțiunea Resubmit va retrimite tranzacția completată anterior în sistem direct către server
și este asemănătoare unei tranzacții din exterior.
Opțiunea Modify va crea o fereastră în pagină cu toate informațiile completate și fiecare
câmp din tranzacția inițială are posibilitatea să fie modificat înainte de a fi trimis către server.
49
Opțiunea Delete va șterge tranzacția din baza de date, din tabelul unde sunt ținute
tranzacțiile ce au nevoie de reparare.
d. Scripturi de configurare
Folosind fi ș iere de tipul Jython , server WebSphere Application Server se poate
configura rulând aceste fi ș iere prin consola dedicată wsadmin . Modelul de administrare a
WebSphere Application Server este bazat pe Java Management Extensions ( JMX ) framework .
Acestă tehnologie îmbină resursele hardware ș i software în Java ș i le expune într-un sistem
distribuit. Serviciile administrative WebSphere con ț in func ț ii care folosesc interfe ț e din JMX ca
să manipuleze configura ț ia server-ului stocate sub forma de XML în fi ș iere aflate pe disk.
WebSphere Application Server oferă următoarele aplica ț ii care ajută la configurarea sa:
● WebSphere administrative console . O aplica ț ie web.
● Comenzi de consolă
● wsadmin – clientul de scripting. Este o linie de comandă în consola
(Command-line interface – CLI) în care scripturile pot fi folosite să
automatizeze configurarea.
● Thin client . O versiune mai mică a modului wsadmin pentru a rula
programe administrative de la distan ț ă.
Programul wsadmin este un client de scripting care se bazează pe CLI. Scopul său este de
a facilita administrarea în detaliu a serverului. Pagina web a consolei de configurare oferă
flexibilitate ș i ajută administratorii mult mai repede. Wsadmin folose ș te Bean Scripting
Frameworework (BSF) ce suportă o varietate de limbaje de scripting printre care: Java Tcl (Jacl)
ș i Jython. WebSphere oferă scripturi de bază ajutătoare scrise în Jython ce se pot folosi direct fără
a include o librărie specifică :
● AdminControl – e folosit atunci când sunt executate comenzi opera ț ionale
● AdminConfig – acest obiect e folosit pentru creare sau modificarea configura ț iei
serverului
● AdminApp – se folose ș te atunci când se execută ac ț iuni pe o aplica ț ie
● AdminTask – e folosit atunci când se execută comenzi administrative
Wsadmin folose ș te Jython versiunea 2.1
50
Capitolul IV – Concluzie
Aplicațiile existente într-un sistem pe AS400 pot evolua către noi servicii și noi
tehnologii. Cel mai ușor mod de a realiza acest lucru este folosind framework JT400. Beneficiile
unui sistem expus către extern deschid oportunități noi, dar, în același timp, reprezintă și o
provocare. Există programe special construite pentru a ușura munca dezvoltatorilor.
Un lucru esențial în proiecte de acest gen îl reprezintă urmărirea paradigmelor de
programare: SOA, Design Pattern, astfel economisindu-se timp în întreținerea codului sursă. Este
imperativ ca orice este dezvoltat să existe salvat într-un sistem de versionare, așa cum este folosit
programul Rational Team Concert .
Scrierea modulară ușurează în viitor schimbarea stratului de comunicare. Acesta poate să
difere în viitor de SOAP și o decuplare de aceste elemente diferite va rezulta în timp câștigat
pentru viitoarea dezvoltare.
Indiferent de specificațiile particulare cerute de anumi ț i clien ț i, se poate aplica cu ușurință
patternul adaptorului.
Testarea modulelor se poate realiza și prin crearea de programe asemănătoare celor care
accesează aplicația. Acest lucru oferă posibilitatea persoanelor non tehnice să testeze modulul
respectiv fără să cunoască detaliile tehnice din spate.
O aplicație matură are un ciclu de viață complet și eficient, dacă după o dezvoltare există
module ce testează automat toată aplicația atât ca testare unitară cât și testare integrală. Sistemul
de build este unul automat și raportează imediat atunci când nu se reușește compilarea.
În funcție de serverul ales, se pot face automatizări și în configurarea sa. WebSphere se
configurează ușor atât de la consola sa web cât și prin fișiere Jython . Acest lucru oferă
posibilitatea instalării de la distanță și managementului de aplicație direct la client. Se
economisește timp cu deplasarea pentru instalare și alte operații de management.
51
Capitolul V – Bibliografie
1. contribuitori Wikipedia, 2017c. IBM Power Systems. Wikipedia, The Free Encyclopedia .
Disponibil la:
https://en.wikipedia.org/w/index.php?title=IBM_Power_Systems&oldid=777827155 [Citat : 20
Mai 2017].
2. contribuitori Wikipedia, 2017b. IBM i. Wikipedia, The Free Encyclopedia . Disponibil la:
https://en.wikipedia.org/w/index.php?title=IBM_i&oldid=799035059 [Citat : 20 Mai 2017].
3. Allen, G., 2008. Beginning DB2 From Novice to Professional , Berkeley, CA: Apress.
4. Autor anonim,2014. IBM developerWorks : Download : Rational Developer for Power
Systems Software. Disponibil la:
https://www.ibm.com/developerworks/downloads/r/rdp/index.html [Citat : 20 Mai 2017].
5. Sadtler, C. et al., 2013. WebSphere Application Server V8.5 Concepts, Planning, and Design
Guide , IBM Redbooks.
6. Keen, M. et al., 2011. Rational Application Developer for WebSphere Software V8
Programming Guide , IBM Redbooks.
7. contribuitori Wikipedia, 2017d. Java (programming language). Wikipedia, The Free
Encyclopedia . Disponibil la:
https://en.wikipedia.org/w/index.php?title=Java_(programming_language)&oldid=798373899
[Citat : 20 Mai 2017].
8. Autor anonim,2015. IBM Toolbox for Java and JTOpen. IBM Corporation . Disponibil la:
https://www-03.ibm.com/systems/power/software/i/toolbox/ [Citat : 20 Mai 2017].
9. Kulkarni, R., 2015. Java EE Development with Eclipse – Second Edition , Packt Publishing.
10. Kurniawan, B., 2016. Servlet & JSP: A Beginner’s Tutorial , Brainy Software Inc.
11. Ghaly, R. & Kothapalli, K., 2002. Sams Teach Yourself EJB in 21 Days , Sams Publishing.
12. Albertoni, F. et al., 2013. WebSphere application server V8. 5 administration and
configuration guide for the full profile , IBM Corporation, International Technical Support
Organization.
13. Autor anonim,Deciding Which Type of Web Service to Use – The Java EE 6 Tutorial.
Disponibil la: http://docs.oracle.com/javaee/6/tutorial/doc/gjbji.html [Citat : 20 Mai 2017a].
52
14. Autor anonim,Lesson: JDBC Introduction (The Java TM Tutorials > JDBC(TM) Database
Access). Disponibil la: https://docs.oracle.com/javase/tutorial/jdbc/overview/ [Citat : 20 Mai
2017c].
15. Coughlan, M., 2014. Beginning COBOL for Programmers , Apress.
16. contribuitori Wikipedia, 2017e. Representational state transfer. Wikipedia, The Free
Encyclopedia . Disponibil la:
https://en.wikipedia.org/w/index.php?title=Representational_state_transfer&oldid=799919103
[Citat : 20 Mai 2017].
17. Autor anonim,The Jython Tutorial — Jython v2.5.2 documentation. Disponibil la:
http://www.jython.org/docs/tutorial/indexprogress.html [Citat : 20 Mai 2017d].
18. contribuitori Wikipedia, 2017f. XML. Wikipedia, The Free Encyclopedia . Disponibil la:
https://en.wikipedia.org/w/index.php?title=XML&oldid=797075197 [Citat : 20 Mai 2017].
19. Autor anonim,What is XSD (XML Schema Definition)? – Definition from WhatIs.com.
SearchMicroservices . Disponibil la:
http://searchmicroservices.techtarget.com/definition/XSD-XML-Schema-Definition [Citat : 20
Mai 2017e].
20. Autor anonim,IBM Knowledge Center. Disponibil la:
https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzahh/pcml.htm [Citat : 20 Mai
2017b].
21.York, R., 2015. Manipulating Content and Attributes. In Web Development with jQuery® .
John Wiley & Sons, Inc, pp. 89–134.
22. contribuitori Wikipedia, 2017a. Bootstrap (front-end framework). Wikipedia, The Free
Encyclopedia . Disponibil la:
https://en.wikipedia.org/w/index.php?title=Bootstrap_(front-end_framework)&oldid=796376578
[Citat : 20 Mai 2017].
23. Saracco, C.M., Chamberlin, D. & Ahuja, R., 2006. DB2 9: pureXML: overview and fast start ,
International Business machines Corporation.
24.Yener, M. & Theedom, A., 2015. Professional Java EE Design Patterns , John Wiley & Sons.
25. Hiebert, D. et al., Building SOA-based Solutions for IBM System i Platform, 2007.07.
53
Capitolul VI – Anexe
1. Diagrama topologică
54
55
56
57
2. Scripturi Jython
a. Instalarea unei aplica ț ii
import sys
def InstallApplication ():
print "======InstallApplication.py.start======="
pathEar = raw_input( "Enter path to EAR file :" )
if (pathEar != "" and pathEar.find( ".ear" ) > -1 ):
newName = raw_input( "Enter name of application:" )
if (newName != "" and len(newName) > 0 ):
apps = AdminApp.list()
listAllApp = AdminUtilities.convertToList(apps)
for app în listAllApp:
found = 0 ;
if (app == newName):
found = 1
break
if (found == 1 ):
print "===Application " + newName + " allready
installed==="
else :
opt = [ "-appname" , newName]
AdminApp.install(pathEar,opt)
AdminConfig.save()
print "Action saved"
result = AdminApp.isAppReady(newName)
while (result == "false" ):
### Wait 5 seconds before checking again
time.sleep( 5 )
result = AdminApp.isAppReady(newName)
print "===Application " + newName + " ready to be started==="
print "======InstallApplication.py.end========="
if __name__ == '__main__' :
InstallApplication()
b. Dezinstalarea unei aplica ț ii
def UninstallApplication ():
58
print "======UninstallApplication.py.start======="
node = AdminControl.getNode()
serverList = AdminTask.listServers( '[-serverType APPLICATION_SERVER
]' )
serverName = AdminConfig.showAttribute(serverList, 'name' )
print "===Current applications installed on this server==="
apps = AdminApp.list()
print AdminUtilities.convertToList(apps)
appName = raw_input( "Enter application name:" )
print "===Uninstall application==="
result = AdminApplication.uninstallApplication(appName)
if (result == 1 ):
print "===Uninstall complete==="
else :
print "===Uninstall incomplet. See error above==="
print "======UninstallApplication.py.end========="
if __name__ == '__main__' :
UninstallApplication()
c. Pornirea unei aplica ț ii
import sys
def StartApplication ():
print "======StartApplication.py.start======="
node = AdminControl.getNode()
cell = AdminControl.getCell()
serverList = AdminTask.listServers( '[-serverType APPLICATION_SERVER
]' )
serverName = AdminConfig.showAttribute(serverList, 'name' )
print "===Current stopped applications installed on this server==="
apps = AdminApp.list()
listAllApp = AdminUtilities.convertToList(apps)
apps = AdminControl.queryNames( 'type=Application,cell=' + cell
+ ',node=' + node + ',process=' + serverName + ',*' ).splitlines()
for app în listAllApp:
found = 0 ;
for runningApp în apps:
aname = AdminControl.getAttribute(runningApp, 'name' )
59
if (app == aname):
found = 1 ;
break
if (found == 0 ):
print app
appName = raw_input( "Enter application name:" )
result =
AdminApplication.startApplicationOnSingleServer(appName,node,serverName)
if (result == 1 ):
print "===Application started==="
# else:
# print "===Application not started==="
print "======StartApplication.py.end========="
if __name__ == '__main__' :
StartApplication()
d. Oprirea unei aplica ț ii
def StopApplication ():
print "======StopApplication.py.start======="
node = AdminControl.getNode()
cell = AdminControl.getCell()
serverList = AdminTask.listServers( '[-serverType APPLICATION_SERVER
]' )
serverName = AdminConfig.showAttribute(serverList, 'name' )
print "===Current running applications installed on this server==="
#print AdminApplication.listApplications()
apps = AdminControl.queryNames( 'type=Application,cell=' + cell
+ ',node=' + node + ',process=' + serverName + ',*' ).splitlines()
for app în apps:
aname = AdminControl.getAttribute(app, 'name' )
print aname
appName = raw_input( "Enter application name:" )
print "===Stopping application==="
result =
AdminApplication.stopApplicationOnSingleServer(appName,node,serverName)
60
if (result == 1 ):
print "===Application stopped==="
else :
print "===Application stil running. See error above==="
print "======StopApplication.py.end========="
if __name__ == '__main__' :
StopApplication()
e. Instalare adaptor
def AdaptorInstall ():
print "===========AdaptorInstall.py.start==========="
inputPath= ""
inputPath = raw_input( "Enter Adapter path:" )
if (inputPath != "" and inputPath.find( ".rar" ) > -1 ):
node = AdminControl.getNode()
print "===Installing the adaptor===="
installResourceAdapter = '[-nodeName ' + node + ' -rarPath "' +
inputPath + '" -rar.archivePath ${CONNECTOR_INSTALL_ROOT}]'
adaptor = AdminTask.installResourceAdapter( '[-nodeName ' + node
+ ' -rarPath "' + inputPath + '" -rar.archivePath
${CONNECTOR_INSTALL_ROOT}]' )
print "===Install completed===="
AdminConfig.save()
print "Action saved" ;
else :
print "You didn't provided a valid path"
print "===========AdaptorInstall.py.end============="
if (__name__ == '__main__' ):
AdaptorInstall()
61
f. Dezinstalare adaptor
def AdaptorUninstall ():
print "===========AdaptorUninstall.py.start==========="
pattern = '*XIBBA*' ;
resourceAdaptor = AdminConfig.list( 'J2CResourceAdapter' , pattern);
if (resourceAdaptor == "" ):
print "===Current list of J2CResourceAdapter on this server==="
print AdminConfig.list( 'J2CResourceAdapter' )
pattern = raw_input( "Adaptor not found please enter a new
pattern: [" + pattern + "]" )
pattern = "*" + pattern + "*"
resourceAdaptor = AdminConfig.list( 'J2CResourceAdapter' ,
pattern);
if (resourceAdaptor == "" ):
print "Adaptor not found"
else :
print "===Uninstall the adaptor==="
AdminConfig.remove(resourceAdaptor)
AdminConfig.save()
print "===Uninstall complet==="
print "===========AdaptorUninstall.py.end============="
if (__name__ == '__main__' ):
AdaptorUninstall()
62
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Dezvoltarea unei aplicații COBOL – JAVA – WEB pe mainframe COORDONATOR ȘTIINȚIFIC LECT [630746] (ID: 630746)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
