Serverul de Aplicatii Glassfish

Informatica

Serverul de Aplicatii Glassfish

Byadmin ianuarie 1, 2024

Cuprins

1.Infrastructura software

1.1 Serverul de aplicații GlassFish

1.2 Hibernate ca librărie de mapare obiect-relațional

1.3 Platforma Java Enterprise Edition

1.4 Securitatea accesului si a identitarii

1.4.1 Security Assertion Markup Language

1.4.2 OpenSSO Enterprise

2. Serviciu de stocare online securizat a documentelor

2.1 Aspecte generale

2.2 Arhitectura aplicației

2.3 Fluxuri de interacțiune

2.3.1 Scenariul de pornire standard al unui client

2.4.1 Scenariul de interacțiuni pentru trimiterea unui token de activare

2.4.2 Fluxul de interacțiuni pentru Criptare / decriptare

2.4.3 Fluxul de interacțiuni pentru recuperarea parolei

2.5 Comunicarea si integrarea cu alte sisteme software

2.6 Server REST API

2.7 Domeniul de date de pe Server

2.8. Aplicația Client

2.9 Structura de nivele

Bibliografie

Tabela de figuri

Capitolul 1. Infrastructura software

1.1 Serverul de aplicații GlassFish

GlassFish este implementarea de referință a Java EE și suporta tehnologii ca JavaBeans, JPA, JavaServer Faces, JMS, RMI, JavaServer Pages, servlets, etc. Acest lucru permite dezvoltatorilor să creeze aplicații de întreprindere, care sunt portabile și scalabile, și in același timp permite integrarea cu tehnologii vechi . Componente opționale pot fi de asemenea instalate pentru servicii suplimentare.

Construit pe un nucleu modular alimentat de OSGi, GlassFish rulează direct pe o implementare Apache Felix. De asemenea, poate fi rulat cu Equinox OSGi sau Knopflerfish OSGi runtime. HK2 abstractizează sistemul modulului OSGi pentru a furniza componente, care pot fi, de asemenea, văzute ca servicii. Aceste servicii pot fi descoperite și injectat în timpul rulării.

GlassFish se bazează pe codul sursă lansat de sistemul de persistența TopLink Sun și Oracle Corporation. Acesta folosește un derivat de Apache Tomcat ca servlet container pentru servire conținut Web, cu o componentă suplimentara numit Grizzly care folosește Java New I/O (NIO) pentru scalabilitate și viteză.

Figura 1. Arhitectura GlassFish

Specificația OSGi (initiative Open Service Gateway) descrie un sistem de module și o platformă de servicii pentru limbajul de programare Java care implementează un model complet și dinamic de componente, ceva ce nu există în medii Java/VM standard. Aplicațiile sau componentele, care vin sub forma de pachete de implementare, pot fi instalate de la distanță, pornite, oprite, actualizate și dezinstalate fără a fi necesară o repornire inclusiv management pachete lor/claselor de Java este specificat în detaliu. Managementul ciclului de viața al aplicațiilor este pus în aplicare prin intermediul API-uri care permit descărcarea de la distanță a politicilor de gestionare. Registru de servicii permite pachetelor sa detecteze adăugarea de noi servicii, sau eliminarea de servicii, și să se adapteze în consecință.

1.2 Hibernate ca librărie de mapare obiect-relațional

Hibernate ORM este o librărie de mapare obiect-relațional pentru limbajul Java, oferind un cadru pentru maparea unui model de domeniu orientat-obiect la o bază de date relațională tradițională. Hibernate rezolvă problemele de nepotrivire obiect-relațional prin înlocuirea accesului direct al bazei de date la cu funcții de nivel înalt de manipulare a obiectelor.

Caracteristică principală la Hibernate este de mapare de la clase Java la tabele de baze de date (și de la tipurile de date Java la tipurile de date SQL). Hibernate oferă, de asemenea facilități de interogare de date și de recuperare de date. Acesta generează apeluri SQL și scutește pe dezvoltator de manipularea unui set de rezultate manual și conversia lor in obiecte. Aplicațiile care folosesc Hibernate sunt portabile pentru diferite baze de date SQL suportate cu foarte puțin deficit de performanță.

Maparea claselor Java la tabele de baze de date se realizează prin configurarea unui fișier XML sau prin utilizarea adnotări Java. Când se utilizează un fișier XML, Hibernate poate genera cod sursă schelet pentru clasele de persistenta. Acest lucru nu este necesar atunci când se folosesc adnotări. Hibernate poate utiliza fișierul XML sau adnotările să mențină schema bazei de date.

Facilități pentru a aranja unu-la-mai multe si mai multe-la-mai multe relații între clase sunt de asemenea furnizate. În plus față de gestionarea asociațiilor între obiecte, Hibernate poate administra, de asemenea, asociațiile reflexive în care un obiect are o relație unu-la-mai-mulți cu alte instanțe de propriul tip.

Hibernate oferă suport pentru modificarea mapării implicite a tipurilor de valoare . Acest lucru face următoarele scenarii posibile:

Suprascrierea tipului SQL implicit ales de Hibernate pentru maparea o coloană pentru o proprietate.

Maparea tipului Java Enum la coloane ca și în cazul în care acestea ar fi fost proprietăți obișnuite.

Maparea cu o singură proprietate pentru mai multe coloane. O

Obiecte de aplicație front-end urmează principii OOPS si obiecte de back-end urmează principiile de normalizare si aceste doua principii generează modele diferite. Această problemă se numește "impedanță de nepotrivire". Maparea este o modalitate de rezolvare a "impedanței de nepotrivire". Maparea va spune la instrumentul ORM despre care obiect de clasa Java este nevoie pentru a fi persistat în care tabel de baze de date.

Figura 2. Arhitectura Hibernate

Hibernate oferă un limbaj inspirat din SQL numit Hibernate Query Language (HQL), care permite interogării SQL ca să fie scrise cu obiecte de date Hibernate. Criteria Queries sunt oferite ca o alternativă orientat-obiect de HQL. Criteria Queries este folosit pentru a modifica obiectele și oferă posibilitatea de a stabili restricții pentru obiectele.

Hibernate oferă persistența transparentă pentru obiecte Plain Old Java (POJOs). Singura cerință strictă pentru o clasă persistentă este un constructor fără argument, nu neapărat public. Comportamentul corect în unele aplicații necesită, de asemenea, o atenție deosebită la metodele equals() și hashCode ().

Deschiderea și închiderea unei sesiuni pentru fiecare apel de baze de date într-un singur fir de execuție este un anti-model de programare. De asemenea, este un anti-model, în ceea ce privește tranzacțiile de baze de date. Apelurile de baza de date trebuie grupate într-o secvență planificată. În același mod, nu se comit după fiecare instrucțiune SQL din aplicație. Hibernate dezactivează sau așteaptă ca serverul de aplicație sa dezactiveze, modul de auto-comit imediat. Tranzacții de baze de date nu sunt niciodată opționale. Toate comunicările cu o bază de date trebuie să fie încapsulate de o tranzacție. A se evita de asemenea un comportament auto-comit pentru citirea datelor, pentru că multe tranzacții mici sunt puțin probabil să funcționeze mai bine decât o unitate clar definit-de acțiuni, și sunt mult mai dificil de a menține și de a extinde.

1.3 Platforma Java Enterprise Edition

Platforma Java, Enterprise Edition (Java EE) oferă o platformă bazată pe standarde pentru dezvoltarea de aplicații web și de întreprindere. Aceste aplicații sunt de obicei proiectate ca aplicații multinivel, cu un nivel interfață constând din cadre web, un nivel de mijloc care oferă securitate și tranzacțiile, și un nivel backend pentru furnizarea de conectivitate la o bază de date sau la sisteme vechi moștenite. Platforma Java EE definește API-uri pentru diferite componente în fiecare nivel, și, de asemenea, oferă unele servicii suplimentare, cum ar fi denumirea, injectarea, și de gestionare a resurselor de pe platforma. Fiecare componentă este definit într-un document de specificații separat, care descrie, de asemenea, API, javadocs, și comportamentul așteptat.

Figura 3. Arhitectura unei aplicatii Java Enterprise Edition

Platforma Java, Enterprise Edition 6 (Java EE 6) a fost lansat în decembrie 2009 și oferă un cadru simplu, ușor de utilizat, și o stivă completa pentru construirea de astfel de aplicații. Versiune anterioara a platformei, Java EE 5, a făcut primul pas în a oferi o experiență simplificată dezvoltatorilor . Platforma Java EE 6 îmbunătățește și mai mult toate aspectele asupra productivității dezvoltatorilor și, de asemenea, adaugă o mulțime si mai mare de funcționalitate noua.

Platforma Java EE 6 aduce ușurința de utilizare pe noi culmi prin utilizarea pe scară largă a convenției in loc de configurare și utilizarea din greu de adnotări pe un obiect Plain Old Java (POJO). Adăugarea @Stateless, @Stateful sau @Singleton la un obiect POJO îl face un Enterprise JavaBean. Mai mult, acestea ar putea fi ușor împachetate într-un fișier WAR in loc de o împachetare in JAR sau EAR. Servlets sunt POJOs de asemenea, adnotați cu @WebServlet. Descriptori de implementare, cum ar fi web.xml și faces-config.xml sunt opționale, în cele mai multe cazuri; informațiile de obicei specificate în descriptorii de implementare sunt acum capturate în adnotări. Există de asemenea reguli implicite de navigație de la o pagină de JSF la alta. Publicarea un POJO ca un serviciu web RESTful este echivalent cu adăugarea unei adnotări @Path pe POJO. Făcând descriptori de implementare opționali, folosind convenție peste configurare, și bazându-se foarte mult pe adnotări face platforma Java EE 6 ușor de utilizat și, mai presus de toate, mai puțin prolixa.

Există 31 de specificații de componente din platforma Java EE 6 , așa cum sunt enumerate în anexa EE.6 din documentul de specificații al platformei. Aceste componente includ Enterprise JavaBeans (EJB), Servlets, JavaServer Faces (JSF), Java API pentru RESTful Servicii Web (JAX-RS), și multe altele. Construirea unei aplicații tipică de întreprindere poate să nu solicite toate componentele. De asemenea, unele dintre tehnologii cum ar fi Java API pentru Registre XML (JAXR) sau Java API pentru RPC bazat pe XML (JAX-RPC) au fost foarte relevante atunci când au fost introduse în platformă. Acum au fost fie înlocuite de componente mai bune, cum ar fi Java API pentru XML Web Services (JAX-WS), sau nu mai sunt folosite.

Platforma oferă un set bogat de funcționalități pentru a crea aplicații Enterprise . Cu toate acestea , este o practică comună de a include cadre terțe să suplimenteze sau să completeze funcționalitate în platforma. Aceste cadre necesită înregistrare a unui ServletListener , ServletFilter sau componente similare , astfel încât acestea sunt recunoscute de către runtime. Documentul de specificații Servlet definește un fragment web ca un mecanism prin care aceste puncte de intrare ale cadrului sunt definite în biblioteca cadru. Containere servlet atunci înregistrează cadrul , scutind dezvoltatorul de sarcina. Acest lucru permite ca aceste cadre să fie tratate ca cetățeni de primă clasă ale platformei . În plus , documentul de specificații pentru Contexte și injectare de dependență ( CDI ) definește un mecanism de extindere portabil care permite să extindă capacitățile platformei în diferite moduri, de exemplu prin furnizarea anumitor domenii predefinite. Un nou domeniu de aplicare poate fi ușor de definit și inclus cu orice server de aplicații – compatibil Java EE 6 folosind metoda extensiilor portabile.

Java EE 6 este format din documentul de specificații care definește Cerințele pe platforma. Se compune, de asemenea din următoarele documente de specificații pentru componente:

Tehnologii Web:

• JSR 45: Debugging Support for Other Languages

• JSR 52: Standard Tag Library for JavaServer Pages (JSTL)1.2

• JSR 245: JavaServer Pages (JSP) 2.2 and Expression Language (EL) 1.2

• JSR 314: JavaServer Faces (JSF) 2.0

• JSR 315: Servlet 3.0

Tehnologii Enterprise:

• JSR 250: Common Annotations for the Java Platform 1.1

• JSR 299: Contexts and Dependency Injection (CDI) for the Java EE Platform 1.0

• JSR 303: Bean Validation 1.0

• JSR 316: Managed Beans 1.0

• JSR 317: Java Persistence API (JPA) 2.0

• JSR 318: Enterprise JavaBeans (EJB) 3.1

• JSR 318: Interceptors 1.1

• JSR 322: Java EE Connector Architecture 1.6

• JSRsind metoda extensiilor portabile.

Java EE 6 este format din documentul de specificații care definește Cerințele pe platforma. Se compune, de asemenea din următoarele documente de specificații pentru componente:

Tehnologii Web:

• JSR 45: Debugging Support for Other Languages

• JSR 52: Standard Tag Library for JavaServer Pages (JSTL)1.2

• JSR 245: JavaServer Pages (JSP) 2.2 and Expression Language (EL) 1.2

• JSR 314: JavaServer Faces (JSF) 2.0

• JSR 315: Servlet 3.0

Tehnologii Enterprise:

• JSR 250: Common Annotations for the Java Platform 1.1

• JSR 299: Contexts and Dependency Injection (CDI) for the Java EE Platform 1.0

• JSR 303: Bean Validation 1.0

• JSR 316: Managed Beans 1.0

• JSR 317: Java Persistence API (JPA) 2.0

• JSR 318: Enterprise JavaBeans (EJB) 3.1

• JSR 318: Interceptors 1.1

• JSR 322: Java EE Connector Architecture 1.6

• JSR 330: Dependency Injection for Java 1.0

• JSR 907: Java Transaction API (JTA) 1.1

• JSR 914: Java Message Server (JMS) 1.1

• JSR 919: JavaMail 1.4

Tehnologii pentru Servicii Web:

• JSR 67: Java APIs for XML Messaging (JAXM) 1.3

• JSR 93: Java API for XML Registries (JAXR) 1.0

• JSR 101: Java API for XML-based RPC (JAXRPC) 1.1

• JSR 109: Implementing Enterprise Web Services 1.3

• JSR 173: Streaming API for XML (StAX) 1.0

• JSR 181: Web Services Metadata for the Java Platform 2.0

• JSR 222: Java Architecture for XML Binding(JAXB) 2.2

• JSR 224: Java API for XML Web Services (JAXWS) 2.2

• JSR 311: Java API for RESTful Web Services (JAXRS) 1.1

Tehnologii pentru Management si Securitate:

• JSR 77: J2EE Management API 1.1

• JSR 88: Java Platform EE Application Deployment API 1.2

• JSR 115: Java Authorization Contract and Containers(JACC) 1.3

• JSR 196: Java Authentication Service Provider Inteface for Containers (JASPIC) 1.0

Figura 4. Arhitectura platformei Java Enterprise Edition

• JPA, JTA, și JMS oferă servicii de bază, cum ar fi acces la baze de date , tranzacții, și de mesagerie.

• Managed Beans și EJB oferă un model de programare simplificat folosind POJOs care utilizează serviciile de bază.

• CDI, Interceptori, și Adnotările comune furnizează concepte care sunt aplicabile la o mare varietate de componente, cum ar fi injectarea de dependență în condiții de siguranță de tip, abordând preocupări transversale folosind interceptoare, și un set comun de adnotări.

• Extensiile CDI permit să se extindă dincolo de platforma capacitățile existente într-un mod standard.

• Serviciilor Web folosind JAX-RS și JAX-WS, JSF, JSP, și EL definesc modelul de programare pentru aplicații web. Fragmentele web permit înregistrarea automată a părți terțe de cadre web într-un mod foarte natural.

• Validarea de Bean oferă un mijloc standard pentru a declara constrângeri și să le valideze în diferite tehnologii.

Un managed Bean este un POJO care este tratat ca o componentă gestionata de un container Java EE. Acesta oferă o bază comună pentru diferite tipuri de componente care există în platforma Java EE. În plus, documentul de specificații definește, de asemenea, un set mic de servicii de bază, cum ar fi injectarea de resurse, callback al ciclului de viață, și interceptoare pe aceste Bean.

Specificații diferite pentru aceste componente pot adăuga alte caracteristici la un managed Bean. Documentul de specificații chiar definește binecunoscutele puncte de extensie pentru a modifica unele aspecte. De exemplu, Contexte și injecția de Dependența (CDI), relaxează cerința pentru a avea o POJO cu un constructor fără-argumente, și permite constructori cu semnături mai complexe. CDI, adaugă, de asemenea, suport pentru domenii și evenimente ale ciclului de viață. În mod similar, Enterprise JavaBeans este un Managed Bean și adaugă suport pentru tranzacții și alte servicii. Acest lucru permite unui dezvoltator sa înceapă ușor și sa creeze o componentă mai puternic cum ar fi un EJB sau CDI Bean în cazul în care și atunci când este necesar.

De obicei, un Managed Bean nu este utilizat de unul singur într-o aplicație Java EE. Cu toate acestea, conceptele definite sunt foarte relevante pentru Java EE și permit construirea de alte specificații pentru componente pe ea.

Ciclul de viață al unui POJO

Figura 5. Ciclul de viață al unui POJO

Un dezvoltator Java creează o instanță a unei clase folosind cuvântul cheie NEW și așteaptă colectorul de gunoi pentru a scăpa de ea și de a elibera memorie . Dar, dacă doriți să rulați un CDI Bean în interiorul unui container , nu se permite să se folosească cuvântul cheie NEW. În schimb trebuie injectat un Bean și containerul face restul , in sensul ca, containerul este cel responsabil pentru gestionarea ciclului de viață de Bean : se creează instanță si apoi se distruge. Deci, cum se face inițializarea unui Bean , dacă nu se poate apela un constructor ? Ei bine , containerul oferă un handle după construirea unei instanțe și înainte de a o distruge .

Ciclul de viață al unui Bean Managed ( și, prin urmare , un CDI Bean ) : Când se injectează un Bean , containerul ( EJB , Web , sau container CDI ) este cel responsabil pentru crearea instanței ( folosind cuvântul cheie NEW) . Apoi rezolvă dependențe și invocă orice metodă adnotata cu @PostConstruct înainte de prima invocare a unei metode de business pe Bean . Apoi, @PreDestroy callback da semnalele de notificare ca instanța este în curs de a fi eliminata prin container.

Interceptarea

Figura 6. Interceptarea apelurilor

Interceptorii sunt utilizați pentru a interveni pe apeluri de metode de business. Sub acest aspect, este similar cu programarea orientata aspect(AOP). AOP este o paradigmă de programare care separă ceea ce privește transversala unei aplicații de codul de business. Cele mai multe cereri au cod comun, care se repetă pe componente. Acestea ar putea fi probleme tehnice (logarea intrării și ieșirii din fiecare metodă, jurnal durata de o invocație de metodă, statisticile de utilizare a metodei, etc.) sau probleme de business (să efectueze verificări suplimentare, dacă un client cumpără mai mult de 10.000 dolari de elemente, trimite un ordin de cumpărare din nou în cazul în care nivelul de inventar este prea mic, etc.). Aceste probleme pot fi aplicate automat prin AOP pentru întreaga cerere sau la un subset de ea.

Cuplarea slaba și Tipuri puternice

Interceptoare sunt un mod foarte puternic de a decupla problemelor tehnice și de la logica de business. Managementul Ciclului de viață contextual decuplează de asemenea, un Bean de gestionarea propriilor cicluri de viață. Cu injectare un Bean nu este conștient de implementarea concretă a oricărui Bean cu care interacționează. Dar este mai mult decât lipsa cuplării în CDI. Un Bean poate folosi evenimentele notificărilor pentru a decupla producătorii de evenimente de consumatorii de evenimente sau decoratori pentru a decupla problemele de business de restul codului. In alte cuvinte, cuplarea slaba este ADN-ul pe care CDI a fost construit.

Și toate aceste facilități sunt livrate într-o manieră typesafe. CDI nu se bazează pe identificatori String pentru a determina modul în care obiectele se potrivesc împreună. În schimb, CDI folosește adnotări cu tipuri puternice (de exemplu, de calificare, stereotipuri, și interceptor legături) pentru a conecta diverse instanțe de Bean împreună. Utilizarea de descriptori XML este minimizat la informații cu adevărat specifice de implementare .

Validarea de Bean

Validarea de date este , de asemenea, o sarcină comună care se întinde pe mai multe , dacă nu toate , straturile de aplicații de astăzi ( de la prezentarea interfeței la baza de date ) . Deoarece procesarea , stocarea , regăsirea datelor sunt cruciale pentru o aplicație , fiecare strat definește validarea cu reguli specifice. De multe ori aceeași logică de validare este puse în aplicare în fiecare strat , dovedindu-se a fi consumatoare de timp , dificil de întreținut , și predispusa la erori . Pentru a evita dublarea acestor validări în fiecare strat , dezvoltatorii împachetează de multe ori logica de validare direct în modelul de domeniu , ocupând clase de domenii cu cod de validare , care este , de fapt , metadate despre clasa în sine .

Bean Validarea rezolvă problema de duplicarea de cod și aglomerarea de clase de domenii , permițând dezvoltatorilor a scrie o constrângere o singura dată ,si apoi sa o utilizeze și valideze în orice strat . Bean Validarea implementează o constrângere în cod simplu Java și apoi se definește printr-o adnotare ( metadate ) . Această adnotare poate fi apoi utilizata in Bean , proprietăți , constructori , parametrii de metode, și la valoarea de returnare. Într-un mod foarte elegant , dar puternic , validare de Bean expune un API simplu, astfel încât dezvoltatorii pot scrie și reutiliza constrângerile logice de business.

Aplicațiile sunt alcătuite din logica de business , interacțiunea cu alte sisteme , interfețe de utilizator . . . și date . Cele mai multe dintre datele pe care aplicațiile noastre le manipulează trebuie să fie stocate în baze de date , preluate , și analizate . Bazele de date sunt extrem de importante : ele stochează datele de business , acționează ca un punct central între aplicații , și prelucrează datele prin declanșatoare sau proceduri stocate . Datele persistente sunt peste tot , și cele mai multe ori se folosesc baze de date relaționale ca suport pentru motorul de persistență ( spre deosebire de bazele de date schemaless) . Bazele de date relaționale stochează datele în tabele făcut cu rânduri și coloane . Datele sunt identificate de chei primare , care sunt coloane speciale cu constrângeri de unicitate și , uneori , indecși . Relațiile dintre tabele folosesc chei externe și tabele de alăturare cu constrângeri de integritate .

Tot acest vocabular este complet necunoscut într-un limbaj orientat pe obiect , cum ar fi Java . În Java , vom manipula obiectele care sunt instanțe ale claselor . Obiectele vor moșteni de la alte obiecte ,s-ar putea să aibă referințe la colecții de alte obiecte , și , uneori, se referențiază într-un mod recursiv . Avem clase concrete , clase abstracte , interfețe , enumerările , adnotări , metode, atribute , și așa mai departe . Obiectele înglobează stare și comportament într-un mod elegant , dar acesta stare este accesibila doar atunci când Java Virtual Machine ( JVM ) se execută : dacă JVM se oprește sau colectorul de gunoi curăță conținutul său din memorie , obiecte dispar , precum și starea lor . Unele obiecte trebuie să fie persistente .Persistenta de date permanenta adică datele sunt stocate în mod deliberat într-o formă permanentă pe suport magnetic , memorie flash , și așa mai departe . Un obiect care poate stoca starea sa si apoi are capacitatea de a obține informațiile pentru a fi refolosite ulterior este declarat a fi persistent .

Principiul de mapare obiect-relațional ( ORM ) este de a aduce lumea de baze de date și obiecte împreună . ea presupune delegarea de acces la bazele de date relaționale la unelte sau cadre externe , care, la rândul lor, dau o viziune object-oriented pentru date relaționale , și vice-versa . Instrumente de mapare au o corespondență bidirecțională între baze de date și obiecte .

EJB

Entitățile pot avea metode pentru a valida atributele lor , dar ele nu sunt făcute pentru a reprezenta sarcini complexe , care de multe ori necesită o interacțiune cu alte componente ( alte obiecte persistente , servicii externe , etc. ) . Stratul de persistența nu este stratul de potrivit pentru procesarea de business . În mod similar , interfața cu utilizatorul nu ar trebui să efectueze logica de business , mai ales atunci când există mai multe interfețe ( Web , Swing , dispozitive portabile , etc. ) . Pentru a separa stratul de persistența din stratul de prezentare , pentru a pune în aplicare logica de business , pentru a adăuga management de tranzacții și de securitate , aplicațiile au nevoie de un strat de business . În Java EE , vom pune în aplicare acest strat , folosind Enterprise JavaBeans ( EJB ) .

Pentru majoritatea aplicațiilor , stratificare este importantă . Pe partea de sus a stratului de domeniu , stratul de business Modelele acțiunile ( sau verbele ) ale cererii (creează o carte , cumpăra o carte , imprima o comandă , livrează o carte , etc. ) . Adesea , acest strat de business interacționează cu servicii de web externe ( SOAP sau servicii web REST ) , trimite mesaje asincrone la alte sisteme (folosind JMS ) , sau mesaje e e-mail-uri ; se orchestrează mai multe componente de baze de date la sisteme externe , și servește ca loc central pentru tranzacții și demarcarea de securitate , precum și punctul de intrare pentru orice tip de client , cum ar ca interfețe web ( Servlets sau Bean suport JSF ) , de prelucrare a loturilor , sau sisteme externe . Aceasta separare logică între entități și bean-urile de sesiune urmează " separarea de preocupări " paradigmă în care o cerere este împărțită în module separate si astfel vom avea componente ale căror funcții se suprapun cât mai puțin posibil .

EJB-urile sunt componente server-side, care încapsulează logică de business și sunt capabile să aibă grijă de tranzacții și de securitate. De asemenea, au un stack integrat de mesaje, de programare, de acces de la distanță, puncte finale de servicii web (SOAP si REST), injecție de dependență, ciclul de viață a componentelor, AOP (programare orientata-aspect), cu interceptori, și așa mai departe. În plus, EJB se poate integra perfect cu alte tehnologii Java SE și Java EE, cum ar fi JDBC, JavaMail, JPA, Java Transaction API (JTA), Java Messaging Service (JMS), Java de autentificare și Serviciul Autorizare (JAAS), Naming Java și Directory Interface (JNDI), și de la distanță Method Invocation (RMI). Acesta este motivul pentru care sunt folosite pentru a construi stratul de logica de business (a se vedea figura 7-1),care sta pe partea de sus a bazei de date, și orchestrează stratul corespunzător modelului de business. EJB acționează ca un punct de intrare pentru tehnologii de nivel de prezentare , cum ar fi JavaServer Faces (JSF), dar, de asemenea, pentru toate serviciile externe (JMS sau servicii web).

EJB folosește un model de programare foarte puternic, care combină ușurința de utilizare și robustețe . Astăzi, EJB-uri sunt un foarte simplu Java server-side model de dezvoltare , prin reducerea complexității aducând în același timp posibilitatea de reutilizare și scalabilitate pentru a aplicații de business mission-critical . Toate acestea vine de la adnotarea unui singur POJO care apoi va fi implementat într-un recipient . Un container EJB este un mediu de rulare , care oferă servicii , cum ar fi management de tranzacții , de control de concurenta , punerea în comun a cererilor , precum și autorizația de securitate .Din punct de vedere istoric ,la serverele de aplicații s-au adăugat apoi alte caracteristici cum ar fi clustering , load balancing și failover . Dezvoltatorii EJB se poate apoi concentra pe punerea în aplicare a logicii de business în timp ce containerul se ocupă cu toate instalațiile tehnice necesare.

Astăzi, mai mult decât oricând , cu versiunea 3.2 , EJB-uri pot fi scrise o singură dată și desfășurate pe orice container care acceptă specificația . API-uri standard, nume JNDI portabile , componente ușoare , integrare CDI , și configurarea prin excepție permite ca mult mai ușor sa se desfășoare procesul de implementat de EJB-uri atât pe platforme open source , precum și implementări comerciale .Tehnologia a fost creata în urmă cu mai mult de 12 ani ,fapt care rezultă în aplicații EJB care beneficiază de concepte dovedite ca excelează in acest domeniu.

Tipuri de EJB-uri

Bean-urile sesiune sunt foarte bune pentru punerea în aplicare la logica de business , procese , și flux de lucru . Și pentru că aplicațiile de business pot fi complexe , platforma Java EE definește mai multe tipuri de EJB-uri . Un Bean de sesiune poate avea următoarele trăsături :

• Stateless: Bean sesiune care nu conține nici o stare de comunicare între metode , și orice instanța poate fi folosita pentru orice client . Acesta este utilizat pentru a gestiona sarcini care pot fi încheiate cu un singur apel de metodă .

• Stateful :Bean sesiune conține stare de comunicare , care trebuie să fie păstrat pentru mai multe metode pentru un singur utilizator . Este util pentru sarcinile care trebuie să fie făcut în mai multe etape .

• Singleton : O singură sesiune de Bean este împărțită între clienți și sprijină accesul concurent . Containerul se va asigura că există doar un singur instanța pentru întreaga aplicație .

Cele trei tipuri de Bean sesiune au toate caracteristicile lor specifice , desigur , dar ele au , de asemenea, multe în comun . În primul rând , ele au același model de programare . Un Bean de sesiune poate avea o interfață locala și / sau de la distanță , sau sa nu aibă deloc interfață. Bean-urile de sesiune sunt componente gestionate de containere , astfel încât acestea trebuie să fie ambalate într-o arhivă ( jar , war , sau ear ) și desfășurate într-un recipient .

Representational State Transfer ( REST ) este un stil arhitectural bazat pe modul în care funcționează Web-ul . Aplicate serviciilor , încearcă să pună Web-ul înapoi in servicii web . Pentru a proiecta un serviciu web RESTful , trebuie să se folosească Hypertext Transfer Protocol ( HTTP ) și identificatori de resurse uniforme( URI-uri ) , și să respecte câteva principii de proiectare . Acest principiu, înseamnă că fiecare adresă URL unică este o reprezentare a unui obiect . Se poate interacționa cu acel obiect , folosind un HTTP GET ( pentru a obține conținutul său ) , DELETE , POST ( pentru a crea) , sau PUT ( pentru a actualiza conținutul ) .

Arhitectura REST a devenit repede populară, deoarece aceasta se bazează pe un protocol de transport foarte robust : HTTP . Serviciile web REST reduc cuplajul client / server , ceea ce face mult mai ușor să se dezvolte o interfață REST lungul timpului fără a rupe clienților existenți protocolul existent. Ca si protocolul pe care se bazează , serviciile web REST sunt fără stare și pot face uz de cache HTTP și servere proxy pentru a ajuta dezvoltatorii să se ocupe de încărcare mare și scalare mult mai bine decât alte soluții. Mai mult decât atât , ele sunt ușor de construit pentru ca nu este necesar un set de instrumente speciale ca WSDL.

Adresabilitatea

Un principiu important de urmat atunci când se face proiectarea de servicii web REST este adresabilitatea. Serviciile web ar trebui să facă cererea cat mai adresabila posibil, ceea ce înseamnă că fiecare piesă valoroasă de informații în cadrul aplicației ar trebui să fie o resursă și respectiv un URI, ceea ce face ca resursele sa fie ușor accesibile. URI este singura bucată care trebuie să publice pentru a face resursa accesibilă, astfel încât partenerul de afaceri nu va trebui sa facă presupuneri cu scopul de a ajunge la resursa.

URI-urile unice, fac resursele corelate, și, pentru că ele sunt expuse printr-o interfață uniformă, toată lumea știe exact cum să interacționeze cu ele, permițând oamenilor să folosească aplicația în moduri pe care n-ar fi imaginat probabil de către cei care au scris-o.

Conectarea

În teoria grafurilor , un grafic se numește conectat dacă fiecare pereche de noduri distincte în graf poate fi conectat prin intermediul unei cai . Se spune că va fi conectat ferm in cazul în care conține o cale directă de la u la v și o cale directă de la v la u pentru fiecare pereche de noduri u , v. REST pledează că resursele ar trebui să fie la fel de conectat pe cat posibil .

Încă o dată , această declarație descurajanta a rezultat dintr-o examinare a succesului de pe Web . Pagini web conțin link-uri pentru a naviga prin paginile într-o manieră logică și ușoara și , ca atare , Web-ul este foarte bine conectat . Dacă există este o relație puternică între două resurse , acestea ar trebui să fie conectate . REST afirmă că serviciile de web ar trebui , de asemenea, profita de hypermedia de a informa clientul de ceea ce este disponibil și unde să meargă . Se promovează principiul de descoperire de servicii . De la un singur URI , un agent utilizator care accesează un serviciu web bine conectat – ar putea descoperi toate aspectele disponibile cum ar fi acțiuni , resurse , diverse reprezentări lor , și așa mai departe .

De exemplu , atunci când un agent de utilizator ( de exemplu , un browser Web ), căuta reprezentarea unui CD aceasta reprezentare ar putea avea nu doar numele artistului , dar, de asemenea, o legătură , sau un URI , la biografia lui. Este apoi la latitudinea agentului utilizator de a prelua sau nu de fapt resursa. Reprezentarea ar putea lega , de asemenea, si alte reprezentări ale resursei sau acțiuni disponibile .

1.4 Securitatea accesului si a identitarii

O identitate federalizată în domeniul tehnologiei informației este mijlocul de a lega identitatea electronică a unei persoane și atributele, stocate pe mai multe sisteme distincte de management de identitate.

Legat de identitatea federalizată este single-sign-on (SSO), în care elementul de autentificare unic a unui utilizator, sau token, este valid în mai multe sisteme informatice sau chiar organizații. SSO este un subset ce aparține de managementul identitarii federale, care se referă doar la autentificare și este înțeleasă la nivel de interoperabilitate tehnic.

În tehnologia informației (IT), managementul identității federale (FIdM) are obiectivul de a avea un set comun de politici, practici și protocoale cu scopul de a gestiona identitatea și încrederea utilizatorilor IT și a dispozitivelor în cadrul organizațiilor.

Figura 7. Componentele unui service de autentificare intr-un mediu OpenSSO

Sisteme de sign-on unic (SSO), permit un singur proces de autentificare a utilizatorului pe mai multe sisteme informatice sau chiar organizații. SSO este un subset al managementului identitarii federale, care se referă doar la autentificare și interoperabilitate tehnica.

Federația de identitate poate fi realizată in mai multe moduri, dintre care unele implică utilizarea de standarde oficiale de Internet, cum ar fi OASIS Security Assertion Markup Language (SAML) specification și dintre care unele pot implica tehnologii open-source și / sau a altor specificații publicate în mod deschis cum ar fi (e.g. Information Cards, OpenID, Higgins trust framework , Novell’s Bandit project).

1.4.1 Security Assertion Markup Language

Security Assertion Markup Language ( SAML ) este un format deschis de date standard bazat pe XML pentru schimbul de date de autentificare și autorizare între părți , în special , între un furnizor de identitate și un furnizor de servicii . SAML este un produs al OASIS Security Services Technical Committee. SAML datează din 2001; cea mai recentă actualizare majoră a SAML a fost publicata în 2005 , dar îmbunătățiri de protocol au fost în mod constant adăugat prin standarde suplimentare , opționale .

Cea mai importanta problema pe care SAML o adresează este web browser single sign-on (SSO) . Soluții de sign-on unic sunt comune la nivelul intranet ( folosind cookie-uri , de exemplu ), dar extinderea acestor soluții dincolo de intranet a fost problematică și a dus la proliferarea de tehnologii proprietare non- interoperabile . ( O altă abordare mai recentă pentru a rezolva problema web browser single sign-on (SSO) este protocolul OpenID . )

Specificația SAML definește trei roluri : principal ( de obicei, un utilizator ) , furnizorul de identitate ( IdP ) , și furnizorul de servicii ( SP ) . În scenariul adresat de SAML , utilizatorul solicită un serviciu de la furnizorul de servicii . Serviciul cere și obține o aserțiune de identitate de la furnizorul de identitate . Pe baza acestei aserțiuni de identitate , furnizorul de servicii poate face o decizie de control acces – cu alte cuvinte, poate decide dacă va efectua unele servicii pentru utilizatorul conectat .

1.4.2 OpenSSO Enterprise

Controlul accesului

OpenSSO Enterprise face managementul pentru acces autorizat la servicii și resurse de rețea. Prin punerea în aplicare a unor proceduri de autentificare și autorizare, OpenSSO Enterprise (împreună cu un agent de administrare instalat) asigură că accesul la resursele protejate este limitat la utilizatorii autorizați. Într-un cuvânt, un agent de administrare interceptează o cerere de acces la o resursă și comunică cu OpenSSO Enterprise pentru autentificarea solicitantului. În cazul în care utilizatorul este autentificat cu succes, agentul de administrare evaluează apoi politicile asociate cu resursele solicitate si utilizatorul pentru a determina dacă utilizatorul autentificat este autorizat să acceseze resursa. În cazul în care utilizatorul este autorizat, agentul de administrare vă permite accesul la resurse, oferind, de asemenea, date de identitate resursei pentru a personaliza interacțiunea.

Figura 8. Arhitectura client-server pentru OpenSSO

Managementul federativ

Odată cu introducerea protocoalelor federative în procesul de management al accesului , informațiile de identitate și drepturile pot fi comunicate peste mai multe domenii de securitate , care acoperă mai mulți parteneri valizi . Prin configurarea unui cerc de încredere (circle of trust) și definirea de aplicații și servicii în calitate de furnizori în acest cerc ( fie furnizori de identitate sau furnizori de servicii ) , utilizatorii pot opta pentru a asocia , a conecta sau lega diferitele identități care le-au configurate pe plan local pentru acești furnizori . Identitățile locale legate sunt federalizate și permit utilizatorului sa se conecteze la un site furnizor de identitate și apoi sa navigheze prin intermediul unui serviciu afiliat furnizor de servicii , fără a fi nevoit să se autentifice din nou. Single sign-on ( SSO ) OpenSSO Enterprise suportă mai multe tehnologii de federație deschise , inclusiv Security Access Markup Language (SAML) versiunile 1 și 2 , WS-Federation , și a Liberty Alliance Project Identity Federation Framework (Liberty ID-FF), încurajând , prin urmare, o infrastructură interoperabilă în rândul furnizorilor .

Securitatea Serviciilor Web

Un serviciu web este un serviciu sau aplicație care expune un anumit tip de business sau funcționalități de infrastructură printr-o interfață într-un limbaj neutru și independent de platforma sau rețea ; întreprinderile ar putea folosi acest serviciu web pentru a construi arhitecturi orientate spre servicii mai extinse. În special , serviciul definește interfața acesteia ( de exemplu , formatul mesajului care va fi schimbat) folosind Web Services Description Language ( WSDL ) , și comunică folosind SOAP și mesaje Extensible Markup Language ( XML ) . Clientul de servicii web ( WSC ), comunică cu furnizorul de servicii web ( WSP ), printr-un intermediar – de obicei un firewall sau echilibrator de sarcină.

Deși serviciile web permit interfețe deschise , flexibile și adaptabile , deschiderea lor creează riscuri de securitate . Fără protecții de securitate adecvate , un serviciu web poate expune vulnerabilități care ar putea avea consecințe grave . Prin urmare , asigurarea integrității , confidențialitatea și securitatea de servicii web , prin aplicarea unui model global de securitate este esențială atât pentru întreprinderi și consumatori . Un model de securitate de succes asociază datele de identificare cu serviciile web și creează interacțiuni sigure service – service . Modelul de securitate adoptată de OpenSSO Enterprise identifică utilizatorul și păstrează această identitate prin multiple interacțiuni , menține confidențialitatea și integritatea datelor , utilizează tehnologii existente , precum și jurnalizarea interacțiunilor.

Identitate pentru Servicii Web

De ceva timp, OpenSSO Enterprise a oferit interfețe client pentru acces la caracteristici si funcționalitate de bază. Aceste interfețe sunt utilizate de către agenții de politici de administrare și aplicații personalizate dezvoltate de clienți. OpenSSO Enterprise expune anumite funcții și servicii simple de identitate web care permite dezvoltatorilor posibilitatea de a le invoca cu ușurință atunci când dezvolta aplicații, folosind un mediul de dezvoltare integrat (IDE). (IDE generează codul stub care se înfășoară pe un apel la serviciul web.) Serviciile web de identitate sunt disponibile prin:

– SOAP și Web Services Description Language (WSDL)

– Representational State Transfer (REST)

Ele nu au nevoie de desfășurarea unui agent sau un proxy și includ următoarele capacități:

– Autentificare pentru a valida date de autentificare.

– Autorizare pentru a permite accesul la resursele protejate.

– Provizionare pentru managementul atributelor de utilizator și înregistrare automata a utilizatorului.

– Logare pentru a urmări toate acțiunile.

Capitolul 2. Serviciu de stocare online securizat a documentelor

2.1 Aspecte generale

Aplicația este un serviciu de stocare online al diverselor documente de maxima importanta pentru o persoana cu servicii de Securitate înalta si criptare. Documentele sunt criptate la nivel de client iar comunicarea cu serverul este securizata prin intermediul unei conexiuni SSL. Aplicația se integrează cu un serviciu separat de management al utilizatorilor si de management al subscripțiilor la servicii oferite de către companie

2.2 Arhitectura aplicației

Figura 9. Schema cu blocurile componente ale aplicației

Părțile componente ale aplicației ar fi următoarele:

Aplicația client dezvoltata in Silverlight

Aplicația server expusa către client ca si un serviciu web REST

Portalul CMS dezvoltat pe o platformă Liferay care hosteaza pagina de start si aplicația client dezvoltata in Silverlight

Baza de date folosind un server Postgresql

Serverul folosit pentru stocarea de fișiere. Calea către aceste documente este păstrata in baza de date

CMS portal :

SilverlightHostPage încorporează controlul Silverlight care conține aplicația client.

SilverlightHostPage va fi găzduit de către aplicația portal CMS. Pagina de gazdă CMS va oferi tokenul de autentificare open SSO la aplicarea Silverlight, printr-un parametru de inițializare.

Serverul pentru stocarea de fișiere

Serverul de depozitarea a fișierelor va fi folosit de către serverul web REST pentru a persista documentele clienților .

Sistemul de fișiere este folosit pentru a stoca documente : fiecare utilizator are propriul director în care sunt stocate documentele .

Accesul la fișiere

Fișierele sunt accesate de către client prin intermediul API-ul REST . Pentru ca fiecare apel de la API-ul REST este autentificat și mai mult decât atât , fiecare apel este autorizat prin validarea faptului ca utilizatorul care accesează resursa este de fapt utilizatorul deține resursele , astfel nu este posibil ca un utilizator să acceseze documentele de un alt utilizator .

În plus , fișierele fiind criptate , un acces neautorizat va păstra în continuare conținutul documentelor secrete la eventuala intruziune.

Backup-ul pentru fișierele stocate

Fișierele de stocare vor fi backup-uite în mod automat de către furnizorul de servicii de hosting .

Baza de date este sursa principală de informații atunci când se afișează informațiile pentru utilizator : pentru ca lista documentelor este luata din baza de date .

Astfel , în caz de desincronizare între conținutul bazei de date și a conținutului de stocare de fișiere , ar putea apărea scenariul ca utilizatorul ar putea iniția un apel pentru a descărca un document care nu mai este prezent pe disc . Acest caz va fi tratat ca un caz excepțional , lăsând utilizatorului opțiunea de a șterge meta-informația corespunzătoare la documentul pentru care conținutul nu mai este prezent.

Aplicația de service web REST:

• va publica API-ul REST consumat de către client ; fiecare cerere REST este verificata pentru tokenul de autentificare folosind REST Serviciu de management al utilizatorilor si subscripțiilor API

• Serverul va organiza documentele postate de către clienți ; documentele trebuie să fie deja criptate de către client atunci când sunt postate pe serviciul web ;

• Pentru a putea utiliza acest REST API , un utilizator trebuie să fie înregistrat ca utilizator valid in Serviciul de management al utilizatorilor si subscripțiilor și are nevoie să dețină o licență pentru serviciul de stocare online securizata a documentelor

• Serviciul de stocare online securizata a documentelor este înregistrat în Serviciu de management al utilizatorilor si subscripțiilor , astfel serviciul de LicenseManagement REST va fi utilizat pentru a gestiona licența pentru un utilizator la acest serviciu .

• Cota disponibil pentru un anumit utilizator este o proprietate a licenței , în mod implicit această valoare este setată la 100 MB , dar poate fi personalizat pentru fiecare utilizator

• Perioada de valabilitate a licenței este stabilită inițial la 1 an, începând din momentul activării licenței

• Fiecare apel la API-ul REST trebuie să conțină token OpenSSO . Acest token este validat prin apelarea unui RegistrationService aparținând unui Serviciu de management al utilizatorilor si subscripțiilor . Pentru a evita supraîncărcarea serverului care oferă un Serviciu de management al utilizatorilor si subscripțiilor , răspunsurile de la RegistrationService sunt trecute în memoria cache . Cache-ul are o valabilitate si un anumit termen de expirare . Acest mecanism ar putea fi considerat un management de sesiune intr-o varianta simplificata.

Aplicația client:

• Va fi găzduit pe o pagină Web, în interiorul portalului

• Conține logica folosita pentru a cripta și încărca fișiere

• Va fi pornita cu tokenul de autentificare deja stabilit ca un parametru de pornire

CMS Portal:

• va conține pagina de destinație, si va face autentificarea în Serviciul de management al utilizatorilor si subscripțiilor și apoi va trece open-SSO token-ul la aplicarea Silverlight

2.3 Fluxuri de interacțiune

2.3.1 Scenariul de pornire standard al unui client

Clientul va accesa pagina gazdă pentru Customer Management Service Portal. Clientul va furniza elementele de acreditare pentru o autentificare de pe pagina gazdă. Odată ce apelul este autentificat, portalul de Customer Management Service va porni aplicația client Silverlight cu tokenul de autentificare de Open SSO.

Figura 10. Scenariul de pornire standard al unui client

2.3.3 Primul acces al clientului (start-up pentru un utilizator nou de Serviciu de stocare online securizata a documentelor)

Un utilizator nou care inițiază un apel pentru accesarea acestui Serviciu de stocare online securizata a documentelor trebuie să se înregistreze in prealabil la Serviciul de stocare online securizata a documentelor. Accesul la Serviciul de stocare online securizata a documentelor este permis numai pentru utilizatorii care au cumpărat un produs desktop stabilit inițial de către business. Pentru a asigura acest lucru, aplicația desktop va integra un generator de link-uri securizate cu o parte fin link fiind generata folosind o logica de protecție si securizare.

Aplicația desktop generează un link ce indică spre pagina gazdă Silverlight, adăugând un parametru de interogare ca token de activare.

Token-ul de activare va fi validat de către aplicația Silverlight și o subscripție va fi creata pentru clientul care solicita accesul prima oara.

Figura 11. Primul acces al clientului

2.4 Securitatea aplicației

Aspecte generale privind securitatea:

• Securitatea la nivel de transport este obținut folosind SSL .

• Documentele sunt stocate criptate pe server , folosind AES ( algoritm simetric ) , cu o cheie de 128 biți .

Parola de criptare pentru documente :

• Acesta nu este niciodată stocate în text clar pe serverul de baza de date

• Acesta este stocat criptat ,cheia de criptare fiind "cheie fraza de recuperare a parolei" , pentru a facilita funcționalitatea de recuperare în cazul în care utilizatorul a uitat parola de criptare

• Un hash a parolei de criptare este , de asemenea, stocat pe serverul de baza de date pentru a permite o validare a parolei atunci când ea este introdusa de utilizator pe interfața client . Algoritmul hash este un derivat al SHA – 256 . ( Clasa HMACSHA256 in Silverlight )

Resursele REST sunt protejate pe partea de server prin verificarea faptului că orice cerere de acces la resurse conține un token de autentificare aparținând unui Serviciu de management al utilizatorilor si subscripțiilor valabil .

De asemenea , serverul va asigura că orice utilizator care accesează o resursă este proprietarul care a creat respectiva resursa ( prin resurse , în acest caz, ne referim la intrarea în baza de date a fișierului de pe disc ) .

2.4.1 Scenariul de interacțiuni pentru trimiterea unui token de activare

Un utilizator nou la accesarea acestui Serviciu de stocare online securizata a documentelor trebuie să se înregistreze

La accesarea link-ului, în cazul în care nu tokenul SSO valabil nu este prezent, utilizatorul este redirecționat către pagina de înregistrare / autentificare. După conectare, aplicația Serviciu de stocare online securizata a documentelor este accesata.

Token-ul de activare va fi validat de către aplicația Silverlight și o subscripție va fi creata pentru clientul care solicita accesul prima oara.

Figura 12. Scenariul de interacțiuni pentru trimiterea unui token de activare

2.4.2 Fluxul de interacțiuni pentru Criptare / decriptare

Diagrama de secvențe de mai jos descrie:

• Fluxul de apeluri, în cazul primului tip de utilizare a aplicației: cum este stabilita fraza de autentificare, cum este generata cheia de criptare și cum toate acestea sunt stocate pe server – criptate și/sau hash-uite

• A doua parte descrie procesul de criptare și de încărcare a unui document

• Ultima parte descrie descărcarea și decriptarea unui document

Figura 13. Fluxul de interacțiuni pentru Criptare / decriptare

2.4.3 Fluxul de interacțiuni pentru recuperarea parolei

Diagrama descrie procesul de recuperare parolei de acces

Figura 14. Fluxul de interacțiuni pentru recuperarea parolei

2.5 Comunicarea si integrarea cu alte sisteme software

Serviciul de stocare online securizata a documentelor REST WS va consuma RegistrationService – Serviciu de management al utilizatorilor si subscripțiilor SOAP WS pentru validarea OpenAM token si SubscriptionMgmt REST API, pentru management de licențe.

Urmează mai jos lista de servicii REST si SOAP pe care serverul de Serviciul de stocare online securizata a documentelor va trebui sa le consume:

RegistrationService corespunzând la /RegistrationService – SOAP

Metoda isUserTokenValid , pentru validarea de OpenSso token

Metoda GetUserInfo. Această metoda va returna informațiile de baza despre utilizatorul care încearcă sa acceseze serviciul ca nume, prenume, adresa de email sau userID toate bazate pe un OpenSso token valid.

SubscriptionMgmt corespunzând la /SubscriptionMgmt/1.0 – REST

Operații:

POST pe /users/{userID}/services –folosit pentru a primi un nou ID de subscripție in scenariul creării unei noi subscripții

Headers

X-HMG-SECURITY={openSsoToken}

Content-Type=application/xml

Exemplu de răspuns

(subscriptionid): 13566

PUT pe users/{userid}/services/{subscriptionid}?serviceInfo_id={id} – folosit pentru a crea o subscripție pentru un serviciu utilizând id-ul obținut in apelul anterior

Headers

X-HMG-SECURITY={openSsoToken}

Content-Type=application/xml

Body content sample:

</SubscribedService>

Exemplu de răspuns:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ServiceName>Document Safe</ServiceName>

<ServiceURL>http://172.18.10.2:8080/DocumentSafe</ServiceURL>

</SubscribedService>

GET pe users/{userid}/services?area="{ProductIdentifier}" – obține toate subscripțiile pe care le are un utilizator, pornind de la un identificator de produs

Request:

Headers:

X-HMG-SECURITY={openSsoToken}

Content-Type=application/xml

Exemplu de răspuns:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ServiceName>Document Safe</ServiceName>

<ServiceURL>http://172.18.10.2:8080/DocumentSafe</ServiceURL>

</SubscribedService>

</SubscribedServices>

2.6 Server REST API

Notă importantă: in Silverlight clientul http acceptă numai metodele GET si POST. Datorită acestei limitări, chiar și operațiunile de ștergere se fac cu ajutorul unui GET.

Aplicația de server care expune REST API conține în pachetul său si aplicația Silverlight.

Acest lucru asigură că Clientul Silverlight și REST API vor fi întotdeauna compatibile.

Această secțiune conține descrierea API-urile REST expuse de către serverul corespunzând acestui Serviciu de stocare online securizata a documentelor.

BrowseResource corespunzând la /browse

Operații:

GET pe /browse/{categoryId}?authToken={openSsoToken}&uid={userID} – obține conținutul unei categorii

GET pe /browse?authToken={openSsoToken}&uid={userID} – se obține toata lista de categorii de pe primul nivel

EntryResource corespunzând la /entry

Operații:

POST pe /entry?authToken={openSsoToken}&uid={userID} – creează o noua entitate având conținutul specificat in interiorul XML-ului

Entry:

</categoryFieldValues>

</entry>

GET pe /entry/{entryId}?authToken={openSsoToken}&uid={userID} – va șterge o entitate cu toate documentele corespunzătoare

GET pe /entry/{entryId}/{documentId}?authToken={openSsoToken}&uid={userID} – va șterge documentul indicat corespunzător unei anumite entități

StructureResource corespunzând la /structure

Fiecare categorie are o mulțime de câmpuri. Acesta resursa oferă accesul la informații despre aceste câmpuri

Operații:

GET pe /structure/categories?authToken={openSsoToken}&uid={userID} – pentru a obține o lista cu toate categoriile definite in sistem

GET pe /structure/categoryFieldTypes?authToken={openSsoToken}&uid={userID} pentru a obține o lista cu toate tipurile posibile de categorii definite in sistem

categoryFieldTypeList:

…

</categoryFieldTypes>

</categoryFieldTypeList>

TransferResource corespunzând la /transfer

Operații:

POST pe /upload/{documentName}/{entryId}/{documentSize}?authToken={openSsoToken}&uid={userID} Face încărcarea unui fișier care va fi inclus in corpul cererii. Calculul dimensiunii fișierului se face pe partea de client pentru ca sa se evite supraîncărcarea serverului cu operații consumatoare de resurse

GET pe /download/{documentId}?authToken={openSsoToken}&uid={userID} – este folosit pentru a descărca un document

UserResource corespunzând la /user

Operații:

POST pe /entryption/set?authToken={openSsoToken}&uid={userID} – este folosit pentru a crea informațiile referitoare la criptare pentru utilizatorul curent, entitatea conținând informațiile fiind inclusa in corpul cererii

XML Structure

Encryption:

encryptedPassphrase – parola folosita de client pentru a vedea fișierele sale, criptata cu codul de recuperare a parolei

passphraseHash – hash-ul parolei folosite pentru a verifica validitatea parolei in momentul in care utilizatorul o introduce.

encryptedEncryptionKey – cheia care este folosita pentru criptarea fișierelor utilizatorului, cheie care este criptata cu parola folosita de utilizator pentru a se autentifica

GET pe /entryption/get?authToken={openSsoToken}&uid={userID} – va returna informațiile referitoare la criptare corespunzătoare unui utilizator

GET pe /quota?authToken={openSsoToken}&uid={userID} } – va returna informațiile referitoare la limitele de stocare pe server corespunzătoare unui utilizator

Quota:

GET pe /isregistered?authToken={openSsoToken}&uid={userID} – va verifica daca un utilizator are o subscripție valida pentru acest serviciu

GET pe /register?authToken={openSsoToken}&uid={userID} – va înregistra utilizatorul indicat in baza de date a serviciului

MetadataResource corespunzând la /metadata

Operații:

GET pe /metadata/time – va returna data si ora curenta pentru serverul sistemului oferind acest serviciu web pentru clienți

GET pe /metadata/version?authToken={openSsoToken} – prin aceasta resursa se va obține versiunea curenta a acestui REST API

CategoryList:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

</documents>

…

</categoryFieldValues>

</entry>

</entries>

</category>

…

</categories>

</categoryList>

2.7 Domeniul de date de pe Server

O scurtă descriere a domeniului de date: utilizatorii au intrări, intrările au documente; o intrare are o categorie; o categorie are un set de câmpuri; un câmp are un tip (tabel categoryfieldtypes); un tip de câmp poate fi o valoare "libera" (de exemplu pentru un tip de dată-oră, valoarea poate fi oricare data si ora pe care utilizatorul selectează fără restricții), dar există, de asemenea, domenii care vor avea valori limitate la un set de posibilități (echivalentul a un dropdown pe ui ); pentru aceste cazuri, se utilizează tabelul categoryfieldchoices.

Figura 15. Domeniul de date de pe Server

2.8. Aplicația Client

Diagrama de mai jos ilustrează principalele clase ale aplicației client Silverlight.

Acest diagrama nu conține întregul set de clase, ci mai degrabă un set de principalele elemente constitutive ale aplicației: modele, interfețe, modele de interfețe, clientul pentru service și alte clase utilitare.

Figura 16. Aplicația Client

2.9 Structura de nivele

La stratul cel mai de sus avem metodele de service REST care sunt expuse clienților externi sub forma unor resurse.

Toate aceste metode se afla in următorul pachet :

.server.frontend.resources

Una dintre aceste resurse ar fi cea care se ocupa cu managementul categoriilor :

@Stateless

@Path("/structure")

public class StructureResource

Marcajul de “@Stateless” face ca starea sa nu fie menținuta intre apeluri si nu se permite accesul concurent la acest Bean. Toate instanțele unui astfel de Bean poți fi considerate identice de către clienți

private static final Logger LOGGER = LoggerFactory

.getLogger(StructureResource.class);

Aici pentru a apela frameworkul de logging folosit se foloseste un strat de fațada Simple Logging Facade for Java (SLF4J) care permite sa se abstractizeze accesul la librăria de logging folosita care poate fi înlocuita fără impact asupra codului din restul aplicației

@EJB

private EntryService entryService;

Acesta adnotare cu “@EJB” face ca si containerul sa instanțieze aceasta referința prin dependency-injection in momentul in care componenta este creata

@Context

private HttpServletResponse httpResponse;

In aceasta situație adnotarea de “@Context” va face informațiile referitoare la contextul HTTP legate de răspunsul dat de web service sa fie injectate in acesta variabila.

Iar una din metodele din aceasta resursa ar fi cea care este folosita pentru obținerea structurii de categorii

@GET

@Produces("application/xml")

@Path("/categories")

public CategoryList getCategoriesStructure(

@QueryParam(Constants.AUTHENTICATION_TOKEN) String token,

@QueryParam(Constants.USER_ID) String userId) {

Util.setNoCacheResponse(httpResponse);

CategoryList categoryList = null;

try {

categoryList = entryService.getCategoriesStructure(UUID

.fromString(userId));

} catch (Exception e) {

LOGGER.error(e.getMessage(), e);

Util.customThrow(e);

}

return categoryList;

}

Adnotarea cu “@GET” o face sa fie o metoda de web service care trebuie sa fie apelata printr-un apel get de HTTP . “@Produces” arata care va fi tipul de date pe care îl returnează aceasta metoda. Iar adnotarea de “@Path” arata ce URL va trebui sa fie folosit pentru a ajunge la aceasta metoda. Adnotarea de “@QueryParam” face ca parametrii din apelul HTTP care au numele din paranteze sa fie injectați in parametrii corespunzători din aceasta metoda

La nivelul următor este nivelul de service care va obține din nivelul de logica de business informațiile cerute de metoda expusa prin resursa REST.

Acest nivel este cuprins in următorul pachet :

.server.service

@Stateless

@Local

@TransactionAttribute(TransactionAttributeType.REQUIRED)

public class EntryService {

private static final Logger LOGGER = LoggerFactory

.getLogger(EntryService.class);

@EJB

private CategoryDAO categoryDAO;

@EJB

private CategoryFieldTypeDAO categoryFieldTypeDAO;

@EJB

private CategoryFieldDAO categoryFieldDAO;

@EJB

private CategoryFieldValueDAO categoryFieldValueDAO;

@EJB

private CategoryFieldChoiceDAO categoryFieldChoiceDAO;

public CategoryList getCategoriesStructure(UUID userId) {

List<Category> categories = categoryDAO.findByUser(userId);

CategoryList userCategories = new CategoryList(categories);

for (CategoryDTO categoryDTO : userCategories.getCategories()) {

categoryDTO.setEntries(null);

}

return new CategoryList(categories);

}

Aici se face convertirea din Entități corespunzătoare nivelului care face extracția din baze de date in DTO (Data Transport Object) care vor fi returnate pana la client.

Marcajul de “@Local” indica faptul ca metodele din acest Bean sunt expuse pentru clienți locali care sunt din aceeași aplicație si deployment.

@TransactionAttribute(TransactionAttributeType.REQUIRED) indica starea tranzacționala a acestui Bean iar aici configurarea arata ca in cazul in care clientul este asociat unui context tranzacțional containerul va apela acest Bean in contextual respectiv.

@Stateless

@Local

public class CategoryDAO extends AbstractGenericDaoImpl<Category> {

public List<Category> findByUser(UUID userId) {

TypedQuery<Category> q = getEntityManager().createNamedQuery(

"Category.findByUser", Category.class).setParameter("id",

userId);

return q.getResultList();

}

Clasa de CategoryDAO se ocupa de găsirea interogării potrivite pentru obținerea din nivelul de ORM si apoi din baza de date a informațiilor necesare pentru metoda de business corespunzătoare.

public abstract class AbstractGenericDaoImpl<E extends AbstractUUIDEntity> {

public EntityManager getEntityManager() {

return entityManager;

}

@PersistenceContext(unitName = Constants.PERSISTENCE_CONTEXT_UNIT_NAME, name = Constants.PERSISTENCE_CONTEXT_NAME, type = PersistenceContextType.TRANSACTION)

private EntityManager entityManager;

Adnotarea de PersistenceContext face ca acesta clasa sa fie asociata cu contextual de persistenta legat de accesul la entitățile obținute prin stratul de ORM.

@XmlRootElement(name="categoryList")

@XmlAccessorType(XmlAccessType.FIELD)

public class CategoryList {

@XmlElementWrapper()

@XmlElement(name="category")

private Collection<CategoryDTO> categories = new ArrayList<CategoryDTO>();

Aici avem maparea proprietăților de JavaBean cu elemente din XML care va fi folosit la serializare.

@XmlRootElement(name = "category")

@XmlAccessorType(XmlAccessType.NONE)

public class CategoryDTO extends AbstractUUIDDto {

@XmlAttribute

private String resourceId;

@XmlAttribute

private boolean isDefault;

@XmlElementWrapper(name = "categoryFields")

@XmlElement(name = "categoryField")

private Collection<CategoryFieldDTO> categoryFields;

public Collection<CategoryFieldDTO> getCategoryFields() {

return categoryFields;

}

public void setCategoryFields(Collection<CategoryFieldDTO> categoryFields) {

this.categoryFields = categoryFields;

}

@XmlElementWrapper(name = "entries")

@XmlElement(name = "entry")

private Collection<EntryDTO> entries;

@XmlAccessorType este configurat pe NONE care indica faptul ca atributele acestui Bean sunt serializate in XML doar daca sunt marcate in mod explicit.

@Entity

@Table(name = "Categories" , schema = Constants.SCHEMA)

@NamedQueries({

@NamedQuery(name = "Category.findByUser", query = "SELECT c FROM Category c INNER JOIN c.userCollection u WHERE u.id = :id"),

@NamedQuery(name = "Category.findById", query = "SELECT c FROM Category c WHERE c.id = :id"),

@NamedQuery(name = "Category.findAll", query = "SELECT c FROM Category c"),

@NamedQuery(name = "Category.findByIsDefault", query = "SELECT c FROM Category c WHERE c.isDefault = :isDefault"),

@NamedQuery(name = "Category.findByResourceId", query = "SELECT c FROM Category c WHERE c.resourceId = :resourceId") })

public class Category extends AbstractUUIDEntity {

@Basic(optional = false)

@Column(name = "IsDefault")

private boolean isDefault;

@Basic(optional = false)

@Column(name = "ResourceId")

@Size(max=Constants.MAX_FIELD_SIZE)

private String resourceId;

@JoinTable(schema= Constants.SCHEMA, name = "UserCategory", joinColumns = { @JoinColumn(name = "Categories_Id", referencedColumnName = "Id") }, inverseJoinColumns = { @JoinColumn(name = "User_Id", referencedColumnName = "Id") })

@ManyToMany

private Collection<User> userCollection;

@OneToMany(mappedBy = "category")

private Collection<CategoryField> categoryFieldCollection;

@OneToMany(mappedBy = "category")

private Collection<Entry> entryCollection;

@OneToMany(mappedBy = "category")

private Collection<UserConfiguration> userConfigurationCollection;

Clasa de “Category” este adnotata ca si un Bean Entitate corespunzător unui table din baza de date. Iar la “NamedQueries” avem interogări care au codul SQL specificat in mod explicit si care vor aduce informațiile cerute din baza de date.

@MappedSuperclass

public abstract class AbstractUUIDEntity{

@Id

@Column(unique = true, nullable = false, columnDefinition = "uuid")

private UUID id;

public AbstractUUIDEntity() {

id = UUID.randomUUID();

}

public AbstractUUIDEntity(UUID id) {

if (id == null) {

throw new IllegalArgumentException("Parameter id was null");

}

this.id = id;

}

public UUID getId() {

return id;

}

In AbstractUUIDEntity avem elementele comune fiecărei entități din baza de date.

Bibliografie

[1]

EJB 3 in Action, Second Edition

By: Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan

Publisher: Manning Publications

Publication Date: 31-MAR-2014

[2]

RESTful Java with JAX-RS 2.0, 2nd Edition

By: Bill Burke

Publisher: O'Reilly Media, Inc.

Publication Date: 29-NOV-2013

[3]

Developing RESTful Web Services with Jersey 2.0

By: Sunil Gulabani

Publisher: Packt Publishing

Publication Date: 20-NOV-2013

[4]

RESTful Web APIs

By: Leonard Richardson; Mike Amundsen; Sam Ruby

Publisher: O'Reilly Media, Inc.

Publication Date: 25-SEP-2013

[5]

The Java EE 7 Tutorial, Volume 2, Fifth Edition

By: Eric Jendrock; Ricardo Cervera-Navarro; Ian Evans; Kim Haase; William Markito

Publisher: Addison-Wesley Professional

Publication Date: 07-MAY-2014

[6]

The Java EE 7 Tutorial: Volume 1, Fifth Edition

By: Eric Jendrock; Ricardo Cervera-Navarro; Ian Evans; Kim Haase; William Markito

Publisher: Addison-Wesley Professional

Publication Date: 06-MAY-2014

[7]

Java EE 7 with GlassFish 4 Application Server

By: David R. Heffelfinger

Publisher: Packt Publishing

Publication Date: 26-MAR-2014

[8]

Java EE and HTML5 Enterprise Application Development

By: John Brock; Arun Gupta; Geertjan Wielenga

Publisher: Oracle Press

Publication Date: 04-MAR-2014

[9]

Java EE 7 First Look

By: NDJOBO Armel Fabrice

Publisher: Packt Publishing

Publication Date: 19-NOV-2013

[10]

Java EE 7 Developer Handbook

By: Peter A. Pilgrim;

Publisher: Packt Publishing

Publication Date: 20-SEP-2013

[11]

Java EE 7 Essentials

By: Arun Gupta

Publisher: O'Reilly Media, Inc.

Publication Date: 23-AUG-2013

[12]

Workshop Java EE 7

By: Marcus Schießer; Martin Schmollinger

Publisher: dpunkt

Publication Date: 15-AUG-2013

[13]

Introducing Java EE 7: A Look at What's New

By: Josh Juneau

Publisher: Apress

Publication Date: 26-JUN-2013

[14]

Beginning Java EE 7

By: Antonio Goncalves

Publisher: Apress

Publication Date: 26-JUN-2013

[15]

Java EE 7 Recipes: A Problem-Solution Approach

By: Josh Juneau

Publisher: Apress

Publication Date: 22-MAY-2013

[16]

Beginning EJB 3: Java EE 7 Edition

By: Jonathan Wetherbee; Chirag Rathod; Raghu Kodali; Peter Zadrozny

Publisher: Apress

Publication Date: 24-APR-2013

[17]

Java EE Development with Eclipse

By: Deepak Vohra;

Publisher: Packt Publishing

Publication Date: 25-DEC-2012

[18]

Java EE 6 Pocket Guide

By: Arun Gupta

Publisher: O'Reilly Media, Inc.

Publication Date: 25-SEP-2012

[19]

Java EE 6 Cookbook for Securing, Tuning, and Extending Enterprise Applications

By: Mick Knutson;

Publisher: Packt Publishing

Publication Date: 25-JUN-2012

[20]

Beginning Java™ EE 6 Platform with GlassFish™ 3

By: Antonio Goncalves

Publisher: Apress

Publication Date: 31-AUG-2010

[21]

Java EE 6 with GlassFish 3 Application Server

By: David R. Heffelfinger;

Publisher: Packt Publishing

Publication Date: 26-JUL-2010

[22]

Beginning Hibernate, Third Edition

By: Joseph B. Ottinger; Dave Minter; Jeff Linwood

Publisher: Apress

Publication Date: 06-APR-2014

[23]

Hibernate Recipes: A Problem-Solution Approach

By: SRINIVAS GURUZU; GARY MAK

Publisher: Apress

Publication Date: 05-JUL-2010

[24]

GlassFish Security

By: Masoud Kalali

Publisher: Packt Publishing

Publication Date: 11-MAY-2010

[25]

REST API Design Rulebook

By: Mark Masse

Publisher: O'Reilly Media, Inc.

Publication Date: 21-OCT-2011

Tabela de figuri

Figura 1. Arhitectura GlassFish 2

Figura 2. Arhitectura Hibernate 4

Figura 3. Arhitectura unei aplicatii Java Enterprise Edition 5

Figura 4. Arhitectura platformei Java Enterprise Edition 8

Figura 5. Ciclul de viață al unui POJO 9

Figura 6. Interceptarea apelurilor 10

Figura 7. Componentele unui service de autentificare intr-un mediu OpenSSO 16

Figura 8. Arhitectura client-server pentru OpenSSO 18

Figura 9. Schema cu blocurile componente ale aplicației 22

Figura 10. Scenariul de pornire standard al unui client 26

Figura 11. Primul acces al clientului 28

Figura 12. Scenariul de interacțiuni pentru trimiterea unui token de activare 30

Figura 13. Fluxul de interacțiuni pentru Criptare / decriptare 32

Figura 14. Fluxul de interacțiuni pentru recuperarea parolei 33

Figura 15. Domeniul de date de pe Server 41

Figura 16. Aplicația Client 42

Bibliografie

[1]

EJB 3 in Action, Second Edition

By: Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan

Publisher: Manning Publications

Publication Date: 31-MAR-2014

[2]

RESTful Java with JAX-RS 2.0, 2nd Edition

By: Bill Burke

Publisher: O'Reilly Media, Inc.

Publication Date: 29-NOV-2013

[3]

Developing RESTful Web Services with Jersey 2.0

By: Sunil Gulabani

Publisher: Packt Publishing

Publication Date: 20-NOV-2013

[4]

RESTful Web APIs

By: Leonard Richardson; Mike Amundsen; Sam Ruby

Publisher: O'Reilly Media, Inc.

Publication Date: 25-SEP-2013

[5]

The Java EE 7 Tutorial, Volume 2, Fifth Edition

By: Eric Jendrock; Ricardo Cervera-Navarro; Ian Evans; Kim Haase; William Markito

Publisher: Addison-Wesley Professional

Publication Date: 07-MAY-2014

[6]

The Java EE 7 Tutorial: Volume 1, Fifth Edition

By: Eric Jendrock; Ricardo Cervera-Navarro; Ian Evans; Kim Haase; William Markito

Publisher: Addison-Wesley Professional

Publication Date: 06-MAY-2014

[7]

Java EE 7 with GlassFish 4 Application Server

By: David R. Heffelfinger

Publisher: Packt Publishing

Publication Date: 26-MAR-2014

[8]

Java EE and HTML5 Enterprise Application Development

By: John Brock; Arun Gupta; Geertjan Wielenga

Publisher: Oracle Press

Publication Date: 04-MAR-2014

[9]

Java EE 7 First Look

By: NDJOBO Armel Fabrice

Publisher: Packt Publishing

Publication Date: 19-NOV-2013

[10]

Java EE 7 Developer Handbook

By: Peter A. Pilgrim;

Publisher: Packt Publishing

Publication Date: 20-SEP-2013

[11]

Java EE 7 Essentials

By: Arun Gupta

Publisher: O'Reilly Media, Inc.

Publication Date: 23-AUG-2013

[12]

Workshop Java EE 7

By: Marcus Schießer; Martin Schmollinger

Publisher: dpunkt

Publication Date: 15-AUG-2013

[13]

Introducing Java EE 7: A Look at What's New

By: Josh Juneau

Publisher: Apress

Publication Date: 26-JUN-2013

[14]

Beginning Java EE 7

By: Antonio Goncalves

Publisher: Apress

Publication Date: 26-JUN-2013

[15]

Java EE 7 Recipes: A Problem-Solution Approach

By: Josh Juneau

Publisher: Apress

Publication Date: 22-MAY-2013

[16]

Beginning EJB 3: Java EE 7 Edition

By: Jonathan Wetherbee; Chirag Rathod; Raghu Kodali; Peter Zadrozny

Publisher: Apress

Publication Date: 24-APR-2013

[17]

Java EE Development with Eclipse

By: Deepak Vohra;

Publisher: Packt Publishing

Publication Date: 25-DEC-2012

[18]

Java EE 6 Pocket Guide

By: Arun Gupta

Publisher: O'Reilly Media, Inc.

Publication Date: 25-SEP-2012

[19]

Java EE 6 Cookbook for Securing, Tuning, and Extending Enterprise Applications

By: Mick Knutson;

Publisher: Packt Publishing

Publication Date: 25-JUN-2012

[20]

Beginning Java™ EE 6 Platform with GlassFish™ 3

By: Antonio Goncalves

Publisher: Apress

Publication Date: 31-AUG-2010

[21]

Java EE 6 with GlassFish 3 Application Server

By: David R. Heffelfinger;

Publisher: Packt Publishing

Publication Date: 26-JUL-2010

[22]

Beginning Hibernate, Third Edition

By: Joseph B. Ottinger; Dave Minter; Jeff Linwood

Publisher: Apress

Publication Date: 06-APR-2014

[23]

Hibernate Recipes: A Problem-Solution Approach

By: SRINIVAS GURUZU; GARY MAK

Publisher: Apress

Publication Date: 05-JUL-2010

[24]

GlassFish Security

By: Masoud Kalali

Publisher: Packt Publishing

Publication Date: 11-MAY-2010

[25]

REST API Design Rulebook

By: Mark Masse

Publisher: O'Reilly Media, Inc.

Publication Date: 21-OCT-2011

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: Serverul de Aplicatii Glassfish (ID: 150439)

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.

Serverul de Aplicatii Glassfish

Copyright Notice

Biserica Si Societatea In Judetul Gorj (1864 1900)

Șabloane de Proiectare în Aplicații Web

Sistem Informatic In Domeniul Marketingului

Sistem de Appleturi Publicitare Elaborate In Mediul Java

Algoritmi Si Structuri DE Date

Caz Practic de Implementare a Formularului Electronic Infopath In Adobe Romania

Copyright Notice

Similar Posts