POC - SOA Proof of Concept Demo

GoogleCodeExporter commented 9 years ago

1. Data Start:
...dec/2013

2. Data estimata finalizare:
09/12/2013

3. Responsabil
drd. Viorel Iacoban [viorel.iacoban@gmail.com]

4. Supervizori
Catalin Strimbei, Marin Fotache

5. Descriere sarcina
Proiect(e)-Concept pentru reformarea arhitecturii pe servicii.
Noile proiecte asociate unui modul:
- se doresc autonome din punctul de vedere al compilarii si instalarii;
- se doresc dependente doar prin "legaturi" de invocare servicii web.
Vezi si descriere de la Issue54 
[https://code.google.com/p/feaa-admitere/issues/detail?id=54]

Original issue reported on code.google.com by catalin....@gmail.com on 4 Dec 2013 at 11:33

GoogleCodeExporter commented 9 years ago

Data revizuita finalizare: 
16/12/2013

Principiile pe care am mers:

1. Introducerea modelului RDF pentru exprimarea datelor procesate de catre 
servicii(input/output). Serviciile intern vor fi responsabile de transformarea 
datelor RDF intr-un alt model intern; Pe langa resusele rezultate din 
procesarile efectuate, serviciile vor fi responsabile deocamdata si pentru 
specificare 'urmatoarelor actiuni' pana la eventual implementare a unui 
mecanism de coregrafie bazat pe configurare dinamica.
2. Servicile vor fi implementate in acord cu o interfata uniforma (un contract 
pentru toate serviciile) si vor fi orientate spre managementul unei anumite 
resurse.
3. Expunerea remote a servicilor se va face peste protocolul HTTP prin 
mijlocirea unui broker in respect cu stilul arhitectural REST. 'Brokerul' va fi 
responsabil de identificarea serviciilor de invocat relativ la un uri, de 
maparea metodelor HTTP si media-type peste operatii, maparea erorilor pe coduri 
HTTP.... etc.
4.Tehnologiile specifice de implementare pentru POC: Jena RDF api, Jersey. 
Proiectele sunt proiecte simple java... Demonstratia se va baza pe invocari 
dintr-o aplicatie sau un test.

Original comment by viorel.iacoban@gmail.com on 13 Dec 2013 at 9:03

GoogleCodeExporter commented 9 years ago

Din pacate nu am reusit sa commit ieri, dar fac tot posibilul sa 'pun sus' 
inseara asta ce am facut, pentru a avea o tema de dezbatere/analiza...

Original comment by viorel.iacoban@gmail.com on 17 Dec 2013 at 2:24

GoogleCodeExporter commented 9 years ago

Pentru a putea intelege arhitectura, cred ca am avea nevoie 
- si de o minima descriere a modului/fluxului de lucru, 
- poate si o minima diagrama UML (fie si o "poza"), 
- si un test start-up care sa ne dea un punct de plecare pe care sa-l urmarim 
in implementarea aplicatiei ...

Original comment by catalin....@gmail.com on 18 Dec 2013 at 6:34

GoogleCodeExporter commented 9 years ago

Desi cu importante intarzieri, am comis proiectele demo pentru o abordare 
soa-rest a aplicatiei pentru admitere.
Deocamdata testele trebuie facute cu un client HTTP: eu am folosit Fiddler care 
are un composer pentru apeluri HTTP.
In directorul poc de pe svn este si un exemplu de input pentru un post la 
serviciul Inscriere.
Voi reveni pentru Luni cu:
- cu o diagrama, cateva explicatii si principii de lucru;
- un client web (care sa faca apelurile si sa construiasca o interfata 
minnimala);
- directii viitoare si probleme de rezolvat, daca modelul va fi validat;

Original comment by viorel.iacoban@gmail.com on 17 Jan 2014 at 7:05

GoogleCodeExporter commented 9 years ago

Pentru a putea testa, trebuie urmati pasii urmatori:
1. Dupa ce s-a facut 'checkout' la surse, trebuie rezolvata acea eroare de 
restricted access la acel server din jdk,... pur si simplu in eclipse marcat ca 
warning...;
2. Proiectele care se termina in '.servicesweb' expun serviciile 
corespunzatoare unui modul/aplicatie si trebuie pornite ca si aplicatii java 
(clasa Program);
3. Dupa parcurgerea pasului 2 se pot invoca serviciile;
4. Exista un client web(incomplet inca) care invoca serviciile din javascript. 
Este o aplicatie web simpla si poate fi rulata folosinf serverul HTTP Preview 
din eclipse;
5. Pentru o mai mare flexibilitate in testare (deoarece clientul web e 
incomplet) se poate folosi un composer (ex: http://fiddler2.com/).
Revin cu instructiuni ...

Original comment by viorel.iacoban@gmail.com on 24 Jan 2014 at 7:50

GoogleCodeExporter commented 9 years ago

6. Pentru a testa unitar se poate incepe cu un GET la serviciul initial 
http://localhost:9992/Inscriere. Ca raspuns va fi furnizat un RDF in care mai 
relevante sunt doua resurse. GET pe fiecare dintre cele doua URI-uri, va fi 
returnata o lista de categorii fise si, respectiv, informatii despre candidat. 
Post la serviciul Inscriere (cu rdf-ul din folderul samples - eventual 
modificat dupa gusturile proprii) va avea ca efect "salvarea unei fise" si 
returnarea unui RDF continand URI-ul resursei salvate....
GET, DELETE, PUT la serviciul http://localhost:9991/CategorieFisa ar trebui sa 
obtineti efectul asociat: obtinere categorii/categorie, stergere, salvare...
7. Clientul Web este un demo (nefinisat) a apelarii serviciilor de mai sus 
(doar GET) si procesarii output-ului RDF folosind Javascript (jquery, si un 
plugin jquery pentru rdf)...Il voi evolua pentru a demonstra un post prin 
parsarea RDFa dintr-un form...

Original comment by viorel.iacoban@gmail.com on 24 Jan 2014 at 4:41

GoogleCodeExporter commented 9 years ago

Am finalizat Clientul Web. Acum este disponibil si POST-ul la serviciul 
Inscriere. Input-ul este obtinut prin extrgerea unui rdf din adnotari rdfa. 
Urmeaza de acum sa dezbatem...

Original comment by viorel.iacoban@gmail.com on 27 Jan 2014 at 8:09

catalinstrimbei / feaa-admitere

POC - SOA Proof of Concept Demo #55