Note tehnice exemplu Application Profile Account Management

Localizarea tabelelor de bază de date
Localizarea codului sursă
Examinarea notelor despre codare
Folosirea serviciului de profil aplicaţie

Localizarea tabelelor de bază de date

Numele bazei de date pentru acest Exemplu este Account. Tabela poate fi găsită în baza de date AppProfileSampleDB.  Pentru a deschide baza de date şi vizualiza tabela, consultaţi ghidul utilizatorului bazei de date Derby.

Localizarea codului sursă

Codul sursă poate fi găsit în directorul profile_root/samples/src/AppProfile.

z/OS: Codul sursă pentru Exemple nu este furnizat pe platforma z/OS deoarece aplicaţiile Exemplu nu sunt construite pe platforma z/OS.

Examinarea notelor despre codare

Privire generală
Servletul AccountManagementServlet
Bean-ul sesiune fără menţinere de stare AccountManager
Bean-ul entitate CMP Account 2.1

 

Privire generală

Exemplul Application Profile Account Management foloseşte tipuri de componentă J2EE pentru a demonstra cum să se folosească serviciul de profilare aplicaţie:

Aplicaţia Account Management este controlată de servletul AccountManagementServlet. Servletul AccountManagementServlet interacţionează cu bean-ul sesiune fără menţinere de stare AccountManager care invocă bean-ul entitate CMP, Account. Persistenţa bean-ului entitate este influenţată de profilurile de aplicaţie care sunt definite folosind uneltele urnizate cu Application Server.


AccountManagementServlet

Servletul AccountManagementServlet furnizează utilizatorilor trei opţiuni:

Realizaţi acţiunea 1 pentru a crea conturi înainte de a realiza acţiunile 2 sau 3.

Fiecare acţiune invocă o metodă business corespunzătoare pe un bean sesiune AccountManager.  


Bean-ul sesiune fără menţinere de stare AccountManager

Bean-ul sesiune AccountManager ia comenzile de la servletul AccountManagementServlet şi face invocări la bean-ul entitate CMP, Account. Bean-ul sesiune AccountManager a fost configurat de Assembly Toolkit cu politicile de taskuri administrate de container. Aceste politici gestionează taskul asociat cu o cerere particular la bean-ul sesiune, prin aceasta suportând metode diferite ale bean-ului sesiune care să controleze rezoluţia diferitelor profiluri de aplicaţie şi politicile de intenţie acces pe bean-ul entitate Account.


Bean-ul entitate CMP EJB 2.1

Account este un bean entitate CMP 2.1. El conţine şi gestionează datele contului, cum ar fi ID-ul contului, balanţa, tipul de cont şi ARP-ul  Bean-ul entitate Account este configurat cu profiluri de aplicaţie şi politici de intenţie acces. Taskurile configurate pe fiecare profil controlează ce politică de intenţie acces se aplică pentru orice cerere dată. Profilurile de aplicaţie sunt create folosind Assembly Toolkit.


Folosirea serviciului de profilare aplicaţie


Definirea cerinţelor de intenţie acces
Crearea unei politici de intenţii acces personalizate
Aplicarea unei politici ca politică de intenţii acces implicită
Crearea unui profil de aplicaţie
Identificarea unui task
Configurarea atributelor tranzacţiei
Observarea politicilor WebSphere de intenţie acces predefinite


Serviciul de profilare aplicaţii furnizează un mecanism pentru dezvoltatori pentru a configura aplicaţiile lor J2EE cu informaţii de care au nevoie containerul şi managerul de persistenţă pentru a obţine cele mai bune optimizări de performanţă posibile fără a compromite integritatea datelor. Assembly Toolkit este unealta principală prin care aplicaţiile sunt configurate cu informaţii de profil de aplicaţie; datele de configuraţie sunt memorate în descriptorii de implementare ai aplicaţiei. Această secţiune vă poartă prin configurarea exemplului AccountManagement pentru a iniţia dezvoltatorii în folosirea acestei noi tehnologii.
  

Definirea cerinţelor de intenţie acces

Primul pas în folosirea serviciului de profilare aplicaţie este să înţelegeţi problemele de persistenţă care trebuie rezolvate pentru o aplicaţie particulară. Acest task necesită o înţelegere foarte clară a designului aplicaţiei şi a mediului în care aplicaţia rulează. Profilurile de aplicaţie vă ajută să reliefaţi gâtuirile identificate precis cauzate de o regie de persitsenţă care nu este necesară.

Exemplul AccountManagement are un singur multifinder pe bean-ul entitate Account:

getLargeAccounts (double balance)

Implicit, această metodă este invocată întotdeauna cu politica de intenţie acces wsPessimisticUpdate-WeakestLockAtLoad. Privind mai de aproape cum lucrează de fapt această metodă, se vede clar că este departe de ideal. Următoarele metode de pe bean-ul sesiune invocă metoda de entitate getLargeAccount:

getLargeAccounts (double balance)
increaseLargeAccountsAPR(double balance, double change)

Metoda getLargeAccounts este o operaţie doar-citire; toate conturile mai mari decât o anumită balanţă sunt returnate doar în scopul afişării. Metoda increaseLargeAccountsAPR este o operaţie doar-actualizare; tuturor conturilor mai mari decât o anumită balanţă li se actualizează APR-ul cu o anumită sumă. Dar, din cauză că metoda getLargeAccounts este întotdeauna invocată cu actualizare pesimistă, operaţia de citire trebuie să aştepte pentru ca operaţia de actualizare să se termine, înainte de a putea obţine rezultatele. Configurarea metodei cu o politică wsPessimisticRead în mod cert rezolvă câteva probleme de performanţă, dar cu costuri în integritatea datelor. Soluţia cea mai bună este să configuraţi bean-ul entitate să folosească o politică de citire când este invocat cu intenţii de citire şi să folosească o politică de actualizare când este invocat cu intenţii de actualizare. Serviciul de profilare aplicaţie face posibilă această configuraţie.


Crearea unei politici de intenţii acces personalizate

Acum când ştiţi cum vreţi să se comporte bean-ul entitate în contextul mai multor cereri, este timpul să vedeţi configuraţia politicilor de intenţii acces implicite. Această operaţie necesită un răspuns la următoarea întrebare: Cum vor fi tratate de către container şi de către managerul de persistenţă cererile pentru care sistemul nu le cunoaşte intenţia? Această problemă este cel mai bine pusă în evidenţă de scenariul celui mai rău caz: presupunerea că este vorba de actualizări. Această presupunere este făcută pentru acest exemplu, dar puteţi încerca să configuraţi incrementul de colectare la o valoare mai mare decât valoarea implicită de unu, prin aceasta reducând numărul de cereri la distanţă între bean-ul sesiune şi bean-ul entitate.
 

  1. Importaţi fişierul AccountManagement.ear în Assembly Toolkit.  Această acţiune creează o serie de proiecte în Assembly Toolkit.
  2. Deschideţi EJB Deployment Descriptor pentru proiectul AccountManagementEJB.
  3. Faceţi clic pe fişa Extended Access a editorului EJB Deployment Descriptor pentru a deschide pagina Extended Access.
  4. Localizaţi secţiunea Defined access intents pe pagina Extended Access şi faceţi clic pe Add pentru a deschide vrăjitorul Defined access intent.
  5. Introduceţi un nume şi o descriere; aceste atribute sunt doar pentru a vă ajuta şi nu sunt folosite la momentul rulării.
  6. Selectaţi wsPessimisticUpdate din meniul pentru tip de acces.
  7. Selectaţi Transaction from Collection scope.
  8. Setaţi valoarea casetei text Collection increment la 10. Această valoare trebuie să fie un întreg.
  9. Faceţi clic pe Finish.


Aplicarea unei politici ca politică de intenţii acces implicită

WebSphere Application Server livrează şapte politici de intenţii acces implicite care pot fi aplicate metodelor unui bean entitate CMP. Politica creată în pasul anterior al acestui exemplu adaugă o nouă politică personalizată care poate fi acum aplicată unui bean entitate CMP EJB 2.1. Pentru a seta politica personalizată ca şi politică de intenţii acces implicită pentru bean-ul entitate CMP EJB 2.1, realizaţi următoarele acţiuni:

  1. Faceţi clic pe fişa Access a editorului EJB Deployment Descriptor pentru a comuta la pagina Access.
  2. Locaţizaţi secţiunea Default Access Intent for Entities 2.x pe pagina Access.
  3. Faceţi clic pe bean-ul Account şi apoi faceţi clic pe Add pentru a deschide vrăjitorul Add Access Intent.
  4. Selectaţi politica de intenţii acces personalizată creată anterior din meniul Access intent name.
  5. Introduceţi o descriere. Acest atribut este doar pentru dumneavoastră şi nu este folosit la momentul rulării.
  6. Faceţi clic pe Next. Sunt afişate cîmpurile de atribute pentru intenţie acces. Această pagină suportă înlocuiri ale valorilor din politica de intenţii acces selectată; nu sunt necesare modificări aici.
  7. Faceţi clic pe Finish.


Crearea unui profil de aplicaţie

Aşa cum s-a menţionat anterior, politica implicită aplicată în secţiunea anterioară nu este corespunzătoare pentru toate cererile. Pentru ca managerul de persistenţă şi containerul să distingă intenţia unei cereri particulare, trebuie create profilurile de aplicaţie.   Deoarece un profil de aplicaţie conţine o listă de intenţii de acces şi taskuri, crearea unui profil de aplicaţie implică şi crearea politicilor de intenţii de acces şi a taskurilor.   Pentru exemplu nostru simplu, un singur profil este suficient.

  1. Faceţi clic pe fişa Extended Access a editorului EJB Deployment Descriptor pentru a comuta la pagina Extended Access.
  2. Localizaţi secţiunea Application profiles pe pagina Extended Access şi faceţi clic pe Add în subsecţiunea Tasks pentru a deschide vrăjitorul Task.
  3. Introduceţi un nume şi o descriere; aceste atribute sunt doar pentru a vă ajuta şi nu sunt folosite la momentul rulării. Faceţi clic pe Next.
  4. Selectaţi bean-ul Account din lista de bean-uri găsite şi apoi faceţi clic pe Finish.
  5. faceţi clic pe taskul nou creat în subsecţiunea Tasks şi faceţi clic pe bean-ul Account în subsecţiunea Access Intent.
  6. Faceţi clic pe Editare ca să deschideţi vrăjitorul Access Intent.
  7. Selectaţi wsPessimisticRead din caseta derulantă cu nume de intenţii de acces.
  8. Introduceţi o descriere.   Acest atribut este doar pentru dumneavoastră şi nu este folosit la momentul rulării.
  9. Crăţaţi caseta de bifare Read Ahead Hint.
  10. Faceţi clic pe Next.
  11. Cîmpurile de atribute pentru intenţia de acces care sunt afişate pe această pagină permite înlocuirea valorilor din politica de intenţii acces selectată. Nu este nevoie să faceţi modificări aici.
  12. Faceţi clic pe Finish.


Identificarea unui task

Aţi asociat acum o intenţie de acces actualizare pentru bean-ul entitate Account şi o politică de intenţii acces citire folosind un profil. Cum poate să determine containerul şi managerul de persistenţă la momentul rulării ce politică să ia în considerare? Până acum, doar intenţia de actualizare implicită este aplicată. Aveţi nevoie de un mod de a distinge identitatea cererilor din bean-ul nostru sesiune. Puteţi da instrucţiuni runtime-ului prin intermediul identităţii cererii. Aşa cum s-a discutat anterior, operaţia de actualizare pe bean-ul entitate este întotdeauna controlată de metoda increaseLargeAccountsAPR de pe bean-ul sesiune AccountManager. Deoarece intenţia de acces implicită a bean-ul entitate Account este intenţia de acces actualizare, nu este nevoie să configuraţi această metodă increaseLargeAccountsAPR.  Ea este rulată întotdeauna sub intzenţia de acces actualizare implicită.  

În continuare, doriţi să configuraţi un task pe metoda getLargeAccounts pe bean-ul sesiune AccountManager. Folosiţi acest task pentru a identifica cererea la profilul de aplicaţie.   Reţineţi că cererea trebuie să conţină un context UOW (unit-of-work), cum ar fi o tranzacţie sau o sesiune actvitate, deoarece taskul este parte a unei unităţi de lucru (UOW).  Următoarea secţiune va explica cum să faceţi partea de task a unui UOW.  Fiecare cerere făcută la metoda getLargeAccounts este asociată cu taskul creat în această secţiune. Aceste task este apoi propagat la toate cererile făcute în cadrul metodei getLargeAccounts şi pot fi folosite pentru a identifica intenţia acestei metode particulare.

  1. Localizaţi secţiunea Container-Managed Tasks pe pagina Extended Access şi faceţi clic pe Add pentru a deschide vrăjitorul Task method policies.
  2. Selectaţi AccountManager din meniul Bean.
  3. Selectaţi getLargeAccounts(double) din meniul Signature.
  4. Selectaţi Remote din meniul Type.
  5. Introduceţi un nume şi o descriere.   Atributul Name este folosit pentru a identifica cererea la un profil de aplicaţie. Atributul Description este doar pentru dumneavoastră şi nu este folosit la momentul rulării.
  6. Faceţi clic pe Finish.


Configurarea atributelor tranzacţiei

Principiul de design al acestei aplicaţii este folosirea bean-ului sesiune AccountManger ca un controler care determină ce politică de intenţie acces să se aplice bean-ului entitate Account.   De aceea, AccountManager va gestiona şi unitatea de lucru (UOW) asociată cu cererea.   Deşi tipul UOW poate fi o tranzacţie sau o sesiune activitate, această aplicaţie se ocupă doar de tipul tranzacţie de UOW.  În cazul bean-urilor tranzacţie gestionate de container, cum ar fi bean-ul AccountManager şi Account, tranzacţia este determinată de configuraţia atributului tranzacţie definită în descriptorul de implementare.

Aţi configurat un task pe metoda getLargeAccounts a bean-ului AccountManager.   Pentru a face taskul parte a unei unităţi de lucru (UOW), care este o tranzacţie în acest caz, trebuie să configuraţi atributul transaction al metodei getLargeAccounts ca RequiresNew, astfel încât o nouă tranzacţie va începe la punctul de invocare a metodei getLargeAccounts şi taskul configurat pe acea metodă va deveni parte a acestei noi tranzacţii.   Reţineţi că dacă metoda getLargeAccounts nu este configurat cu atributul transaction RequiresNew, se va renunţa la taskul configurat pe ea.  Vă rugăm consultaţi documentaţia pentru Profil aplicaţie pentru informaţii suplimentare.

Mai departe aveţi de configurat atributul tranzacţie al metodei findLargeAccounts a bean-ului Account ca Mandatory, astfel încât metoda findLargeAccounts se va executa în domeniul (scope) tranzacţiei care vine cu cererea.   Dacă cererea vine de la metoda getLargeAccounts a bean-ului AccountManager, tranzacţia conţine taskul configurat pe metoda getLargeAccounts.  Acest task va fi folosit în serviciul Application Profile pentru a determina ce politică de intenţii acces se aplică bean-ului Account.

Pentru a simplifica configuraţia, puteţi configura fiecare metodă a bean-ului AccountManager cu atributul de tranzacţie RequiresNew şi fiecare metodă a bean-ului Account cu atributul tranzacţie Mandatory.


Observarea politicilor WebSphere de intenţie acces predefinite

WebSphere Application Server se livrează cu şapte politici de intenţie acces predefinite: