Ș. L. Dr. Ing. Mihnea Moisescu [305423]

Universitatea Politehnică București

Facultatea de Automatică și Calculatoare

LUCRARE DE DISERTAȚIE

Metodologie de dezvoltare a unui sistem

de tip ERP utilizând arhitectura SOA

Coordonator științific:

Ș. L. Dr. Ing. Mihnea Moisescu

Masterand: [anonimizat], 2018

1. Introducere

1.1. Scopul și obiectivele lucrării de disertație

Proiectul de disertație prevede prezentarea unei metodologii de dezvoltarea a unui sistem de tip ERP utilizând arhitectura orientată pe servicii (SOA).

Obiectivele specifice ale prezentei lucrări sunt:

Realizarea unui studiu asupra metodologiilor actuale de dezvoltare a [anonimizat], pe baza rezultatelor studiului.

1.2. Justificarea alegerii temei

Companiile din întreaga lume pun accentul pe strategia elaborării și a implementării din cauza unei concurențe sporite, a globalizării și a necesității de fezabilitate și adaptabilitate a mediului de afaceri. Strategia dezvoltării este o sarcină multilaterală bazată pe o serie de factori interdependenți. [anonimizat], rolul sistemelor bazate pe o arhitectură orientată pe serviciu.

Arhitectura orientată pe servicii (SOA) reușește să depăseașcă multe dintre deficiențețe tehnologiilor anterioare de integrare prin adoptarea conceptului de serviciu. Un serviciu este o [anonimizat], care este expusă și disponibilă pentru toate aplicațiile dintr-o întreprindere. Servicii multiple sunt asamblate și reutilizate pentru a crea mai repede aplicații care pot susține mai bine schimbarea proceselor de afaceri. Abordarea SOA pentru sistemele software permite ca un consumator de serviciu să fie decuplat de la furnizorul de servicii. [anonimizat], care permit interoperabilitatea prin funcții decuplate. [anonimizat] o abordare care construiește o arhitectură software de integrare bazată pe servicii.

SOA descrie un set de șabloane pentru a [anonimizat], [anonimizat] o [anonimizat]: performanță, securitate, scalabilitate.

2. Concepte de arhitectură orientate pe servicii (SOA)

2.1. Considerente generale despre arhitectura orientată pe servicii (SOA)

Arhitectura orientată pe servicii (SOA) este definită ca:
• O "paradigmă pentru organizarea și utilizarea capacităților distribuite care pot fi sub diferitelor domenii de proprietate " (OASIS) [2]
• O [anonimizat], care să fie combinate și reutilizate rapid pentru a satisface cerințele afacerii.

Arhitectura orientată pe servicii (SOA) oferă o [anonimizat] (loose coupling) între funcționalitățile modulelor de aplicații. Această conexiune slab cuplată între modulele de aplicație permite detaliile de implementare a unui modul să fie schimbate fără a necesita reproiectarea sau recompilarea altor module. Într-[anonimizat]. Sistemele de implementare urmând paradigma SOA permit integrarea rapidă între diferite aplicații conexe utilizate în cadrul unei organizații (aplicație la cerere), integrarea aplicațiilor utilizate de diferite organizații (de la afaceri la afacere B2B).

SOA minimizează decalajul semantic dintre modelele de proces și codul executabil. Acesta atinge acest obiectiv prin furnizarea unei limbi comune analiștilor de afaceri, arhitecților IT și dezvoltatorilor. În acest context, nu trebuie să uităm importanța reutilizării, care este cheia dezvoltării rapide a noilor soluții și a eforturilor minime de testare (datorită reutilizării artefactelor existente), după cum se arată în figura următoare:

Figura 1. Relația dintre BPM și SOA

2.2. Analiză comparativă SOA vs. abordare tradițională

Pentru a înțelege în continuare abordarea și avantajele diferite oferite de SOA, să analizăm mai întâi modul în care rezultatele tradiționale ale aplicațiilor au o funcționalitate strâns cuplată.

În diagramă, cele patru funcții de afacere sunt încapsulate în întregime în codul aplicației și nu sunt expuse în afara aplicației în sine. Orice interacțiune între procesul de afaceri și fiecare funcție este invocată printr-un apel API intern și orice reutilizare a acestei funcționalități cu alte aplicații conexe ar putea fi obținută numai prin partajarea codurilor prin intermediul bibliotecilor. Aplicațiile noi necesită mai mult timp pentru a dezvolta modificări ale funcțiilor aplicației și pot avea impact direct, afectând binarele aplicației. În urma acestei abordări, orice modificare a implementării funcțiilor afacerii, cum ar fi numărul sau tipul parametrilor, influențează apelurile API încorporate în alte aplicații care accesează codul și care necesită modificarea și recompilarea acestora ceea ce conduce la costuri mai mari de întreținere. [4]

Figura 2. Încapsularea funcțiilor de afaceri în aplicațiile tradiționale

În urma unei abordări SOA, fiecare dintre cele patru funcții de afaceri ale noastre din exemplul anterior ar fi implementat ca un serviciu care este autonom și oferă funcționalitate în propriul său drept, în loc să fie încapsulat sau afiliat la o anumită aplicație. Dat fiind faptul că serviciile sunt create independent de modul în care acestea sunt consumate de aplicații specifice, reutilizarea este mai fundamentală pentru proiectarea lor. Toți clienți utilizează exact aceeași implementare fizică a fiecărui serviciu cuplat slab. Funcționalitatea serviciilor este expusă fiecărei aplicații printr-un contract de servicii bine definit. În loc de invocare directă prin apeluri API care detaliază lista de parametri așteptată, serviciile sunt invocate prin parcurgerea parametrilor ca mesaje XML. Operațiile furnizate de un serviciu și formatul mesajelor XML care furnizează parametrii de intrare și formatul de răspuns așteptat sunt externalizați și publicați sub formă de fișier XML (WSDL). Acest lucru oferă o formă mai relaxată de cuplare la schimbări.

Figura 3. Implementare în SOA

2.3. Ce beneficii oferă arhitectura orientată pe servicii (SOA)?

SOA oferă o mai mare flexibilitate în dezvoltarea, integrarea și gestionarea aplicațiilor, îmbunătățește agilitatea IT a organizațiilor, permițând reutilizarea sau adaptarea rapidă a funcțiilor afacerii existente pentru a implementa sau modifica funcțiile afacerii, oferă flexibilitate mai mare schimbărilor în cerințele afacerii, scurtează timpii de dezvoltare, reduce efortul de întreținere, permite ca aplicațiile să fie integrate într-o manieră slabă cuplată, promovând: integrarea între diferite aplicații conexe din cadrul unei organizații (aplicație la cerere), integrarea între aplicațiile utilizate în cadrul diferitelor organizații de la afaceri la afacere (B2B).

Figura 4. SOA pentru creșterea agilității

Enumerare beneficii SOA:

Reutilizabilitate: funcțiile existente în cadrul unei aplicații sunt reutilizate în cadrul organizațiilor și proceselor de afaceri;

Interoperabilitate: comunicarea între servicii nu depinde de platformă;

Serviciile sunt slab cuplate;

Scalabilitate: aplicațiile sunt flexibile la schimbarea cerințelor afacerii;

Eficiența costurilor: costurile sunt reduse și livrarea de noi funcționalități este accelerată deoarece resursele existente sunt reutilizabile și integrarea resurselor de afaceri se bazează pe standard.

2.4. Arhitectura componentei de serviciu (SCA)

Arhitectura componentei de serviciu este un set de specificații care descriu un model pentru construirea de aplicații, utilizând o arhitectură orientată spre servicii. Serviciile sunt asamblate pentru a forma o aplicație compusă care creează o soluție ce răspunde la cerințele specifice ale unei afaceri. Aplicațiile compuse pot conține servicii noi (specifice pentru aplicație) și funcțiile de afaceri din sistemele și aplicațiile existente (reutilizare în compozită). SCA oferă un model atât pentru compunerea serviciilor, cât și pentru crearea de componente de serviciu, inclusiv reutilizarea celor existente. Atunci când sunt asamblate într-o aplicație compusă, acestea sunt gestionate, întreținute și lansate împreună. Acest lucru simplifică gestionarea componentelor de servicii cooperante în comparație cu tehnologiile anterioare care au gestionat aplicațiile SOA ca un set de servicii individuale. [7]

Figura 5. Arhitectura componentelor de serviciu (SCA)

2.5. De ce sunt standardele importante în SOA?

Serviciile sunt funcții de afaceri care formează baza pentru utilizarea unei abordări SOA pentru a crea aplicații. Pentru a reutiliza serviciile (un obiectiv fundamental al SOA), serviciul trebuie să fie descris prin utilizarea interfeței standard și a structurilor de mesaje.Abordările bazate pe SOA, firește, au îmbrățișat multe dintre standardele mesajelor ilustrate în figura 6, inclusiv XML, XSD și SOAP.

Aceste structuri de documente sunt ușor de schimbat utilizând protocoalele standard de Internet, cum ar fi HTTP. Acest lucru este mai ușor, interoperabilitate între rețelele intranet și Internet.Standardele de descoperire și descriere, cum ar fi WSDL și UDDI, contribuie la reutilizarea serviciilor și ajută la obținerea independenței hardware-ului, sistemelor de operare și limbajelor de implementare.

După cum sugerează și numele acestora, standardele WS-Security și WS-Reliable Messaging descriu standardele pentru livrarea sigură și sigură a mesajelor în cadrul aplicațiilor bazate pe servicii. BPEL oferă o gramatică XML pentru a descrie un proces de afaceri ca o serie de activități.

Specificațiile de arhitectură a componentelor de service (SCA) și a obiectelor de date de serviciu (SDO) sunt lucrări în curs, ghidate de organizația OASIS. Aceste lucrări pot conduce la o nouă colecție de standarde cu o abordare bazată pe SOA.

Figura 6. Standarde SOA [8]

3. Noțiunea serviciu. Comunicarea, interacțiunea dintre servicii.

3.1. Ce sunt serviciile și cum sunt utilizate în arhitectura orientată pe servicii (SOA)

Un serviciu este o bucată de funcționalitate de afaceri autonomă. Funcționalitatea ar putea fi la fel de simplă ca și stocarea datelor despre clienți sau la fel de complexă ca un proces de afaceri pentru comanda unui client. Serviciile se concentrează asupra valorii afacerii unei interfețe. Serviciile interacționează prin schimbul de mesaje cu alți clienți și alte servicii. În Oracle SOA Suite 12c, serviciile descriu interfața lor utilizând WSDL (Web Service Definition Language) care specifică următoarele:

Operații care pot fi executate;

Structuri de mesaje pentru comunicarea datelor necesare pentru fiecare operație. Structurile de mesaje se bazează pe tipurile exprimate într-un Document XML Schema (XSD).

Independența este un aspect fundamental al serviciilor și SOA în ansamblu. Combinarea liberă inerentă unei implementări a serviciului eliberează un serviciu de legături imediate cu un alt serviciu. Acest lucru face mult mai ușor să se realizeze reutilizarea. În plus, atunci când există mai puține dependențe, modificarea sau defecțiunile unui sistem vor avea mai puține efecte asupra altor sisteme. Abordările SOA nu necesită servicii web și, prin urmare, WSDL nu este o cerință pentru toate implementările SOA. Cu toate acestea, implementările Oracle SOA Suite 12c utilizează WDSL pentru toate definițiile interfeței de servicii. Serviciile reprezintă elementele de bază ale sistemelor SOA. Detaliile de implementare a serviciului sunt mascate în întregime de consumatorul de servicii. [3]

Un serviciu implementează o sarcină bine înțeleasă care are un contract clar și bine definit între consumator și furnizor. Atunci când lucrăm cu servicii, ne concentrăm asupra intrării, serviciilor oferite și rezultatelor – ne putem permite să tratăm detaliile implementării ca pe o cutie neagră. De exemplu, atunci când folosim un serviciu de spălătorie, ne concentrăm pe furnizarea de haine murdare, primirea unui serviciu de spălare și obținerea de haine curate. Atâta timp cât rezultatele răspund așteptărilor, nu trebuie să ne preocupe modul în care a fost implementat serviciul.

Ciclul de viață al serviciului permite agilitatea IT, în timp ce ciclul de viață al procesului permite agilitatea afacerii. Următoarea figură 7. arată modul în care ciclurile de viață ale procesului și ale serviciului se potrivesc și cum interconectează.

.

Figura 7. Procesul și ciclul de viață al serviciului

Serviciile permit ca funcționalitatea afacerii să fie implementată ca un set de servicii granulare discrete și autonome, care:

efectuarea unei sarcini bine definită descrie parametrii și rezultatele folosind metadate (fișiere WSDL), astfel încât acestea să poată fi utilizate de alte servicii;

să furnizeze unități de funcționalitate care nu au apeluri directe sau asociații cu alte servicii pentru a asigura reutilizarea;

schimbul de informații între furnizorul de servicii și consumatorul de servicii este prin intermediul mesageriei

formatul mesajului (definirea intrărilor și ieșirilor) este definit folosind XML;

formatul mesajului este publicat ca fișier WSDL (de exemplu, UDDI Repository) și disponibil ca contract pe care un client îl poate urma pentru a consuma serviciul;

ușor de consumat de diverse instrumente de dezvoltare pentru a genera codul pentru crearea mesajelor și transportul între consumatorul de servicii și furnizorul;

pot fi combinate pentru a defini unitățile de nivel superior de funcționalitate care sunt apoi consumabile ca servicii în sine.

Noi servicii pot fi create prin asamblarea unuia sau a mai multor servicii pentru implementarea unei funcționalități de nivel superior, care la rândul său poate fi combinată cu alte servicii (în urma unui model recursiv sau ierarhic).

3.2. Protocoale și tehnologii de bază pentru Servicii Web

Serviciul este publicat în catalog (registru);

Figura 8. Utilizarea serviciului

Clientul obține interfața publică a serviciului, invoca operația și primește rezultatul.

XML (Extensible Markup Language) – limbaj generic care poate fi utilizat pentru a reprezenta orice tip de conținut într-un mod structurat – conținutul este separat de modul de prezentare;

SOAP (Simple Object Access Protocol) – protocol prin care un client poate invoca operații ale unui serviciu aflat la distanță, independent de platform, de caracteristicile rețelei și de limbajele de programare, mesajele transmise sunt în format XML;

WSDL (Web Services Description Language) – limbaj bazat pe XML, pentru descrierea interfeței oferite de un anumit serviciu, descrierea WSDL este publicată de furnizorul de servicii pentru a specifica operațiile oferite și parametrii acestora, WSDL este utilizat pentru a descrie modul de acces al serviciului;

UDDI (Universal Description, Discovery and Integration) – protocol utilizat pentru a obține informatii despre servicii web și furnizorii acestora.

3.3. Orchestrarea serviciilor

Pentru a implementa sarcinile de afaceri mai complexe, serviciile individuale fine sunt compuse sau orchestrate în secvențe mai puterniceorchestrarea este definită în XML, urmând un standard stabilit în limba BPEL (Business Process Execution Language) permite programatorului:

să definească ce servicii să invocăm și ordinea în care ar trebui executate;

identificarea elementelor de date care urmează să fie transmise ca intrări la fiecare invocare a serviciului;

furnizare logică condițională bazată pe valorile returnate de apelurile de servicii.

Pe lângă orchestrarea unui număr de servicii, fiecare orchestrație de servicii în sine:

îndeplinește o sarcină bine definită;

descrie parametrii de intrare și rezultatele utilizând metadatele;

oferă un serviciu în propriul său drept care poate fi reutilizat în cadrul unor orchestrații suplimentare de servicii, definind nivele mai ridicate de funcționalitate.

3.4. Comunicarea dintre servicii

Definim un serviciu ca software, care este disponibil pe Internet sau într-o rețea și care expune funcționalitatea ca una sau mai multe operațiuni sau acțiuni către alte aplicații. Serviciul și apelul la mesajele schimbate între aplicații. Deși există mai multe modele de interacțiune diferite, într-un scenariu comun, aplicația apelantă invocă serviciul și, ca parte a acestei invocări, furnizează date de intrare. Apoi, serviciul își completează unitatea de lucru și returnează datele sau dacă nu este capabil să finalizeze operațiunea solicitată, pot fi returnate informații despre eșec. Pentru ca aplicația de apelare să schimbe mesajele cu serviciul, trebuie să se definească un mijloc pentru ca aplicația să furnizeze informațiile solicitate într-un format acceptabil, iar aplicația să interpreteze mesajul de ieșire (sau eroare) furnizat de serviciu. Deși nu este o cerință strictă, XML este utilizat în mod obișnuit pentru aceste mesaje de intrare, ieșire și mesaje de eroare, iar pentru a descrie structura acestor mesaje XML este utilizată o definiție a schemei XML (XSD).

Figura 9. Comunicarea dintre servicii

Mediatorii sprijină atât interacțiunile sincrone (cerere-răspuns), cât și cele asincrone (atât într-un singur fel, cât și în cel de apel invers). Într-o interacțiune sincronă, clientul solicită un serviciu și apoi așteaptă un răspuns la solicitare. În timp ce clientul așteaptă, canalul de comunicare dintre părți este lăsat deschis până când apare răspunsul. Acest lucru poate fi nedorit dacă numărul mare de canale este lăsat deschis pentru perioade lungi de timp. Este posibil să nu fie necesar dacă clientul nu are nevoie de un răspuns imediat. În aceste cazuri, un răspuns asincron poate fi mai adecvat. Într-o interacțiune asincronă, clientul invocă serviciul, dar nu așteaptă un răspuns înainte de a continua. Operațiile asincrone deschid un canal de comunicare între părți, fac cererea și închid canalul înainte ca răspunsul să apară. Răspunsul poate apărea ulterior printr-o operațiune de apel invers, sau deloc pentru interacțiuni într-un singur sens.

3.5. Tipuri de interacțiuni. Modele cerere-răspuns

Modelele cerere-răspuns facilitează comunicarea dintre componentele procesului BPEL.

1.Interacțiune realizată printr-un mesaj trimis într-un singur sens. Modelul este reprezentat în figura 10.

Figura 10. Model mesaj într-un singur sens

Modelul de couminicare pentru interacțiunea mesajului unic implică:

un consumator de servicii: clientul care invocă serviciul și furnizează mesajul de intrare;

un furnizor de serviciu: serviciul care acceptă un mesaj de intrare de la clientul de serviciu, și oferă

un răspuns (mesaj de ieșire).

Implementarea SOA pentru acest tip de mesaj este prezentată în diagrama x. Sunt reliefate două tipuri de implementări ale acestui model, cum ar fi:

componentă Mediator cu o regulă de rutare la un serviciu;

componentă BPEL la un serviciu;

serviciul care consumă mesajul poate fi, de asemenea, o altă componentă SOA, descris în

exemplul BPEL-BPEL, care conține următoarea implementare: Clientul BPEL execută o activitate de invocare (Invoke) pentru a executa o operație cu sens unic expusă de Partner Link, serviciul BPEL acceptă mesajul de intrare utilizând o activitate de primire (Receive) și nu utilizează o activitate de răspuns deoarece nu este furnizat sau așteptat niciun răspuns. WSDL nu definește un mesaj de ieșire pentru operație.

Figura 11. Implementarea SOA pentru mesajul într-un singur sens

2.Interacțiune sincronă

Figura 12. Model mesaj sincron

Într-o interacțiune sincronă, un client trimite o cerere către un serviciu și primește un răspuns imediat sau un mesaj de eroare. Figura x. prezintă două diagrame ale unei interacțiuni sincrone între două componente SOA. Prima componentă Mediator cu un serviciu de proces BPEL, clientul conține o rutare sincronă pentru a trimite cererea către serviciu BPEL și pentru a primi răspuns sau mesaj de eroare. Serviciul BPEL conține o activitate Receive pentru a obține mesajul de solicitare și, după o anumită prelucrare, returnează un răspuns utilizând activitatea Reply. A doua componentă BPEL conține activitatea Invoke pentru a gestiona cererea de solicitare-răspuns.

Figura 13. Implementarea SOA pentru mesajul sincron

3.Interacțiunea asincronă

Figura 14. Model mesaj asincron

Într-o interacțiune asincronă, un client trimite o solicitare către un serviciu și așteaptă răspunsul serviciului. În figura x, se pot vedea două diagrame ale unei interacțiuni asincrone între două componente SOA. Serviciul BPEL conține o activitate Receive pentru a obține mesajul de solicitare și apoi după o anumită prelucrare, returnează un răspuns utilizând un apel Invoke.

Figura 15. Implementarea SOA pentru mesajul asincron

4. O cerere, un răspuns obligatoriu și un răspuns opțional

Figura 16. Model mesaj cerere, un răspuns obligatoriu și un răspuns opțional

În acest tip de interacțiune, clientul trimite o singură solicitare unui serviciu și primește unul sau două răspunsuri. În exemplu, cererea este de a comanda un produs online. În cazul în care produsul este întârziat, se va trimite notificare. Pentru implementare este nevoie de o activitate Scope care conține activitatea Invoke pentru a trimite solicitarea și o activitate Receive pentru a accepta răspunsul obligatoriu. Managerul de mesaje din activitatea Scope (onMessage A) este setat să accepte mesajul opțional și instrucțiuni despre ce trebuie realizat în cazul în care mesajul opțional este primit (spre exemplu, produsul este întârziat). Dacă răspunsul obligatoriu este primit primul, atunci nu se așteaptă răspunsul opțional. Ca și în cazul tuturor activităților partenere, fișierul WSDL definește interacțiunea. Serviciul BPEL are nevoie de o activitate Scope care să conțină activitatea Receive și activitatea Invoke pentru a trimite mesajul de expediere obligatoriu și o activitate de comutare Switch pentru a trimite mesajul întârziat opțional dacă un temporizator expiră (trimite mesaj dacă articolul nu este expediat în 24h).

Figura 17. Implementare SOA mesaj cerere, un răspuns obligatoriu și un răspuns opțional

3.6. Descrierea unui mesaj cu XSD

XSD înseamnă definirea schemei XML. După cum sugerează și numele, un XSD este folosit pentru a descrie (sau a definii) structura (sau schema) unui mesaj XML. De fapt, un XSD utilizează un format XML pentru a furniza acea descriere. Documentele XML sunt descrise în termeni de elemente componente sau elemente. O definiție a schemei XML este utilizată pentru a defini aceste elemente. Poate fi folosit pentru a defini secvența, atributele lor, relația lor (părinte / copil), numărul permis de evenimente, tipurile de date și valorile implicite sau fixe, dacă există. Tipurile de date încorporate (o listă a exemplelor utilizate în mod obișnuit ar include integer, double, Boolean, data și șir, printre altele) simplifică descrierea conținutului permis de documente și a formatelor de date în schemele XML. XSD suportă, de asemenea, tipuri complexe care descriu elementele care sunt alcătuite din alte elemente. Ca și alte documente XML, exemplul din figură include o definiție a spațiului de nume. Definițiile spațiilor de nume sunt folosite în XML pentru a permite programelor să se dezambiguie printre elementele de document care pot avea același nume, dar sunt extrase din diferite surse și au astfel semnificații diferite. Elementele următoare din document încep cu prefixul spațiului lor de nume.

3.7. Documentul Web Service Description Language (WSDL)

Descrierea structurii mesajelor care trebuie schimbate între o aplicație de apelare și un serviciu este importantă, dar nu este suficientă pentru a permite conversațiilor aplicațiilor. Pentru aceasta, este utilizat un document de descriere a serviciului Web sau un document WSDL. Această descriere (XML) include formatul mesajelor de intrare, de ieșire și de eroare și tipurile de date pe care le utilizează. Acesta include, de asemenea, numele operațiunilor pe care le oferă serviciul și cum și unde să găsească serviciul. Informațiile dintr-un singur document WSDL sunt organizate în două părți: definiția abstractă (ceea ce face un serviciu web) și definiția concretă (cum și unde să accesați serviciul).

Figura 18. Structura documentului WSDL

Definițiile definitive includ tipurile, mesajul, funcționarea și tipul portului.Tipurile definesc tipurile de date utilizate în mesaje. Aceste tipuri sunt deseori extrase din limba XML Schema Language. Mesajele descriu părțile mesajelor de intrare, ieșire și de eroare care sunt schimbate cu programul de apelare. Operațiile oferă un nume pentru acțiunea efectuată pe mesaje. Tipurile de mesaje PortTypes cu operațiuni.

Documentele WSDL generate de JDeveloper pentru serviciile locale (cele din cadrul serverului WebLogic) pot să nu includă partea concretă a WSDL. Cu toate acestea, documentele WSDL pentru serviciile implementate în afara serverului WebLogic includ elementele concrete ale WSDL, care furnizează informații suplimentare despre cum și unde să acceseze serviciul:

Legarea descrie modul în care este transmisă o anumită operație portType, cum ar fi HTTP sau SOAP (adică protocolul) și informații despre locul în care se află serviciul;

Portul specifică o combinație a unei adrese de rețea și a unei legături, care constituie un punct final;

Un serviciu grupează porturile împreună. Un serviciu dezvăluie unui program de apelare unde să acceseze serviciul web și prin ce port. De asemenea, descrie modul în care sunt definite mesajele de comunicare.

4. Avantajele adoptării unei arhitecturi orientată pe serviciu (SOA). Studiu de caz

4.1. Studiu de caz companie fictivă. Procedura de retur a bunurilor

Compania MO1 a introdus politica de returnare a bunurilor de la clienții lor. Această operațiune este denumită în general manipularea returului, mărfurilor, inventarul învers. Compania MO1 lansează cataloage tipărite și acceptă comenzi prin apeluri telefononice. Clienții restituie aproximativ 15% din bunurile vândute. Aproximativ 20% din spațiul de depozitare este dedicat procesării returnărilor.

Operațiunea curentă în afaceri: produsele pot fi returnate în termen de 30 de zile de la livrare. Dacă, din orice motiv, un client nu este mulțumit de un produs, tot ce trebuie să facă este să sune la linia de asistență pentru clienți. Dacă nemulțumirea rezultă din cauza unei probleme tehnice, suportul pentru clienți face tot posibilul pentru a rezolva. În cazul în care clientul confirmă decizia de returnare, reprezentantul serviciului de relații cu clienții înregistrează motivul returnării și oferă clientului o adresă de retur. Toate returnările sunt trimise la depozit. Când un pachet sosește, un membru al personalului localizează jurnalul centrului de apeluri pentru a afla care sunt motivele pentru care produsul este returnat. Un manager de proces de afaceri sau un analist va modela în mod tipic procesul de afaceri în acest mod folosind notații grafice.

4.2. Identificarea problemelor

În ansamblu, MO1 trebuie să reducă costurile de manipulare a returnării și să minimizeze erorile. În mod specific, în operațiunea curentă există următoarele probleme:

Când se primește un pachet returnat, este nevoie de un membru al personalului pentru câteva minute pentru a găsi detaliile comenzii și jurnalul centrului de apeluri. Personalul încearcă să găsească informațiile prin căutarea numelui și adresei clientului.

Membrii personalului trebuie să introducă manual aceleași date în mai multe sisteme. Aceste sisteme includ centru de primiri apeluri telefonice, sistemul managementului de depozit, site-ul web al producătorului, site-ul operatorului de transport maritim și sistemul contabil. Acest lucru încetinește operația și introduce erori.

Unele dintre elementele defecte sunt trimise înapoi producătorului. Personalul angajat a făcut greșeli atunci când pregătea pachetul pentru expedierea către producător. Eticheta de expediere a fost tipărită cu adresa producătorului greșit.

În prezent, membrii personalului se conectează la sistemul contabil și inițiază rambursarea către client. Acest lucru a condus la erori și, în unele cazuri, la practici incorecte.

Îmbunătățirea oportunităților

MO1 a identificat mai multe domenii de îmbunătățire: Se crede, în general, că anumite produse au o rată de rentabilitate mai mare. Acest lucru poate avea legătură cu modul în care produsul este reprezentat pe site-ul Web sau în catalogul tipărit. MO1 ar dori să știe care produse au o rată de returnare ridicată, astfel încât să se poată face schimbări adecvate descrierii și fotografiei produsului. Pentru unele dintre elementele mai ieftine, procesarea costurilor de returnare este mai mare decât elementul însuși. În aceste cazuri, elementele ar putea fi pur și simplu eliminate. Întoarcerea la prelucrare poate fi sporită considerabil printr-un flux de lucru mai bine proiectat și printr-un proces mai eficient de sortare. Principalul domeniu de interes va fi integrarea între diferite sisteme, ceea ce va elimina necesitatea introducerii de date duplicat.

Figura 19. Diagrama retur produs

4.3. Cum poate ajuta SOA?

Poate SOA ajuta într-adevăr MO1 să elaboreze o soluție?

SOA are o viziune mult mai completă asupra problemei de afaceri decât abordările tradiționale, cum ar fi analiza și proiectarea orientată pe obiecte (OOAD). SOA încearcă să rezolve o problemă utilizând o combinație de angajați, resurse precum aplicații software, mașini, fabrici și parteneri de afaceri. Într-un sens, SOA nu poate fi prezentată doar ca o metodologie de dezvoltare software. Este o abordare generală de rezolvare a problemelor. Aceasta implică întreaga afacere în construirea unei soluții. Acum, să aruncăm o privire la modul în care urmează abordarea SOA pentru a rezolva aceste probleme. În primul rând, SOA necesită o analiză atentă a procesului de afaceri. În cazul MO1, procesul actual de manipulare a retururilor este foarte ineficient și este predispus la multe erori. Prin realizarea managementului proceselor de afaceri (BPM), vom putea îmbunătăți procesul destul de puțin. După ce MO1 a redesenat procesul de afaceri, s-au făcut următoarele îmbunătățiri:

În pachetele expediate clienților, includeți o etichetă care ar trebui utilizată ca adresă de retur. Acest lucru face viața clienților mai ușoară. Mai important, eticheta conține un cod de bare care identifică comanda. Când pachetul returnat este primit la depozit, personalul va scana codul de bare. Nu mai este nevoie să căutați comanda folosind numele și adresa clientului.

Odată scanat codul de bare, sistemul ar trebui să afișeze automat jurnalul centrului de apeluri pentru comandă. Membrul angajatului nu trebuie să se conecteze la aplicația de call center și să caute comanda.

Personalul introduce motivul returuluii într-o bază de date. Acesta este ulterior analizat pentru a identifica probleme cum ar fi erori în site-ul web.

Fluxul de lucru ar trebui să contacteze automat software-ul contabil și să inițieze rambursarea.

Dacă produsul este defect și producătorul acceptă returnări, sistemul ar trebui să trimită automat o factură fabricantului și să imprime eticheta de transport corectă. Toți membrii personalului trebuie să facă acest lucru, făcând clic pe acea etichetă pe pachet și mutându-l în secțiunea de transport a depozitului. Dacă pachetul a fost deteriorat în timpul expedierii, sistemul ar trebui să dețină o reclamație automată cu transportatorul de marfă.

În SOA, procesul de afaceri în sine se execută ca software. Acesta poate automatiza mai multe sarcini, de exemplu, afișarea jurnalului centrului de apeluri și inițierea unei rambursări cu sistemul contabil. Angajații nu trebuie să se conecteze la toate tipurile de aplicații software și să introducă manual datele.

Apoi, SOA solicită identificarea oficială a jucătorilor în proces. Acestea se numesc furnizori de servicii sau pur și simplu servicii. În procesul de gestionare a returnării, serviciile sunt angajații, site-ul Web, aplicația de call center, sistemul contabil, producătorul și transportatorul de transport.

Fiecare serviciu efectuează un set de sarcini. De exemplu, sistemul contabil poate fi solicitat să restituie cardul de credit utilizat pentru o comandă. Transportatorului maritim i se poate cere să accepte o cerere de asigurare pentru mărfurile deteriorate. Membrii personalului acceptă pachetele returnate, fac atingeri și se reambală. De asemenea, plasează obiectele în stare bună înapoi pe raft. Figura 20. prezintă o listă de servicii în procesul de gestionare a returnării și sarcinile pe care le efectuează. Odată ce serviciile sunt identificate, rolurile și responsabilitățile lor devin foarte clare. SOA vă cere acum să căutați modalități de automatizare a sarcinilor. Activitatea automată a sarcinilor poate reduce semnificativ eroarea și costurile.

Dacă un furnizor de servicii este un software, cum ar fi sistemul contabil, este relativ ușor să automatizezi sarcinile. În esență, o sarcină este automatizată prin dezvoltarea software-ului pentru serviciul care efectuează această sarcină.

Exemple de servicii identificate din procesul de gestionare a returnării. Fiecare serviciu afișează un set de operațiuni pe care este capabil să le efectueze

Figura 20. Exemple de servicii

Dacă furnizorul de servicii este o ființă umană, trebuie să căutăm modalități de utilizare a software-ului pentru a automatiza sarcina. De exemplu, am putea lansa automat sistemul de apel call center și trageți jurnalul de apeluri și istoricul comenzilor înainte ca un angajat să înceapă procesarea unui return. Nu toate sarcinile umane pot fi automatizate. SOA și BPM recunosc această realitate și sprijină și serviciile bazate pe om. Transportatorul maritim și producătorii sunt organizații externe. Aceștia pot sau nu pot oferi servicii software pentru automatizarea sarcinilor. În caz contrar, trebuie să luați în considerare utilizarea acestora în loc să utilizați site-urile web, telefonul sau faxul pentru a le cere să îndeplinească aceste sarcini. De exemplu, dacă transportatorul de marfă oferă un serviciu Web pentru a defini o cerere de asigurare, ar trebui să luăm în considerare utilizarea acesteia. Odată ce toate serviciile sunt implementate (fie prin utilizarea software-ului, fie prin atribuirea sarcinilor relevante membrilor personalului), putem dezvolta orchestrarea.

Orchestrația este un program software care controlează succesiunea sarcinilor într-un proces. Fiecare sarcină este efectuată de un serviciu. Prin orchestrare, ființele umane nu mai gestionează fluxul de activități într-o afacere. De exemplu, dacă un produs a fost returnat deoarece a fost deteriorat în timpul expedierii, orchestrarea va solicita automat serviciului de transport maritim să formuleze o cerere.

Orchestrația cunoaște contextul, care este ordinea inițială plasată de client. În consecință, acesta poate prelua automat toate informațiile solicitate de operatorul de transport maritim, cum ar fi numărul de scrisoare de transport și numărul contului. Figura x. arată cum arată o orchestrație. De obicei, dezvoltatorii de software iau modelul procesului de afaceri creat de manageri sau analiști și convertirea lor în orchestrație. Orchestrarea folosește activitatea Invoke pentru a cere unui serviciu să îndeplinească o sarcină specifică. MO1 dorește să înțeleagă mai bine procesul de procesare a returnării. Pentru a ajuta la aceasta, putem defini indicatori cheie de performanță (KPI) pentru orchestrație. Pentru MO1, KPI relevante sunt:

Distribuția procentuală a motivului pentru returnare.

Produsele de top care se întorc pentru că nu satisfac așteptările clienților cu privire la calitate sau nu răspund nevoilor lor.

Cât timp durează sfârșitul la sfârșit de la primirea unui pachet returnat până la momentul procesării complete. Acest lucru va da o idee despre cât de bine funcționează procesul.

Figura 21. Un fragment din orchestrarea de manipulare a retururilor

Soluție Rezumat

Acest lucru completează proiectul nostru fictiv în care urmăm abordarea SOA pentru rezolvarea problemelor MO1. După cum puteți vedea, SOA nu este o tehnologie, ci o mentalitate pentru proiectarea unei soluții. Ceea ce urmează este un rezumat al ceea ce am făcut:

Am folosit BPM pentru a examina procesul curent de afaceri. Am gasit mai multe moduri de a face acest lucru mai greu si mai rapid.Am identificat rolurile și responsabilitățile fiecărui furnizor de servicii. Apoi am căutat metode de automatizare a sarcinilor. Am făcut acest lucru dezvoltând servicii. Activarea automată a tastelor poate accelera funcționarea și reduce erorile. Am dezvoltat o orchestrație. Aceasta va supraveghea succesiunea sarcinilor. Orchestrarea are un avantaj dublu. Ajută la automatizare. De asemenea, poate capta date statistice cheie cunoscute sub numele de KPI (indicatorii cheie de performanță), care ne ajută să înțelegem mai bine afacerea și să îmbunătățim operațiunile sale.

5. Elementele unei aplicații composite

5.1. Ce sunt serviciile compozite?

O compozită SOA proiectată și implementată împreună într-o singură aplicație. Cablarea între un serviciu, o componentă de serviciu și o referință permite comunicarea mesajelor. Compozita procesează informațiile descrise în mesaje. Graficul din figura 22. oferă un exemplu de compozită care include un serviciu expus (1), o varietate de componente de servicii (2) care interacționează și mai multe referințe externe (3).

Figura 22. Exemplu de compozită

1.Serviciile oferă un client compozit cu un punct de intrare la aplicația compusă SOA. Serviciul își face publice capabilitățile (cunoscute și ca operațiuni) pentru aplicațiile externe cu un fișier WSDL. Legarea serviciului descrie protocoalele care pot comunica cu aplicația. Exemplele includ SOAP / HTTP sau un adaptor JCA.

2.Componentele de servicii reprezintă componentele unei aplicații compuse SOA.
3.Referințele permit transmiterea mesajelor din aplicația compusă SOA către servicii care sunt exterioare compozitei.

Figura 23. Reliefarea unui serviciu cu un nivel mai ridicat de funcționalitate

5.2. Regulile de afaceri (Oracle Business Rules)

Politicile privind regulile de afaceri, constrângerile, calculele și raționamentul, în timp ce se separă logica regulilor de codul aplicației de bază. Regulile de afaceri implementează condițiile ca structuri IF-THEN sau ca tabele de decizie. Aceste condiții pot fi editate de un analist de afaceri pentru a actualiza politici și valori de calcul cu puțin sau deloc asistență de la un programator.

Exemple pentru utilizarea regulilor de afaceri includ:

Procesarea dinamică: Regulile pot determina căi inteligente de rutare în cadrul unui process de afaceri bazat pe acorduri la nivel de serviciu sau alte orientări;

Validarea datelor și controalele de constrângere: Regulile pot valida documentele de intrare sau se pot aplica constrângeri suplimentare asupra cererilor;

Redirecționarea sarcinilor umane: Regulile pot fi utilizate pentru a efectua asignări de sarcini bazate pe politici pentru a trimite sarcini către anumite roluri sau utilizatori sau pentru a echilibra sarcini între utilizatori pentru a controla sarcina asignării sarcinilor.

Figura 24. Exemplu regulă de afaceri

Codul nu este ușor pentru cititorii non-tehnici și este adesea dificil de înțeles și de modificat. Companiile își schimbă frecvent politicile, ceea ce, în multe medii de producție, duce dezvoltatorului la modificarea aplicațiilor afectate și la recompilarea și redistribuirea acestora. În funcție de politica companiei, există mai multe procese riguroase implicate înainte ca schimbările să poată fi introduse în sistemele de producție. Utilizând regulile Oracle Business Rules, procesul de modificare a regulilor și politicilor de afaceri poate fi simplificat, deoarece separarea regulilor de afaceri de aplicație permite utilizatorilor de afaceri să schimbe cu ușurință regulile de afaceri fără implicațiile ciclului de viață al dezvoltării software-ului. Regulile Oracle Business permit unui analist de afaceri să schimbe politicile care sunt exprimate ca reguli de afaceri, cu puțin sau deloc asistență de la un programator.

5.3. Business Process Execution Language (BPEL)

5.3.1. Procese de afaceri și BPEL

Multiple servicii pot fi încorporate într-un proces de afaceri prin utilizarea Business Process Execution Language. Specificația BPEL definește gramatica XML care oferă servicii, manipulează datele și aruncă defecțiuni. Serviciile multiple sunt orchestrate de un motor BPEL utilizând fișierele BPEL, WSDL și XSD. Termenul de orchestrare înseamnă a coordona fluxul de informații către și de la clienți și între serviciile invocate de procesul BPEL pentru a implementa în întregime sau parțial procesul de afaceri. Motorul creează reprezentări ale procesului (instanțe ale procesului) într-un server de aplicații (cum ar fi WebLogic Server). În Oracle SOA Suite 12c, un proces BPEL este o componentă a unei aplicații compuse SOA, care primește și returnează date prin punctele de acces la servicii. Punctele de intrare a serviciului pot fi onectate la o componentă a procesului BPEL, care procesează datele și interacționează cu referințele externe (servicii externe) ale aplicației compuse. Când se recepționează un mesaj, motorul BEP creează o nouă instanță de proces și o pornește. Motorul este responsabil de executarea logicii de afaceri specificate in procesul BPEL.

Figura 25. Motorul BPEL

5.3.2. Elemente ale procesului BPEL: Partner Links, Activități

Elementele cheie ale unui proces BPEL sunt:

interfață de serviciu, care este WSDL care descrie funcționarea procesului BPEL și cererea asociată și structurile opționale de răspuns. Un proces BPEL poate fi expus ca un serviciu pentru o aplicație compusă. Interfața de servicii oferă clientului BPEL o modalitate de a interacționa cu componenta procesului BPEL.

Activități, care sunt elementele XML actuale care alcătuiesc fluxul procesului BPEL sau secvența de instrucțiuni care trebuie executate. Aceasta implică, de obicei, invocarea altor servicii pentru a îndeplini funcția necesară pentru implementarea procesului de afaceri.

Linkuri de parteneri, care reprezintă o referire la serviciile externe invocate de activitățile procesului BPEL. În editorul JDeveloper Composite, atunci când conectați o componentă de proces BPEL, în componenta procesului BPEL este creată o referință externă (serviciu) – o legătură parteneră. O legătură parteneră descrie rolurile jucate pentru interacțiunea dintre procesul BPEL și serviciul pe care îl invocă.

Figura 26. Elemente ale procesului BPEL

Prin definiție, un proces de afaceri interacționează cu alte servicii web. Pentru a vă conecta cu acestea, serviciile BPEL importă informațiile stocate în WSDL pentru fiecare serviciu. fișierele XSD. Prin urmare, un fișier BPEL include în mod obișnuit o serie de instrucțiuni <import> care permit procesul de a mobiliza informațiile stocate în fișierele WSDL și XSD ale fiecărui serviciu.

Figura 27. Activități BPEL

Procesele BPEL oferă capacități de procesare mai sofisticate și condiționale decât pot fi obținute prin trasarea, filtrarea și transformarea posibile prin utilizarea componentei Mediator.

Fiecare interacțiune reprezintă o relație între procesul BPEL și serviciul invocat printr-un rol pe care fiecare îl joacă în interacțiune. Pentru a identifica rolurile și relațiile care se aplică într-o interacțiune, un proces BPEL utilizează un link partener și un tip de legătură de partener.
O legătură parteneră, definită în sursa BPEL, descrie rolurile procesului BPEL și jocul invocat de serviciu. Fiecare rol este asociat unui tip de port (operațiune definită în WSDL), care determină structurile de date ale mesajelor pe care le pot manipula în cadrul lor respectivele roluri. Un link partener este configurat cu un nume, un tip de link de partener și un rol pentru interacțiuni sincrone sau două roluri pentru interacțiuni asincrone. Un tip de Partner Link, definit într-un document WSDL, descrie posibilele interacțiuni pe care un serviciu le poate realiza, caracterizând astfel relația de conversație dintre două servicii prin specificarea rolurilor pentru fiecare tip de interacțiune oferit de serviciu. O legătură de partener tip definește unul sau două roluri.

Un rol indică faptul că serviciul poate finaliza conversația fără apel invers;

Două roluri indică faptul că există o cerință de a primi un apel invers de la serviciu..

Un rol este asociat unui tip de port, care este definit în WSDL a unui serviciu, care determină operația efectuată de rol și structura mesajelor primite într-o solicitare sau returnată ca răspuns în contextul conversației.

5.3.3. Variabilele BPEL.Tipul și domeniul de aplicabilitate

Motorul BPEL este responsabil pentru gestionarea valorilor datelor utilizate de procesul de afaceri. Valorile tipice includ datele transmise procesului prin partenerul client invocat, iar răspunsul trebuie să fie creat sau urmărit sau ambele. În cele din urmă, procesul poate avea nevoie de menținerea datelor la nivel intern, cum ar fi numere de ordine și așa mai departe. Toate aceste date pot fi stocate în variabilele BPEL. Fișierul de proces BPEL își declară variabilele înainte de succesiunea activităților. Un exemplu apare în figura 20.

Figura 28. Declararea variabilelor

Interacțiunile cu partenerii

Un proces mai bun este organizat în pași sau activități distincte. Specificația BPEL identifică o serie de activități cu o varietate de aplicații. Un grup de activități include serviciul primitiv sau serviciul de a aștepta primirea unui mesaj de la un client pentru a genera răspunsul unei operații de intrare / ieșire, a copia datele de la o sursă la o destinație, pentru a indica că ceva nu a mers bine sau o serie de alte sarcini.

Sunt folosite trei activități diferite pentru a interacționa cu partenerii. Prima dintre acestea este activitatea de primire. Primirea reprezintă intrarea (primirea unui mesaj) a unei operații WSDL furnizată de proces. Atributele activității de primire includ partenerul partener, precum și tipul de port și funcționarea procesului vizat de partener. Activitatea Primire ia mesajul primit, îl pune în variabila specificată și se termină. A doua activitate care interacționează cu partenerii este activitatea Invocare. Activitatea Invocare invocă o operațiune unidirecțională sau de răspuns-răspuns între procesul BPEL și un serviciu web partener într-un port furnizat de partener.
Parametrii pentru activitatea Invoke, cum ar fi portType, partener și operație, sunt specificați ca atribute. De asemenea, sunt specificate variabilele de intrare și ieșire care conțin intrarea și ieșirea a operației invocate.În cele din urmă, dacă procesul trebuie să trimită înapoi un răspuns sincron la partenerul client care a trimismesajul, este necesară și o activitate de răspuns. Atributele partnerLink, de operare și portType pentru activitatea de răspuns trebuie să se potrivească cu atributele corespunzătoare activității de primire.

Un proces BPEL sincron:

Conține activități care nu ar trebui să dureze mult timp, deoarece clientul așteaptă răspuns;

Obține cererea cu o activitate de primire;

Returnează răspunsul cu o activitate de răspuns.

Un proces BPEL asincron:

Conține activități care pot dura ceva timp;

Obține cererea cu o activitate de primire;

Returnează un răspuns opțional cu un apel invers care este implementat cu o activitate Invocare.

Structura de bază a fluxului de proces BPEL asincron, așa cum a fost creat de Oracle JDeveloper Crearea expertului BPEL Process, cuprinde următoarele elemente:

1. O activitate de primire la începutul fluxului;

2. Un număr de activități intermediare pe termen lung;

3. O activitate Invocare la sfârșitul fluxului.

Oracle BPEL Process Manager gestionează automat corelația dintre clienții procesului invocat prin utilizarea tehnicilor de adresare WS. Acest lucru permite un proces de lungă durată pentru a invoca clientul atunci când procesul este complet. Operația finală Invocare este un apel invers.

6. Descrierea instrumentelor utilizare în dezvoltarea aplicației

6.1. Oracle SOA Suite 12c

Produsul Oracle SOA Suite 12c din familia Fusion Middleware oferă o suită cuprinzătoare de componente de infrastructură de servicii care permit dezvoltarea, gestionarea și orchestrarea serviciilor în compozite, securizarea și monitorizarea SOA, inclusiv:

Componentele de service, care sunt blocurile de construcție folosite pentru a construi o aplicație compusă SOA

Motoarele de service, care implementează componentele de service la momentul executării

Adaptoare, care asigură conectivitate pentru funcționalități în afara aplicației compuse

Infrastructura de servicii, care oferă capabilitățile interne de transport de mesaje pentru conectarea componentelor de serviciu și activarea fluxului de date

Figura 29. Oracle Fusion Middleware 12c: SOA Suite

Această diagramă 29, ilustrează modul în care se îmbină diferite componente Fusion Middleware în imaginea de ansamblu. Înainte de a le explora mai detaliat, mă voi referi doar la câteva dintre ele. Un service bus oferă o bază de date bazată pe standarde, care permite primirea mesajelor XML pe diferite opțiuni și protocoale de transport (cum ar fi SOAP, JMS, JCA). Componenta Service Bus și Mediator poate fi utilizată pentru filtrarea, transformarea și direcționarea mesajelor primite către un serviciu desemnat.Managerul politicii de servicii Web permite conturarea constrângerilor de securitate care trebuie aplicate diferitelor puncte terminale URL la care sunt livrate serviciile. Se poate asigura că mesajele care conțin informații sensibile sunt criptate în timpul transportului și schimbate numai cu clienți capabili să furnizeze o autentificare adecvată.

BPEL Process Manager conduce execuția serviciilor compuse definite în limba BPEL prin fluxul lor de procesare.Componenta Business Rules oferă un mijloc prin care utilizatorii de afaceri, mai degrabă decât programatorii, pot defini logica afacerii. Logica de afaceri este mutată în afara orchestrărilor de serviciu și accesată ca serviciu de decizie.În mod similar, o componentă a fluxului de lucru umane permite interacțiunii umane, cum ar fi aprobările, să aibă loc în timpul executării proceselor de afaceri.

Managerul BAM și Enterprise furnizează capabilități de monitorizare. BAM permite monitorizarea în timp real a măsurătorilor arbitrare a afacerii, bazate pe datele mesajelor care se reflectă în sistem (de exemplu, valoarea comenzilor de vânzări pe oră), în timp ce EM permite monitorizarea activității și a erorilor compozitelor utilizate.

6.2. Oracle JDeveloper

Oracle JDeveloper este componenta de dezvoltare a Oracle SOA Suite. Formează un mediu integrat de servicii pentru crearea și implementarea compozitei, asamblarea, orchestrarea, testarea, întreținerea aplicațiilor compozite bazate pe servicii.Editorul SOA Composite permite crearea, editarea și implementarea serviciilor și asamblarea într-o aplicație. Aceste componente sunt integrate într-o singură aplicație și comunică cu lumea exterioră prin legarea componentelor, cum ar fi servicii web și adaptoare JCA. Editorul SOA Composite permite utilizarea oricărei dintre cele două abordări pentru proiectarea aplicațiilor:

Abordarea de sus în jos (top-down) a construirii unei compozite. Abordarea de sus în jos a construirii unei aplicații compozite pune mai întâi interfețele și apoi continuă implementarea. Spre exemplu, mai întâi se adaugă la o aplicație procesele BPEL, sarcinile umane, regulile de afaceri și serviciile de rutare Oracle Mediator și definirea ulterioară a conținutului specific al acestor componente de servicii.

Abordarea de jos în sus (bottom-up) ia în considerare implementările existente ale componentelor și serviciilor, serviciile le împachetează cu interfețe de servicii web pentru asamblarea într-o aplicație compusă.Spre exemplu, crearea și definirea conținutului specific al proceselor BPEL, sarcinile umane, regulile de afaceri și componentelor de servicii de rutare Oracle Mediator și mai târziu crearea unei aplicații compusă SOA la care se adaugă aceste componente de serviciu.

Oracle JDeveloper oferă următoarele editoare suplimentare pentru proiectarea componentelor de serviciu: Oracle BPEL Designer, editorul Oracle Mediator, editorul de activități umane (Human Task Editor), designerul de reguli de afaceri (Business Rules Designer).

Figura 30. Editoare suplimentare Oracle Jdeveloper

6.3. WebLogic Application Server

Deoarece aplicațțile compuse SOA sunt aplicații Java Enterprise, acestea trebuie să ruleze într-un container Java. WebLogic Server (WLS) oferă mediul Java EE pentru acestea. Platforma Oracle SOA Suite 12c cuprinde un server Oracle WebLogic Administration și unul sau mai multe server Oracle WebLogic Managed (componentele și resursele aplicației). Serverul de administrare oferă un punct central pentru gestionarea grupurilor logice de resurce care sunt organizate în domenii. Domeniile constau dntr-unul sau mai multe Oracle WebLogic Managed care sunt gestionate printr-un singur server de administrare. Toate informațiile domeniilor sunt stocate în fișiere de configurare. Domeniile WLS pot separa aplicațiile de dezvoltare, testare și producție; administrare și responsabilități operaționale; sau diviziuni organizaționale și de afaceri.

Figura 31. WebLogic Server

Oracle SOA Suite 12C necesită o bază de date Oracle pentru a menține configurația aplicației SOA. Această bază de date este cunoscută sub numele de Oracle Metadata Service Repository (MDS). MDS este folosit pentru a gestiona serviciile implementate și aplicațiile compozite, iar această gestionare are loc în mod transparent pentru dezvoltatorii de aplicații și administratorii Oracle SOA Suite 12c. MDS poate fi, de asemenea, utilizat ca locație centrală pentru stocarea și referirea la servicii partajate artefacte, cum ar fi evenimente de afaceri, seturi de reguli pentru Oracle Business Rules, fișiere XSLT pentru Oracle Mediator, XSD și WSDL pentru Oracle BPEL Process Manager și alte servicii documente care pot fi implementate într-un format de arhivă cunoscut sub numele de metadate arhiva (fișiere .mar).

6.4. Infrastura SOA și conexiunea la baza de date

Infrastura SOA este o aplicație compatibilă Java EE care rulează în Oracle WebLogic Server. Aplicația gestionează compozitele și ciclurile lor de viață, motoarele de serviciu și componentele obligatorii care execută logica pentru adaptoare. Infrastructura SOA utilizează o structură normalizată a mesajului în tim ce furnizează interfeței interne capacitățile infrastructurii de rutare a mesajelor pentru conectarea componenteloor și activarea fluxului de date. Un mesaj normalizat este un obiect Java Map în care cheia este numele părți mesaj și valoarea este un obiect Document reprezentând conținutul XML. Infrastructura SOA:

Primește mesaje de la furnizorii de servicii sau partenerii externi prin SOAP, adaptoare sau API de livrare sub formă de XML.

Rutează mesaje pe baza definiției compozitei la motorul de serviciu corespunzător.

Figura 32. Infrastructura SOA

Conexiunea bazei de date pentru infrastructura SOA

Infrastructura SOA se conectează la două baze de date importante. Aceste două baze de date pot fi aceeași bază de date fizică, dar schemele utilizate pentru fiecare scop sunt diferite. Al doilea este depozitul de servicii de metadate SOA Oracle (MDS), care este folosit pentru a menține metadatele compozite, cum ar fi implementările și urmărirea versiunii, precum și descrierea serviciilor disponibile. alocare, prelucrare a solicitărilor etc.

Figura 33.Conectarea la baza de date

Când infrastructura Oracle SOA inițializează diferitele servicii motoare și încarcă compozitele prezente din depozitul MDS. Se adresează individului componente pentru motoarele lor specifice. După încărcarea compozitului, sistemul este disponibil pentru primiți cereri. La timpul de execuție, infrastructura SOA gestionează toate comunicările.

6.5. Oracle Enterprise Manager 12c

Oracle Enterprise Manager 12c Fusion Middleware Control este instrumentul principal pentru gestionarea, monitorizarea și configurarea mediului de rulare SOA și a componentelor acestuia.
Prin utilizarea funcției Fusion Middleware Control se pot efectua activități precum:

Implementarea aplicațiilor compuse;

Gestionarea stadiului de execuție al aplicațiilor compuse;

Oprirea și repornirea aplicațiilor compuse;

Inițierea testelor aplicațiilor SOA utilizând un instrument web de testare a serviciilor;

Urmărirea și monitorizarea instanțelor de aplicații compuse și a fluxurilor de mesaje printr-o aplicație compusă;

Examinarea și gestionarea condițiilor de defecțiune ale aplicației;

Monitorizarea motoarelor componente.

6.6. Oracle Human Workflow Service

Componenta fluxului de lucru uman oferă interacțiunile umane cu procesele, inclusiv atribuirea și rutarea sarcinilor către utilizatorii sau grupurile corecte.

Serviciul Oracle Human Workflow oferă un mijloc de interacțiune umană cu clienții de aplicații și atât Business Process Execution Language (BPEL), cât și Procesele de afaceri pentru modelarea proceselor (BPMN).În cadrul componentei, interfața de serviciu permite ca datele de sarcină sau parametrii să fie transmise ca tipuri de date simple sau într-un format XML.

Figura 34. Componenta Human Workflow Service

Multe procese de afaceri necesită interacțiuni umane pentru aprobări, gestionarea excepțiilor sau alte activități necesare pentru avansarea procesului de afaceri. Componenta fluxului de lucru uman oferă următoarele caracteristici:

Interacțiunile umane cu procesele, inclusiv atribuirea și direcționarea sarcinilor către utilizatorii sau grupurile corecte;

Termene limită, escaladări, notificări și alte caracteristici necesare pentru asigurarea îndeplinirii în timp util a unei sarcini (activitate de activitate umană);

Prezentarea sarcinilor către utilizatorii finali printr-o varietate de mecanisme, inclusiv o cerere de listă de lucru;

Organizarea, filtrarea, prioritizarea și alte caracteristici care sunt necesare pentru ca utilizatorii finali să-și îndeplinească productiv sarcinile;

Rapoartele, realocările, echilibrarea încărcării și alte caracteristici care sunt solicitate de către supervizori și proprietari de firme pentru a gestiona performanța sarcinilor.

7. Implementare aplicației

7.1. Configurare mediului

Prima etapă a constat din efectuarea instalării Oracle SOA Suite 12c, configurarea setărilor de memorie pentru o performanță sporită, pornirea serverului integrat și configurarea unui domeniu. În anexe se vor descrie pașii de configurare.

Figura 35. Arhitectura SOA

7.2. Construirea aplicației SOA

Proiect de modernizare IT care să se alinieze la obiectivele de îmbunătățire a satisfacției clienților. Un domeniu cheie de îmbunătățire va fi eficientizarea procesului de comandă care trebuie furnizat, o mai bună urmărire a comenzilor prin intermediul aprobărilor, executării, expedierii și livrării.

În sistemul actual plățile cu cardurile de credit sunt adesea negate pentru probleme motive minore, cum ar fi data expirării cardului de credit. Nu există o urmărire și o rezolvare consecventă cu clienții. Comenzile pot duce la pierderea sau întârzierea în sistem, ceea ce duce la nemulțumirea clienților. Afacerea a indicat că un nou sistem de detectare a fraudei cu card de credit trebuie pus în aplicare pentru a contracare abuzurile. Un mecanism consistent împotriva fraudei va necesita un proces de validare a cărților de credit în toate sistemele de intrare.

Am dorit realizarea unei aplicații ce poate să fie accesată inclusiv prin intermediul API-urilor RESTful.

7.2.1. Crearea aplicației compozite

În SOA Suite 12c, o serie de caracteristici noi se regăsesc pentru a îmbunătăți partajarea de cod comun între echipe, departamente sau chiar de la un partener la client. O nouă caracteristică este SOA Templates. Aceste SOA Templates, vor fi folosite ca puncte de pornire în dezvoltarea aplicațiilor SOA.

Prima compozită creată este cea de validare.

În această compozită, plățile cu cardurile de credit vor fi validare și starea plății va fi returnată. În cazul în care plata este refuzată, comanda nu va fi procesată. Toate cardurile disponibile sunt stocate în baza de date, inclusiv tipul de plată, numărul cardului, data expirării, numele cardului și limita zilnică. Mesajul de comandă de intrare include informații despre cardul de credit.

Figura 36. Diagrama compozitei de validare

Procesul de validare al serviciului de plată cu cardul include trei etape:

Informațiile sunt extrase din baza de date: numărul cardului de credit și mesajul comenzii. Dacă nu există date disponibile pentru acest număr de card de credit, plata este refuzată.

Dacă sunt disponibile date pentru numărul cardului de credit, data de expirare înregistrată în baza de date este comparată cu data de expirare menționată în mesaj. Dacă nu corespund, plata este refuzată.

Dacă suma totală a comenzii este mai mică decât limita zilnică de pe cardul de credit în baza de date plată este autorizată. În caz contrar, serviciul este refuzat.

Implementarea acestui serviciu utilizează un proces BPEL pentru a prelua datele pentru cardul de credit din baza de date și pentru a efectua testele prezentate mai sus. Serviciul va returna două valori: autorizare, refuzare plată.

Crearea conexiunii la baza de date pentru ca adaptorul să returneze informații despre plățile efectuate

Secțiunea referințe externe conține adaptorul bazei de date getpaymentInformation. Acest adaptor va furniza informațiile din baza de date, utilizând numărul cardului de credit și cheia. Pe baza datei de expirare, a limitei zilnice și a valorii totale a comenzii, se va calcula dacă plata este autorizată sau refuzată. Adaptorul bazei de date procesează opțiunile și furnizează un serviciu care aplică operația specifică. Se poate vizualiza fișierul .jca al adaptorului bazei de date, împreună cu două fișiere XML. Se crează un fișier schemă .xsd. Acesta este folosit pentru a seta intrările și ieșirile pentru apelul adaptorului bazei de date.

Figura 37. Activitatea Invoke

Crearea procesului BPEL

Procesul BPEL este componenta responsabilă cu orchestrarea din SOA Suite. Se adaugă acest proces BPEL pentru a orchestra o cerere către serviciul creat cu adaptorul bazei de date. Serviciul expus este serviciu extern al clientului, care va oferi informații despre procesul BPEL.

Figura 38. Procesul BPEL

Serviciul este conectat prin activitatea Invoke. Variabile de intrare și de ieșire sunt definite pentru apelul adaptorului la baza de date. Folosim activitățiile Invoke atunci când comunicăm cu servicii, cum ar fi adaptoarele și serviciile web. Variabila desemnată pentru intrare va conține datele (numărul cardului de credit) care va fi trimis la serviciu atunci când este invocat. Se foloseste maparea XSLT pentru a calcula statusul plăților.

Figura 39. Transformarea XSLT

Transformarea XSLT este pentru a determina dacă plata este valabilă, în funcție de limita zilnică (extrasă din baza de date) și suma totală a comenzii. Suma totală a comenzii trebuie să fie mai mică decât limita zilnică a cardului de credit. Două variabile de intrare: variabila de ieșire a daptorului de baze de date, care include informațiile de plată stocate în baza de date și variabila de intrare a procesului BPEL care include suma totală a comenzii. Ieșirea este câmpul de stare în mesajul de ieșire a procesului, care va fi setat acceptat sau refuzat.

Figura 40. Maparea XSLT

Adăugarea unui senzor pentru statusul plății

Senzorii permit efectuarea activitățiilor: monitorizarea mesajelor primite și trimite, găsirea unei anumite instanțe prin căutarea unor detalii specifice in consola Enterprise Manager, publicarea datelor JMS calculate din mesajele primite și trimise.

Figura 41. Crearea unui senzor

După crearea primei compozite pentru protejarea consumatoriilor care folosesc compozita de modificările de rutină, cum ar fi locația de implementare și actualizările de implementare am înregistrat compozita pe Service Bus. Service Bus va ajuta la scalarea serviciului pentru a face față unui volum mai mare de solicitări și pentru a oferi o reziliență pentru serviciu atunci când trebuie să fie oprit pentru întreținere. Am creat un Business Service pentru înregistrarea Uri-ului compozitei. Apoi am adăugat Pipeline (conțin acțiuni efectuate pe Service Bus pentru validarea și trasformarea datelor, înainte de a invoca serviciul backend) și Proxy (invocare prin Proxy, permite mai multă agilitate și flexibilitate în gestionarea schimbărilor).

Figura 42. Înregistrarea compozitei pe Service Bus

A doua compozită creată pentru procesarea comenzilor. Multe tipuri de clienți o vor accesa prin diferite protocoale și formate de date, inclusiv dispozitive mobile. Noul sistem de procesare a comenzilor trebuie să sprijine accesul prin RESTful API. Trebuie să permită sistemelor existente să trimită comenzi utilizând fișiere xml și fișiere csv.

Soluția din punct de vedere arhitectural.

Compozita va accepta comenzi noi, le va aproba și le va transmite sistemului spre procesare.

Componente: primirea unei comenzi prin intermediul unui apel de serviciu web, crearea numărului comenzii, setarea datei comenzii și setarea comenzii = Nou, calcularea sumei totale a comenzii, salvarea comenzii în baza de date cu status = New, returnarea confirmării clientului cu numărul comenzii.

Figura 43. Diagrama compozitei

Definirea unei referințe către serviciu. SOAP Web Service utilizat

Figura 44. SOAP Web Service

După atribuirea comenzii unei variabile de proces, se calculează valoarea totală a comenzii, care este utilizată pentru a valida plata. Calcului se face printr-o mapare XSLT.

O activitate de atribuire (Invoke) adaugă suma totată a comenzii la mesajul de comandă.

Figura 45. Activități de assign și invoke

Am adăugat senzori.

Figura 46. Senzori

Am înregistrat și acestă compozită pe Service Bus. Am configurat un adaptor File Adapter Proxy cu traducere Nxsd.

Figura 47. Înregistrarea compozitei pe Service Bus

Diagrama Pipeline

Figura 48. Diagrama Pipeline

A treia compozită pentru ambalare și expediere comenzi. Sunt mai multe metode de expediere, se calculează pe baza vitezei de expediere pe care a ales-o clientul când a plasat comanda și starea de expediere (în adresă). O dată ce comanda a fost expediată, se trimite un e-mail clientului care confirmă furnizorul de transport și starea comenzii se actualizează.

Am creat o interfață de intrare SOA Rest utilizând ca resursă Shipping. Am creat un proces BPEL pentru a seta starea comenzii, statusul și actualizarea stării comenzii în baza de date, am adăugat un senzor și am implementat serviciul de trimitere e-mail clientului. Am definit o operație POST utilizând din paleta de componente BPEL – Rest Binding Adapter.

7.2.2. Trimitere notificări client

Am folosit UMS Adapter și Apache James Email Server. Am configurat UMS Messaging Driver Configuration în Enterprise Manager FMW Control. În User Messaging Service am selectat Email Driver Properties

Figura 49. Configurare usermessagingdriver – email

Definirea regulilor de afaceri

Figura 50. Compozita în JDeveloper

Adaptorul Database analizează tabelul de comandă pentru comenzile care sunt pregătite pentru expediere. O regulă de afaceri (tabel de decizie) este utilizată pentru a decide metoda de expediere bazată pe viteza de expediere și starea de transport. Pe baza metodei de expediere, furnizorul de transport preferat este preluat din baza de date. Comanda este trimisă către serviciul de amblare prin intermediul SOA REST Outbound. Adaptorul de coerență pune furnizorul de transport în cache, astfel încât să poată fi recuperat din memoria cache în loc de baza de date. Mesajul de comandă de intrare include viteza de expediere selectată de către client: livrare standard, transport în două zile lucrătoare, transport rapid în aceeasi zi.

Figura 51. Definirea tabelului de reguli de afaceri

7.2.3. Testarea aplicației

Testare Service Bus

Figura 52. Testare Service Bus

Testarea compozitelor si Composite Senzor Values

Figura 53. Senzori pentru status

Testare Serviciu Web

Figura 54. Testare răspuns (Launch Flow Trace)

Figura 55. Statusul comenzii

Figura 56. Secvența compozitelor

Figura 57. Flow Trace

Figura 58. Payload. Audit Trail

Figura 59. Payload. Reguli de afaceri

Figura 60. AuditTrail. Flow

8. Monitorizare în timp real a proceselor. Oracle Business Activity Monitoring (BAM)

Oracle Business Activity Monitoring (BAM) este un framework ce facilitează monitorizarea activă a datelor, de la indicatori esențiali unei afaceri până la cei de performanțe. Acesta poate fi folosit pentru implementarea dashboard-urilor ce afișează date în timp real, crearea regulilor pentru notificări și dezvoltarea aplicațiilor web ce expun date în grafice.

Arhitectura sa scalabilă și performantă se axează pe datele obținute în timp real, numite și date active. BAM-ul le va gestiona într-un mod dinamic, astfel încât să ajungă la toți utilizatorii. Serviciile pe care le oferă sunt cele de rapoarte în timp real ce conțin informații care se modifică în mod continuu, alerte instantanee care pot fi trimise prin email și posibilitatea de a trimite informații către un grup restrâns de utilizatori.

Figura 61. Definirea Data Objects, Business Queries, Business Views, Dashboards

Componentele care alcătuiesc framework-ul sunt în număr de cinci. Prima se ocupă cu propagarea datelor în Oracle BAM, cea de streaming a datelor. Cea de-a doua este BAM Server care se ocupă cu agregarea datelor și propagarea acestora către utilizatori. Aceasta utilizează un Active Data Cache (ADC) folosit pentru a optimiza accesul la date și în cazul în care sunt folosite cantități mari de date. BAM Web Application oferă o interfață utilizator pentru crearea rapoartelor, alertelor și managementul utilizatorilor. BAM Data Control permite construirea unei interfețe dinamice care se poate schimba în funcție de anumite evenimente. Ultima componentă este ICommand, o consolă prin care un utilizator poate executa diferite operații pe ADC.

Figura 62. Definirea Data Objects în BAM Composer

Monitorizarea în timp real a IncomingRequests

Figura 63. Interfață dinamică BAM Composer

9. Performanță și depanare

Performanța reprezintă un termen relativ, fiecare aplicație în parte și fiecare caz de utilizare are propriile cerințe, însă există un set de principii de bază care ajută la asigurarea faptului că aplicația va atinge obiectivele.

Există multe astepte legate de performanța unei aplicații SOA Suite, iar instrucțiunile de proiectare depind de problemele de afaceri specifice pe care aplicația trebuie să le rezolve. Factori precum numărul de sisteme externe care sunt orchestrate, complexitatea transformării datelor, cât și cerințele de persistență, toți au un impact asupra performanței aplicației SOA Suite.

La proiectarea aplicației trebuie să se încerce limitarea cantități de date privind încărcătura utilă (payload) care trece prin compozite și procese. Este mult mai eficientă stocarea datelor într-o bază de date și trimiterea cheilor și metadatele prin procese, pentru a recupera date când este necesar. Suprasolicitarea pașilor care determină persistența bazei de date este o cauză obișnuită a problemelor de performanță. De asemenea, este recomandat să se utilizeze modelele standard de proiectare ale serviciilor web, cum ar fi utilizarea apelurilor asincrone și invocările.

Pentru a crește performanță, se pot utiliza pași paralele pentru procesul BPEL atunci când nu există dependențe, astfel se reduce timpul de așteptare pentru finalizarea sistemelor externe.

Figura 64. Sarcini în paralel pentru îmbunătățirea performanței

Dacă există o serie de sarcini ce nu au depentențe, se pot executa sarcinile precedente în paralel. Pentru a reduce latența invocărilor de servicii externe într-un proces BPEL, se creează mai multe fluxuri. Servicile compuse adesea apelează alte servicii web externe HTTP. Dacă aceste servicii externe nu sunt disponibile sau timpul de răspuns este mare, atunci și acest lucru poate influența performanța aplicațiilor. Prin setarea timpului de expirare la o valoare mai mică sau mai mare, performanța poate fi îmbunătățită. Un alt lucru ce poate fi aplicat pentru a crește performanța este dezactivarea vizualizărilor rezultatelor tuturor invocărilor de instanțe.

Figura 65. Dezactivare Payload Validation

Procesul de depanare

Procesul de depanare are ca scop identificarea și rezolvarea problemelor ce pot apărea în folosirea Oracle SOA Suite. O depanare bună are ca efect pe lângă rezolvarea acestora și reducerea timpului necesar rezolvării. Acest lucru implică încercarea mai multor soluții recomandate, pe rând, fără a încurca pașii, iar uneori scrisul acțiunilor executate este binevenit atunci când o soluție este mai dificilă și unii pași se pot repeta sau este nevoie de un expert care va vedea ce rezolvare s-a încercat.

O depanare trebuie executată dacă a apărut o eroare în cursul unei tranzacții din Oracle Fusion, dacă aceasta durează foarte mult timp sau dacă nu funcționează cum trebuie. Desigur că fiecare problemă trebuie tratată cu atenție și cauza trebuie izolată cât mai repede, dar există și verifcări generale care se pot efectua. Acestea pot fi verificarea log-urilor atât pe server cât și pe composite în Oracle WebLogic Server Administration Console, log-urile din Fusion Applications Control, verificarea evenimentelor declanșate de compozite, a configurărilor incorecte de rețea și în caz de nevoie contactarea support-ului Oracle.

Exemplu:

1) Tranzacția unei aplicații nu este finalizată, iar instanța este blocată într-o stare de funcționare.

Problemă: O tranzacție a unei aplicații nu este finalizată cu succes. De exemplu, starea unei comenzi de achiziție poate rămâne blocată în status de execuție. Defecțiunile pot apărea din mai multe motive:

activitate BPEL a invocat un serviciu web extern care nu era disponibil;

activitate BPEL a fost deja anulată de către administrator;

activitate BPEL a fost defectată de o eroare (eroare de afaceri, o eroare de autorizare de securitate);

activitate BPEL a invocat un serviciu ADF asincron și mesajul este blocat în coada AQ/JMS;

activitate BPEL a invocat un serviciu ADF asincron, dar deoarce SOA nu era disponibil, mesajul de apel invers nu a sosit;

activitate BPEL a invocat un serviciu ADF sincron, care durează mai mult (sau este agățat);

a apărut o eroare de rețea.

10. Bibliografie

[1] Matjaz B. Juric; Sven Bernhardt; Hajo Normann; Danilo Schmiedel; Guido Schmutz; Mark Simpson; Torsten Winterberg, June, 29, 2015; Design Principles for Process-driven Architectures Using Oracle BPM and SOA Suite 12c, Packt Publishing, chapter 4.

[2] Thomas Erl; Pethuru Chelliah; Clive Gee; Jürgen Kress; Berthold Maier; Hajo Normann; Leo Shuster; Bernd Trops; Clemens Utschig, October 31, 2014; Next Generation SOA: A Concise Introduction to Service Technology & Service-Orientation, Prentice Hall, chapter 2, chapter 4.

[3] Eben Hewitt, March 26, 2009, Java SOA Cookbook, O`Reilly Media, Inc.

[4] Arun Pareek; Harold Dost; Ahmed Aboulnaga, November 27, 2015; Oracle SOA Suite 12c Administrator`s Guide, Packt Publishing.

[5] Dan Woods; Thomas Mattern, April 28, 2006; Enterprise SOA, O`Reilly Media, Inc.

[6] Lucas Jellema, Septembrie 1, 2015; Oracle SOA Suite 12c Handbook, Oracle Press.

[7] Antony Reynolds; Matt Wright, December 26, 2012; Oracle SOA Suite 11g Developer`s Cookbook, Packt Publishing..

[8] Sergey Popov, August 12, 2014; Applied SOA Patterns on the Oracle Platform, Packt Publishing.

[9] Helen Grembowicz, Vinaye Misra, 2014, Oracle Fusion Middleware Administering Oracle Fusion Middleware, 12c (12.1.2), Copyright © 2009, 2014, Oracle and/or its affiliates. All rights reserved.

[10] Arun Pareek, Ahmed Aboulnaga, August 2012, Oracle SOA Suite 11g Administrator`s Handbook, Packt Publishing.

[11] Deborah Steiner (lead), Don Biasotti, Shelly Butcher, Thom Chumley, Carole Eubanks, Laura Ferris, Christine Ford, Helen Grembowicz, Jeanine Gutauskas, Sue Highmoor, Mark Kennedy, Vinaye Misra, Shannon Murray, Clarissa Raffanelli, Bert Rich, Stefanie Rhone, Karen Smith, Melissa Snow, Denise Storm, Leslie Studdard, Carlos Subi, Karen Summerly, Vivian Schupman, Kat Weill, Sally Wilkins, September 2011, Oracle Fusion Applications Administrator's Guide, 11g Release 1 (11.1.1.5) E14496, Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

[12] Dalton Iwazaki, 2013, Oracle WebLogic Server 12c Advanced Administration Cookbook, Packt Publishing.

[13] Atul Kumar, 2011, Oracle Identity and Access Manager 11g for Administrators, Packt Publishing.

[14] Michel Schildmeijer, September 2011, Oracle WebLogic Server 11gR1 PS2: Administration Essentials, Packt Publishing Birmingham B3 2PB, UK.

[15] Matt Brasier, Nicholas Wright, 2013, Oracle SOA Suite Performance Tuning Cookbook, Packt Publishing.

[16] Glenn Stokol, Ron Pinkerton, Armando Hernandez, Oracle University, December 2016, Oracle SOA Suite 12c: System Architecture and Administration, Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

[17] Ron Pinkerton, Simone Geib, Jay Kasi, David Mills, Ted Witiuk, Pete Laseau, Tom Barrett, November 2014, Oracle SOA Suite 12c: Build Composite Applications, Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

[18] Al Saganich, Bill Bell, Elio Bonazzi, Luis Celis and TJ Palazzolo, April 2016, Oracle WebLogic Server12c: Administration I, Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

[19] Mark Lindros, TJ Palazzolo, Al Saganich, Tom Eliason, December 2016, Oracle WebLogic Server12c: Administration II, Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

[20] Apoorva Srinivas, November 2016, Oracle Database 12c R12: SQL Workshop I, Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

11. Anexe

Instalare și utilizare

Pagina de configurare si monitorizare servere, baza de date, adaptori JMS, BAM, UMS.

Figura 66. WebLogic Server

Figura 67. Oracle Enterprise Manager Fusion Middleware Control 12c