WorkArea |
|
|
![]() |
|
Configurare şi rulare | Note tehnice | Javadoc | Construire cu Ant |
Localizarea codului sursă |
Cum lucrează Exemplul Company Context |
Localizaţi codul sursă în:
z/OS: Codul sursă pentru Exemple nu este furnizat pe platforma z/OS deoarece aplicaţiile Exemplu nu sunt construite pe platforma z/OS.
Exemplul WorkArea Company Context verifică instalarea corectă şi configuraţia serviciului WorkArea şi a serviciului partiţie WorkArea în trei medii runtime suportate: client J2EE (Java 2 Enterprise Edition), servlet şi bean-uri enterprise. Un flux operaţional abstract arată folosirea corectă a API-ului WorkArea şi sugerează cum ar trebui folosit serviciul WorkArea într-o aplicaţie comercială reală.
Funcţia serviciului WorkArea este de a comunica implicit mediul unui client către runtime-ul serverului, astfel încât procesarea în aval să se poată configura singură după starea runtime a clientului. În exemplul Company Context, sunt identificate două trăsături ale clienţilor: prioritatea şi compania. Prioritatea poate fi Platinum, Gold, Silver, Bronze sau Tin, unde Platinum este cea mai mare prioritate şi Tin este cea mai mică. Companie identifică cu ce birou filială este asociat clientul.
Aplicaţia este extrem de simplă. Logica operaţională este încapsulată de două bean-uri de sesiune: Bean şi BackendBean. Fiecare interfaţă defineşte aceeaşi metodă:
String [] test( );
Reţineţi că metoda test nu are parametri. String [ ] întoarce textul afişare clientului original.
Exemplul are doi clienţi: un client J2EE şi un servlet. După ce un utilizator selectează o prioritate şi o companie (sau acceptă valorile implicite), clientul invocă Bean. Înainte ca cererea la distanţă să fie lansată, implementarea clientului începe o zonă de lucru pe partiţia UserWorkArea şi o partiţie exemplu, dacă ea există pe server. Aceste partiţii sunt populate cu informaţii despre companie şi prioritate. Compania este setată la read_only; clientul nu vrea ca logica operaţională să opereze sub altă identitate de companie. Apoi este invocat Bean.
Mai întâi Bean încearcă să scrie în zona de lucru importată pe partiţia UserWorkArea şi eşuează; scrierea în zona de lucru importată este în mod explicită refuzată de modelul de programare WorkArea, deoarece partiţia UserWorkArea este configurată cu proprietatea Bidirectional setată la false (pentru mai multe explicaţii despre această proprietate şi despre alte proprietăţi de configuraţie pentru o partiţie, vedeţi documentaţia despre WorkArea). Dacă partiţia exemplu este definită Bean încearcă să scrie şi în partiţia exemplu. Această operaţie reuşeşte dacă partiţia exemplu există şi a fost configurată cu proprietatea Bidirectional setată la true. Va eşua dacă este configurată cu proprietatea Bidirectional setată la false. Apoi, bean-ul începe o nouă zonă de lucru pe partiţia UserWorkArea. Dacă partiţia exemplu există şi nu este configurată ca Bidirectional (proprietatea setată la false), atunci Bean începe şi o nouă zonă de lucru pe partiţia exemplu. Dacă partiţia exemplu există şi este configurată ca Bidirectional (proprietatea setată la true), atunci Bean nu începe o nouă zonă de lucru, dar setează contextul (o pereche valoare cheie) în zona de lucru.
Această activitate demonstrează diferenţa între configurarea unei partiţii ca să aibă propagare bidirecţională a contextului său şi configurarea unei partiţii să propage contextul său într-o unică direcţie. Dacă partiţia exemplu este configurată să fie bidirecţională, atunci contextul setat în partiţia exemplu se propagă la BackendBean, precum şi înapoi la apelant (client). Pentru a ilustra cum este impusă proprietatea read_only, implementarea Bean încearcă prima dată să înlocuiască proprietatea company şi eşuează. În final, Bean înlocuieşte prioritatea cu succes. Teoretic Bean doreşte să seteze temporar o nouă prioritate şi acţionează ca propriul client la obiectul BackendBean.
Obiectul BackendBean este poziţionat ca helper la Bean; poate fi o funcţie de înregistrare în istoric sau de urmărire, sau poate reprezenta o căutare de cont client. Implementarea începe o zonă de lucru pe partiţia UserWorkArea şi setează contextul. Dacă partiţia exemplu există, obiectul BackendBean nu începe o nouă zonă de lucru, dar încearcă să seteze contextul. Setarea reuşeşte sau eşuează în funcţie de valoarea proprietăţii Bidirectional. În final, obiectul BackenBean trage afară toate cheile şi valorile celor două zone de lucru importate, pe partiţia UserWorkArea pentru a demonstra funcţia retrieveAllKeys( ). Observaţi că cheile înlocuite sunt extrase doar o dată; funcţia reprezintă cu adevărat setarea matematică a tuturor cheilor. Obiectul BackendBean trage afară şi perechile cheie valoare din partiţia exemplu. Dacă partiţia exemplu există, observaţi diferenţa din contextul conţinut în ambele partiţii, atunci când partiţia exemplu este configurată diferit de partiţia UserWorkArea.
Bean termină zona de lucru imbricată când se termină apelul la obiectul BackendBean; restul logicii operaţionale operează sub zona de lucru importată a clientului pe partiţia serWorkArea. Implementarea se uită la compania clientului şi declară că dacă compania este un birou de vânzări, serviciul este refuzat.
În final, Bean se întoarce la apelant (client). Clientul tipăreşte contextul rezultant
al partiţiei UserWorkArea şi al partiţiei exemplu. Dacă partiţia exemplu există şi este configurată să fie bidirecţională, atunci contextul setat
de Bean şi de obiectul BackendBean se afişează pe client.
Dacă partiţia exemplu există şi nu este configurată să fie bidirecţională, atunci contextul setat
de Bean şi de obiectul BackendBean nu se afişează, şi se afişează doar contextul setat de client.
În acest caz, contextul pentru ambele partiţii este egal.