Raport Etapa I

SCIPA - Stabilirea cerințelor în contextual lumii reale

SCIPA

Servicii software semantice de Colaborare si

Interoperabilitate pentru realizarea Proceselor

Adaptive de business

Stabilirea cerinţelor în contextual lumii reale

Autori – Academia de Studii Economice Bucureşti

Prof. dr. Ion Smeureanu – responsabil științific,

Prof. dr. Ion Gh. Roşca,

Conf. dr. Marian Dârdală,

Conf. dr. Titus-Felix Furtună,

Lect. dr. Adriana Reveiu,

Lect. dr. Ramona Bologa,

Prep. drd. Andreea Dioşteanu,

Drd. Alexandra Tudorache

Contract nr. 12118/01.10.2008

Autoritatea contractantă: CNMP

SCIPA - Stabilirea cerinţelor în contextual lumii reale

2

CUPRINS

Partea I– Definirea cerinţelor utilizatorilor şi a cazurilor utilizator ................................... 3

1 Modelarea proceselor de business .................................................................................. 7 1.1 Modalitatea generală de lucru în vederea proiectării modelului de business ............. 7

1.2 Simularea proceselor .................................................................................................. 9

1.3 Maparea modelului de business peste modelul lingvistic implementat cu ajutorul

ontologiilor şi semanticii web ................................................................................................ 9

2 Analiza procesului de afaceri pentru construirea ontologiilor .................................. 12 2.1 Metodologie de analiză de tip proces-activitate ....................................................... 12

2.2 Colectarea informaţiilor despre activităţi şi procese ................................................ 15

2.3 Gestiunea lanţului de activităţi aprovizionare-desfacere – caz utilizator ................. 15

3 Cerinte ale unei platforme de interoperabilitate bazate pe semantici, ontologii si

reguli de afaceri ...................................................................................................................... 18 3.1 Testarea compatibilitatii regulilor de afaceri corespunzatoare organizatiilor

implicate intr-o solutie de interoperabilitate ........................................................................ 18

3.2 Integrarea semanticii vocabularului regulilor de afaceri .......................................... 18

3.3 Compatibilizare la nivel de procese de afaceri. Interpretarea abstracta si concreta a

unui proces de afaceri ........................................................................................................... 19

3.4 Urmarirea gradului de aliniere a sistemului informatic la strategia firmei .............. 20

3.5 Impactul adaptabilitatii proceselor de afaceri asupra proiectarii platformei de

interoperabilitate ................................................................................................................... 20

3.6 Orientarea tehnologica a platformei ......................................................................... 21

3.7 Identificarea nevoilor si ofertelor de cooperare ....................................................... 21

3.8 Identificarea sabloanelor de colaborare agreate de o firma ...................................... 21

3.9 Alegerea celor mai influenti agenti economici din lantul de creare a valorii noi

adaugate. ............................................................................................................................... 21

4 Soluţii de cooperare virtuală pentru mediu de afaceri ............................................... 23 4.1 Structuri virtuale ....................................................................................................... 24

4.1.1 Biroul virtual .................................................................................................... 24

4.1.2 Întreprinderea virtuală ...................................................................................... 24

4.1.3 Organizaţia virtuală .......................................................................................... 26

4.1.4 Echipa virtuală .................................................................................................. 26

4.2 Caracteristicile întreprinderii virtuale ...................................................................... 26

4.3 Vectorii virtualităţii. Avantaje şi riscuri în întreprinderea virtuală .......................... 33

4.4 Implicaţiile virtualizării structurii organizatorice .................................................... 35

4.4.1 Implicaţii din punct de vedere al strategiei competitive .................................. 35

4.4.2 Implicaţii din punct de vedere al costurilor tranzacţionale .............................. 36

4.4.3 Implicaţii din punct de vedere al dreptului de proprietate ............................... 36

4.4.4 Avantaje şi riscuri ale cooperării în cadrul întreprinderilor virtuale ................ 37

Bibliografie .............................................................................................................................. 38


3

Partea I– Definirea cerinţelor utilizatorilor şi a cazurilor utilizator

Rezumat Parte

Majoritatea proceselor de business au fost documentate în vederea creării unor

modelele de management complexe. Datorită volumului mare de informaţii şi transformărilor

care au loc în domeniul IT&C, companiile se confruntă cu probleme care nu mai pot fi

modelate şi tratate conform metodelor tradiţionale. În vederea soluţionării cât mai eficiente a

problemei modelării proceselor de afaceri, au fost create ontologii, semantici web şi sisteme

bazate pe agenţi inteligenţi.

Pentru modelarea cât mai aproape de realitate a proceselor de afaceri, există

posibilitatea de a defini regulile după care se defăşoară. În vederea implementării unui model

de business, primul lucru care trebuie avut în vedere este modelul serviciilor web care

conţin funcţionalităţile specifice fiecărui element al modelului.

Semantica utilizată în modelul lingvistic se bazează pe ontologii. Regulile semantice şi

lexicale vor fi create pe baza unor euristici conform regulilor lingvistice şi a logicii

economice. Prin intermediul modelului lingvistic sunt reprezentate: fluxurile de date,

mesajele, evenimentele, regulile de afaceri, excepţiile, tranzacţiile (distribuite, sincrone,

asincrone, etc).

Modelarea proceselor de business este o etapă esenţială în cadrul unei organizaţii. Cu

ajutorul acestor modele se vor putea valorifica mai uşor şi mai eficient experienţele

anterioare.

Toate tehnicile de analiză bazate pe metoda proces-activitate presupun analiza afacerii

pentru a obţine informaţii semantice referitoare la activităţile efectuate şi modul de transfer

al informaţiilor între activităţi și pot fi folosite în vederea construirii ontologiilor. Utilizarea

acestor tehnici transcede orice sector al industriei. Această metodă poate fi aplicată la orice

nivel al unei organizaţii, la colaborarea între organizaţii, oricărei activităţi care consumă

resurse. Operaţiile sunt formate dintr-un număr de subprocese, unele dintre acestea fiind de

tip suport şi sunt comune majorităţii organizaţiilor precum: aprovizionare, recrutare de

personal, gestiunea informaţiilor. Alte operaţii sunt specifice domeniului analizat, şi

formează o listă de aşteptare. În funcţie de activităţile şi procesele folosite, datele trebuie

colectate de la persoanele care participă la realizarea activităţilor din fiecare centru de

buget sau sub-proces.

Există o serie de metode care pot fi folosite pentru colectarea datelor în vederea

construirii semanticilor.

Gestiunea lanţului de activităţi de la aprovizionare până la desfacere presupune

controlul și coordonarea tuturor activităţilor unei organizaţii de la furnizorii de produse la

clienţii săi și poate fi folosită drept caz utilizator pentru sistemul IT integrat.

Regulile de afaceri se referă la multitudinea de politici, proceduri sau definiţii care

guvernează modul de funcţionare al unei organizaţii, împreună cu interacţiunea acesteia cu

furnizorii si beneficiarii săi. Reiese ca orice interoperabilitate trebuie sa asigure


4

respectarea sistemului de reguli de afaceri ale fiecarui participant intr-o solutie de

interoperabilitate.

Completitudinea si coerenta sistemului de reguli de afaceri la nivelul unei organizatii

cade in sarcina organizatiei; in cazul unei platforme de colaborare, compatibilizarea

regulilor de afaceri dupa care se conduc partenerii cade in sarcina platformei.

O solutie de interoperabilitate bazata pe agenti va avea ca suport informatia oferita de

sistemele informatice ale partenerilor implicati, impreuna cu dictionarul semantic al

domeniului de business.

Desi aparent cooperarea intre firme n-ar trebui sa implice cunoasterea detaliilor

privind procesele de afaceri, ci numai "interfetele" lor, in realitate pot exista constrangeri

privind procesele tehnologice, succesiunile de activitati, calitatea output-urilor etc. Spre

exemplu, un proces tehnologic nu poate utiliza decat o materie prima de o anume calitate sau

obtinuta la randul ei numai printr-un anumit proces tehnologic.

Agentul de negociere a unei cooperari trebuie sa aiba capacitatea abstractizarii unui

proces de afaceri, sa inceapa cautarea cu semantica nivelului cel mai abstract, procedand

apoi la particularizari specifice unui domeniu de afaceri.

Schimbarile majore din sistemele informatice ale firmelor se produc ca urmare a

schimbarilor din procesele de afaceri. La proiectarea unei platforme de interoperabilitate

trebuie sa se tina seama de directia evolutiei, pentru a asigura adaptabilitatea. Pentru a

aprecia gradul de aliniere a sistemului informatic la strategia firmei. Intotdeauna se incepe

cu clientii urmarindu-se adaptarea produselor la asteptarile acestora; se continua cu analiza

procesului de business care sa permita obtinerea produselor dorite; abia apoi sunt deduse

tehnologiile necesare, informatiile si tipul participantilor la un astfelde proces.

Corelarea se produce in ambele sensuri şi poate fi apreciata la un moment dat

(static), dar si in dinamica, cand o modificare a unui element atrage schimbari in lant

(produse noi care presupun schimbari tehnologice, training pentru adaptare la noua

tehnologie, achizitia de noi informatii si cunostinte).

Cunoasterea flexibilitatii si limitelor proceselor tehnologice, dar si a sistemelor

informatice de a se reconfigura pe masura schimbarilor din mediu de afaceri, reprezinta un

criteriu esential in selectarea oportunitatilor si posibilitatilor de cooperare intre firme.

Teoretic, arhitectura SOA incapsuleaza integral un domeniu de business; maniera in

care o face este insa esentiala si depinde de abilitatea celui care modeleaza. In principiu, se

urmareste gasirea unui echilibru intre diminuarea numarului de dependente dintre servicii

(deoarece la un numar mare de interactiuni, modificarea unui serviciu antreneaza modificari

in cascada in alte servicii) si evitarea unei granularitati exagerate, care ar conduce la o

complexitate prea mare a sistemului. Alegerea unui nivel optim de descompunere a

proceselor pe servicii asigura posibilitatea reconfigurarii sistemului prin compunerea

serviciilor existente si doar rareori scrierea de noi servicii.

Solutia de interoperabilitate trebuie sa fie orientata spre noile tehnologii de realizare a

sistemelor informatice pentru afaceri, urmand ca sistemele mostenite (legacy systems) sa

beneficieze de facilitatile unei astfel de platforme numai dupa expunerea functionalitatii lor

prin servicii. Odata realizata aceasta transpunere, modificarea sau rescrierea totala a unei

functionalitati nu mai afecteaza ulterior schema de colaborare intre functii si nici intre firme.

Platforma trebuie sa dispuna de un set de sabloane de colaborare folosite uzual in

domeniul afacerilor. Se includ aici modele incepand cu simple acorduri de colaborare,

comenzi ferme emise in baza unor acorduri, contracte, pana la conventii prin care o firma


5

preia atributii decizionale pe un segment limitat de competente dintr-o alta firma (spre

exemplu, o firma furnizoare declanseza un proces de aprovizionare a unui supermarket).

Avand in vedere ca procesul de creare a valorii adaugate este un flux, profitul unei

firme depinde nu numai de performantele firmei si competitorilor, ci si de eficienta cu care

opereaza furnizorii si beneficiarii: acest lucru se explica prin faptul ca valoarea adaugata se

redistribuie prin preturi intre participanti, pe intreg lantul in care e creata.

In consecinta, la alegerea partenerilor de afaceri, firma este interesata sa colaboreze

cu cei mai influenti si eficienti participanti din lantul de creare al valorii adaugate.

Platforma de interoperabilitate trebuie eventual sa permita utilizatorilor sa adere la

anumite lanturi de creare a valorii nou adaugate.

Noua economie digitală, bazată pe Internet este o economie a afacerilor clădite în jurul

serviciilor Internet şi a reţelelor electronice, o economie în care apar noi forme de companii

şi noi forme de muncă. În noua economie se observă o schimbare a paradigmelor legate de

producţie şi management care însoţeşte trecerea de la societatea industrială la societatea

informaţională.

Întreprinderile virtuale sunt create pentru a veni în întâmpinarea unor anumite

oportunităţi ivite pe piaţă şi sunt dizolvate în momentul în care oportunitatea dispare.

Integrarea virtuală , opusă integrării verticale, va fi probabil fundamentul pentru o strategie

de afaceri competitivă.

Caracteristic oricărui obiect virtual este posibilitatea formării şi dizolvării legăturilor

dintre părţile componente pentru a reacţiona rapid şi eficient la diferitele probleme ce apar

în sistem sau în mediul său înconjurător.

Biroul virtual defineşte companie sau un parteneriat de natură permanentă, dar care

are un număr important de angajaţi la distanţă. Biroul virtual îndeplineşte rolul biroului

tradiţional, centralizat, dar pe de altă parte, angajaţii lucrează în birouri aflate la domiciliu,

şi colaborează în cea mai mare parte a timpului electronic, venind doar ocazional în contact

cu ceilalţi angajaţi.

Întreprinderea virtuală este o reţea, mai mult sau mai puţin temporară, alcătuită din

întreprinderi sau persoane independente din punct de vedere juridic care care îşi unesc

bunurile, competenţele şi alte resurse în scopul realizării unui proiect comun care depăşeşte

capacităţile fiecăreia dintre unităţi luată individual în ceea ce priveşte posibilitatea de a

exploata oportunităţile volatile, de a avea acces la noi pieţe şi de a partaja costurile şi

riscurile, întreagă această suprastructură bazându-se pe noile tehnologii ale informaţiei şi

telecomunicaţiilor.

O organizaţie virtuală (sau organizaţia cu structură organizatorică virtuală) este

formată din unităţi organizatorice distribuite care participă la un proces de muncă

coordonat, divizat, unităţi ce sunt părţi ale unei reţele complexe susţinute de tehnologii

informaţionale corespunzătoare.

Pornind de la definiţia biroului virtual, putem defini echipa virtuală ca fiind construită

pentru situaţii în care membrii săi sunt distribuiţi geografic. Atât biroul, cât şi echipa virtuală

presupun membrii distribuiţi, aşadar au nevoie de infrastructură similară şi vor necesita

planificare şi executare a sarcinilor într-un mediu cu restricţii de resurse.

Pentru interconectarea întreprinderilor în întreprinderi virtuale este important nivelul

executiv, unde există numeroase procese care pot să beneficieze de pe urma tehnologiei

informaţiei şi chiar să fie complet automatizate.


6

Abordările mai noi ale integrării întreprinderilor virtuale propun un model al fluxului

de producţie interorganizaţional pe trei niveluri, care surprinde fluxurile de producţie ale

partenerilor, viziuni ale fluxurilor şi fluxuri ale coaliţiei. În acest mod sunt depăşite limitările

modelului cu un nivel (punct la punct) sau cu două niveluri (privat-public).

Caracteristica esenţială a unei întreprinderi virtuale este virtualitatea, o capacitate pe

care fiecare o posedă într-o măsura mai mare sau mai mică,.

Virtualitatea este definită ca abilitatea unei organizaţii de a obţine şi menţine

competenţe critice prin modelul proceselor sale de adăugare a valorii şi prin structura sa

organizaţională. Compania obţine toate competenţele necritice din exterior, adică de la alte

companii, împreună cu care formează o întreprindere virtuală. De aceea, conceptual tinde să

extindă din punct de vedere conceptual noţiunile de eficienţă şi eficacitate la mai multe

companii, şi, de exemplu prin externalizare sau francizare, să lege resursele într-o companie

fără să fie nevoie să investească pentru ele.

Folosirea comună a capacităţilor de producţie, canalelor de distribuţie, aprovizionare

şi a altor resurse (potenţate de posibilitatea de comunicare şi monitorizare prin TIC) conduce

la reducerea costurilor globale, apariţia unui efect de sinergie, a economiilor de scală şi a

creşterii calităţii) datorită încrederii, destinului comun.

Un alt aspect benefic este schimbul de cunoştinţe legate de tehnicile de producţie

eficiente din punct de vedere al costurilor, activităţile comune în domeniul cercetării–

dezvoltării bazate pe groupware, email, videoconferinţe, etc.

Ca urmare, apare producţia comună de bunuri şi servicii inovative, puternic orientate

spre client. Accesul lărgit la informaţii, legate spre exemplu de modificarea cerinţelor

clientului, reduce mult timpul de reacţie la schimbările de pe piaţă. Ambele efecte oferă

protecţie faţă de produsele substitut, în cazul în care substituibilitatea produselor şi

serviciilor este corelată negativ cu complexitatea acestora. Are loc o reducere a timpului şi

costurilor de comunicaţie şi creşterea vitezei tranzacţiilor de plată prin mijloace electronice,

ceea ce conduce la îmbunătăţirea rezultatelor financiare.


7

1 Modelarea proceselor de business

Companiile investesc sume uriaşe în managementul proceselor de business. Majoritatea

proceselor de business au fost documentate în vederea creării unor modelele de management

complexe. Datorită volumului mare de informaţii şi transformărilor care au loc în domeniul

IT&C, companiile se confruntă cu probleme care nu mai pot fi modelate şi tratate conform

metodelor tradiţionale. În vederea soluţionării cât mai eficiente a problemei modelării

proceselor de afaceri, au fost create ontologii, semantici web şi sisteme bazate pe agenţi

inteligenţi.

Pentru modelarea proceselor de business există o serie de limbaje care pot fi utilizate:

UML şi BPMN. SCIPA îşi propune ca pornind de la unul dintre aceste limbaje (BPMN este

candidatul preferat), să dezvolte o extensie care va include caracteristici precum: specificarea

proceselor colaborative inter-întreprinderi şi utilizarea şabloanelor de cooperare, cât şi

instrumente de modelare şi simulare asociate. Astfel se doreşte dezvoltarea unui model al

proceselor de business care să permită adnotarea semantică a componentelor (pe baza unei sau

mai multor ontologii ale cunoştiinţelor de business) şi modelarea aspectelor adaptive în

funcţie de context şi mediul specific.

Un astfel de model va fi privit sub forma unei diagrame care va surprinde toate etapele

principale ale procesului, actorii implicaţi şi acţiunile întreprinse. În spatele componentelor

acestei diagrame vor fi apeluri către webservice-uri care conţin funcţionalităţi specifice.

Alături de această component grafică de bazat pe ontologii pornind de la BPML, un limbaj

care să faciliteze regăsirea modelare, mediul de lucru va avea şi un limbaj de modelarea

(Language Modelling) semantic informaţiilor (Querry Language, o extensie a BPMQ) şi

instrumente de simulare şi adaptare a procesului modelat pe situaţii concrete de lucru.

Modalitatea de lucru folosind soluţia propusă va fi intuitivă şi similară metodelor de

modelarea ale analiştilor de business astfel încât utilizatorii obişnuiţi (fără cunoştiinţe solide

de IT) să nu întâmpine dificultăţi. De asemenea, notaţiile şi reprezentările utilizate vor fi

accesibile şi uşor de înţeles de către toţi utilizatorii din lumea de afaceri care participă la

modelarea proceselor, începând cu analiştii care concep schemele iniţiale şi până la

responsabilii tehnici care vor implementa aceste procese.

Soluţia oferită va integra modelul adaptiv semantic bazat pe colaborare, cu

funcţionalităţi care permit compunerea serviciilor cu agenţi cognitivi (practic pornind de la

ontologiile dezvoltate pentru procesul de afaceri, împreună cu modelul adaptiv şi serviciile

identificate se vor dezvolta sisteme inteligente) ce vor simula condiţiile reale din mediul de

afaceri modelat. Pentru a modela corect un proces de afaceri este necesară parcurgerea

următoarelor etape.

1.1 Modalitatea generală de lucru în vederea proiectării modelului de business

Se va specifica o singură diagramă de proces. Această diagramă va fi uşor de utilizat şi

înteles chiar şi de către persoanele care nu au experinţă în domeniul tehnic (de obicei

managerii). De asemnea, această diagramă va fi suficient de expresivă pentru a permite

modelarea proceselor de business foarte complexe care vor fi ulterior mapate uşor în limbajele

de implementare, simulare şi execuţie.

Pentru a modela un proces, utilizatorul va trebui să:


8

identifice evenimentele importante din cadrul procesului de afaceri

să modeleze evenimentele identificate

să proceseze evenimentele care se execută

să centralizeze rezultatele obţinute.

La pasul următor, se identifică elementele de tip decizional, precum şi elementele de

ramificare ale fluxului. Acestea se vor modela cu ajutorul unor elemente speciale denumite

“gateways”. Aceste elemente vor fi similare cu blocurile decizionale din cadrul schemelor

logice.

De asemenea, un proces poate conţine la rândul lui alte subprocese, care vor fi

reprezentate grafic prin intermediul unei alte diagrame conectate prin intermediul unei

legături de blocul de tip proces care reprezintă părintele. Procesele care nu se vor descompune

în alte subprocese sunt considerate task-uri (cel mai jos nivel de proces). Simbolizarearea

grafică se realizează prin semnul “+” lângă numele procesului conform reprezentării specifice

BPMN. Procesele care nu au acest semn sunt task-uri.

Pentru a scpecifica “cine ce face” evenimententele şi procesele vor fi plasate în aşa

zisele “piscine” care denotă cine execută procesul respectiv. Aceste elemente de grupare pot fi

partiţionate la rândul lor. Spre exemplu, organizaţia poate reprezenta “piscina”, iar o

subdiviziue a ei să fie un department sau o divizie.

Evenimentele care se execută pot fi de mai multe tipuri şi complexităţi. Când se

modelează fluxuri de proces mai complexe cum sunt serviciile web B2B se vor folosi

evenimente mai complexe precum: mesaje, timere, reguli de business, condiţii de eroare,etc.

În centrul modelării procesului de business se află chiar procesele care pot fi de trei

tipuri: proces, subproces şi task. De aceea este foarte important ca utilizatorul să identifice

corect procesele şi ieararhiile care se stabilesc între acestea încă de la începutul etapei de

proiectare.

Blocurile de decizie care modelează logica interacţiunii dintre procese vor a avea

implementări specifice fiecărui tip de operator logic: “sau”, “şi”, “sau-exclusiv”. De

asemenea, va exista o modelare specifică şi pentru deciziile complexe realizate prin

compunerea oparaţiilor logice.

Pentru modelarea cât mai aproape de realitate a proceselor de afaceri, există

posibilitatea de a defini regulile după care se defăşoară. Sistemul nu permite crearea de

legături între blocuri în situaţia în care sunt încălcate regulile respective. Astfel se reduce

riscul de a introduce erori sau inconsistenţe logice în proiectarea modelului.

Transformarea fluxului de date de-a lungul diagramei

În cadrul organizaţiei, datele sunt transformate prin intermediul proceselor. Spre

exemplu, un proces de tip comandă determină crearea unei comenzi. Atunci când produsul

este livrat către consumator comanda a fost realizată. Dacă apar inconsistenţe în modul de

achitare al comenzii (informaţii eronate cu privire la datele despre cont , etc) se poate

determina anularea comenzii. Clientul poate să îşi corecteze informaţiile legate de cont.

Pentru modelarea datelor în cadrul unei diagrame de proces, se vor identifica

principalele tipuri de date şi se vor utiliza obiecte de tip dată. Obiectele de tip dată sunt

artefacte care reprezintă tipuri de elemente electronice şi fizice. Datele reprezintă în esenţă

entităţi (corespunzătoare tabelelor din baza de date) sau clase (corespunzatoare modelelor

orientate obiect care conţin date).


9

Modelarea datelor poate fi opţională deoarece nu afectează în mod direct fluxul, ci mai

degrabă oferă informaţii despre anumite procese.

1.2 Simularea proceselor

Un model descris conform paşilor de mai sus reprezintă o descriere logică a fluxului.

Pornind de la modelul realizat, se va putea defini semantica asociată. Totuşi, pentru a obţine

rezultate optime această abordare trebuie sincronizată cu etapa de simulare a procesului.

Simularea pentru un model, se referă la “mimarea” operaţiilor de business care se vor

realiza, prin testarea pas cu pas a evenimentelor. Pe parcursul simulării vor fi înregistrate

metrici de performanţă care vor fi ulterior analizate şi evaluate. Avantajul acestei etape este

acela că reduce considerabil riscul de a comite erori cu consecinţe grave în mediul real de

lucru.

1.3 Maparea modelului de business peste modelul lingvistic implementat cu ajutorul ontologiilor şi semanticii web

Semantica utilizată în modelul lingvistic se bazează pe ontologii. Structura reţelei va fi

similară cu cea din WordNet. Regulile semantice şi lexicale vor fi create pe baza unor

euristici conform regulilor lingvistice şi a logicii economice. Modelul lingvistic va avea la

bază limbajul XML pentru modelarea şi structurarea informaţiilor.

În prezent, majoritatea modelelor lingvistice utilizează XML-ul şi sunt construite peste

limbajul de descriere al serviciilor web (WSDL) conform standardelor W3C. Fluxul major din

cadrul WSDL este acela că limbajul amestecă descrierea interfeţelor statice cu legarea

informaţiilor de anumite protocoale de comunicare.

Prin intermediul modelului lingvistic sunt reprezentate:

fluxurile de date;

mesajele;

evenimentele;

regulile de afaceri;

excepţiile;

tranzacţiile (distribuite, sincrone, asincrone, etc)

Serviciile web

În vederea implementării unui model de business, primul lucru care trebuie avut în vedere

este modelul serviciilor web care conţin funcţionalităţile specifice fiecărui element al

modelului. Serviciile web reprezintă baza pentru elementele descrise anterior. Această etapă

va avea la rândul ei 5 subetape:

proiectarea procesului de afaceri

dezvoltarea serviciilor care să implementeze funcţionalităţile pentru componentele

modelului

simularea procesului şi relizarea anumitor modificări în vederea sporirii eficienţei

publicarea serviciilor

modelarea serviciilor în concordanţă cu procesele de business prin asamblarea şi

coordonarea comportamentului lor.


10

Exemple de diagrame realizate cu pentru modelarea proceselor de afaceri cu BPMN

A. modelarea procesului de licitaţie

B. Modelarea procesului de afaceri pentru rezervarea biletelor

Modelarea proceselor de business este o etapă esenţială în cadrul unei organizaţii. Cu

ajutorul acestor modele se vor putea valorifica mai uşor şi mai eficient experienţele

anterioare.

De asemenea, datorită faptului că se va utiliza un limbaj intuitiv, concis şi clar pentru

reprezentarea proceselor, evenimentelor, datelor, etc în cadrul unui flux de afaceri, toate

persoanele implicate (de la analiştii de afaceri la persoanele tehinice care vor implementa

software-ul necesar) vor putea înţelege logica din spatele procesului modelat.

Figura 1. Procesul de afaceri din cadrul unei licitaţii [ORJ03]

Figura 2. Rezervarea biletelor [2]


11

Cu ajutorul modelelor grafic, lingvistic şi de simulare a procesului se vor putea crea mai

uşor reguli de business care vor reprezenta baza de cunoştiinţe a sistemului inteligent care va

sprijini managementul organizaţiei în procesul decizional.


12

2 Analiza procesului de afaceri pentru construirea ontologiilor

Toate tehnicile de analiză bazate pe metoda proces-activitate presupun analiza afacerii

pentru a obţine informaţii semantice referitoare la activităţile efectuate şi modul de transfer al

informaţiilor între activităţi. O serie de activităţi legate între ele formează un process.

Tehnicile bazate pe metoda process- activitate pot fi grupate în 3 mari categorii:

Cost/preţ/profit:

Cost per activitate,

Cost per produs sau serviciu,

Preţ per produs sau serviciu,

Profitul pieţei/canalului/sectorului sau clientului,

Preţul de transfer.

Creşterea performanţelor:

Planificarea proceselor şi activităţilor

Reducerea costurilor,

Analiza valorii,

Eliminarea constrângerilor,

Reingineria procesului de afaceri,

Integrarea fluxului de procese,

Benchmarking.

Gestiunea performanţelor curente:

Gestiunea bazată pe valoare,

Măsurarea şi gestiunea performanţelor,

Evaluarea la nivelul serviciului,

Bugetare bazată pe activitate,

Bugetare bazată pe prioritate,

Bugetarea şi contabilizarea resurselor (în sectorul public),

Benchmarking,

“Cea mai bună valoare”,

Contabilizarea bazată pe process,

Integrarea fluxului de procese.

Utilizarea acestor tehnici transcede orice sector al industriei. Această metodă poate fi

aplicată la orice nivel al unei organizaţii, la colaborarea între organizaţii, oricărei activităţi

care consumă resurse.

2.1 Metodologie de analiză de tip proces-activitate

Pentru realizarea analizei de tip activitate-proces se pleacă de la structura

organizaţională a companiei. Reprezentanţii fiecărui centru cu buget propriu din structura

organizaţională a departamentului sau unităţii de afaceri analizează activitatea realizată şi

operaţiile din cadrul activităţii desfăşurate.

Operaţiile şi activităţile sunt grupate în fluxuri de activităţi formând sub-procese,

acestea putând fi legate de procesele de bază ale afacerii. Procesele de bază sunt acele procese

care definesc scopul existenţei organizaţiei, procesele care au ca efect obţinerea serviciilor sau

produselor pe care compania le oferă. Toate activităţile şi sub-procesele desfăşurate în cadrul


13

companiei trebuie să contribuie la aceste procese de bază în diferite moduri. Acest tip de

analiză clarifică tipurile de relaţii şi permite înţelegerea modului în care funcţionează

afacerea.

În acest model de analiză numărul nivelurilor ierarhiei variază considerabil în funcţie de

mărimea organizaţiei şi de nivelul de detaliere cerut pentru a atinge obiectivele definite şi

pentru extragerea semanticilor.

Ierarhia care arată relaţiile şi contribuţiile la produsele şi serviciile finale este

reprezentată în figura 4.

Având ca exemplu activitatea unei agenţii imobiliare, structura organizaţională a

agenţiei imobiliare este prezentată pe verticală şi procesele de bază pe orizontală, în figura 5.

Diagrama din figura 5 prezintă modul în care departamentele din structura organizaţională

contribuie la procesul de bază prin intermediul sub-proceselor pe care le realizează. Procesele

reprezintă o serie de activităţi care produc o anumită ieşire şi ignoră toate barierele

funcţionale.

Figura 4. Ierarhia modelului proces-activitate

Procese de bază (unităţi)

Operaţii (mii)

Sub procese (zeci)

Activităţi (sute)

Figura 3. Structura ierarhică a organizaţiei

Departamente (unităţi)

Operaţii (mii)

Centre de cost (zeci)

Activităţi (sute)


14

În Figura 6, este exemplul sistemului şi al sub-procesului de distribuţie de produse văzut

ca un sub-proces care contribuie la dezvoltarea infrastructurii, aceasta contribuind la rândul ei

la dezvoltarea proceselor de bază. Figura 6 arată că un sub-proces este format dintr-un flux de

activităţi, fiecare putând fi analizată în fluxul de operaţii care compun activitatea. Dacă este

necesar, fiecare operaţie poate fi împărţită în sub-operaţii.

Toate operaţiile sunt formate dintr-un număr de subprocese, unele dintre acestea fiind

de tip suport şi sunt comune majorităţii organizaţiilor precum: aprovizionare, recrutare de

personal, gestiunea informaţiilor. Alte operaţii sunt specifice domeniului analizat, şi formează

o listă de aşteptare.

Analiza

afacerii

Sistemul de

dezvoltare

Sistemul

de testare

Documentare Sistemul de

distribuţie

Nivelul activităţilor

Nivelul operaţiilor

Analiza

iniţială

Justificarea

costurilor

Scrierea

specificaţiilor

afacerii

Agregarea

specificaţiilor

Dezvoltarea

sistemului

Figura 6. Analiza sistemului şi a sub-proceselor în procesul de livrare

Agenţie imobiliară

Regiunea 1

Regiunea 3

Regiunea 2

Secretariat

Financiar

Conducerea

agenţiei

Serviciile

agenţiei

Dezvoltare

Cinci departamente structurate fizic în 3 regiuni şi zeci de zone

Furnizarea de

servicii

direcţionate

către

utilizator

Figura 5. Diagrama contribuţiei departamentelor la procesul de bază


15

2.2 Colectarea informaţiilor despre activităţi şi procese

În funcţie de activităţile şi procesele folosite, datele trebuie colectate de la persoanele

care participă la realizarea activităţilor din fiecare centru de buget sau sub-proces.

Informaţile înregistrate sunt folosite pentru construirea semanticilor activităţilor şi

proceselor descrise şi pot fi referitoare la:

Activităţile şi operaţiile efectuate,

Fluxul de relaţii dintre activităţi sau procese,

Intrările şi ieşirile activităţilor sau proceselor şi unităţile lor de măsură,

Resursele consumate, ca de exemplu: timp, spaţiul de birouri folosit (depinde de tipul de

resurse),

Alocarea per produs, serviciu sau client (depinde de tipul de activităţi),

Factorii care influenţează performanţa procesului sau activităţii (depinde de cost),

Măsurarea performanţei (criterii financiare şi non-financiare, cantitative şi calitative),

Obiective şi responsabilităţi per activitate sau process,

Clasificarea activităţii (de bază, suport, divers),

Servicii alternative,

Idei de îmbunătăţire.

Metode de colectare a datelor pentru semantici

Există o serie de metode care pot fi folosite pentru colectarea datelor în vederea

construirii semanticilor.

Principalele surse pentru date sunt:

Sistemele de pontaj - pentru identificarea resurselor,

Sistemele informaţionale ale organizaţiei – pentru identificarea activităţilor, ieşirilor şi

parametrilor non-financiari,

Sistemele informaţionale financiare – pentru costuri, materiale şi bugete,

Sistemul de resurse umane - pentru structuri organizaţionale, informaţii despre persoane

şi salarii,

Centrul de cost al departamentului sau procesului analizat (activităţi, relaţii, fluxuri,

costurile implicate, intrări şi ieşiri).

Principalele metode de colectare a datelor sunt:

Metoda observaţiei,

Grupuri de discuţii folosite pentru a obţine sugestii pentru analiza activităţii sau procesului

– ultile când se încearcă obţinerea rapidă de informaţii iniţiale,

Preluarea informaţiilor din alte sisteme informatice,

Interviuri,

Aplicarea de chestionare.

2.3 Gestiunea lanţului de activităţi aprovizionare-desfacere – caz utilizator

Gestiunea lanţului de activităţi de la aprovizionare până la desfacere presupune

controlul și coordonarea tuturor activităţilor unei organizaţii de la furnizorii de produse la

clienţii săi.


16

Lanţul de aprovizionare poate fi împărţit în două componente:

lanţul superior – componenta de cumpărare a comerului electronic

lanţul inferior – componenta de vânzare a comerţului electronic.

Figura 7 prezintă cele două părţi ale lanţului de activităţi de la aprovizionare la

desfacere împreună cu legăturile cu partenerii şi furnizorii precum şi cu furnizorii, partenerii

şi clienţii acestora. După fabricare, produsele sunt transmise prin lanțul de distribuţie

aprovizionare-desfacere. Când se implică clientul se vorbește despre un canal de tip cerere

care îţi bazează toate resursele, inclusive producţia, vânzările, marketing-ul, cercetarea,

dezvoltarea şi serviciile pe cererile clienţilor.

Modelul de afaceri axat pe cerere foloseşte o serie tehnologii, precum previziuni,

cercetări de piaţă şi business intelligence pentru îmbunătăţirea canalului cererii şi pentru a

putea răspunde comportamentului actual al consumatorului. Toate aceste tehnici se pot folosi

pentru construirea semanticilor asociate acestor activități.

Principalele caracteristici ale lanțului aprovizionare-desfacere sunt prezentate în figura

8.

Rezultatele estimate sunt:

creşterea încasărilor şi profitului,

reducerea stocurilor,

îmbunătăţirea gestiunii produselor.

Furni-

zor A

Furni-

zor C

Furni-

zor B

Schimb B2B

Distribuitor/

agent

Partener

1

Aplicaţii web

Instrumente şi servicii

ERP,

CRM,

SCM Web

Lanţul superior

Vânzător cu

amănuntul

Distribuitor/

agent

Partener

2

Lanţul inferior

Client 1

Client 2

Client 3

Client 4

Furnizorii Partenerii Intermediari Intermediari Partenerii Clienţii

furnizorilor furnizorilor la cumpărare la vânzare clienţilor clienţilor

Figura 7. Reţele de lanţuri de activităţi de la aprovizionare la

desfacere


17

Furnizor Client

Creşterea eficienţei Scop: reducerea costurilor în lanțul de

distribuție

Elemente cheie: controlul pe termen scurt

al resurselor și al constrângerilor legate de

capacități

Rezultate: dezvoltarea parteneriatelor și

afacerilor electronice

Creșterea valorii adăugate Scop: identificarea soluților pentru creșterea

profiturilor obținute de clienți

Elemente cheie: planificare pe termen lung,

realizarea de cercetări de piață și business

intelligence

Rezultate: îmbunătățirea gestiunii la nivel de

produs, reducerea stocurilor

Figura 8. Caracteristici ale lanțului aprovizionare – distribuție

Un sistem de gestiune a lanțului aprovizionare-desfacere este format din următoarele 5

componente:

Planificarea – dezvoltarea unei strategii pentru gestiunea lanțului aprovizionare-desfacere

în vederea obținerii eficienței maxime,

Sursa - implică selectarea furnizorilor de bunuri și servicii necesare în lanțul

aprovizionare-desfacere; gestiunea relațiilor, stabilirea regulilor de plată, de livrare și de

calcul al prețurilor.

Producția – acoperă planificarea cererii, fabricarea, asamblarea, testarea, împachetarea și

crearea stocurilor de produse.

Livrarea – se referă la recepționarea cererilor clienților, depozitarea, selectarea și livrarea,

facturarea și plata.

Retururi – presupune crearea proceselor pentru gestiunea bunurilor returnate de clienți,

inclusiv a celor care necesită reparații.


18

3 Cerinte ale unei platforme de interoperabilitate bazate pe semantici, ontologii si reguli de afaceri

3.1 Testarea compatibilitatii regulilor de afaceri corespunzatoare organizatiilor implicate intr-o solutie de interoperabilitate

Regulile de afaceri se referă la multitudinea de politici, proceduri sau definiţii care

guvernează modul de funcţionare al unei organizaţii, împreună cu interacţiunea acesteia cu

furnizorii si beneficiarii săi. Reiese ca orice interoperabilitate trebuie sa asigure respectarea

sistemului de reguli de afaceri ale fiecarui participant intr-o solutie de interoperabilitate.

Este important de făcut deosebirea dintre strategii şi reguli de afaceri, în sensul că

regulile reprezintă fundamentul pe care se construiesc strategiile, inclusiv cele de cooperare

Una dintre primele definitii ale regulii de afaceri ofera o perspectiva foarte interesanta

din punctul de vedere al demersului cercetarii noastre: “O regula de afacere este o declaraţie

explicită a unei constrângeri care există în cadrul ontologiei afacerii” (Daniel S. Appleton

(1984), [APL84]).

Completitudinea si coerenta sistemului de reguli de afaceri la nivelul unei organizatii

cade in sarcina organizatiei; in cazul unei platforme de colaborare, compatibilizarea

regulilor de afaceri dupa care se conduc partenerii cade in sarcina platformei.

3.2 Integrarea semanticii vocabularului regulilor de afaceri

Fara a intra in detalii privind conceptualizarea si formalizarea regulilor de afaceri, nu

putem omite ca o solutie de interoperabilitate bazata pe agenti va avea ca suport informatia

oferita de sistemele informatice ale partenerilor implicati, impreuna cu dictionarul semantic al

domeniului de business. Din acest unghi de vedere, devine interesanta conceptualizarea

propusa de Zachman, pentru dezvoltarea sistemelor informatice ([ZAC87].) si alinierea lor la

strategia de business.

Conform lui, arhitectura unui sistem informatic este determinată de strategia de

afaceri, deci de obiectivele şi rezultatele aşteptate ale organizaţiei. Astfel, el identifică două

modalităţi de reprezentare care, atunci când sunt utilizate în combinaţie, descriu precis natura

şi scopul acestor rezultate în contextul organizaţiei. Aceste modalităţi de reprezentare sunt:

Perspectiva umană, care are în vedere diferitele viziuni ale persoanelor implicate în

dezvoltarea sistemului. Au fost identificate trei viziuni arhitecturale fundamentale:

Modelul de business (business view), Modelul de proiectare (designer’s view),

Modelul tehnologic (builder’s view) împreună cu trei orientari pentru etapele de

dezvoltare ale sistemului: Scopul (scope view), Prezentarea detaliată (out-of-context

view) şi Viziunea operaţională (operational view).

Tipurile de abstractizări ce descriu fiecare perspectivă sunt folosite pentru a detalia

caracteristicile relevante si pentru a pune accentul pe diferite aspecte ale sistemului.

Au fost identificate şase tipuri de abstractizări: Datele (what ? ), Funcţiile (how ? ),

Reţeaua (where ? ), Factorul uman (who?), Timpul (when ? ) şi Motivaţia (why ? ).

Ca parte a unui consorţiu format din 17 organizaţii, cunoscut sub denumirea de “The

Business Rules Team” (BRT), Business Rules Grup”(BRG) a participat la propunerea venită

din partea Object Management Group (OMG) de a analiza semantica regulilor de afaceri

din perspectiva afacerii. Răspunsul BRT, denumit Semantica Regulilor şi a Vocabularului


19

Afacerii, (Semantics of Business Vocabulary and Business Rules - SBVR), reprezintă un

studiu exhaustiv privind semantica vocabularului afacerii şi a regulilor de afaceri, în care s-au

avut în vedere următoarele aspecte [OMG06]:

Orientarea spre afacere, în sensul că nu se fac referiri la sisteme informatice sau la

concepte specifice acestora, ci se concentrează exclusiv asupra modului în care

gândesc oamenii de afaceri.

Regulile de afaceri sunt integral specificate pornind de la vocabularul afacerii.

Semantica regulilor de integritate trebuie să se bazeze pe logica predicatelor.

Folosirea vocabularului afacerii ca element de comunicare intre oamenii de afaceri

(în calitate de “clienţi”) si specialiştii în informatică (în calitate de “furnizori de

servicii”), comunicare concretizata sub forma specificaţiilor cerinţelor sistemului.

3.3 Compatibilizare la nivel de procese de afaceri. Interpretarea abstracta si concreta a unui proces de afaceri

Desi aparent cooperarea intre firme n-ar trebui sa implice cunoasterea detaliilor privind

procesele de afaceri, ci numai "interfetele" lor, in realitate pot exista constrangeri privind

procesele tehnologice, succesiunile de activitati, calitatea output-urilor etc. Spre exemplu, un

proces tehnologic nu poate utiliza decat o materie prima de o anume calitate sau obtinuta la

randul ei numai printr-un anumit proces tehnologic.

Agentul de negociere a unei cooperari trebuie sa aiba capacitatea abstractizarii unui

proces de afaceri, sa inceapa cautarea cu semantica nivelului cel mai abstract, procedand apoi

la particularizari specifice unui domeniu de afaceri.

Pe nivelul cel mai inalt, un proces de afaceri se defineste ca ansamblu de activitati

interconectate, care folosesc oameni, informatii si resurse tehnologice pentru a crea valoare

adaugata pentru clienti. Intr-o reprezentare schematica (figura 9), cinci sunt componentele de

baza care afecteaza procesul de afaceri: Clientii, care influenteaza proiectarea si realizarea

produselor, intr-o strategie customer oriented; Produsele, Tehnologia; Informatia si

Participanti.

O interoperabilitate pe criterii semantice la nivelul resurselor de business trebuie sa

porneasca de la acest nivel, explorand ontologiile procesului si identificand formele specifice

de manifestare (tipuri de produse, profesii implicate, tehnologii existente, cunostiinte obtinute

pe baza informatiilor).


20

Figura 9. Reprezentarea abstracta a unui proces de afaceri [ALT 96]

3.4 Urmarirea gradului de aliniere a sistemului informatic la strategia firmei

Schimbarile majore din sistemele informatice ale firmelor se produc ca urmare a

schimbarilor din procesele de afaceri. La proiectarea unei platforme de interoperabilitate

trebuie sa se tina seama de directia evolutiei, pentru a asigura adaptabilitatea. Pentru a aprecia

gradul de aliniere a sistemului informatic la strategia firmei. Intotdeauna se incepe cu clientii

urmarindu-se adaptarea produselor la asteptarile acestora; se continua cu analiza procesului de

business care sa permita obtinerea produselor dorite; abia apoi sunt deduse tehnologiile

necesare, informatiile si tipul participantilor la un astfelde proces.

Corelarea se produce in ambele sensuri şi poate fi apreciata la un moment dat (static ),

dar si in dinamica, cand o modificare a unui element atrage schimbari in lant (produse noi

care presupun schimbari tehnologice, training pentru adaptare la noua tehnologie, achizitia de

noi informatii si cunostinte).

3.5 Impactul adaptabilitatii proceselor de afaceri asupra proiectarii platformei de interoperabilitate

Cunoasterea flexibilitatii si limitelor proceselor tehnologice, dar si a sistemelor

informatice de a se reconfigura pe masura schimbarilor din mediu de afaceri, reprezinta un

criteriu esential in selectarea oportunitatilor si posibilitatilor de cooperare intre firme.

Teoretic, arhitectura SOA incapsuleaza integral un domeniu de business; maniera in

care o face este insa esentiala si depinde de abilitatea celui care modeleaza. In principiu, se

urmareste gasirea unui echilibru intre diminuarea numarului de dependente dintre servicii

(deoarece la un numar mare de interactiuni, modificarea unui serviciu antreneaza modificari

CUSTOMERS

Internal / external customers

PRODUCTS Specific output or result used directly by customers

BUSINESS PROCESS

Major steps Basic approach

Related activities that combine to create Sumarized in terms of basic approach value for customers

nforms to customers PARTICIPANTS

People who enter or use information

INFORMATION

Numbers, text, sounds

Pictures

TECHNOLOGY

Computers

Telecommunications system

Software


21

in cascada in alte servicii) si evitarea unei granularitati exagerate, care ar conduce la o

complexitate prea mare a sistemului. Alegerea unui nivel optim de descompunere a proceselor

pe servicii asigura posibilitatea reconfigurarii sistemului prin compunerea serviciilor existente

si doar rareori scrierea de noi servicii.

3.6 Orientarea tehnologica a platformei

Solutia de interoperabilitate trebuie sa fie orientata spre noile tehnologii de realizare a

sistemelor informatice pentru afaceri, urmand ca sistemele mostenite (legacy systems) sa

beneficieze de facilitatile unei astfel de platforme numai dupa expunerea functionalitatii lor

prin servicii. Odata realizata aceasta transpunere, modificarea sau rescrierea totala a unei

functionalitati nu mai afecteaza ulterior schema de colaborare intre functii si nici intre firme.

3.7 Identificarea nevoilor si ofertelor de cooperare

Asa cum se cunoaste, un contract SOA specifica in principal:

functionalitatea asigurata prin serviciu;

input-urile cu care lucreaza serviciul si output-urile furnizate clientului;

preconditiile si post-conditiile

gestiunea erorilor

calitatea serviciului si garantii oferite.

Dintre toate, functionalitatea este cea care sta la baza initierii unei colaborari,

deoarece este direct legata de un proces sau subproces de business, iar colaborarile inter-firme

urmaresc in primul rand asigurarea unei functionalitati. Input-urile si output-urilor vor fi luate

in considerare doar in masura in care cerintele de colaborare au o specificitate aparte sau

functionalitatea cunoaste o diversitate mare de implementari.

O atentie speciala la cautari pe baza de semantici trebuie acordata sinonimelor, care

prin acelasi termen desemneaza functionalitati dintre cele mai variate.

3.8 Identificarea sabloanelor de colaborare agreate de o firma

Platforma trebuie sa dispuna de un set de sabloane de colaborare folosite uzual in

domeniul afacerilor. Se includ aici modele incepand cu simple acorduri de colaborare,

comenzi ferme emise in baza unor acorduri, contracte, pana la conventii prin care o firma

preia atributii decizionale pe un segment limitat de competente dintr-o alta firma (spre

exemplu, o firma furnizoare declanseza un proces de aprovizionare a unui supermarket).

3.9 Alegerea celor mai influenti agenti economici din lantul de creare a valorii noi adaugate.

Avand in vedere ca procesul de creare a valorii adaugate este un flux, profitul unei firme

depinde nu numai de performantele firmei si competitorilor, ci si de eficienta cu care opereaza

furnizorii si beneficiarii: acest lucru se explica prin faptul ca valoarea adaugata se redistribuie

prin preturi intre participanti, pe intreg lantul in care e creata (Porter, 1985).

In consecinta, la alegerea partenerilor de afaceri, firma este interesata sa colaboreze cu

cei mai influenti si eficienti participanti din lantul de creare al valorii adaugate.

Platforma de interoperabilitate trebuie eventual sa permita utilizatorilor sa adere la

anumite lanturi de creare a valorii nou adaugate.


22

FurnizorFurnizor

Comanda

ferma

Prototip

Componente /

semifabricate

Prognoze

Facturi Cereri

Service

Produse

finite

Preferinte

ProiectareProiectare LivrariLivrariVanzariVanzariProductieProductie ServiceService

ClientiClienti

Produse finite

Echipamente

/ informatii

FurnizorFurnizor

Comanda

ferma

Prototip

Componente /

semifabricate

Prognoze

Facturi Cereri

Service

Produse

finite

Preferinte

ProiectareProiectare LivrariLivrariVanzariVanzariProductieProductie ServiceService

ClientiClienti

Produse finite

Echipamente

/ informatii

Figura 10. Firma vazuta ca o succesiune de cinci procese de afaceri


23

4 Soluţii de cooperare virtuală pentru mediu de afaceri

Noua economie digitală, bazată pe Internet este o economie a afacerilor clădite în jurul

serviciilor Internet şi a reţelelor electronice, o economie în care apar noi forme de companii şi

noi forme de muncă. În noua economie se observă o schimbare a paradigmelor legate de

producţie şi management care însoţeşte trecerea de la societatea industrială la societatea

informaţională şi este ilustrată în următoarele tabele.

Producţie de masă Produse şi servicii flexibile, adaptate cererii clienţilor

Producţia de bunuri Producţia de servicii

Produse tangibile Produse intangibile,digitale,dematerializate

Ciclu de producţie

lung Ciclu de producţie mai scurt datorită inovării

permanente

Piaţă naţională Piaţă globală

Avantaj comparativ Avantaj competitiv

Tabelul 1. Schimbarea principalelor paradigme ale proceselor de producţie

Centralizare Descentralizare şi delocalizare

Ierarhie rigidă Organizare flexibilă

Structuri tip companie Companii orientate pe proiecte şi

companii virtuale

Lanţ de activităţi Organizare tip reţea şi eliminarea

intermediarilor

Suntem separaţi şi

rivali Suntem conectaţi şi putem coopera

Tabelul 2 Schimbarea principalelor paradigme ale organizării şi

managementului companiilor

Imaginea unui nou tip de organizaţie, organizaţia virtuală a fost mult vehiculată de la

apariţia cărţii lui Malone şi Davidow în 1992 [MDa92]. Mulţi autori au prezentat o imagine

puternic pozitivă a organizaţiilor virtuale şi au înaintat ipoteza unei acceptări largi şi rapide a

acestora. Organizaţiile virtuale pot fi definite ca ”reţele temporare de companii independente

– furnizori, clienţi, competitori – interconectate prin tehnologia informaţiei pentru a partaja

competenţe, costuri şi acces la pieţele celorlalţi ” [BBB93].

Aflaţi la începutul secolului 21, nu observăm ca această viziune să fi fost pusă în

practică pe scară largă, şi nici măcar să se fi atins o acceptare comună a acestei forme de

organizare. Ba chiar există autori care văd în organizaţiile virtuale doar o etapă intermediară

în tranziţia spre ceea ce ei numesc “întreprindere bazată pe Internet”(“internetworked

enterprise”) care va apărea într-o comunitate viitoare a afacerilor electronice.

Întreprinderile virtuale sunt create pentru a veni în întâmpinarea unor anumite

oportunităţi ivite pe piaţă şi sunt dizolvate în momentul în care oportunitatea dispare.

Integrarea virtuală , opusă integrării verticale, va fi probabil fundamentul pentru o strategie de

afaceri competitivă în acest secol. Pot fi găsite multe motive pentru proiectarea organizaţiilor


24

virtuale sau pentru organizarea activităţilor într-o organizaţie virtuală în locul unei organizaţii

tradiţionale. În principal, aceste motive se reduc la:

Nevoie sporită de flexibilitate, în raport cu care competenţele principale necesare pot fi

obţinute doar în colaborare cu parteneri externi. Flexibilitatea a devenit o necesitate din

cauza schimbărilor rapide care au loc în mediul organizaţiilor. De o bună perioadă de timp

se observă că organizaţiile se concentrează pe nişte competenţe principale, pe activităţile

la care sunt bune. Crearea de valoare adăugată pentru client a devenit un proces tot mai

complex şi presupune combinarea unui numar mare de tipuri de cunoştinţe. În această

situaţie, într-un grup de organizaţii, acestea au nevoie de cunoştinţele celorlalte pentru a

produce bunuri şi servicii şi formează împreună o organizaţie virtuală. Acesta este de fapt

cel mai puternic motiv pentru care partenerii lucrează împreună: partajarea competenţelor

principale ale fiecăruia şi combinarea cunoştinţelor acestora astfel încât să se genereze un

proces inovativ.

Nevoia de eficienţă sporită prin partajarea resurselor cu partenerii. Pentru a putea

reacţiona la cerinţele mediului de afaceri, se pare că colaborarea a devenit un factor tot

mai important. Avantajele de scală şi de experienţă pot fi mai bine folosite când partenerii

partajează resurse, ceea ce conduce la creşterea eficienţei şi competitivităţii, şi pe de altă

parte are loc şi o reducere a riscurilor, prin difuzia acestora.

4.1 Structuri virtuale

Caracteristic oricărui obiect virtual este posibilitatea formării şi dizolvării legăturilor

dintre părţile componente pentru a reacţiona rapid şi eficient la diferitele probleme ce apar în

sistem sau în mediul său înconjurător.

4.1.1 Biroul virtual

Biroul virtual defineşte companie sau un parteneriat de natură permanentă, dar care are

un număr important de angajaţi la distanţă. Biroul virtual îndeplineşte rolul biroului

tradiţional, centralizat, dar pe de altă parte, angajaţii lucrează în birouri aflate la domiciliu, şi

colaborează în cea mai mare parte a timpului electronic, venind doar ocazional în contact cu

ceilalţi angajaţi. De obicei, birourile virtuale sunt consorţii (au personalitate juridică), iar

consorţiile nu ţin cont de localizarea geografică a angajaţilor. Chiar şi în birourile tradiţionale,

multe dintre relaţiile de afaceri se desfăşoară în medii distribuite, de exemplu clienţii şi

furnizorii se află în locuri diferite, cei care lucrează împreună într-un proiect pot aparţine unor

divizii diferite, etc. Atât în cazul biroului tradiţional, cât şi în cazul birului virtual, misiunea

organizaţiei rămane aceeaşi, dar procedurile se schimbă în al doilea caz, adaptându-se

colaborării la distanţă.

4.1.2 Întreprinderea virtuală

Întreprinderea virtuală pleacă de la conceptul de organizaţie reţea, concept foarte

general, care se referă la orice grup de organizaţii interconectate printr-o reţea de calculatoare,

fără a fi necesar ca acestea să partajeze abilităţi, resurse, procese sau scopuri.

Întreprinderea virtuală este o reţea, mai mult sau mai puţin temporară, alcătuită din

întreprinderi sau persoane independente din punct de vedere juridic care care îşi unesc

bunurile, competenţele şi alte resurse în scopul realizării unui proiect comun care depăşeşte

capacităţile fiecăreia dintre unităţi luată individual în ceea ce priveşte posibilitatea de a

exploata oportunităţile volatile, de a avea acces la noi pieţe şi de a partaja costurile şi riscurile,


25

întreagă această suprastructură bazându-se pe noile tehnologii ale informaţiei şi

telecomunicaţiilor.

Procesele legate de funcţionarea afacerii şi de realizarea produselor sunt dispersate în

diferitele companii partenere. Acestea sunt distribuite în diverse ţări şi au o cooperare strânsă.

Fiecare dintre aceste companii se distinge prin produsele, procesele, competenţele sale

principale, unice. Întreprinderea virtuală este alcătuită din aceste companii independente şi

beneficiază de competenţele lor centrale pentru a câştiga oportunităţi importante de piaţă care

nu pot fi obţinute de companii de unele singure.

Figura 11. Întreprinderea virtuală

Acest tip de organizaţie poate fi realizată şi dezasamblată rapid ca răspuns la

schimbarea rapidă a oportunităţilor. Această proprietate face întreprinderea virtuală cel mai

promiţător tip de organizaţie pentru secolul 21.

În general, tehnologia necesară unei întreprinderi virtuale este similară celei dintr-o

întreprindere centralizată, dar există câteva diferenţe:

deseori întreprinderile virtuale sunt birouri virtuale, aşadar e vorba de medii distribuite;

trebuie să satisfacă anumite cerinţe legate de partajarea proprietăţii intelectuale înafara

organizaţiei;

pot să fie temporare.

Un concept înrudit este întreprinderea extinsă, care se aplică în cazul în care o

întreprindere îşi extinde limitele peste o parte din furnizorii săi, în timp ce întreprinderea

virtuală poate fi văzută ca un concept mai general, prin care se include alte organizaţii într-o

structură în care comunicarea se face peer-to-peer. Având în vedere aceste aspecte,

întreprinderea extinsă poate fi considerată un caz particular de întreprindere virtuală.


26

4.1.3 Organizaţia virtuală

O organizaţie virtuală (sau organizaţia cu structură organizatorică virtuală) este

formată din unităţi organizatorice distribuite care participă la un proces de muncă coordonat,

divizat, unităţi ce sunt părţi ale unei reţele complexe susţinute de tehnologii informaţionale

corespunzătoare.

Conceptul de organizaţie virtuală este oarecum similar celui de întreprindere virtuală,

ea incluzând o reţea de organizaţii care partajează resurse şi abilităţi pentru a-şi realiza

scopurile, dar fără a fi limitată la întreprinderi. De exemplu, municipalitatea virtuală care

integrează prin intermediul unei reţele de calculatoare toate organizaţiile la nivelul

municipalităţii: serviciile de distribuţie a apei, serviciile de întreţinere a spaţiilor verzi, de

producere şi distribuţie a energiei termice, de salubrizare, etc. Întreprinderea virtuală

reprezintă un caz particular de organizaţie virtuală [DHa98]

Organizaţia virtuală include atât birourile virtuale, cât şi întreprinderile virtuale. Acest

termen poate fi aplicat şi unor organisme de standardizare, consorţii sau proiecte de cercetare.

Figura 12. Relaţii între tipuri de organizaţii

4.1.4 Echipa virtuală

Pornind de la definiţia biroului virtual, putem defini echipa virtuală ca fiind

construită pentru situaţii în care membrii săi sunt distribuiţi geografic. Atât biroul, cât şi

echipa virtuală presupun membrii distribuiţi, aşadar au nevoie de infrastructură similară şi vor

necesita planificare şi executare a sarcinilor într-un mediu cu restricţii de resurse.

În cazul biroului virtual, acesta este relativ permanent, cu membrii stabili, cu resurse

stabile şi o cultură de întreprindere comună, formată în ani de zile. În cazul echipei virtuale,

membrii se adaugă sau pleacă în mod dinamic, contextual comun trebuie transmis cât mai

repede, situaţiile se schimbă rapid. La prima vedere pare necesară eliminarea rapidă a

barierelor de comunicare şi formarea unui mediu collaborative, dar este suficient un mediu

bine înţeles, cu structură modulară, care poate fi rapid configurat pentru a se adapta unor

cerinţe variate după cum se schimbă situaţiile şi tehnologiile disponibile.

4.2 Caracteristicile întreprinderii virtuale

Atunci când mai multe companii îşi combină specialiştii pentru a crea un produs,

rezultatul poate fi numit întreprindere virtuală (ÎV). După cum s-a spus, o întreprindere

virtuală este, prin definiţie, o alianţă de întreprinderi care conlucrează pentru a partaja abilităţi

Întreprinderi extinse

Întreprinderi virtuale

Organizaţii virtuale

Organizaţii reţea


27

sau competenţe centrale şi resurse pentru a răspunde mai bine la oportunităţile ivite pe piaţă,

cooperarea având la bază o reţea de calculatoare şi o arhitectură cooperativa, distribuită a

sistemelor informatice.

O întreprindere virtuală emergentă [THT02] merge un pas mai departe, asigurând o

monitorizare continuă a performanţelor sale şi a pieţei pentru a-şi îmbunătăţi performanţele şi

eficienţa, adică verifică în permanenţă dacă există parteneri disponibili pe piaţă care ar putea

fie să-i înlocuiască pe cei existenţi, fie să contribuie la obiectivele globale într-o manieră

pozitivă. Această caracteristică poate conduce la schimbări organizaţionale frecvente care

trebuie reflectate prin schimbări corespunzătoare ale sistemelor informatice.

Deşi există numeroase definiţii pentru întreprinderea virtuală, nici una nu este unanim

acceptată. Întreprinderea virtuală este o reţea temporară de cooperare a unor companii,

instituţii sau indivizi independenţi care se unesc rapid şi participă cu competenţele lor centrale

pentru a exploata o oportunitate de piaţă. Deşi întreprinderea virtuală refuză instituţionalizarea

– nu are birou central, ierarhie sau integrare verticală – partenerii autonomi acţionează ca o

singură corporaţie pentru cei din exterior. Deoarece cooperarea este realizată prin intermediul

tehnologiei informaţiei şi comunicaţiilor, structura sa organizaţională va fi fluidă şi flexibilă.

Competenţele centrale sunt definite ca abilităţi, tehnologie şi know-how care sunt esenţiale

pentru succesul companiei şi îi permit să obţină produse destinate pieţei. Esenţa organizaţiilor

virtuale este metamanagementul activităţii orientate spre obiect într-o manieră independentă

de mijloacele pentru realizarea acestei activităţi.

Companiile întreprinderii virtuale împart costurile, abilităţile şi eficienţa pentru a avea

acces pe piaţa globală. Cisco Systems este unul dintre cele mai cunoscute exemple de

întreprindere virtuală care se concentrează pe dezvoltarea şi vânzarea de noi produse, lăsând

toate celelalte activităţi pe seama partenerilor lor.

Întreprinderea virtuală este o subdiviziune a reţelei de cooperare, a cluster-ului. Este o

organizaţie ce se poate reconfigura, cu management propriu, resurse productive şi obiective

de producţie proprii. Întreprinderea virtuală va combina activităţile de maximă eficienţă prin

folosirea optimală a resurselor de producţie în concordanţă cu oportunităţile pieţei, indiferent

de timp şi spaţiu. Are propria conducere şi se comportă ca o unitate economică individuală.

Datorită cerinţelor specifice ale proiectului, întreprinderea virtuală poate conţine

unităţi care nu aparţin reţelei, dacă abilităţile necesare nu sunt disponibile în reţea. În cadrul

întreprinderii virtuale, resursele sunt alocate pentru realizarea unui anumit produs pe baza

eficienţei şi disponibilităţii, fără a se lua în considerare locaţia geografică şi structura

organizatorică. Unităţile sunt conectate într-un proces de producţie virtual realizat în cadrul

unei singure unităţi, chiar dacă resursele sunt distribuite.

Una dintre caracteristicile definitorii ale întreprinderii virtuale este natura sa

oportunistă. Întreprinderile pot folosi strategia întreprinderii virtuale pentru întâmpinarea

schimbărilor neaşteptate şi evenimentelor neprevăzute. Unul dintre beneficii este acela că pot

deveni productive capacităţile neutilizate sau pentru care planificarea depăşeşte necesarul.

Pentru tratarea cazului în care un anumit tip de capacitate este temporar indisponibilă,

întreprinderea virtuală va include mai mulţi membrii cu aceleaşi capacităţi, creându-se o

structură redundantă care conferă un plus de agilitate întreprinderii.

În literatura de specialitate referitoare la teoriile organizaţionale nu există o definiţie

unică şi unanim acceptată a organizaţiilor virtuale. Oricum, e foarte probabil ca o organizaţie

să nu îndeplinească aproape niciodată toate caracteristicile tipului ideal. O organizaţie poate


28

să aibă un număr de caracteristici care să o facă să apară mai mult sau mai puţin virtuală.

Câteva caracteristici generale ale organizaţiilor virtuale sunt enumerate în tabelul 3:

Proprietăţi din punct de vedere

instituţional

Proprietăţi din punct de vedere

funcţional

1. unităţi independente juridic

2. competenţe profesionale

complementare limitate în timp

3. partajare de resurse, know-how şi

riscuri

4. inexistenţa concurenţei, cooperare

totală pentru atingerea scopurilor

5. nu există o entitate centrală care să

controleze activitatea; totul se bazează

pe încredere reciprocă

1. independente de forma social-

juridică

2. coordonarea şi conducerea

activitaţii se realizează de către

competenţele profesionale

3. orientare adaptativă după cerinţele

problemei

Tabelul 3. Caracteristici generale ale organizaţiilor virtuale

Aceste caracteristici diferenţiază întreprinderea virtuală de alte forme de structuri

interorganizaţionale pe temen mai lung cum ar fi linia de aprovizionare sau întreprinderea

extinsă. O linie de aprovizionare este un ansamblu stabil de activităţi prin care mai multe

întreprinderi s-au angajat să contribuie cu competenţele lor la realizarea şi livrarea unui

produs pe o piaţă relativ stabilă. Comunicarea într-o astfel de structură are ca scop

minimizarea stocurilor şi a întârzierilor, monitorizarea calităţii, şi posibilitatea de introducere

a unor programe de modernizare pe măsură ce se produce trecerea de la orientarea pe produs

la orientarea pe client.

Integrarea tehnologiei informaţiilor şi comunicaţiilor (TIC) într-o linie de

aprovizionare se bazează pe fluxul de informaţii EDI (Electronic Data Interchange) ca parte

integrantă a procesului operaţional şi include de asemenea schimbul de date despre produs,

previziuni şi planuri de producţie. Capacităţile sunt angajate pe o perioadă lungă de timp.

Întreprinderea extinsă poate fi privită ca o corporaţie virtuală care a evoluat dintr-o

linie de aprovizionare. Pe măsură ce o linie de aprovizionare creşte într-o întreprindere cu mai

multe nivele, cu furnizori pe mai multe nivele, colaborarea trece dincolo de nivelul producţiei,

la nivelul proiectării, dezvoltării, costurilor.

Întreprinderea extinsă este întâlnită, de obicei, în cazul unor produse complexe, al

producţiei orientate pe loturi mari/medii şi al unei diferenţieri considerabile a produselor în

funcţie de client. Integrarea este strânsă, permiţând un nivel înalt de sincronizare a

programelor dezvoltării proceselor, producţiei şi livrării la nivelul partenerilor.

Având în vedere natura oportunistă a întreprinderii virtuale, unul dintre scopurile sale

este de a atinge nivelul de coordonare al întreprinderii extinse, fără a implica relaţii pe termen

lung într- o linie de aprovizionare şi fără a aştepta viitoare economii de scală.

În producţie, modelul întreprinderii virtuale se concentrează asupra produselor de

serie mică sau a produselor unicat, pentru care clienţii, activităţile de planificare, producţie,

testare, pot fi răspândite pe mai multe continente.

Liniile de aprovizionare şi întreprinderile extinse pot evolua spre întreprinderi virtuale

ca răspuns la presiunile pieţei şi pentru a realiza un nivel de personalizare satisfăcător pentru

clienţi. Transformarea poate avea loc şi invers. Dacă o alianţă de tipul întreprinderii virtuale

are asigurată o piaţă stabilă, partenerii vor dezvolta relaţii pe termen lung şi se va transforma


29

astfel într-o linie de aprovizionare sau într-o întreprindere extinsă, dacă un anumit partener

preia conducerea.

Datorită unei strategii de diversificare, o întreprindere poate fi în acelaşi timp parte a

unei linii de aprovizionare, a mai multor întreprinderi virtuale şi, de asemenea, prezentă pe

mai multe pieţe electronice. Aşadar, întreprinderea va fi implicată doar ca o mică parte din

capacitatea de producţie a întreprinderii virtuale, alte părţi fiind implicate în angajamente pe

termen lung, de exemplu în linii de aprovizionare, după cum se poate observa în figura 11.

Figura 13. Participare simultană a unei întreprinderi într-o linie de aprovizionare

şi într-o întreprindere virtuală

Într-o întreprindere virtuală pot fi active simultan mai multe clustere. Un cluster este un

grup de întreprinderi, membre ale unei întreprinderi virtuale mai mari care sunt implicate

curent în execuţia unei comenzi de la un client. Resursele folosite într-un cluster trebuie să fie

libere în momentul în care sunt necesare execuţiei comenzii. Surse de resurse disponibile:

politici bazate pe supracapacitate, foarte populare pentru că sporesc flexibilitatea;

comenzi întârziate sau anulate;

planificarea comenzilor, proceselor, operaţiilor.

O observaţie importantă este este că întreprinderile din clustere obţin cea mai mare

parte din venituri prin contracte pe termen lung, care reprezintă principalele lor angajamente.

Întreprinderea virtuală este privită doar ca o activitate colaterală, dar care le ajută să:

acopere golurile în utilizarea resurselor lor şi astfel să-şi crească performanţele;

participe activ la piaţa globală;

extindă virtual tipurile de resurse.

În prezent există mai mulţi factori care favorizează expansiunea întreprinderilor virtuale:

eradicarea barierelor taxelor şi globalizarea pieţelor;

nivelul şi utilizarea facilă a resurselor de transport;

mobilitatea crescută a populaţiei şi uşurinţa interacţiunii umane;

uşurinţa comunicaţiilor, mai ales prin dispozitive mobile şi Internet.

Linie de aprovizionare 1

Linie de aprovizionare 2

Linie de aprovizionare n

O posibilă

întreprindere virtuală

Cluster: întreprindere virtuală

pentru comenzi neaşteptate

Grupul de clienţi 1

Grupul de clienţi 2

Grupul de clienţi n


30

Pentru interconectarea întreprinderilor în întreprinderi virtuale este important nivelul

executiv, unde există numeroase procese care pot să beneficieze de pe urma tehnologiei

informaţiei şi chiar să fie complet automatizate:

planificare de detaliu şi planificarea producţiei;

alocarea resurselor;

urmărirea produselor şi echipamentelor;

monitorizarea fluxului de producţie;

managementul calităţii şi al inventarului;

raportare la nivelurile superioare.

La nivelul implementării caracteristicile acestui tip de întreprinderi indică puternic

folosirea unei arhitecturi de sistem multi-agent, în care întreprinderile sunt reprezentate de

unul sau mai mulţi agenţi. În mediul unui sistem multiagent se presupune că fiecare agent este

autonom şi arhitectura sa este în principiu plată, adica nu apar relaţii de subordonare. Acest

lucru corespunde cu procesul de formare al întreprinderilor virtuale la nivel interîntreprinderi

(integrare orizontală), nivelul cel mai discutat în literatura de specialitate. De cele mai multe

ori se consideră că acestea au o arhitectură plată, care asigură comunicare punct la punct.

Această abordare caracterizează cea mai mare parte a cercetărilor legate de crearea

întreprinderii virtuale, în care formarea coaliţiilor este realizată prin integrare orizontală,

bazată pe diferite mecanisme de brokeraj.

Figura 14. Întreprinderea virtuală şi piaţa

Abordările mai avansate ale integrării întreprinderilor virtuale propun un model al

fluxului de producţie interorganizaţional pe trei niveluri, care surprinde fluxurile de producţie

ale partenerilor, viziuni ale fluxurilor şi fluxuri ale coaliţiei. În acest mod sunt depăşite

limitările modelului cu un nivel (punct la punct) sau cu două niveluri (privat-public).

Deşi răspund mai bine necesităţii alocării dinamice a resurselor (permiţând

autoorganizarea), aceste întreprinderi virtuale sunt limitate la structuri predeterminate, statice,

Proiectare ÎV, constituire şi control

soluţii ICT

Integrator

Atribuţie 1 Atribuţie 2 Atribuţie 3 Atribuţie 4

IMM 1,2,3 IMM 4,5 IMM 6 IMM 7,8

Întreprinderea virtuală

Produs final

Competiţia Client

Utilizatori

finali

Întreprinderi mari

Piaţa

Informaţii

despre

piaţă


31

cu parteneri şi resurse fixe, cunoscute. Astfel tehnicile avansate de descoperire şi compunere a

serviciilor nu pot fi exploatate pentru a crea, rafina şi optimiza structuri organizaţionale create

ad-hoc, orientate pe scop. Aceste cerinţe pot fi atinse doar dacă se realizează o integrare mai

profundă (integrare verticală). Acest lucru este foarte important mai ales pentru organizaţiile

globale (corporaţii multinaţionale) care se grupează pentru un interval de timp mai lung

pentru a reacţiona la cerinţele pieţei, integrarea permiţând deciziilor de la nivel

interîntreprinderi să fie propagate şi reflectate la toate nivelurile în întreprinderile membre.

Abordări recente sugerează că ierarhiile imbricate ar putea să modeleze corespunzător

coordonarea activităţilor la toate nivelurile într-o structură confederativă. Există deja

companii vizionare, cum este TheMindElectric care încearcă crearea unei infrastructuri de

servicii care copiază comportamentul biologic. Pentru a integra o astfel de arhitectură într-o

societate de agenţi, este folosit conceptul de sistem de agenţi holonic, constând din mai multe

niveluri imbricate recursiv de structuri similare (holonii) care se autorestructurează dinamic

pentru a atinge scopurile sistemului.

Tipologii de întreprinderi virtuale

Analizând caracteristicile pe care le prezintă, se pot distinge două mari tipuri de

întreprinderi virtuale: statice şi dinamice [GKT98].

Întreprinderile virtuale statice, în care colaborarea are un caracter permanent şi, de

obicei, există o organizaţie care este partenerul central şi stabileşte regulile colaborării.

Pe de altă parte există întreprinderile virtuale dinamice, în care relaţiile de

colaborare sunt temporare, însoţite de partajarea conducerii. Aproape toate definiţiile din

literatură se referă la acest al doilea tip de întreprinderi virtuale.

Întreprinderi virtuale statice

În întreprinderea virtuală statică modul de conectare între partenerii de afaceri este

static, fix, procesele economice partajate fiind puternic integrate. Relaţiile economice între

parteneri sunt predefinite, strânse, fixe, bine integrate. Reţeaua de parteneri este fixă şi

predeterminată, ceea ce determină o structură a întreprinderii virtuale statică şi

predeterminată. Exemple bine cunoscute de astfel de organizaţii sunt reţelele în care operează

firmele Dell sau Amazon.com.

În funcţie de stilul de management din cadrul reţelei, se pot diferenţia două categorii

de întreprinderi virtuale statice: centralizate şi descentralizate.

a. În cazul întreprinderilor virtuale statice centralizate există un centru de

coordonare al relaţiilor economice între membrii reţelei, ceea ce impune existenţa unor

interfeţe tehnice pentru integrarea partenerilor. Acestea integrează procesele partenerilor prin

crearea unor procese partajate, în timp ce toată infrastructura tehnică şi procesele economice

ale partenerilor sunt gestionate în mod centralizat. Între organizaţia centrală se formează

relaţii pe termen lung, şi recuperarea investiţiilor are în vedere un orizont lung de timp,

deoarece costurile de integrare, dezvoltare şi reinginerie sunt ridicate pentru toţi membrii.

Constituirea întreprinderii virtuale este realizată manual, controlul aparţinând în totalitate

organizaţiei dominante.

Acest model de întreprindere virtuală a fost aplicat în industria constructoare de

automobile [ZPo99]. În cazul acesta, un producător important de automobile are o reţea de

furnizori, distribuitori, vânzători care sunt implicaţi în producţie, distribuţie şi revânzare.

Producătorul are anumite cerinţe care trebuie realizate pentru a creşte gradul de automatizare

şi a descreşte costurile de producţie şi distribuţie. Între reţeaua de colaboratori şi organizaţa


32

centrală se stabileşte o colaborare strânsă prin adoptarea şi integrarea unor interfeţe

predefinite.

b. În cazul întreprinderilor virtuale statice descentralizate, partenerii de afaceri

sunt conectaţi într-un mod autonom şi descentralizat. Reţeaua este similară celei anterioare,

dar nu există o organizaţie centrală, dominantă, şi fiecare membru poate coopera liber cu

oricare dintre celelalte întreprinderi. Integrarea membrilor se realizează împreună, în mod

coordonat şi incremental. Între parteneri se stabilesc relaţii pe termen lung şi recuperarea

investiţiilor are în vedere un orizont lung de timp. Constituirea întreprinderii virtuale este

realizată manual, în funcţie de cerinţele tehnice ale partenerilor şi în acest caz costurile de

integrare şi dezvoltare sunt ridicate.

Acest model de întreprindere virtuală a fost aplicat în industria high-tech.

Organizaţiile se concentrează pe câte o activitate specifică (de exemplu, fabricarea de

semiconductoare, asamblare) şi realizează parteneriate cu alte organizaţii pentru a juca un rol

în mai multe lanţuri valorice. Fiecare partener joacă un rol în cadrul întreprinderii virtuale şi

contribuie cu competenţele sale.

Pentru a automatiza procesul de formare a întreprinderilor virtuale au fost propuse în

ultima vreme soluţii bazate pe pieţe virtuale sau servicii de director prin care potenţialii

parteneri să-ţi înregistreze resursele şi procesele economice. Piaţa virtuală oferă servicii de

căutare de parteneri potenţiali care oferă anumite procese (matchmaking). Ulterior, începe un

proces manual de negociere pentru selectarea celui mai potrivit partener. Timpul necesar

găsirii de parteneri şi stabilirii de relaţii este astfel îmbunătăţit. După formarea întreprinderii

virtuale însă, relaţiile rămân fixe, statice, adăugarea de noi membrii care ar putea oferi servicii

mai bune este imposibilă.

Pieţele virtuale pot fi folosite în mod dinamic şi în faza de operare a întreprinderilor

virtuale [OTs99]. Partenerii implicaţi în a oferi procese partajate se schimbă în permanenţă,

dinamic, în funcţie de cerinţele clientului şi proceselor. Pentru fiecare execuţie a unui proces

se crează în mod dinamic o nouă întreprindere virtuală, în funcţie de necesităţile clientului şi

partenerilor.

Întreprinderi virtuale dinamice

În întreprinderea virtuală dinamică, partenerii de afaceri sunt conectaţi în mod

dinamic, la cerere, conform cerinţelor clientului, prin intermediul unei pieţe virtuale. Între

parteneri nu trebuie să existe relaţii de afaceri fixe, astfel încât întreprinderea virtuală se poate

schimba continuu în funcţie de cerinţele pieţei. Piaţa virtuală oferă servicii pentru

înregistrarea ofertelor de procese ale partenerilor utilizând o serie de modele de procese

generice, globale, cunoscute. În momentul în care un partener doreşte să utilizeze un anumit

proces realizează o căutare a tuturor celor care ar putea oferi procesul respectiv. Urmează un

proces de selecţie, bazat de obicei pe negociere manuală sau automată, rezultatul fiind un

contract pe termen scurt care reglementează relaţiile între părţile implicate.

Datorită faptului că se utilizează pieţe virtuale de produse sau servicii organizate pe

baza unor modele globale, nu există relaţii statice între parteneri şi nu este necesară o

integrare a proceselor partenerilor. Deşi pieţele electronice au fost folosite pentru comerţ

electronic de mai mult timp, nu prea au folosite pentru întreprinderi virtuale, în special

datorită lipsei de tehnologii capabile să ofere definirea simplă a modelelor de proces,

mecanismelor de negociere automată şi interacţiunilor autonome între diferite părţi. În ultima

vreme însă, datorită dezvoltării XML, acestea au început să se dezvolte.

Relaţiile între cei care oferă şi cei care solicită procese sunt de obicei pe termen scurt,

astfel că recuperarea investiţiei se realizează pe baza unei singure tranzacţii, sau în intervalul


33

în care se participă pe piaţa respectivă. Numărul de membrii se schimbă în permanenţă,

structura întreprinderii virtuale evoluând de asemenea în funcţie de necesităţi.

În funcţie de stilul de management din cadrul reţelei, se pot diferenţia două categorii

de întreprinderi virtuale dinamice: centralizate şi descentralizate.

a. Întreprinderile virtuale dinamice centralizate sunt cele în care unul dintre

parteneri este proprietarul pieţei electronice, realizând gestionarea acesteia şi impunând

modelele de procese. Acest tip de organizaţie nu este prea întâlnit, deoarece piaţa ar trebui să

aparţină unei terţe părţi de încredere, care nu e implicată în întreprinderea virtuală. Totuşi, pot

exista situaţii de organizaţii foarte mari care vor să transforme întreprinderea virtuală statică

centralizată într-o variantă mai dinamică.

b. În cazul întreprinderilor virtuale dinamice descentralizate, piaţa virtuală

aparţine unei terţe părţi. Este cel mai evoluat şi mai performant tip de întreprindere virtuală,

dar deocamdată tehnologiile şi sistemele economice existente sunt prea imature pentru acest

tip de întreprindere.

Elemente al acestui model sunt aplicate în domeniul comercial, de exemplu pentu

companiile de logistică. Acestea pot să îşi înregistreze procesele pe o piaţă specializată

(destinaţia finală, preţul, timpul necesar transferului, garanţiile, etc), ulterior acestea putând fi

regăsite prin căutări automate.

Acest ultimul tip de întreprinderi virtuale există de obicei doar pe durata furnizării

unui singur serviciu. Partenerul este selectat de fiecare dată în funcţie de cerinţe specifice de

selecţie şi negociere. Pieţele virtuale devin, în ultima vreme, tot mai specializate şi mai legate

de anumite domenii industriale. Probabil că în viitor vor apărea comunităţi speciale pentru

schimburi în cadrul unor domenii specifice.

4.3 Vectorii virtualităţii. Avantaje şi riscuri în întreprinderea virtuală

Caracteristica esenţială a unei întreprinderi virtuale este virtualitatea, o capacitate pe

care fiecare o posedă într-o măsura mai mare sau mai mică,.

Virtualitatea este definită ca abilitatea unei organizaţii de a obţine şi menţine

competenţe critice prin modelul proceselor sale de adăugare a valorii şi prin structura sa

organizaţională. Compania obţine toate competenţele necritice din exterior, adică de la alte

companii, împreună cu care formează o întreprindere virtuală. De aceea, conceptual tinde să

extindă din punct de vedere conceptual noţiunile de eficienţă şi eficacitate la mai multe

companii, şi, de exemplu prin externalizare sau francizare, să lege resursele într-o companie

fără să fie nevoie să investească pentru ele.

Scopul este de a se ajunge la situaţia câştigător-câştigător pentru părţile implicate.

Relaţiile dintre companii sunt în esenţă voluntare, deşi prin dependenţe economice se creează

presiuni inerente. Un studiu de caz asupra ultimilor 10 ani relevă multe exemple de astfel de

aranjamente “win-win“ între companii. Industrii întregi s-au schimbat, de exemplu industria

automobilelor sau comerţul cu amănuntul. Domenii care au fost dominate înainte de corporaţii

integrate pe verticală sunt acum deservite de reţele de companii în care funcţia de coordonare

a fost în mare parte preluată de corporaţii multinaţionale, împreună cu câteva funcţii

reziduale.

Expertiza coordonatorilor reţelei constă în abilitatea lor de a face faţă complexităţii

acestei structuri. Procesele reale de adăugare a valorii sunt realizate de un număr mare de

întreprinderi mici şi mijlocii, unele dintre ele necunoscute clientului. Ei controlează fluxul de

informaţie şi au capacitatea şi cunostinţele pentru a-l reproduce în sisteme.


34

Din punctul lor de vedere, fluxul de informaţie în reţea este mult mai puţin complex în

comparaţie cu companiile integrate vertical, din moment ce, cu un management de interfaţă

corespunzător, multe decizii pot fi cedate partenerilor. Pentru partenerii de externalizare (cei

mai mulţi fiind firme mici), complexitatea a crescut. De aceea, ele sunt asignate

coordonatorului. Aceste două puncte diferite de vedere trebuie luate în considerare când

evaluăm avantajele şi dezavantajele întreprinderii virtuale. Conceptul de virtualitate se bazează pe considerente de ordin strategic, cum sunt:

asigurarea unor competenţe centrale,

mărimea optimă a companiei sau

aria de piaţă a produsului.

Este necesară, desigur, implementarea în interiorul companiei şi între companii. Aceste

schimbări necesită perioade lungi de timp (ani de zile). De aceea, evoluţia companiilor

virtuale nu este un proces rapid; dacă există capacitatea, este posibil ca partenerii să fie

schimbaţi rapid, aceasta fiind singura modalitate de a introduce flexibilitatea necesară.

Schimbarea este deseori condusă de un expert, cu multă influenţă, lider de opinie.

Venkatraman şi Henderson [VHe96] pornesc de la ideea că modelele actuale de

strategie şi structură organizaţională, nu au succes în competiţia actuală, bazată tot mai mult

pe cunoştinţe. Concentrându-se pe importanţa cunoştinţelor şi intelectului în crearea valorii

adăugate, ei elaborează un cadru conceptual pentru organizarea virtuală. Tehnologia

informaţiei este inima acestui model, iar cei trei vectori interdependenţi ai virtualităţii sunt:

Interacţiunea cu piaţa – tratează noile provocări şi oportunităţi pentru interacţiunile

dintre companie şi clienţi;

Echilibrarea competenţelor – crearea şi amplasarea bunurilor de natură intelectuală,

cele de natură fizică fiind luate dintr-o reţea de afaceri complexă;

Configurarea muncii – se referă la posibilitatea echilibrării-compensării diferitor surse

de expertiză în cadrul şi înafara graniţelor organizaţionale.

Vectori

Etape

ale virtualităţii

Interacţiune

cu piaţa

(Întâlnire virtuală)

Echilibrarea

competenţelor

(Resurse virtuale)

Configurarea

muncii (munca

virtuală)

Etapa 1 Produse şi servicii

experimentate de la

distanţă

Resurse eficiente

pentru componente

standard

Maximizarea

expertizei

individuale

Etapa 2 Personalizarea

produselor sau

serviciilor

Echilibrarea

eficientă a activelor

Valorificarea

expertizei

organizaţionale

Etapa 3 Croirea de soluţii

client

Cearea de noi

competenţe prin

alianţe

Echilibrarea

expertizei

comunităţii de

profesionişti

Tabelul 4. Etapele virtualităţii

Au fost identificate mai multe etape ale virtualităţii:

Etapa 1 se concentrează asupra unităţilor de lucru, cum sunt serviciile client, achiziţiile,

dezvoltarea unui nou produs. Obiectivul implicit este de creştere a eficienţei prin integrarea

mai strânsă a clienţilor.


35

Etapa 2 se concentrează pe coordonarea activităţilor pentru crearea de valoare superioară.

Implicit, în această etapă apar noi aranjamente organizaţionale.

Etapa 3 se concentrează asupra reţelei internaţionale pentru a proiecta şi completa comunităţi

interdependente pentru inovare şi creştere. Trebuie recreată în această etapă valoarea în

termenii produselor şi serviciilor.

Caracteristicile întreprinderii virtuale îi oferă un plus de flebibilitate şi dinamism. Dar care

sunt deosebirile între întreprinderile virtuale şi celelalte modele tradiţionale de grupare a

întreprinderilor? Mertens şi Faisst [MFa95] sunt cei care au analizat pentru prima dată acest

aspect, principalele concluzii fiind prezentate în tabelul 5.

Tip de grupare Deosebiri faţă de întreprinderile virtuale

Alianţă strategică cooperare slabă

nu exista o virtualizare a serviciilor

majoritar întreprinderi mari

Concern dominare sau existenţa pachetului

majoritar

Cartel dorinţa de a limita concurenţa

Consorţiu colaborare formală

Joint Venture necesitatea înfiinţării unei noi

întreprinderi

Franciză existenţa unei relaţii de subordonare pe

termen lung

Tabelul 5. Întreprindere virtuală versus alte tipuri de grupări organizaţionale

Organizaţiile virtuale nu creează de obicei noi funcţii centrale pentru coordonare; acest

lucru este rezolvat cu ajutorul tehnologiei informaţiei şi telecomunicaţiilor şi, ca urmare, nu

apar noi nivele de management, ci dimpotrivă se reduc cele existente. Relaţiile sunt mai puţin

formalizate, sunt limitate în timp, mai strânse decât relaţiile de piaţă (bazate pe EDI şi

groupware). Relaţiile din structurile organizatorice de coordonare şi administrare sunt

înlocuite cu relaţii contractuale pe termen scurt.

4.4 Implicaţiile virtualizării structurii organizatorice

4.4.1 Implicaţii din punct de vedere al strategiei competitive

Folosirea comună a capacităţilor de producţie, canalelor de distribuţie, aprovizionare

şi a altor resurse (potenţate de posibilitatea de comunicare şi monitorizare prin TIC) conduce

la reducerea costurilor globale, apariţia unui efect de sinergie, a economiilor de scală şi a

creşterii calităţii) datorită încrederii, destinului comun.

Un alt aspect benefic este schimbul de cunoştinţe legate de tehnicile de producţie

eficiente din punct de vedere al costurilor, activităţile comune în domeniul cercetării–

dezvoltării bazate pe groupware, email, videoconferinţe, etc.

Ca urmare, apare producţia comună de bunuri şi servicii inovative, puternic orientate

spre client. Accesul lărgit la informaţii, legate spre exemplu de modificarea cerinţelor

clientului, reduce mult timpul de reacţie la schimbările de pe piaţă. Ambele efecte oferă

protecţie faţă de produsele substitut, în cazul în care substituibilitatea produselor şi serviciilor

este corelată negativ cu complexitatea acestora. Are loc o reducere a timpului şi costurilor de


36

comunicaţie (EDI, email) şi creşterea vitezei tranzacţiilor de plată prin mijloace electronice,

ceea ce conduce la îmbunătăţirea situaţiei financiare.

O cooperare puternică între partenerii de afaceri va conduce la o poziţie mai puternică

pe piaţă şi va împiedica intrarea pe piaţă a unor competitori care nu se pot baza pe un efect de

sinergie similar.

4.4.2 Implicaţii din punct de vedere al costurilor tranzacţionale

Tranziţia la organizaţia virtuală presupune o anumită infrastructură, aranjamente

contractuale referitoare la modul de cooperare. Acestea reclamă dezvoltarea şi implementarea

de sisteme informatice interorganizaţionale, ceea ce determină o sporire a cheltuielilor

[Geb96]. Cresc de asemenea costurile datorită nevoii de coordonare recurentă a unităţilor

organizaţionale.

Pe de altă parte, scad cheltuielile pentru operaţiile zilnice: căutarea informaţiei,

negocieri, contractări datorită unui număr mai redus de parteneri şi mai multor informaţii

disponibile despre parteneri şi produsele lor. Scad costurile şi consumul de timp pentru

schimbul de informaţii datorită canalelor de comunicare eficiente şi sistemelor informatice

interorganizaţionale.

Totuşi, datorită interdependenţelor între participanţi, creşte gradul de vulnerabilitate.

Posibilitatea apariţiei comportamentului oportunist din partea unor parteneri, care să profite

de ceilalţi creşte, de unde şi nevoia de monitorizare a activităţilor. Totuşi, probabilitatea de

apariţie a unor astfel de comportamente oportuniste este destul de redusă pentru că relaţiile pe

termen mai lung şi mai stabile conduc la o interdependenţă reciprocă, şi cresc vulnerabilitatea

pentru toţi cei implicaţi.

Aşadar, din punct de vedere al costurilor tranzacţionale, costurile de coordonare tind

să crească, dar scad cheltuielile la nivelul operaţiilor, şi probabil pentru monitorizare, datorită

creşterii vulnerabilităţii. Deci, eficienţa globală e îmbunătăţită atât timp cât economiile nu

sunt depăşite datorită cheltuielilor adiţionale pentru coordonare, având în vedere că alţi

factori, de exemplu costurile de producţie ramân neschimbate.

4.4.3 Implicaţii din punct de vedere al dreptului de proprietate

Pentru a funcţiona corespunzător, structurile de cooperare trebuie bazate pe contracte

cât mai complete (orice modificare ulterioară neprevăzută în contract trebuie negociată),

reguli bine stabilite pentru a păstra încrederea între parteneri egali şi mecanisme

corespunzătoare pentru a monitoriza performanţele actorilor economici. Nici una dintre părţi

nu trebuie să fie dezavantajată în raport cu celelalte, toţi ar trebui să aibă cam acelaşi raport

cost-beneficiu. În acest context, vor juca un rol important mecanismele de monitorizare a

performanţelor (sisteme informatice interorganizaţionale cu funcţii de monitorizare şi creştere

a transparenţei).

Graniţele pentru fluxurile de informaţii ar trebui să fie permeabile din toate direcţiile,

nu doar pentru una din părţi. Astfel, creşterea propriei arii de influenţă înseamnă, de

asemenea, extinderea influenţei factorilor externi asupra condiţiilor interne, astfel că efectul

global e nedeterminat.

Pe de altă parte, pentru a păstra încrederea între parteneri egali, e necesară respectarea

unor reguli, fie ele stipulate prin contract, fie reguli nescrise. Partenerii renunţă astfel la o

anumită libertate de mişcare şi are loc o reducere a motivării, a securităţii angajaţilor.


37

4.4.4 Avantaje şi riscuri ale cooperării în cadrul întreprinderilor virtuale

Utilizarea acestei scheme de cooperare aduce numeroase beneficii, influenţând pozitiv

parametrii globali ai întreprinderii virtuale. Pe baza unor cazuri reale, în cadrul proiectului

ALIVE (Advanced Legal Issues în Virtual Enterprise), au fost obţinute evaluările următoare,

la nivelul anului anului 2003:

Tipuri de metrici Valoare

Reducerea costurilor individuale Până la 50%

Reducerea globală a costurilor 15%-20%

Reducerea expunerii financiare a partenerilor 25%

Creşterea profitabilităţii proiectelor 25%

Reducerea timpului necesar formalizării

contractelor de cooperare 50%

Reducerea timpului de ieşire pe piaţă 25%

Creşterea veniturilor utilizatorilor individuali Peste 25%

Creşterea eficienţei proceselor de cooperare 15-30%

Tabelul 6. Beneficii ale întreprinderii virtuale

O sinteză a principalelor avantaje şi riscuri oferite de întreprinderea virtuală este

prezentată în următorul tabel:

Avantaje Riscuri

flexibilitate mare a lucrului în echipă lipsa specializării

posibilitatea reducerii costurilor

noi oportunităţi de piaţă

distanţarea faţă de piaţă

situaţia instabilă a posturilor

avantaje în ceea ce priveşte timpul de

lucru

inexistenţa unei culturi a firmei

accesul la resurse în afara

întreprinderii

fixarea de scopuri, uneori divergente

proces de învăţare continuă în cadrul

organizaţiei (schimb de experienţă)

dezavantaje macroeconomice (şomaj)

avantaje pentru clienţi riscul neacceptării din partea clienţilor

Tabelul 7. Principalele avantaje şi riscuri ale întreprinderii virtuale


38

Bibliografie

[ALT96] S.A. Alter, Information Systems: A Management Perspective, Benjamin Cummings, 1996, ISBN 0-8053-2430-5.

[APL84] D. Appleton, Business Rules: The Missing Link, Datamation, Octombrie, 1984.

[BBB93] J.A.Byrne, R. Brandt, O. Bort, The Virtual Corporation, Business Week, februarie, 1993.

[DHa98] Y.L, Doz, G. Hamel, Alliance Advantage. The Art of Creating Value through Partnering, Boston: Harvard Business

School Press, 1998.

[Geb96] J. Gebauer, Virtual Organizations from an Economic Perspective, Proceedings of the 4th European Conference on

Information Systems, vol. 1, Lisabona, Portugalia, iulie, 1996;

[GKT98] A. Geppert, M. Kradolfer, D. Tombros, Market-Based Workflow Management, International IFIP Conf. on

Distributed Systems for Electronic Commerce, Hamburg, Germania, iunie 1998.

[Lho06] R. Lhotka, Expert C# 2005 Business Objects, Second Edition, Apress, 2006.

[May03] May M., Business Process Management: Integration in a web-enabled environment, Prentice Hall, 2003.

[MDa92] M. S. Malone, W.H. Davidow, The Virtual Corporation: Structuring and revitalizing the corporation for the 21st

century, New-York, Harper Business, 1992.

[MFa95] P. Mertens, W. Faisst, Virtuelle Unternehmen - eine Organisationsstruktur für die Zukunft?, în revista Technologie

& Management, vol 44, 1995, nr. 2, p. 61 -68, 1995.

[OMG06] Semantics of Business Vocabulary and Business Rules, disponibil la http://www.omg.org/docs/dtc/06-03-02.pdf.

[ORJ03] M. Owen, and J. Raj, BPMN and Business Process Management-Introduction to the New Business Process

Modeling Standard, Popkin Software, 2003.

[OTs99] V. Ouzounis, V. Tschammer, A Framework for Virtual Enterprise Support Services, 32nd International Conference

on Systems and Sciences (HICSS32) Maoui , Hawaii, ianuarie, 1999.

[THT02] H.K. Tönshoff, O. Herzog, I.J. Timm, P.O. Woelk, Emerging Virtual Enterprises, Proceedings of the 4th

International Workshop on Emergent Synthesis (IWES-02), Kobe University, Japan, mai 2002.

[VHe96] N.Venkatraman, J. C. Henderson, The Architecture of Virtual Organizations: Leveraging Three Interdependent

Vectors, lucrare elaborată în cadrul Systems Research Center, Boston University School of Management, Boston, MA 1996.

[Whi03] S. A. White, Using BPMN to Model a BPEL Process, IBM Corp., US, 2003.

[ZPo99] A. Zarli, P. Poyet, A Framework for Distributed Information Management in the Virtual Enterprise: The VEGA

Project, în Infrastructures for Virtual Enterprises. Networking Industrial Enterprises, IFIP TC5 WG5.3 / PRODNET

Working Conference for Virtual Enterprises (PRO-VE'99), Porto, Portugalia, p. 293-306, octombrie 1999.

http://www.omg.org/docs/dtc/06-03-02.pdf


39




Stabilirea cerinţelor în contextul lumii reale - Continuare

Autori – SC IPA SA - Societate comerciala pentru cercetare,

proiectare si productie de echipamente si instalatii de automatizare

Dr.Ing. Pîrvu Cristian

Ing. Bran Iuliana

Ec. Borta Roxana

Cs. Ing. Predescu Ciprian

Cs. I Ing. Gheorghiu Apolodor

Contract nr. 12118/01.10.2008


Pagina Web: www.ipa.ro

Info contact: http://www.ipa.ro/html/contact.html

http://www.ipa.ro/

http://www.ipa.ro/html/contact.html


40

CUPRINS

5 Modele de afaceri ............................................................................................................ 41 5.1 Studiul de caz: Controlul documentelor si informatiilor ce circula intr-o

intreprindere ......................................................................................................................... 41

5.2 Studiu de caz: plan tehnic de materiale ..................................................................... 43 5.3 Studiu de caz: flux de cereri de avans si deconturi .................................................... 45

5.4 Studiu de caz: modele de procese de afaceri ............................................................. 46 5.5 Studiu de caz: Cultura managerial in business .......................................................... 46 5.6 Studiu de caz: managementul afacerii bazat pe plan de afaceri ................................ 48


41

5 Modele de afaceri

5.1 Studiul de caz: Controlul documentelor si informatiilor ce circula intr-o intreprindere

Organizatia este structurata in jurul documentelor: teancuri de scrisori, copii dupa diverse

documente, rafturi pline cu dosare, cutia postala plina de mesaje electronice - sunt doar cateva

exemple. Intreaga activitate a firmei este organizata in jurul acestor documente. Afacerea poate fi

definita ca o arhitectura de documente. De aceea, putem spune ca documentele reprezinta esenta

intregii afaceri. Dar o simpla analiza a problemelor legate de fluxul manual de documente arata

dificultatile managementului clasic de documente in conditiile unei organizatii moderne.

Managementul Documentelor reprezinta un sistem informatic care permite circulatia

(pentru informari, aprobari sau modificari), stocarea si regasirea documentelor aflate in orice

format electronic, cu facilitati de conectare la alte sisteme informatice sau dispozitive

electronice (de exemplu, prin conectarea la dispozitive de scanare pot fi introduse automat in

sistem documentele pe hartie).

Caracteristici ale sistemelor de management al documentelor

Un sistem performant de management al documentelor:

implementeaza rapid fluxuri de documente

este flexibil la orice structura organizationala

are un grad inalt de securitate

este adaptabil la orice tip de document

este conectabil la alte aplicatii

prezinta usurinta in exploatare

este scalabil la dezvoltari ulterioare

Sistemele de management al documentelor asigura:

Alocarea unui numar unic de Inregistrare fiecarui document

Stabilirea locului unde se afla fiecare document activ

Urmarirea intregului ciclu de viata al unui document


42

personalul insarcinat cu receptia acestuia

momentul la care a fost receptionat

persoana care raspunde de avizarea/raspunsul formulat

data la care raspunsul/avizarea au fost finalizate

Avantaje ale sistemelor de management al documentelor

Spre deosebire de sistemele manuale sistemele automate de management al

documentelor:

Stocheaza informatiile legate de document intr-un singur loc

Permit accesul rapid la locul in care se afla documentul in organizatie

Informeaza privind stadiul de avizare (rezolutie) in care se afla un document

Urmaresc timpul necesar finalizarii unei avizari (rezolutii) si cele care au depasit

acest termen

Vizualizeaza numarul de documente intrate zilnic,saptamânal si lunar

Documentele sunt elemente cheie pentru succesul in afaceri pentru orice firma.

Documentul ajuta mult mai mult in prezent ca inainte sa cream noi relatii, prin

posibilitatea de a-l particulariza in concordanta cu dorintele destinatarului.

Documentul interactiv ofera autorului posibilitatea de a diversifica accesul, continutul si

modalitatea de transmitere a documentului, in functie de destinatar. Noile structuri de

administrare, noile tehnici si strategii sunt efectul adoptarii unui marketing de tipul unu la

unu. Documentul interactiv sprijina comunicarea si colaborarea in sensul maririi eficientei si a

gradului de satisfactie in munca noastra. De asemenea, documentele ne permit sa construim

mai multe medii de comunicare conectate intre ele. Mai jos este prezentata o imagine

simplificata a stadiilor documentelor si fluxului cunostintelor intr-un proiect global din cadrul

unei intreprinderi.


43

Tehnologiile care permit administrarea si gestionarea documentelor, fara necesitatea de

a le tipari, cresc semnificativ cantitatea de informatie inglobata in documentele unei firme,

aceasta putandu-se dubla chiar anual.

Managementul documentelor are sanse de existenta gratie tehnologiei de "tiparire la

cerere", care inseamna un soi de tiparire a documentelor atunci cand se cere acest lucru,

eliminandu-se astfel necesitatea de a se tipari de pilda un intreg inventar deoarece tocmai au

aparut anumite actualizari.

Ca aceasta tehnologie se va numi "tiparire la cerere" sau, dupa alte propuneri, "tiparire

la nevoie" are mai putina importanta. Mult mai importanta este tehnologia in sine, de care

vom tot auzi in urmatorii ani. Potentialul real al tiparirii la cerere este tocmai posibilitatea de a

tipari ceea ce este necesar, atunci cand este nevoie.

Utilizatorul documentului are posibilitatea de a asambla doar informatia de care are

nevoie si sa tipareasca astfel documentul, cand are nevoie. Valoarea economica in birouri a

acestui concept va putea fi observata si printr-o simpla privire spre cosul de hartii.

5.2 Studiu de caz: Plan tehnic de materiale

Procesul de proiectare culmineaza cu un plan tehnic de materiale care descrie toate

componentele care trebuie asamblate in produsul final. Acesta se transforma intr-un plan

tehnic de manopera care descrie modul de construire a unei unitati din produs. Informatiile

referitoare la productie sunt gestionate de mediul de management al resurselor intreprinderii

pentru a asigura reflectarea cunostintelor cuprinse in planul tehnic de manopera in procesul

efectiv de productie. Aceasta implica managementul resurselor, planificarea productiei,

achizitiile si stocarea materialelor si componentelor si managementul comenzilor de lucru.

Productia are legaturi cu un numar de sisteme secundare precum managementul resurselor

umane, contabilitate si costuri si sisteme de control al planificarii.

Managementul proceselor de schimbare tehnica si in documentatie poate fi realizat cel

mai eficient prin intermediul unui sistem electronic de flux al muncii (suport in luarea

deciziilor).

Proiectele mari cuprind foarte multe cunostinte,regasite in diferite documente, atat in

interiorul proiectului cat si livrabile clientului.

Multe tipuri de documente trebuie pastrate timp de mai multi ani. De exemplu, scrierea

documentatiei de intretinere pentru produsul respectiv incepe cu mult timp inainte de livrarea

lui. Documentatia trebuie actualizata cu schimbarile produse in configuratia tehnica pana cand

ultimul produs va iesi din serviciu. Costurile pentru producerea, gestiunea si livrarea

documentatiei legate de proiect reprezinta cateva procente din costurile totale de achizitie.


44

Figura 1 Fluxul informatiilor in producerea documentatiei de intretinere

Figura de mai sus insumeaza procesul prin care aceste informatii sunt asamblate dintr-o

varietate de surse.

Cerintele pentru documentatia suport sunt specificate in contract si documentele conexe.

Acestea sunt extinse si detaliate in planul integrat de suport logistic.

Manualele tehnice si alte documentatii pentru sisteme si echipamente ofera informatii

despre acestea. Detaliile despre ierarhia sistemelor, materiale,componente, instrumente, fluide

si lubrifianti si alte elemente si echipamente de test sunt asamblate si gestionate in baza de

date a sprijinului logistic integrat.

Inginerii de logistica si intretinere transforma documentatia primita intr-o versiune

initiala a planului de intretinere tehnica pentru sistemele proiectate, care stabileste filosofia de

baza pentru intretinerea fiecarui sistem. Planurile de intretinere tehnica descriu doua tipuri de

intretinere: specificatii tehnice de reparatie (care descriu sarcini de intretinere realizate de

obicei de agenti externi) si proceduri de intretinere (care descriu sarcini de intretinere

periodica efectuate de personalul beneficiarului).

Studiu de caz:arhitectura pentru sisteme de management al cunostintelor pentru

intretinere in serviciu Implementarea sistemului descris anterior a oferit o platforma pentru o

arhitectura care a rezolvat cu succes problemele majore legate de procedurile de intretinere,

atat intern cat si pentru client. Contractele cu valoare fixa pentru proiectele mari au o serie de

caracteristici unice care forteaza compania sa se concentreze nu numai pe gestiunea fluxului

de cunostinte in proceduri de management, dar si pe sprijinirea si actualizarea acestor

cunostinte si dupa livrarea produselor si intrarea in serviciu.

Figura de mai jos ilustreaza fluxul de informatii pentru actualizarea cunostintelor pentru

suport logistic in partea de intretinere in serviciu a ciclului de viata al proiectului. Sagetile

indica o bucla de reactie intre cunostintele operationale despre performanta pachetului de

suport logistic (inclusiv documentatii) in timpul serviciului si modificarile adaptive ale

diferitelor forme de documentatie care descriu cum trebuie intretinute sistemele in timpul

serviciului. Aceste cunostinte au fost rafinate prin experienta acumulata in serviciu si poate fi


45

folosita in alte proiecte similare. Totusi, pentru alte tipuri de documentatie, cunostintele

autorului raman implicite si se pierd usor odata cu schimbarile de personal.

5.3 Studiu de caz: Flux de cereri de avans si deconturi

Un exemplu tipic de documente care circula Intr-o firma sunt cererile de avans de

numerar si deconturile ulterioare. Ele sunt originate de regula de o persoana de executie,

avizate de seful ierarhic, de contabilitate si aprobate de conducatorul organizatiei sau

sucursalei.

Sistemul automatizeaza fluxul documentelor si reduce consumul de hârtie la minimum.

Documentul de cerere de avans spre decontare este emis electronic de solicitant. El are

o forma similar cu cel standard pe hârtie

Documentul este rutat automat prin email catre persoanele care trebuie sa-i avizeze sau

aprobe.

In caz de respingere sau cerere de refacere documentul se intoarce la emitent. Dupa

aprobarea cererii se tipareste chitanta de avans si casieria elibereaza numerarul. Decontul se

intocmeste tot electronic.

Dupa aprobarea decontului se tipareste borderoul pentru semnarea de catre contabilitate

si descarcarea posesorului de avans. Aprobarea se realizeaza electronic.

Traseul documentelor de cerere de avans si decont este urmarit strict de sistem cu

mentionarea datei si orei exacte când documentele au fost emise, avizate sau aprobate.

Singurele documente tiparite conform legislatiei actuale sunt cele legate de primirea de

numerar si decontare.

Utilizatorul este informat privind destinatía urmatoare a documentului .Sistemul de

cereri de avans si deconturi poate fi util si prin datele suplimentare ce le ofera. Ca de exemplu

totaluri de cereri, cereri aprobate si respinse, sume nedecontate, etc.


46

5.4 Studiu de caz: Modele de procese de afaceri

Dezvoltarea orientata pe model (MDD = Model-driven development), si in particular

OMG Model Driven Architecture este o abordare in dezvoltarea aplicatiilor si sistemelor

software moderne din intreprinderi. Paradigma MMD ofera a modalitate de a aborda

problemele de interoperabilitate spre deosebire de abordari anterioare care nu se bazau pe

model. Un model independent de platforma (PIM) corespunde unei viziuni a platformei de

implementare independenta de aceasta, descriind specificatiile software independent de detalii

de executie cum ar fi servicii Web, J2EE, .net, agenti sau tehnologii P2P. Un model specific

platformei (PSM) descrie realizarea sistemelor software intr-o anumita platforma specifica

sau intr-un set de platforme.

Un proces de business sau proces de afaceri (BP) este o colectie de activitati (task-uri)

interconectate care rezolva o anumita problema de business. F. Davenport (1993) spune ca

"un proces de business este o multime structurata si masurabila de activitati proiectate pentru

a produce o iesire specifica pentru un client sau o piata". Modelarea BP poate fi vazuta ca o

reprezentarea grafica a BP intr-un flux de lucru (workflow, un concept mai restrictiv decat cel

de proces, care pune in evidenta fluxul de control si de date dintr-o perspectiva centralizata).

La ora actuala, cele mai importante standarde considerate pentru modelarea proceselor de

afaceri sunt BPMN (Business Process Modeling Notation) adoptat ca standard de OASIS din

februarie 2006 si UML (stanadrd OMG).

In prezent s-au impus doua concepte importante legate de BP: orchestrarea BP in care

procesul este vazut ca o ordonare totala sau partiala a activitatilor sub control centralizat si

coreografia BP in care procesul este vazut ca un schimb de mesaje intre participanti; defineste

interactiuni. Standardele cele mai important pentru orchestrarea si executarea proceselor de

afaceri sunt la ora actuala BPEL (Business Process Execution Language) cu varianta WS-

BPEL pentru servicii, si ebXML, iar la nivelul coreografiei serviciilor Web propunerile

actuale sunt WSCL (Web Service Conversation Language) si WSCI (Web Service

Choreography Interface). Coordonarea proceselor de business este de asemenea un aspect

important in care procesul de afaceri este vazut ca un set de activitati corelate intre partenerii

de business. De exemplu, standardul WS Coordination specifica modul in care mai multe

servicii Web opereaza intr-o maniera coordonata si un context consistent.

Solutia propune si dezvolta un model al proceselor de afaceri care include adnotarea

semantica a componentelor, adaptibilitatea modelului in functie de cerintele procesului de

business si mediul in care acesta se desfasoara, cat si procese colaborative care pot fi evaluate

si stocate sub forma unor sabloane de cooperare ce vor deveni progresiv fluxuri de lucru

reutilizabile. Solutia cuprinde o platforma de modelare si dezvoltare software complexa care

include: componente strategice si de proiectare cum ar fi modelatorul procesului de business

(PB), componenta de proiectare a serviciilor semantice, si componente de implementare cum

ar fi platforma de realizare si oferire a serviciilor software semantice bazata pe o arhitectura

SOA, browserul de servicii (inclusiv descoperire), componenta de compunere a serviciilor,

componenta de construire a regulilor de coordonare.

5.5 Studiu de caz: Cultura managerial in business

Intr-o cultură organizaţională puternică, majoritatea managerilor împărtăşesc un set

comun de credinţe, valori, comportamente cu privire la modul în care trebuie direcţionată

afacerea respectivă. Noii angajaţi intră în contact cu acest set cultural şi îl adoptă, atât ca

urmare a manifestării lor formale, cât şi informale.

Cultura organizaţională este considerată din ce în ce mai mult astăzi ca unul dintre

factorii cu o influenţă


47

determinantă asupra performanţelor unei firme. În majoritatea cazurilor, rezultatele

bune şi foarte bune sunt asociate cu capacitatea proprietarilor, managerilor, liderilor de a crea,

menţine şi dezvolta o cultură organizaţională „puternică”, care să energizeze componenţii săi

către realizarea obiectivelor propuse.

Prin poziţia, statutul pe care îl au managerii în ierarhia organizaţiei, aceştia modelează

semnificativ

atitudinile, deciziile şi comportamentele subordonaţilor. Apare astfel o cultură

managerială, ca parte integrantă a culturii organizaţionale, asupra căreia poate exercita o

influenţă pozitivă sau chiar negativă uneori. Firmele ce beneficiază de o cultură managerial

puternică, bine conturată, care îi individualizează acţiunile şi evoluţia în mediul de afaceri,

sunt considerate a fi companii, branduri cu un anumit “stil”.

Adesea, valorile manageriale, îndeosebi ale topmanagerilor, cu un impact remarcabil

asupra evoluţiei

firmei, sunt favorizate, oficializate în misiunea firmei, în diferite comandamente sau

declaraţii care sunt communicate şi afişate în întreaga organizaţie, pentru a se da un nou

imbold, o nouă direcţionare a eforturilor tuturor angajaţilor. Maniera în care cultura

managerială influenţează performanţele unei firme poate fi explicată în mai multe moduri:

asigură direcţionarea eforturilor către un obiectiv sau set de obiective precizat(e);

dezvoltă o motivaţie puternică pentru salariaţi în obţinerea rezultatelor aşteptate;

furnizează o structură şi un sistem de mecanisme care coordonează eforturile

angajaţilor fără a fi

nevoie de un set de proceduri sau sisteme formale.

Prin cultură managerială înţelegem, , totalitatea credinţelor, valorilor, simbolurilor,

atitudinilor şi comportamentelor managerilor dintr-o organizaţie, care se reflectă în

deciziile şi acţiunile pe

care aceştia le adoptă şi aplică pentru asigurarea unei dezvoltări competitive a

firmei.

Cultura managerială este mai bine înţeleasă şi exercită un rol major în cultura

organizaţională în special

atunci când managerii conştientizează rolul pe care ei îl au în firmă, nu numai la nivel

formal ci şi informal şi, în consecinţă, sunt dispuşi să afecteze o parte apreciabilă din timpul

lor pentru comunicarea şi pregătirea salariaţilor în ceea ce priveşte filosofia managerială şi

setul de valori de bază al firmei.

O modalitate larg răspândită pentru a promova astfel de concepte este aceea ca, în

diferitele situaţii

informaţionale (rapoarte, sinteze etc.), să fie publicate, pe lângă misiunea firmei

(recomandabil pe coperta interioară sau pe prima pagină din interior), şi declaraţii precum că

„realizările sunt datorate şi valorilor, atitudinilor şi comportamentelor salariaţilor în

consonanţă cu cultura organizaţională a firmei”, „comunicarea deschisă şi spiritual de echipă

au făcut posibile rezultatele acestea” etc.

Strâns legat de această modalitate, se mai poate apela şi la o serie de ritualuri, de

ceremonii (precum

participarea la anumite excursii sau alte acţiuni de socializare) care să ofere sentimentul

apartenenţei la un

anumit grup.

Filosofia firmelor cu brand, acentueaza câteva principii larg îmbrăţişate:

respect pentru demnitatea salariaţilor şi drepturi egale în firmă pentru aceştia;

oferirea celor mai bune servicii clienţilor săi, la un nivel superior în comparaţie cu

orice altă companie din lume;


48

realizarea tuturor sarcinilor, cu obiectivul permanent în minte de a le realiza la un

nivel

superior celor precedente.

5.6 Studiu de caz: Managementul afacerii bazat pe plan de afaceri

Prezentul Plan de Afaceri se întocmeşte în vederea implementarii proiectului ”Studii şi

cercetări privind sisteme pentru monitorizarea în timp real a calităţii energiei în staţiile electrice de

medie tensiune – SISMED-2 ”. Planul de Afaceri este susţinut de trei entităţi juridice diferite:

Universitatea din Craiova prin Facultatea de Inginerie în Electromecanică, Mediu şi

Informatică Industrială care va fi şi coordonatorul proiectului realizînd în acelaşi timp şi activităţi de

cercetare-dezvoltare, testare, monitorizare, elaborare a pachetelor de programe si analiză a rezultatelor

obţinute;

SC IPA SA (Institutul de Proiectări pentru Automatizări) prin Sucursala IPA CIFATT

Craiova care va fi partener în acest proiect şi care va fi implicată în cercetarea aplicativă privind

elaborarea soluţiei tehnice, proiectarea echipamentelor şi sistemelor, elaborarea pachetelor de

programe, implementarea şi punerea în funcţiune a sistemului;

SC RomData AQ srl (entitate operatoare după finalizarea etapei de proiectare), societate

comercială privată, cu experienţă în domeniul producerii, implementării, comercializării şi

mentenanţei soluţiilor de acest tip care va participa cu specialişti în activitatea concepţională si în plus

va prelua producţia de serie, după ce va fi identificată soluţia optimă.

În consecinţă planul de afaceri se va axa pe modelul firmei SC RomData AQ srl, deoarece

activitatea productivă viitoare (ca rezultat al proiectului de investiţie) va fi efectuată de această

entitate. Se va urmări modul în care va creste competitivitatea economică a firmei SC RomData

AQ srl, ca rezultat al preluării know-how-ului generat de activitatea de cercetare dezvoltare a

Universităţii din Craiova în colaborare cu SC IPA SA. Planul de Afaceri va încerca să

dovedească faptul că proiectul este durabil şi că societarea RomData AQ SRL, parteneră în cadrul

proiectului, care va prelua rezultatele activităţii de cercetare din cadrul proiectului, după realizare,

dovedeşte durabilitate financiara şi are suficientă capacitate financiară si managerială de a menţine

afacerea viabilă.

Implementarea acestui proiect va duce la cresterea competitivitatii economice a

intreprinderilor la care se va implementa, care vor realiza o activitate viabila din punct de vedere

economico – financiar, dar si la cresterea competitivitatii beneficiarilor indirecti ai proiectului, prin

faptul ca vor dispune de un sistem care le va permite eficientizarea activitatilor de productie.


49

SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si

coordonare agenţi

SCIPA




Studiul şi evaluarea standardelor

actuale în agenţi cognitivi ofertanţi de

servicii si coordonare agenţi

Autori Universitatea din Craiova

Contract nr. 12118/01.10.2008


Pagina Web: http://www.ucv.ro/

http://www.ucv.ro/


coordonare agenţi

2/ 2/6/2009

CUPRINS

Partea III – Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si

coordonare agenţi ....................................................................................................................... 3

1 Agenţi ................................................................................................................................. 4 1.1 Definiţii ........................................................................................................................ 4 1.2 Autonomia agenţilor .................................................................................................... 5

1.2.1 Autonomia faţă de utilizator ................................................................................. 5 1.2.2 Autonomia socială ................................................................................................ 5

1.2.3 Autonomia faţă de norme ..................................................................................... 5 1.2.4 Modelarea conceptului de autonomie .................................................................. 5

1.3 Arhitecturi .................................................................................................................... 6 1.3.1 Arhitectura unui agent cu autonomie adaptabilă .................................................. 6

2 Servicii software ................................................................................................................. 8

2.1 Arhitectura orientata pe servicii .................................................................................. 8 2.1.1 Conceptul de serviciu ........................................................................................... 8

2.2 Servicii Web ................................................................................................................ 8

2.2.1 Introducere ........................................................................................................... 8 2.2.2 Tehnologii ............................................................................................................ 9 2.2.3 Arhitectura .......................................................................................................... 10

3 Standarde si instrumente pentru servicii Web .................................................................. 13 3.1 Standarde pentru servicii Web ................................................................................... 13

3.1.1 SOAP .................................................................................................................. 13

SOAP Envelope ........................................................................................................................ 14 3.1.2 WSDL ................................................................................................................. 19

3.1.3 UDDI .................................................................................................................. 23 3.2 Instrumente pentru servicii Web ................................................................................ 26

3.2.1 AXIS2 ................................................................................................................. 26 4 Standardele FIPA ............................................................................................................. 31

4.1 Principalele specificatii FIPA .................................................................................... 31 4.1.1 Structura unui mesaj FIPA ACL ........................................................................ 31 4.1.2 Tipuri de mesaje FIPA ACL .............................................................................. 32 4.1.3 Limbajul FIPA-SL pentru specificarea mesajelor semantice ............................. 37

4.1.4 Protocoale de interactiune .................................................................................. 41 5 Platforme de agenti FIPA – JADE ................................................................................... 47

1.4 Despre JADE ............................................................................................................. 47 1.5 Arhitectura ................................................................................................................. 48 1.6 Framework de baza .................................................................................................... 50

1.7 Comunicarea intre agenti ........................................................................................... 53 1.8 Comportamentul agentilor (Agent Behaviour) .......................................................... 55

Bibliografie ............................................................................................................................... 58


coordonare agenţi

3/ 2/6/2009

Partea III – Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare

agenţi

Rezumat

Scopul acestei sectiuni a raportului este prezentarea rezultatelor unui studiu de

evaluare a domeniului agentilor cognitivi din punctul de vedere al ofertarii de servicii si

coordonarii prin protocoale de interactiune. Evaluarea are in vedere trei aspecte : conceptele

de baza, principalele standarde existente, si suportul oferit de instrumentele software actuale.


coordonare agenţi

4/ 2/6/2009

1 Agenţi

1.1 Definiţii

Deşi nu exista o definiţie unică, general acceptată a agenţilor artificiali (software sau

hardware), marea majoritate a definitiilor propuse (şi nu sunt de loc putine, de exemplu

definiţiile citate în [FRA96]) includ ca o proprietate fundamentala a acestora autonomia.

Astfel, autonomia este o noţiune centrală în majoritatea definiţiilor agenţilor inteligenţi.

Exemplificăm acest lucru prin indicarea unor definiţii existente în literatura de specialitate.

Un agent este o entitate care percepe mediul înconjurător şi acţionează asupra lui

[RUS97].

Agenţii inteligenţi sunt entităţi logice care realizează operaţii în locul unui utilizator

sau al altui program, având un anumit grad de independenţă sau autonomie, şi pentru a

realiza acest lucru foloseşte cunoştinţe şi reprezentări ale scopurilor sau dorinţelor

utilizatorului (Agentul IBM).

Un agent este o entitate care funcţionează în mod continuu şi de manieră autonomă

într-un mediu în care alte procese se desfăşoară şi alţi agenţi există. [SHO93].

Un agent este o entitate autonomă, reală sau abstractă, care este capabilă să acţioneze

asupra să şi a mediului inconjurător, entitate care într-un univers multi-agent poate

comunica cu alţi agenţi, iar comportamentul său este o consecinţă a observaţiilor,

cunoştinţelor şi interacţiunilor cu alţi agenţi [FEB95].

Un agent este o entitate software sau hardware caracterizată prin următoarele

proprietăţi [WOO95]:

- Conectat - agentul este capabil de a acţinona asupra mediului său, pornind de la

intrările senzoriale pe care le primeşte din mediu;

- Autonom - agentul este capabil să acţioneze fără intervenţia altuia (agent sau

persoană) şi să îşi controleze propriile acţiuni şi stări interne;

- Proactiv - agentul trebuie să fie dotat cu un comportament oportunist, să fie

capabil să ia iniţiativa la momentul potrivit;

- Capabil de un răspuns în timp - agentul tebiue să fie capabil de a percepe mediul

înconjurător şi de a elabora un răspuns într-un anumit interval de timp;

- Social- agentul trebuie să fie capabil să interacţioneze cu alţi agenţi (logici sau

umani) pentru a îndeplini diverse sarcini sau de a juta pe ceilalţi agenţi să le

îndeplinească.

Intr-un sistem multi-agent (SMA), un agent intra în interacţiune cu alti agenţi (artificiali

sau umani), deci agenţii au o dimensiune sociala. Deoarece agenţii sunt autonomi, una din

cele mai dificile probleme şi bariere actuale ale adoptarii pe scara larga a paradigmei SMA

este caracterul nedeterminist al comportarii ce rezulta din interactiuni dinamice intre

componente autonome [GRE01] . Arhitecturi de agenţi existente arată că noţiunea de

autonomie este strâns legată de capacitatea de luare a deciziilor a agentului inteligent.

Diversitatea definiţiilor, arhitecturilor şi implementărilor existente arată că nu există o

definiţie unitară şi comună a noţiunii de autonomie.


coordonare agenţi

5/ 2/6/2009

Specificarea precisă a noţiunii de autonomie şi a implicaţiilor unei comportari autonome

ar putea conduce la rezolvarea, cel putin partiala daca nu totala, a problemei

comportamentului nedeterminist al agenţilor autonomi.

Cu toate ca exista numeroase cercetari care s-au orientat şi se orienteaza spre aceasta

directie, nu exista pana în prezent o definiţie unica a autonomiei ci diferite definitii care, de

multe ori, se refera la concepte diferite.

1.2 Autonomia agenţilor

1.2.1 Autonomia faţă de utilizator

Una dintre seminificatiile frecvente ale notiunii de autonomie este autonomia agentului

fata de utilizator: masura în care agentul alege şi urmareste autonom scopuri sau, alternativ,

consulta utlizatorul pentru prioritatea scopurilor şi a modului de satisfacere a acestora.

Capacitatea agentului de a parcurge tot spectrul de la o comportare total autonoma la una total

dependenta de utilizator este numita la ora actuala autonomie adaptabila [37, 39] şi este

identificata ca o caracteristica de dorit în aplicatiile de calcul omniprezent şi pentru

construirea dispozitivelor inteligente interconectate.

1.2.2 Autonomia socială

O semnificatie oarecem alternativa a autonomiei este data în context social cu referire la

capacitatea agenţilor de a delega scopuri şi, respectiv, de a adopta sau nu scopurile altor agenţi

[5, 23]. În [LUC98] autonomia sociala este capacitatea agenţilor de a genera noi scopuri pe

baza motivatiilor iar în [CAS00] autonomia este bazata pe teoria dependentelor sociale.

1.2.3 Autonomia faţă de norme

O semnificatie recenta a notiunii de autonomie este data în contextul cercetarilor actuale

despre sistemele de norme în SMA. Una din solutiile propuse recent pentru reducerea gradului

de nedeterminism al comportarii agenţilor intr-un SMA este utilizarea legilor sociale sau a

normelor ce trebuie respectate de toti agenţii din sistem. Intr-un astfel de sistem, agenţii

trebuie să fie capabili să recunoasca, să inteleaga şi să aplice normele existente [21, 22]. Cu

toate acestea, în functie de anumite situatii sau context, agenţii pot decide să nu respecte

anumite norme, aparand astfel o noua semnificatie a autonomiei, respectiv autonomia fata de

norme [VEN99, CCD99].

1.2.4 Modelarea conceptului de autonomie

Una din concluziile care s-a impus după studiul diferitelor tipuri de autonomii

menţionate în literatură a fost aceea că autonomia nu trebuie considerată ca o proprietate

absolută ci trebuie văzută în funcţie de entităţile şi actorii implicaţi în decizia autonomă dar şi

dependentă de context şi de relaţiile care se stabilesc între agenţi autonomi şi între agenţi şi

utilizatori.

Nu se poate vorbi despre un autonomia unui agent fără a specifica faţă de ce este

agentul autonom, şi anume obiectul autonomiei, şi faţă de cine este agentul autonom, şi

anume cel care poate influenţa autonomia (faţă de cine este autonom). De exemplu, un agent

personal al unui utilizator poate fi autonom faţă de alţi agenţi personali în selectarea unor

informaţii de interes pentru utilizator şi poate fi autonom faţă de utilizator în elimnarea

mesajelor electronice ce cuprind reclame de produse. Agentul poate să nu fie autonom faţă de


coordonare agenţi

6/ 2/6/2009

utilizator din punct de vedere al trierii mesajelor venite de la prieteni şi poate să nu fie

autonom faţă de alţi agenţi personali dacă aşteaptă de la aceştia noi adrese Web unde pot fi

găsite informaţii de interes pentru utilizator.

În plus, autonomia trebuie considerată în contextul de acţiune al agentului. De exemplu,

în cazul autonomiei sociale, nu se paote spune pur şi simplu că un agent are sau nu autonomie

socială, ci dacă agentul are autonomie socială faţă de un alt agent (software sau uman) pentru

decizia relativă la o anumită entitate (de exemplu adoptarea unui scop, executarea unei

acţiuni, etc.) şi într-un context dat.

Se pot identifica, de asemenea, două perspective ale autonomiei: autonomia externă

care este cea a unui observator (utilizator, alt agent) şi autonomia internă, care este cea a

agentului şi de fapt, este cea a proiectantului agentului. Din prima perspectivă, spunem că un

agent este sau nu autonom dacă comportarea lui nu poate sau poate să fie impusă de o sursă

externă. Din perspectiva internă, un agent este autonom sau nu dacă este proiectat astfel încât

să manifeste un comportament autonom sau nu.

Beavers şi Hexmoor [BEV03] spun că nu poate exista autonomie fără intenţia agentului

de a fi autonom. Suntem de acord cu aceast punct de vedere şi spunem că un agent, pentru a fi

autonom, trebuie să aibă intenţia să se comporte autonom. Acesta este cazul autonomiei

explicite a agenţilor. Există însă şi cazul autonomiei implicite, agentul cu autonomie implicită

fiind acel agent al cărui comportament autonom este codificat direct în aplicaţie.

Faţă de cine Utilizator Societate Norme

Obiect Dorinţe Scopuri Intenţii

Convingeri

Autonomie internă

Explicită Implicită

C

O

N

T

E

X

T

Autonomie

externă

Figura 1. Dimensiunile noţiunii de autonomie a agenţilor

1.3 Arhitecturi

1.3.1 Arhitectura unui agent cu autonomie adaptabilă

Agenţii au o structură BDI [WOO95] şi presupunem că dorinţele agenţilor sunt

consistente, formând deci mulţimea de scopuri. Scopurile agentului pot fi realizate pe baza

execuţiei unor taskuri. Există două tipuri de taskuri: taskuri specifice (ST) şi taskuri

cooperative (CT). Un task specific poate fi executat de către agentul individual pe când un

task cooperativ necesită intervenţia mai multor agenţi. Pentru executarea unui task cooperativ

agenţii trebuie să realizeze coordonarea execuţiei taskului cooperativ. În plus, în sistem există

un set de norme pe care agenţii ar trebui să le respecte. Fiecare task are asociat un câştig


coordonare agenţi

7/ 2/6/2009

pentru agentul care îl execută şi încălcarea unei norme din sistem are asociată o penalizare

pentru agentul care a încălcat norma.

Taskurile pe care un agent le alege pentru a fi executate se transformă în angajamente.

Un agent poate să formeze mai multe tipuri de angajamente:

- angajamente de tip acţiune pe care să le execute el însuşi;

- angajamente de tip acţiune pe care să le delege altor agenţi;

- angajamente de tip comunicare, respectiv acţiuni comunicative care implică

transmiterea unor mesaje.

Taskurile pot fi generate de trei surse: de agentul însuşi, primite spre adoptare dacă au

fost delegate de alt agent agentului în cauză; generate de normele din sistem.

Figura 2 prezintă arhitectura agenţilor din sistem. Modulul de generare taskuri (Task

Generation) generează cele trei tipuri de taskuri iar acestea sunt trimise către modulul de luare

a deciziilor (Decision-Making). Un task este structurat şi realizat pe baza unui plan, plan care

se formează de către o componentă de planificare pe baza bibliotecii de planuri (Plan

Library). Există două tipuri de planuri: planuri pentru executarea unui unui task specific şi

planuri pentru executarea unui task cooperativ. Planul pentru executarea unui task cooperativ

include delegarea de taskuri sau subtaskuri către alţi agenţi. Dacă un agent a hotărât să delege

un task, atunci planul corespunzător trebuie să includă şi acţiuni comunicative prin care

agentul să transmită delegarea taskului către un alt agent şi să aştepte răspunsul de la acesta.

Protocolul de comunicare este preluat dintr-o bibliotecă de protocoale (Protocol Library).

Procesul de decizie asupra alegerii unui scop de îndeplinit şi a creării unui angajament

pentru taskul asociat este iniţiat fie dacă modulul mediu (Environment) detectează o nouă

stare a mediului fie dacă un agent primeşte o cerere de adoptare a unui task de la un alt agent

prin modulul de comunicare (Communication Module). Modulul de luare a deciziilor este cel

care va decide asupra angajamentelor asumate de agent la un moment dat, în funcţie de

taskurile potenţiale disponibile sau propuse agentului şi în funcţie de autonomia agentului.

Modulul de luare a deciziilor include doua componente: componenta efectivă de luare a

deciziilor care alege dintre taskurile candidate cele care pot fi indeplinite în functie de

preferintele agentului, în particular acea de maximizare a câştigului ţinând cont de norme. O a

doua componenta este componenta de meta-decizie care implementează comportamentul

autonom al agentului în funcţie de dimensiunile specificate în secţiunea anterioară (figura 1).

Angajamentele asumate sunt apoi transmise modulului de planificare (Scheduler) în

care taskurile sunt ordonate în functie de durata, prioritate şi termen de execuţie.

Fig. Arhitectura agentului cu autonomie adaptabilă

Task Generation

Scheduler

Plan

library

Protocol

library

Adopted

norms

Env.

Module

Comm.

Module

action

result

receive send

Environment Other agents

Decision-Making

Module

commitments

new

message

environment state

AGENT

tasks generated from

norms, by itself or

delegated by others

reselect

regenerate


coordonare agenţi

8/ 2/6/2009

2 Servicii software

2.1 Arhitectura orientata pe servicii

2.1.1 Conceptul de serviciu

O tendinta moderna in construirea sistemelor distribuite ce promoveaza orientarea pe

obiect si reutilizarea este de a descompune aplicatiile in multimi de componente si de a

incapsula functionalitatea oferita de acestea sub forma de servicii. In acest fel aplicatiile

distribuite se transpun in multimi de servicii expuse utilizatorilor umani sau artificiali si

respectiv interni sau externi.

O definitie generala a conceptului de serviciu conform [SM05] este: “useful labour that

does not produce a tangible commodity”. In cadrul proiectului SCIPA suntem interesati de

servicii livrate prin software ce furnizeaza la cerere resurse de calcul sau resurse

informationale necesare pentru implementarea proceselor adaptive de business.

Conform [SM05], serviciile software cuprind urmatoarele categorii:

Servicii utilizator inteligente si adaptive la context. Acestea sunt servicii de inteligenta

ambientala ce ofera utilizatorilor abilitatea de acces convenabil la diverse

functionalitati, de oriunde, oricand si de pe orice tip de dispozitiv.

Servicii informationale. Acestea sunt servicii prin care se ofera informatie

personalizata sau cu valoare adaugata, spre exemplu prin compararea, clasificarea, sau

rezumarea uneia sau mai multor surse de informatie.

Servicii de intermediere. Acestea sunt servicii care sprijina gasirea altor servicii

corespunzator cerintelor clientilor.

Servicii dependente de locatie. Reprezinta o familie de servicii a caror functionalitate

depinde de cunoasterea locatiei geografice a utilizatorului disponibila prin intermediul

dispozitivelor mobile.

Un serviciu software furnizeaza o functionalitate precisa prin intermediul unei interfete

software bine definite. Serviciile pot fi compuse in scopul definirii unor servicii complexe.

Serviciile necesita definirea rolurilor de furnizor si respectiv consumator de servicii. Un

furnizor ofera un serviciu spre a fi folosit de unul sau mai multi consumatori, fara ca acestia

sa trebuiasca sa cunoasca detaliile interne de implementare ale serviciului respectiv.

Consumatorii pot fi la randul furnizori de servicii compuse, bazate pe serviciile oferite de alti

furnizori.

2.2 Servicii Web

2.2.1 Introducere

La ora actuala nu exista o definitie unanim acceptata a termenului de serviciu Web. Cu

toate acestea principalele definitii propuse in literatura de specialitate sau de catre diversele

organisme de standardizare fac apel la concepte si tehnologii relativ independente de diversele

moduri de interpretare.


coordonare agenţi

9/ 2/6/2009

Intr-un sens foarte larg prin serviciu Web se poate intelege orice aplicatie care este

accesibila altor aplicatii prin intermediul Web-ului. Conform acestei definitii orice aplicatie

care are un URL public este un serviciu Web, de la un script CGI pana la o aplicatie stabila cu

o interfata de programare precisa, posibil descrisa intr-un serviciu de directoare.

Conform organismului de standardizare OASIS, serviciile Web permit aplicatiilor sa

comunice independent de platforma si limbajul de programare folosind protocoale standard

bazate pe XML [OA-WS08]. Aceasta definitie evidentieaza urmatoarele aspecte ale unui

serviciu Web: independenta de platforma si de limbajul de programare, standardizarea

protocoalelor de comunicare si folosirea XML.

Clarificari suplimentare asupra diverselor definitii ale serviciilor Web sunt aduse de

Consortiul Web. Din pacate, nici acest organism nu reuseste sa furnizeze o unica definitie a

serviciilor Web. Astfel, conform [WSARCH04], un serviciu Web este un sistem software

proiectat pentru a sprijini interoperabilitatea interactiunilor intre calculatoare intr-o retea. El

are o interfata descrisa printr-un format procesabil de calculator (mai precis WSDL). Alte

sisteme interactioneaza cu un serviciu Web intr-o maniera prestabilita in descrierea sa,

folosind mesaje SOAP transportate utilizand HTTP cu serializare XML si in conformitate cu

alte standarde Web. Conform [Web Services Architecture Requirements, 2004], un serviciu

Web este un sistem identificat printr-un URI, ale carui interfete publice si legaturi sunt

definite si descrise folosind XML. Definitia sa poate fi descoperita de alte sisteme software.

Aceste sisteme pot interactiona cu serviciul Web intr-o maniera prestabilita de definitia sa,

utilizand mesaje bazate pe XML [XML08] si transportate de protocoalele Internet.

In cadrul proiectului SCIPA vom adopta punctul de vedere din [ACKM04] si vom

considera ca serviciile Web reprezinta o modalitate de a expune functionalitatea unui sistem

informatic si de a o face disponibila altor aplicatii prin tehnologii Web standardizate. In acest

fel serviciile Web deschid in mod natural perspective pentru noi arhitecturi si paradigme in

directia calculului orientat pe servicii.

2.2.2 Tehnologii

Din definitiile expuse rezulta ca tehnologia serviciilor Web trebuie sa resolve

urmatoarele patru probleme: descrierea, descoperirea, interactiunea si compunerea.

Cea mai importanta dintre organizatiile care se ocupa cu specificatiile serviciilor Web

este World Wide Web Consortium (W3C). Consortiumul W3C administreaza specificatiile

legate de SOAP, WSDL, XML, XML Schema, HTTP, etc. W3C administreaza, de asemenea

arhitectura serviciilor web, WS-Architecture. Acest document stabileste o definitie formala a

serviciilor Web.

O alta organizatie importanta in lumea serviciilor web este organizatia “Organization

for the Advancement of Structured Information Standards (OASIS)”. OASIS administreaza

specificatiile pentru UDDI, securitatea serviciilor web (WS-Security), SAML, etc.

Urmatoarele standarde sunt considerate principalele standarde pentru serviciile web:

SOAP. Termenul SOAP provine de la Simple Object Access Protocol. SOAP este o

specificatie care defineste o gramatica XML pentru trimiterea si primirea de mesaje. Scopul

specificatiei SOAP este acela de a descrie un format de mesaje care sa nu depinda de


coordonare agenţi

10/ 2/6/2009

arhitectura hardware sau software, capabil sa transmita si sa receptioneze mesaje la/de la orice

platforma.

Extensible Markup Language (XML). XML este un meta-limbaj de baza peste care

sunt construite limbajele pentru serviciile Web. XML este mai mult un meta-limbaj decat un

limbaj, deoarece este folosit pentru a crea gramatici. Aceste gramatici sunt descrise in scheme

XML care specifica tag-urile care sunt permise de legaturile dintre elementele definite de

aceste tag-uri. SOAP, WSDL si UDDI sunt gramatici bazate pe XML.

Hypertext Transport Protocol (HTTP). Protocolul HTTP este un standard care

precede aparitia serviciilor Web. Acesta a fost dezvoltat pentru a facilita trasnsferul de cereri

dintre navigator (browser) si serverul Web. Serviciile Web beneficiaza de avantajul existentei

acestui protocol matur cu ajutorul caruia se transmit mesaje SOAP si documente WSDL de la

un calculator la altul.

Versiunile mai noi de SOAP descriu cum alte mecanisme de transport ca FTP, SMTP si

JMS pot fi folosite pentru a realiza aceeasi functie. Totusi majoritatea serviciilor Web este

construite pe protocolul HTTP.

Web Services Description Language (WSDL). Limbajul WSDL este o specificatie

despre modalitatea de a descrie un program software in functie de apelurile de metode la care

trebuie sa raspunda. Aceste metode sunt descrise intr-un mod abstract care este independent

de limbajul de programare in care este scris serviciul, de calculator sau de sistemul de operare.

WSDL contine, de asemenea, o sectiune in care sunt descrise detalii de conectare la serviciu.

Universal Discovery Description Integration (UDDI). Specificatia UDDI descrie cum

un potential client al serviciului Web poate invata despre capabilitatile serviciului si cum

poate obtine informatia de baza necesara pentru a face contactul cu site-ul. Acest contact

include si descarcarea documentului WSDL. Registrii UDDI pot fi publici, privati sau

semiprivati.

2.2.3 Arhitectura

Un serviciu Web este o functionalitate software accesibila in retea si construita pe

tehnologii independente de platforma, limbaj de programare si componente. Serviciile Web

se bazeaza pe Service-Oriented Architecture (SOA) unde functionalitatea software este

distribuita intr-un set de servicii. Pentru ca un serviciu sa existe in domeniul SOA, este

necesar un mecanism care sa descrie, sa descopere si sa faca apel la servicii. In figura

urmatoare se observa diferite roluri si interactiunile dintre aceste roluri intr-o arhitectura

orientata pe servicii.


coordonare agenţi

11/ 2/6/2009

Figura 2.1. Arhitectura orientata pe servicii

Arhitectura SOA descrie 3 roluri de baza (vezi figura 2.1):

Service Provider. Furnizorul de servicii este responsabil cu implementarea serviciilor

Web. Prima sarcina pe care un service provider trebuie s-o indeplineasca este de a

determina functionalitatea pe care o ofera ca serviciu. O data ce au realizat acest

lucru, trebuie sa descrie interfata acestei functionalitati intr-o metoda standard. In

final, trebuie sa publice aceasta interfata intr-un registru pentru a oferi consumatorilor

de servicii posibilitatea de a-si gasi servicii web.

Service Registry. Registrul de servicii functioneaza ca un repozitoriu de servicii Web.

Ofertantii de servicii publica in acest registru definitiile serviciilor lor. Prin urmare,

registrele de servicii au facilitate de publicare a serviciilor web si functioneaza ca un

repozitoriu pentru consumatorii de servicii, pentru a le permite acestora sa gaseasca

aceste servicii Web si de a le asigura informatia necesara pentru a apela serviciul Web.

Service Consumer. Consumatorul de servicii foloseste serviciile Web create de

ofertantul de servicii. Regaseste toata informatia necesara pentru a se conecta (bind) la

serviciul web din registrul de servicii, incluzand interfata la serviciul respectiv

publicat de provider-ul de servicii. Interfata ofera detalii ale metodelor, parametrilor si

protocolului de transport necesar pentru utilizarea lui.

SOA definit mai sus este un model abstract, dar are totusi cateva instantieri concrete.

Una din aceste instantieri o reprezinta stiva de specificatii pentru servicii Web. Aceasta

descrie tehnologiile folosite pentru a asigura functiile descrise mai sus: gaseste, conecteaza si

publica. Figura 2.2 prezinta o aceasta stiva impreuna cu tehnologiile necesare.

La nivelul cel mai de jos este nivelul de transport responsabil cu comunicarea intre

porturile de comunicare care pot trimite si primi mesaje. Tehnologiile de servicii Web

protejeaza investitia in tehnologiile de retele existente, folosind unele mecanisme de transport

deja existente si foarte des folosite, in special HTTP. Este important de stiut ca se poate folosi

orice protocol de transport. Cu un nivel mai sus se gaseste nivelul de mesaje, responsabil cu

invocarea serviciilor web de catre consumator. Aici consumatorul foloseste mesaje SOAP

pentru a apela metodele oferite de serviciul Web si ofertantul de servicii descrie interfata

respectiva intr-o metoda standard cu WSDL (Web Services Description Language). Pe cel mai

de sus nivel se afla descoperirea serviciilor Web, implementata in UDDI (Universal

Description and Discovery Interface).


coordonare agenţi

12/ 2/6/2009

Figura 2.2. Stiva de servicii Web


coordonare agenţi

13/ 2/6/2009

3 Standarde si instrumente pentru servicii Web

3.1 Standarde pentru servicii Web

3.1.1 SOAP

SOAP (Simple Object Access Protocol) este un format bazat pe XML si permite apel la

distanta (Remote Procedure Calls) si transport de mesaje peste orice protocol de retea, dar in

special peste HTTP [SOA07]. Deoarece se foloseste formatul XML in locul celui binar, acesta

este interoperabil intre platforme, limbaje de programare, componente, etc. Deoarece este

bazat pe mesaje, SOAP poate fi usor implementat peste protocoale de retea asincrone cum ar

fi SMTP sau JMS – Java Messaging Services.

SOAP are cateva avantaje comparativ cu predecesorul sau, protocol XML-RPC. XML-

RPC Protocol este un protocol simplu care permite apeluri la distanta folosind XML pentru

codificare si HTTP pentru protocolul de transport. SOAP este construit pe baza acestui

protocol, oferind suport pentru tipuri de date complexe si diferite protocoale de transport,

impreuna cu posibilitatea de a specifica exact metoda de procesare a mesajelor.

W3C a inceput lucrul la formatul SOAP in 1999 [SOA07]. In prima versiune (1.0) a

specificatiilor, SOAP era in intregime bazat pe HTTP. In urmatoarea revizie a specificatiilor

(SOAP 1.1, Mai 2000), SOAP a fost pus deasupra mai multor protocoale de transport. In mai

2003, W3C a propus versiunea SOAP 1.2, versiunea revizuita. Versiunea curenta este SOAP

1.2 care clarifica si adauga aspecte semantice peste SOAP 1.1 in termenii legarii de

protocoale de transport si codificarii XML.

SOAP defineste modul de organizare a informatiei utilizand XML intr-o forma

structurata, si specifica urmatoarele:

Un format de mesaj pentru comunicarea unidirectionala, descriind cum poate fi

impachetata informatia intr-un document XML.

Un set de conventii pentru folosirea mesajelor SOAP pentru a implementa modelul de

interactiune RPC, definind cum clientii pot invoca o procedura aflata la distanta prin

trimiterea de mesaje SOAP si cum serviciile pot raspunde prin trimiterea unui alt

mesaj SOAP inapoi la apelant.

Un set de reguli pe care fiecare entitate care proceseaza un mesaj SOAP trebuie sa le

urmareasca, definind in particular elemente XML pe care entitatea trebuie sa le

citeasca si intelege si actiuni pe care entitatile trebuie sa le ia daca nu inteleg

continutul.

O descriere a modalitatii in care mesajul SOAP trebuie sa fie transportat cu un

protocol de transport (HTTP, SMTP).

Ca si protocol de comunicare, SOAP este fara stare si unidirectional. De asemenea,

SOAP ignora aspectele semantice ale mesajelor.

Un mesaj SOAP este un document XML care consta din urmatoarele 3 parti prezentate,

mai jos.

<SOAP-ENV: Envelope

xmlns: SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"


coordonare agenţi

14/ 2/6/2009

xmlns: xsd="http://www.w3.org/2001/XMLSchema"

xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

...

</SOAP-ENV:Header>

<SOAP-ENV:Body>

...

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP schimba informatie, folosind mesaje [ACKM04]. Aceste mesaje sunt folosite ca

un plic (envelope) unde aplicatia inchide orice informatie care trebuie trimisa. Fiecare plic

(envelope) contine 2 parti: header si body. Elementul header este optional, in timp ce

elementul body este obligatoriu. Atat elementul header si body pot avea subparti multiple sub

forma de blocuri header si blocuri body.

Figura 3.1. Structura mesajelor SOAP

SOAP presupune ca fiecare mesaj are un emitator, un receptor si un numar arbitrar de

intermediari (noduri) care proceseaza mesajul si il trimit la receptor. Principala informatie pe

care emitatorul o trimite la receptor trebuie sa se gaseasca in corpul mesajului. Informatia

aditionala necesara procesarii intermediare (autentificare, securitate, tranzactie, versiune) se

gaseste in header. Ideea urmareste metoda din protocoalele standard de comunicare.

SOAP Envelope

SOAP header

Header Block

SOAP Body

Body

Block


coordonare agenţi

15/ 2/6/2009

Exista doua aspecte care influenteaza modul in care sunt construite mesajele SOAP din

header si body [SOA07]: stilul de interactiune si regulile de codificare. Stiluri de interactiune

pot fi: interactiune bazata pe document si RPC. In interactiunea de tip document, cele doua

aplicatii care interactioneaza se pun de acord cu structura documentelor schimbate intre ele.

Mesajele SOAP sunt folosite pentru a transporta aceste documente de la o aplicatie la alta.

Exemplu de mesaj SOAP care contine cele trei componente:

<SOAP-ENV: Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<SOAP-ENV:Header>

<t:Transaction

xmlns:t="some-URI"

SOAP-ENV: mustUnderstand="1">

5

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI">

<symbol>DEF</symbol>

</m:GetLastTradePrice>

</SOAP-ENV:Body>


a. SOAP Envelope

SOAP envelope este elementul radacina obligatoriu al mesajului SOAP. Contine un tag

<Header> optional, ce permite specificarea informatiilor aditionale despre mesajul, si un tag

obligatoriu <Body> ce contine mesajul propriu-zis, fie el o cerere de la un serviciu sau un

raspuns de la server. Elementul <Envelope> poate fi comparat cu plicul unei scrisori.

b. Header-ul SOAP

Specificatia SOAP nu defineste cum sunt utilizate caracteristici precum autentificare,

securitate, tranzactie, versiune etc. Totusi, aplicatiile au posibilitatea de a extinde protocolul

prin adaugarea de informatie in tag-ul <Header>. De exemplu, poate fi folosit acest element

pentru a adauga informatie despre securitate:

<SOAP-ENV:Header>

<axis:security xmlns:axis="http://www.wrox.com/axis">

<axis:loginid>0495-40359-35345309-9-935-349543</axis:loginid>

</axis:security>

</SOAP-ENV:Header>

Marcajul <Header> are 2 atribute: mustUnderstand si actor – amandoua extrem de

importante. Acestea sunt componente intre clientul SOAP si serverul SOAP, procesand atat

raspunsul cat si cererea mesajului. De exemplu, instrumentul AXIS asigura suport pentru

intermediarii SOAP, permitand introducerea propriilor handle-re care pot intercepta cererea

si/sau raspunsul.


coordonare agenţi

16/ 2/6/2009

Atributul mustUnderstand indica destinatarului mesajului SOAP (intermediar sau final)

faptul ca atributul header trebuie procesat obligatoriu. Daca valoarea atributului

mustUnderstand este 1, trebuie recunoscut elementul <Header> si procesat. Daca elementul

nu este recunoscut, trebuie raportata o exceptie ca SOAP Fault. Daca mustUnderstand este

setat pe 0, procesarea elementului este optionala. Un exemplu de atribut mustUnderstand este

prezentat mai jos:

<SOAP-ENV:Header>

<axis:transaction xmlns:axis="http://www.wrox.com/axis"

SOAP-ENV:mustUnderstand="1">

<axis:transactionid>3534-121212</axis:transactionid>

</axis:transaction>

</SOAP-ENV:Header>

Atributul actor specifica cine trebuie sa proceseze informatia din header. Actorul poate

fi: none, next, ultimateReceiver. Daca actorul este none atunci informatia din header nu este

necesar sa fie procesata; next indica ca un nod care primeste mesajul poate procesa blocul din

header; ultimateReceiver indica ca header-ul este procesat in recipientul final al mesajului.

c. SOAP Body

Elementul <Body> defineste continutul mesajului. Elementul poate fi un apel RPC sau

un mesaj. Poate de asemenea contine SOAP fault in caz de eroare. Specificatia SOAP descrie

cum un apel RPC este mapat in structura XML.

De exemplu, sa presupunem ca avem nevoie sa invocam, folosind SOAP, metoda

getPrice() a obiectului SparePartPrice. Metoda primeste ca si parametru un sir de caractere

(identificatorul obiectului) si returneaza un numar de tip float (pretul obiectului). Serializarea

SOAP RPC a acestui apel va fi ca in exemplul de mai jos:

<SOAP-ENV:Envelope ...>

<SOAP-ENV:Header>...</SOAP-ENV:Header>

<SOAP-ENV:Body>

<ns1:getPrice xmlns:ns1="SparePartPrice">

<sku xsi:type="xsd:string">SKU-123</sku>

</ns1:getPrice>

</SOAP-ENV:Body>


Primul element copil in elementul <Body> identifica metoda getPrice() a obiectului.

Spatiul de nume ns1 indica obiectul. Acesta are, de asemenea, elemente copil care indica

numarul necesar de parametri pentru a invoca metoda getPrice(). In mod similar, cand primim

raspunsul, se va obtine:



<SOAP-ENV:Body>

<ns1:getPriceResponse xmlns:ns1="SparePartPrice">

<getPriceResult xsi:type="xsd:float">10.99</getPriceResult>


coordonare agenţi

17/ 2/6/2009

</ns1:getPriceResponse>

</SOAP-ENV:Body>


In acelasi timp, exista o mare flexibilitate a folosirii mesajului de tip document-based

protocol in loc de mecanismul RPC descris mai sus. Pentru stilul document-based

mecanismul este urmatorul: se trimita mesajul serverului SOAP, serverul SOAP proceseaza

mesajul si trimite un raspuns. Diferenta este ca acum se lucreaza cu un mesaj intreg in loc de

obiecte, metode si parametri. Pe scurt, elementul <Body> contine intregul document XML

care va fi interpretat si procesat de destinatar. Protocolul bazat pe document este important

pentru tranzactii electronice bazate pe standarde, precum ebXML, RosettaNet etc. unde intreg

documentul XML contine detalii despre tranzactie. De exemplu, un protocol bazat pe

document poate avea o cerere de forma:



<SOAP-ENV:Body>

...[XML Document as Request] e.g. ebXML Payload / RosettaNet

Payload

</SOAP-ENV:Body>


Raspunsul este similar:



<SOAP-ENV:Body>

...[XML Document as Response]

</SOAP-ENV:Body>


d. Tratarea erorilor in SOAP

Specificatia SOAP mentioneaza, de asemenea ca toate erorile ar trebui raportate ca

elemente SOAP <Fault>. Elementul <Body> al mesajului de raspuns SOAP poate contine

elementul <Fault> ca in exemplul, de mai jos:

<SOAP-ENV:Body>

<Fault>

<faultcode>...</faultcode>

<faultactor> </faultactor>

<faultstring> </faultstring>

<detail> </detail>

</Fault>

</SOAP-ENV:Body>

Un element <Fault> contine elementele <faultcode>, <faultactor>, <faultstring> si

<detail>.


coordonare agenţi

18/ 2/6/2009

Elementul <faultcode> este folosit pentru a indica sursa erorii. Poate avea urmatoarele

valori:

VersionMismatch: indica faptul ca destinatarul mesajului nu intelege atributul

namespace al elementului <Envelope>.

MustUnderstand: indica faptul ca destinatarul elementului copil al elementului

<Header> are un atribut MustUnderstand dar destinatarul nu a inteles acest atribut.

Client: indica faptul ca mesajul SOAP nu contine toata informatia necesara

destinatarului pentru procesare. Un motiv poate fi faptul ca lipseste informatie din

elementul <Body> sau ca mesajul a fost format incorect. Este in general un indiciu ca

mesajul nu trebuie retrimis fara modificari.

Server: indica faptul ca destinatarul mesajului nu a fost capabil sa proceseze mesajul

din cauza unor probleme de partea serverului. Cel mai probabil eroarea nu se

datoreaza continutului mesajului.

Elementul <faultactor> este folosit pentru a identifica serviciul care a cauzat eroarea.

Elementul <faultstring> ofera o descriere mai detaliata a erorii. Elementul <detail/> ofera

mai multa informatie specifica aplicatiei. Trebuie sa fie prezenta daca elementul <Body> nu

poate fi procesat.

e. Legatura dintre SOAP si protocoalele de transport

Legarea formatului SOAP la un protocol de transport reprezinta descrierea modalitatii

in care mesajele SOAP sunt trimise folosind protocolul de transport. SOAP nu impune

folosirea unui anumit tip de protocol de transport [ACKM04].

Cel mai comun protocol pentru SOAP este HTTP, dar pot fi folosite si alte protocoale

cum ar fi SMTP. SOAP poate folosi GET sau POST. Cu GET, cererea nu este un mesaj

SOAP, dar raspunsul este un mesaj SOAP, cu POST, atat cererea cat si raspunsul sunt mesaje

SOAP. SOAP foloseste aceleasi erori si coduri de stare ca si HTTP.

SOAP este independent de protocolul de Internet folosit pentru transmiterea mesajelor.

Totusi, specificatia SOAP defineste legaturile pentru cererile HTTP POST. Prin urmare

legatura cu HTTP defineste relatia dintre partile mesajului SOAP si header-ele HTTP. Cele

mai intalnite elemente intr-o cerere SOAP sunt Content-Type, Content-Length si un antet

SOAPAction. Mesajul SOAP este transmis ca si continutul unei cereri sau al unui raspuns

HTTP.

Sa consideram ca exemplu urmatoarea tranzactie SOAP care invoca metoda getPrice() a

obiectului SparePartPrice. Metoda getPrice() are un singur parametru si returneaza valoarea

indicata de pret. Cererea SOAP este mai jos:

POST /axis/services HTTP/1.0

Content-Length: 445

Host: localhost

Content-Type: text/xml; charset=utf-8

SOAPAction: ""

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

<SOAP-ENV:Envelope

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


coordonare agenţi

19/ 2/6/2009

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<ns1:getPrice xmlns:ns1="SparePartPrice">

<sku xsi:type="xsd:string">SKU-123</sku>

</ns1:getPrice>

</SOAP-ENV:Body>


In mod similar, raspunsul SOAP este mapat la raspunsul HTTP ca in exemplul de mai

jos:

HTTP/1.1 200 OK

Content-Type; text/xml: charset=utf-8

Content-Length: 480

Date: Mon, 11 Feb 2002 12:10:32 GMT

Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)

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

<SOAP-ENV:Envelope

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<ns1:getPriceResponse xmlns:ns1="SparePartPrice">

<getPriceResult xsi:type="xsd:float">10.99</getPriceResult>

</ns1:getPriceResponse>

</SOAP-ENV:Body>


3.1.2 WSDL

Web Services Description Language (WSDL) este un limbaj pentru descrierea

interfetelor serviciilor Web. Cu ajutorul sau se pot descrie serviciile Web astfel: metodele care

pot fi invocate, parametrii metodelor, tipurile parametrilor, protocolul care va fi folosit, etc.

Avand dat un document WSDL al unui serviciu Web se poate scrie un client care sa invoce

functionalitatea serviciului Web [WSD07].

Documentul WSDL este un document XML structurat in doua parti: prima este o

definitie abstracta a serviciului Web si contine tipuri de date, metode, etc., si a doua contine

detalii despre protocolul de transport folosit (HTTP, SMTP, FTP, etc) si implementarea de

SOAP folosita.


coordonare agenţi

20/ 2/6/2009

Figura 3.2. Structura documentului WSDL

Elementele documentului sunt [WSD07]:

Elementul <type> reprezinta tipurile de date folosite in mesajele schimbate in

comunicarea cu serviciul Web: float, integer, string, etc. WSDL foloseste

specificatiile XML Schema pentru codificarea tipurilor de date.

Fiecare element <message> reprezinta o unitate de comunicatie cu serviciul invocat.

O operatie in terminologia WSDL reprezinta semnatura metodei si cuprinde legatura

dintre mesajele de intrare si iesire. O operatie descrie astfel un schimb simplu de

mesaje cu serviciul Web.

Elementul <portType> descrie o multime de operatii expuse de serviciul Web. Fiind

asemanator unei interfete din invocarea procedurilor la distanta. Elementul

<portType> contine o colectie de operatii.

Elementul <binding> este folosit pentru a specifica protocolul de transport care este

folosit (SOAP este folosit peste HTTP, SMTP, posibil si alt protocol de transport)

impreuna cu tipul de cerere SOAP (rpc sau document).

Un element <service> creeaza legatura cu implementarea actuala a serviciului. Acesta

va referi elementul <binding> care este asociat cu elementul <port> ce contine adresa

serviciului Web sub forma unui URL.

Serviciul Web SparePartPrice are o singura metoda numita getPrice(). Metoda

getPrice() primeste un singur parametru de tip string si returneaza pretul care este de tipul

float. Documentul WSDL pentru acest serviciu este urmatorul:

Elementul radacina este <definitions>:

<wsdl:definitions

targetNamespace=

http://localhost:8080/ea-axis/services/SparePartPrice"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:impl=

"http://localhost:8080/ea-axis/services/SparePartPrice-impl"

xmlns:intf="http://localhost:8080/ea-axis/services/SparePartPrice"


coordonare agenţi

21/ 2/6/2009

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/soap/

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Elementele <message> definesc parametrii de intrare (getPriceRequest) si de iesire

(getPriceResponse), cu tipurile de date potrivite.

<wsdl:message name="getPriceResponse">

<wsdl:part name="return" type="xsd:float"/>

</wsdl:message>

<wsdl:message name="getPriceRequest">

<wsdl:part name="in0" type="xsd:string"/>

</wsdl:message>

Elementul operation este similar cu apelul unei metode in Java. Exista insa diferenta ca

numai 3 mesaje sunt permise intr-o operatie:

Elementul <input> defineste datele pe care serviciul Web asteapta sa le primeasca ca

cereri.

Elementul <output> defineste datele pe care serviciul Web asteapta sa le trimita ca

raspuns.

Elementul <fault> defineste mesajele de eroare care sunt returnate de serviciul Web.

Intr-un document WSDL pot fi declarate mai multe tipuri de operatii. Acestea sunt:

Request/Response – clientul face o cerere si serviciul Web raspunde la ea.

Solicit/Response – serviciul Web trimite un mesaj la client si clientul raspunde.

One-way – clientul trimite un mesaj la un serviciu Web, dar nu asteapta nici un mesaj.

Notification – serviciul Web trimite un mesaj la client dar nu asteapta nici un raspuns.

Figura 3.3. Tipul de mesaje transmise intr-o operatie


coordonare agenţi

22/ 2/6/2009

Atributul name al elementului <portType> identifica obiectul – SparePartPrice si

operatiile (metodele) lui. Se observa semnatura metodei: intrarea este mesajul

getPriceRequest() care primeste un string ca parametru si iesirea getPriceResponse() care

returneaza un numar de tip float.

<wsdl:portType name="SparePartPrice">

<wsdl:operation name="getPrice" parameterOrder="in0">

<wsdl:input message="intf:getPriceRequest"/>

<wsdl:output message="intf:getPriceResponse"/>

</wsdl:operation>

</wsdl:portType>

Elementul <binding> mapeaza elementul <portType> (SparePartPrice) la un protocol

specific. In acest caz elementul se mapeaza la SOAP.

<wsdl:binding name="SparePartPriceSoapBinding"

type="intf:SparePartPrice">

<wsdlsoap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="getPrice">

<wsdlsoap:operation soapAction="" style="rpc"/>

<wsdl:input>

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace=

"http://localhost:8080/ea-axis/services/SparePartPrice"

use="encoded"

/>

</wsdl:input>

<wsdl:output>

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace=

"http://localhost:8080/ea-axis/services/SparePartPrice"

use="encoded"

/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

Elementul <service> face maparea la elementul <port> care reprezinta adresa fizica

accesibila a serviciului Web.

<wsdl:service name="SparePartPriceService">

<wsdl:port binding="intf:SparePartPriceSoapBinding"

name="SparePartPrice">


coordonare agenţi

23/ 2/6/2009

<wsdlsoap:address location=

"http://localhost:8080/ea-axis/services/SparePartPrice"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Structura de date WSDL are implicatii interesante in ceea ce priveste interactiunea

dintre servicii. Unele dintre ele sunt legate de tipurile de operatii. Modurile de interactiune

care pot fi asociate cu operatii WSDL arata ca un serviciu poate initia interactiunea si un

serviciu nu expune doar operatii care sa poata fi invocate, insemnand ca un serviciu poate

actiona ca un client. In domeniul serviciilor Web, fiecare entitate de interactiune este

modelata, de obicei ca un serviciu WSDL.

O alta implicare a specificatiei WSDL este aceea ca nu se presupune o anumita forma

particulara pentru schimburile care au loc. De aceea, WSDL poate descrie 2 aspecte ale

serviciilor Web: interfata abstracta a serviciului, fara a specifica locatia sau protocolul care se

foloseste si partea a doua reprezinta locatia serviciului si protocolul de comunicare folosit

[WSD07].

Avantajul acestei separari este acela ca specificatiile WSDL care descriu interfete

abstracte pot fi reutilizabile: servicii diferite pot fi combinate in interfete, folosind diferite

metode de legare (bindings) si sa le faca disponibile la diverse adrese. Reutilizarea este

facilitata, de asemenea, de faptul ca documentele WSDL pot sa importe alte documente

WSDL.

Se observa, de asemenea, corelatia dintre descrierea WSDL si SOAP. Abilitatea atat a

SOAP, cat si a WSDL de a fi capabile sa foloseasca mai multe tipuri de legaturi cu

protocoalele de transport si codificarile XML, este aspectul crucial al eforturilor de

standardizare a serviciilor Web [WSD07].

WSDL este un standard orizontal in sensul ca acesta poate fi utilizat de o varietate de

instrumente si nu contine nici o specificatie a unui domeniu particular. Acesta a fost proiectat

ca un limbaj generic de descriere a serviciului. Pe langa WSDL, au fost create numeroase

standarde B2B, printre acestea sunt Electronic Data Exchange (EDI) folosit in manufacturing

si SWIFT folosit in lumea financiara.

Avantajul acestor standarde peste WSDL este acela ca sunt proiectate pentru aplicatii

concrete si captureaza aspecte semantice pe care WSDL nu este capabil sa le captureze.Este

posibil ca unele din aceste standarde sa convearga tot la WSDL, producand standarde hibride

care vor fi utilizate in arii de aplicatii concrete, iar alte standarde sa supravietuiasca si sa

ramana independente de WSDL.

3.1.3 UDDI

Probabil specificatia UDDI este cea mai elaborata dintre toate specificatiile de pana

acum [UOS08]. Ultima versiune este 3.0.2.

versiunea 1 definea conceptele de baza pentru directoare de servicii de business

(business service registry)


coordonare agenţi

24/ 2/6/2009

versiunea 2 adapteaza lucrul serviciilor de directoare UDDI la SOAP si WSDL

versiunea 3 redefineste rolul si scopul directoarelor UDDI, pune in evidenta rolul

implementarilor private si se ocupa cu problema interactiunii dintre directoarele UDDI

private si publice.

Initial, UDDI a fost conceput ca si “Universal Business Registry” similar cu motoarele

de cautare (e.g., Google) si va fi folosit ca mecanism principal pentru a gasi serviciile

electronice oferite de companii din lumea intreaga.

In prezent, UDDI este cea mai pragmatica specificatie si recunoaste realitatile

interactiunilor B2B: acesta este o infrastructura pentru serviciile Web, avand acelasi rol ca si

serviciul de nume si director (binder in RPC), dar aplicat serviciilor Web si folosit in medii cu

constrangeri (intern intr-o companie sau intr-o multime de parteneri de afaceri).

Exista cativa registri UDDI universali mentinuti de IBM, Microsoft, SAP, etc. Acesti

registri sunt vizibili, dar din pacate sunt foarte mici si cele mai multe intrari nu functioneaza

sau nu corespund unui serviciu real [UOS08].

Serviciile oferite prin Internet companiilor necesita mult mai multa informatie decat

intr-un serviciu tipic de middleware. Registrii UDDI se comporta ca si alte servicii Web:

Figura 3.4. Registrii UDDI

Toate API-urile din specificatiile UDDI sunt definite in XML, localizate in elementele

SOAP envelope si trimise peste HTTP. In plus cererile clientilor care necesita modificarea

datelor trebuie sa fie securizate si autentificate.

O intrare intr-un registru UDDI este un document XML compus din diferite elemente,

cele mai importante fiind [UOS08]:

businessEntity: reprezinta descrierea organizatiei care ofera serviciul.

BusinessService: este o lista de servicii Web oferite de entitatea de business.

bindingTemplate: descrie aspectele tehnice al serviciului care va fi oferit.

tModel: (“technical model”) este un element generic care poate fi utilizat pentru a

memora informatii aditionale despre serviciu, in special informatie tehnica aditionala

despre cum se foloseste serviciul, conditiile de utilizare, garantii, etc.

Impreuna, aceste elemente sunt folosite pentru a oferi:


coordonare agenţi

25/ 2/6/2009

Informatii despre paginile albe: date despre cel care ofera serviciul (nume, adresa,

persoana de contact, etc.)

Informatii despre paginile galbene: ce tip de servicii sunt oferite si o lista cu diferitele

servicii oferite

Informatii despre paginile verzi: informatie tehnica despre cum sunt folosite fiecare din

serviciile oferite, incluzand referinte la descrierile WSDL ale serviciilor (care nu se

gasesc in registrul UDDI)

Entitatea Business

Informatia despre paginile generice albe si galbene despre cel care ofera serviciul este

memorata in entitatea businessEntity, care contine urmatoarele date:

fiecare businessEntity are un businessKey

discoveryURLs este o lista de URL-uri

Name: contine informatie textuala

Business description: contine informatie textuala

Contacts: contine informatie textuala

businessServices: o lista de servicii oferite de entitatea businessEntity

identifierBag: o lista de identificatori externi

categoryBag: o lista de categorii de business (de exemplu, industrie, categorie produs,

regiune geografica)

Entitatea Business nu trebuie sa fie o companie. Aceasta trebuie sa reprezinte orice entitate

care ofera servicii: poate fi un departament, un grup, server sau o multiem de servere, etc.

Serviciul Business

Serviciile oferite de o entitate de afacere sunt descrise folosind elemente

businessService. Elementul businessService poate descrie un serviciu Web sau un grup de

servicii Web asociate (toate oferite de aceeasientitate businessEntity).

Binding Template

Sablonul de legatura Bindingtemplate contine informatie tehnica asociata unui serviciu

particular care consta in:

bindingKey

serviceKey

description

accessPoint: adresa de retea a servicului oferit ( de obicei un URL)

tModels: este o lista de intrari corespunzatoare elementului tModels asociat cu un

anumit element de legatura. Aceasta lista include referinte la tModels, documente care

descriu tModels, scurte descrieri, etc.

categoryBag: informatie aditionala despre serviciu si despre legaturile sale (de exemplu

daca este o legatura de test, sau este in productie, etc)

businessService poate avea mai multe bindingTemplates dar un bindingTemplate poate

avea doar un businessService

binding template poate fi vazut ca un director unde este memorata informatia tehnica

despre serviciu


coordonare agenţi

26/ 2/6/2009

tModel

tModel este un container de informatie unde proiectantii pot scrie informatie tehnica

asociata cu folosirea unui serviciu Web:

interfata si protocolul folosit, incluzand o referinta a descrierea WSDL

descrierea protocolui de afacere si conversatiile suportate de serviciu

Acesta contine

tModelKey

name

description

overviewDoc: (cu un overviewURL si useType care indica unde se gaseste informatia

si formatul sau, de exemplu “text” sau “wsdldescription”)

identifierBag

categoryBag

Interfete UDDI

Specificatia UDDI ofera un numar de API-uri (Application Program Interfaces) care

dau posibilitatea accesului la un sistem UDDI:

UDDI Inquiry: pentru a localiza si gasi detalii in registrii UDDI si suporta navigarea,

invocarea, etc.

UDDI Publication: pentru a publica si modifica informatia in registrii UDDI. Toate

operatiile din acest API sunt atomice in sensul tranzactional.

UDDI Security: pentru controlul accesului la registrii UDDI.

UDDI Subscription: permite clientilor sa subscrie la schimbarile de informatii din

registrele UDDI.

UDDI Replication: descrie cum se efectueaza replicarea informatiei in nodurile din

registrele UDDI.

UDDI Custody si Ownership transfer: folosite pentru a schimba proprietarul

(publisher) informatiilor si pentru a transfera custodia de la un nod la altul din registrul

UDDI.

UDDI ofera de asemenea API-uri pentru clientii sistemul UDDI:

UDDI Subscription Listener: partea de client pentru API de subscriere.

UDDI Value Set: folosit pentru a valida informatia oferita de un registru UDDI.

3.2 Instrumente pentru servicii Web

3.2.1 AXIS2

Pentru a putea crea servicii Web, avem nevoie de anumite instrumente software. In

primul rand avem nevoie de un procesor care sa prelucreze mesajele SOAP primite si sa

apeleze functii sau metode pe care aceste mesaje le indica. Pe piata exista mai multe produse

care sa raspunda acestor cerinte.

In plus, unele dintre ele ofera si alte instrumente care sa ajute dezvoltatorul sa scrie cod

necesar crearii de servicii Web. Unul dintre aceste produse este Apache Software

Foundation’s Axis [AA08].


coordonare agenţi

27/ 2/6/2009

Apache Axis este un proiect open-source, iar numele provine de la Apache Extensible

Interaction System. In prezent Axis a ajuns la versiunea 2.

Axis realizeaza implementarea formatului Simple Object Access Protocol: SOAP.

SOAP este folosit pentru interschimbarea datelor intr-un mediu distribuit. Soap este construit

pe baza limbajului XML. Exista cateva implementari pentru SOAP, si una dintre aceste

implementari este Apache SOAP, care in present a ajuns la versiunea 2.2. Axis este de

asemenea creat de proiectul Apache. Apache Axis a fost complet rescris si a fost imbunatatit,

devenind mult mai flexibil si performant. Axis poate fi vazut ca vesiunea 3 pentru Apache

Soap.

Arhitectura Axis

Scopul fiecarui instrument de dezvoltare a serviciilor Web este acela de a construi o

legatura intre procesarea mesajelor SOAP si logica de business care se executa pe server. In

mod normal, logica de afacere este pastrata separat de logica procesarii mesajelor SOAP. In

urmatoarea figura se prezinta aceasta structura [AA08].

Figura 3.5. Arhitectura Axis

Arhitectura Apache Axis este construita pe fundatia motorului de procesare a mesajelor

SOAP. Acest motor de procesare accepta mesaje SOAP, le parseaza si apeleaza metode si

functii din serviciul Web.

Componentele principare ale sistemului AXIS sunt:

AxisEngine - acesta este elementul principal in procesarea SOAP si

functioneaza ca si controler pentru alte componente.

MessageContext – clasa Messagecontext este ca un „wrapper” pentru cererile si

raspunsurile SOAP; aceasta ofera informatie despre mesaje celorlalte

componente din sistemul de procesare a mesajelor din AXIS.

Handlers,Chains - handler-ele sunt blocurile de baza din sistemul AXIS. Un

handler primeste un obiect MessageContex si efectueaza o anumita actiune pe

baza continutului acestuia. Chain este un handler special care reprezinta un sir

de alte handler-e.

Transport – componenta de transport ofera un mecanism pentru ca mesajele

cerere sa ajunga la AXISEngine si pentru a trimite mesaje raspuns la client.

Serializers, Deserializers – acestia convertesc datele din forma lor nativa in

XML, si invers.

Deployment, Configuration – AXIS defineste un descriptor bazat pe XML

cunoscut ca Web Service Deployment Descriptor care defineste cum o instanta

particulara a AXIS trebuie sa se comporte.


coordonare agenţi

28/ 2/6/2009

Procesarea mesajelor SOAP

Principalul punct de intrare intr-un serviciu Web este Axis. Acest motor parseaza

mesajele si apeleaza lanturile de handlerele potrivite in coformitate cu instructiunile oferite

pentru descarcarea serviciilor Web. Dupa cum se poate observa din figura urmatoare, Axis

trebuie sa existe atat pe partea de client, cat si pe partea de server.

Figura 3.6. Sistemul AXIS si procesarea mesajelor

Punctul principal al sistemului de pe client sau server este clasei implementarea

org.apache.axis.AxisEngine. In terminologia UML, AXISEngine joaca rolul de actor care

interactioneaza cu alte componente de procesare a mesajelor, cum ar fi handler-ele si lanturile

de handlere si coordoneaza fluxul de mesaje prin intregul sistem.

Sistemul de procesare de mesaje din AXIS foloseste un obiect de tip Message pentru a

interpreta mesajele SOAP de tip request, response, fault. Obiectele Message sunt incluse in

obiecte MessageContext si apoi sunt disponibile tuturor componentelor (chain, handler, etc.).

Obiectul MessageContext este de fapt un container de mesaje request, response, fault care de

asemenea ofera informatii contextuale, cum ar fi protocolul de transport cu ajutorul caruia

mesajele sunt primite, referinte despre la instanta AxisEngine, etc.

Clasa abstracta org.apache.axis.AxisEngine descrie sistemul de procesare a mesajelor.

Axis ofera urmatoarele implementari ale AxisEngine:

AxisServer – aceasta este pentru partea de procesare a mesajelor pe server

AxisClient – aceasta este pentru partea de procesare a mesajelor pe client

AxisEngine este de asemenea responsabil pentru invocarea tuturor lanturilor de handlere in

ordinea definita in descriptorul de descarcare si sa se asigure ca semantica mesajelor SOAP

este respectata. De exemplu, AxisEngine, trebuie sa asigure ca atribute ca mustUnderstand

sunt tratate corect.

Handlere, Chains

Axis este construit pe ideea de handlere. Un handler este o parte de cod care efectueaza

o anumita functie. Un handler poate pastra log-urile mesajelor sau altul poate decripta mesaje

etc. Aceste handlere trebuie scrise in Java, in versiunile curente de Axis, dar o versiune 1.6 de

C++ a Axis este in dezvoltare . Handlerele sunt direct invocate de Axis.


coordonare agenţi

29/ 2/6/2009

Axis chains sunt tipuri speciale de handlere care pot contine alte handlere. Handlerele

pe care ele le contin pot fi de asemenea lanturi. Executia acestora este ordonata, astfel incat

lanturile reprezinta un tip de limbaj de control, dar fara pasare de parametri.Un lant tinta este

un tip special care contine mai multe intrari intr-un punct. Handlerele de transport au atat

parte de client cat si de server, care permit unui handler HTTP sa primeasca dar si sa trimita

mesaje.

In figura urmatoare se observa cum handlerele pot fi folosite pentru a subdiviza sarcini

asociate cu procesarea mesajelor SOAP.

Figura 3.7. Procesarea mesajelor SOAP

Transport

Transportul reprezinta mecanismul de a transmite si primi mesaje de la /la Axis. La

inceput, HTTP a fost un protocol pentru orice motor de servicii Web, dar suportul pentru

SMTP, FTP si JMS a inceput sa apara de curand. Toate aceste tipuri de transport au o

modalitate de a transfera datele de la un calculator la altul, dar cu grade variate de siguranta si

viteza [AA08].

Dispecer

Un dispecer este un tip special de handler care este folosit pentru a separa logica de

business de logica handlerelor. Un dispatcher special, RPCDispatcher converteste mesajele

SOAP la obiecte Java si apoi apeleaza serviciul Web, eliminand astfel logica de afacere din

handlere.

Ascultatori de transport

Un ascultator de transport este un servlet care asteapta mesajele SOAP. Acesta este

responsabil pentru crearea unei instante a Axis (sau gasirea unei instante existente) si pasarea

de mesaje SOAP la aceasta. De asemenea, ii spune motorului de Axis ce tip de transport sa

foloseasca pentru a returna raspunsul clientului. Un sistem care suporta 3 tipuri de transport

are 3 ascultatori de transport:


coordonare agenţi

30/ 2/6/2009

Figura 3.8. Ascultatorii de transport

Dupa ce un ascultator de transport proceseaza mesajul, acesta devine mesaj SOAP

generic. Aceasta permite ca procesarea sa fie facuta in acelasi fel pentru toate mesajele

indiferent de mecanismul de trasnport folosit pentru a le trimite.

Transmitatorii de transport

Cand Axis actioneaza ca un client, are nevoie sa trimita un mesaj SOAP ca si cerere pentru

serverul de SOAP. Handlerele de Axis care fac aceasta se numesc transmitatori de transport.

Daca un mesaj SOAP trebuie trimis la un serviciu Web prin HTTP, se va folosi transmitatorul

de transport HTTP din AXIS.


coordonare agenţi

31/ 2/6/2009

4 Standardele FIPA

4.1 Principalele specificatii FIPA

4.1.1 Structura unui mesaj FIPA ACL

Comunicarea intre agenti este diferita de comunicarea dintre obiecte in paradigma

orientata pe obiecte (invocarea de metode): deoarece agentii sunt autonomi, un agent nu poate

obliga un alt agent sa execute o actiune si nici nu poate modifica starea interna a unui agent.

In schimb un agent poate comunica in incercarea de a influenta alti agenti.

Comunicarea poate fi tratata ca actiune, pornind de la teoria actelor de comunicare

("speech act theory") [Aus62], [Sea69]. Aceasta se bazeaza pe faptul ca actele de comunicare

sunt realizate de agenti ca oricare alte actiuni, in sprijinul intentiilor lor [Coh79], [Coh90].

Teoria actelor de comunicare a influentat in mod direct un numar de limbaje dezvoltate

special pentru comunicarea intre agenti. Astfel la inceputul anilor 1990 au fost dezvoltate

doua limbaje de catre KSE (US-based DARPA-funded Knowledge Sharing Effort) [KES93]:

KQML (Knowledge Query and Manipulation Language) – un limbaj de comunicare

interagenti bazat pe mesaje. KQML defineste un format comun pentru aceste mesaje,

incluzand un performativ si un numar de parametri

KIF (Knowledge Interchange Format) – un limbaj bazat pe logica de ordinul I pentru

reprezentarea cunostintelor dintr-un anumit domeniu. A fost creat in primul rand

pentru a reprezenta partea de continut a mesajelor in format KQML.

Limbajul KQML prezinta insa cateva dezavantaje [Woo02], precum:

mecanismele de transport pentru mesajele KQML nu au fost precis definite, facand

dificila interoperabilitatea agentilor care folosesc KQML

multimea prea mare de performative

lipsa unei semantici riguros definite (semnificatia performativelor a fost definita doar

in limbaj natural)

lipsa angajamentelor din multimea de performative

In acest context, pentru a elimina neajunsurile KQML, FIPA a dezvoltat un nou limbaj,

numit ACL (Agent Communication Language), devenit standard in 2002 [ACL02]. ACL

ofera un set de 22 de performative si nu impune un anumit format pentru continutul propriu-

zis ale mesajului, fiind asemanator la nivel de sintaxa cu KQML.

Un mesaj FIPA ACL contine o multime de parametri, care definesc:

tipul actului de comunicare:

o performative (vezi sectiunea 4.2.2)

participantii la comunicare:

o sender – denota identitatea (numele) agentului care trimite mesajul; acesta

poate fi omis daca agentul expeditor doreste sa ramana anonim

o receiver – denota identitatea agentului caruia ii este destinat mesajul. Daca

mesajul este multicast, atunci parametrul va contine o multime de nume de

agenti. Acest parametru poate fi omis daca destinatarul poate fi identificat din

context sau in cazul mesajelor incorporate in proxy sau propagate.


coordonare agenţi

32/ 2/6/2009

o reply-to – indica agentul caruia i se vor trimite urmatoarele mesaje din aceasta

conversatie (in locul agentului din parametrul sender)

continutul mesajului:

o content – denota continutul mesajului, care trebuie interpretat de destinatarul

acestuia. Unele tipuri de mesaje (de exemple cancel) au un continut implicit,

caz in care parametrul content poate sa lipseasca

descrierea continutului:

o language – denota limbajul in care este specificat continutul mesajului (de

exemplu FIPA-SL, FIPA-CCL, FIPA-KIF, FIPA-RDF) (vezi sectiunea 4.2.3)

o encoding – denota modul de codificare al continutului mesajului

o ontology – denota ontologia utilizata in continutului mesajului

controlul conversatiei:

o protocol – denota protocolul de interactiune utilizat de agentul expeditor al

mesajului

o conversation-id – introduce un identificator al conversatiei, care va fi utilizat in

toate actele de comunicare ce fac parte din conversatia curenta

o reply-with – introduce o expresie care va fi utilizata de agentul respondent

pentru a identifica mesajul curent

o in-reply-to – denota o referinta la o actiune anterioara, pentru care mesajul

curent este un raspuns

o reply-by – denota data pana la care expeditorul doreste sa primeasca raspunsul

Dintre acesti parametri, obligatoriu este doar parametrul performative; de asemenea,

majoritatea mesajelor ACL contin si parametrii sender, receiver si content. Unii parametri pot

fi omisi atunci cand valoarea lor poate fi dedusa din context. In plus, o implementare specifica

poate include si alti parametri definiti de utilizator, al caror nume trebuie prefixat cu "X-".

Daca un agent nu recunoaste sau nu poate procesa unul dintre parametri, acesta va raspunde

cu mesajul not-understood.

4.1.2 Tipuri de mesaje FIPA ACL

FIPA propune un set de 22 de performative ([ACT02]). O clasificare a acestor

performative in functie de rolul lor este inclusa in tabelul 4.1.

Performativa Transmitere

de informatii

Cerere de

informatii

Negociere Realizare

de actiuni

Tratarea

erorilor

accept-proposal

agree

cancel

cfp

confirm

disconfirm


coordonare agenţi

33/ 2/6/2009

failure

inform

inform-if

inform-ref

not-understood

propagate

propose

proxy

query-if

query-ref

refuse

reject-proposal

request

request-when

request-whenever

subscribe

Tabelul 4.1. Clasificarea performativele incluse in FIPA ACL (conform [Woo02])

In continuare vom prezenta o descriere succinta (informala) a acestor performative.

accept-proposal – acceptarea unei propuneri (facute anterior de un alt agent) de

realizare a unei actiuni

agree – acordul pentru a realiza o anumita actiune. Este utilizata de un agent pentru a

indica faptul ca accepta o cerere (request) a unui alt agent si ca intentioneaza sa

realizeze actiunea ceruta.

cancel – utilizata de un agent pentru a informa un alt agent ca primul agent nu mai

doreste ca cel de-al doilea agent sa realizeze o anumita actiune (ceruta anterior printr-

un mesaj de tip request)

cfp – cerere de propuneri pentru realizarea unei anumite actiuni; utilizata pentru a

initia negocierea intre agenti. Atributul content cuprinde atat o actiune cat si o conditie

(termenii in care se doreste sa fie realizata actiunea)

confirm – este utilizata de un agent pentru a informa un alt agent ca o anumita

propozitie (continutul mesajului) este adevarata, in conditiile in care expeditorul crede

ca destinatarul are o incertitudine asupra valorii de adevar a acestei propozitii

disconfirm – similara cu confirm; este utilizata de un agent pentru a informa

destinatarul mesajului ca o anumita propozitie este falsa, in conditiile in care

expeditorul crede ca destinatarul crede ca propozitia este adevarata.

failure – utilizata de un agent pentru a informa un alt agent ca o actiune intreprinsa a

esuat.

inform – una dintre cele mai importante performative; mecanismul de baza pentru

comunicarea de informatii; este utilizata de un agent pentru a-l informa pe un alt agent

ca o propozitie este adevarata (expeditorul doreste ca destinatarul sa creada ca

propozitia este adevarata; in mod implicit expeditorul afirma faptul ca el crede ca

propozitia este adevarata)

inform-if – este o macro-performativa, specificand daca o anumita propozitie este

adevarata sau nu. Actele de comunicare pot fi realizate direct, planificate si cerute de


coordonare agenţi

34/ 2/6/2009

un agent unui alt agent; actele macro pot fi planificate si cerute dar nu pot fi realizate

direct. Este si cazul lui inform-if, care este de obicei utilizata ca si continut al unui

mesaj de tip request: expeditorul mesajului cere destinatarului sa-l informeze daca

continutul lui inform-if este adevarat sau fals.

inform-ref – similara cu inform-if; diferenta este ca agentul expeditor doreste sa afle nu

daca o expresie este adevarata sau falsa ci care este valoare unei expresii.

not-understood – Expeditorul mesajului (agentul i) il informeaza pe destinatar (agentul

j) ca a perceput faptul ca j a realizat o anumita actiune dar nu a inteles actiunea

realizata de j. O utilizare comuna este ca i sa-i indice lui j ca nu a inteles mesajul pe

care j tocmai i l-a trimis lui i. Continutul mesajului include atat o actiune (cea care nu

a fost inteleasa) cat si o afirmatie care ofera explicatii referitor la cauza neintelegerii.

propagate – Continutul mesajului cuprinde doua parti: un alt mesaj si o expresie care

denota o multime de agenti. Ideea este ca destinatarul mesajului trebuie sa trimita

mesajul incorporat agentilor desemnati in aceasta expresie.

propose – Un agent face o propunere de realizare a unei actiuni unui alt agent (de

exemplu ca urmare a unui mesaj cfp trimis anterior)

proxy – Expeditorul mesajului il trateaza pe expeditor ca pe un proxy pentru o

multime de agenti. Continutul include atat un alt mesaj incorporat, care se doreste a fi

redirectat catre alti agenti, cat si o specificare a acestor agenti.

query-if - Expeditorul mesajului il intreaba pe destinatar daca o anumita propozitie

(repezentata de continutul mesajului) este adevarata sau nu

query-ref – Expeditorul mesajului il intreaba pe destinatar care este obiectul referit de

o anumita expresie referentiala.

refuse – este utilizata de un agent pentru a indica unui alt agent ca nu va realiza o

anumita actiune; continutul mesajului va cuprinde atat actiunea refuzata cat si o

explicatie a acestui refuz.

reject-proposal – este utilizata de un agent pentru a indica unui alt agent ca nu accepta

o propunere facuta in cadrul unei negocieri (prin intermediul unui mesaj propose).

Continutul mesajului specifica atat propunerea care este respinsa cat si motivele

acestei respingeri

request – utilizata de un agent pentru a cere unui alt agent sa realizeze o anumita

actiune

request-when – utilizata de un agent pentru a cere unui alt agent sa realizeze o actiune

atunci cand o anumita propozitie devine adevarata

request-whenever - similara cu request-when; diferenta este ca actiunea trebuie

realizata atunci cand propozitia devine pentru prima data adevarata, precum si ori de

cate ori propozitia devine din nou adevarata

subscribe – Continutul este o expresie referentiala; expeditorul doreste sa fie informat

de valoarea referintei si ori de cate ori obiectul identificat de referinta se modifica.

Exemple de mesaje ACL [ACT02]:

1. Agentul i il informeaza pe agentul j ca (este adevarat ca) ninge astazi.


coordonare agenţi

35/ 2/6/2009

2. Agent i ii cere agentului j sa livreze o cutie la o anumita locatie; j raspunde ca este de

acord cu cererea, dar aceasta va avea o prioritate mica.

3. Agentul j ii cere agentului i sa ii trimita propunerea sa pentru vanzarea a 50 de cutii

de prune:

4. Agentul j il informeaza pe agentul i ca a esuat in incercarea de a deschide un fisier


coordonare agenţi

36/ 2/6/2009

5. Agentul i il informeaza pe agentul j ca nu a inteles un mesaj query-if pentru ca nu a

recunoscut ontologia.

6. Agentul i il intreaba pe agentul j care sunt serviciile disponibile. Agentul j ii raspunde

ca poate face rezervari pentru tren, avion, masina.

7. Agentul i ii spune agentului j sa-l anunte ori de cate ori pretul componentelor creste

peste 50.

Cum una din cele mai importante critici aduse limbajului KQML a fost lipsa unei

semantici clare, FIPA ACL ofera o semantica formala riguroasa. Solutia abordata porneste de

la teoria actelor de comunicare ca actiuni rationale [Coh90], [Bre97]. Definirea semanticii se

bazeaza pe un limbaj formal numit FIPA SL [SL02], care permite reprezentarea


coordonare agenţi

37/ 2/6/2009

convingerilor, dorintelor si convingerilor incerte ale agentilor, precum si a actiunilor realizate

de agenti. Au mai fost propuse si alte limbaje pentru specificarea mesajelor semantice: CCL

[CCL01], KIF [KIF03], RDF [RDF01], dar acestea au inca un statut experimental. Singurul

care a devenit standard este FIPA-SL, pe care il vom prezenta in sectiunea urmatoare.

4.1.3 Limbajul FIPA-SL pentru specificarea mesajelor semantice

Fiecare mesaj ACL e mapat la o formula din limbajul SL, care defineste o constrangere

(numita conditie de fezabilitate) pe care agentul care trimite mesajul trebuie sa o respecte

pentru a fi considerat conform cu standardul ACL. De asemenea, semantica mapeaza fiecare

mesaj la o formula SL care defineste efectul rational al actiunii – scopul mesajului (ce

incearca agentul sa realizeze prin trimiterea mesajului). Evident, intr-o societate de agenti

autonomi efectul rational al mesajului nu poate fi garantat. Conformanta la standardul ACL

nu presupune asadar ca destinatarul mesajului sa respecte efectul rational al mesajului ci doar

conditia de fezabilitate.

In cele ce urmeaza vom prezenta semantica pentru cele mai importante tipuri de mesaje:

inform si request. Toate celelalte performative din FIPA ACL sunt definite pe baza acestora

doua.

<i, inform(j, )>

FP: iB jji UifBifB ( )

RE: jB

iB semnifica faptul ca agentul i are convingerea

iBif semnifica faptul ca agentul i are o opinie clara despre adevarul sau falsitatea lui

iUif semnifica faptul ca agentul i are o incertitudine legata de

Astfel un agent i care trimite un mesaj inform cu continutul agentului j respecta

semantica FIPA ACL daca: i) are convingerea si ii) nu are convingerea ca j are fie o opinie

clara despre , fie o incertitudine legata de . Daca actiunea de informare are success, atunci

destinatarul mesajului, agentul j, va avea convingerea .

<i, request(j, a)>

FP: FP (a) [i\j] )(),( aDoneIBajAgentB jii

RE: Done(a)

Expresia Agent(j, a)semnifica faptul ca agentul care realizeaza actiunea a este j.

Done(a) semnifica faptul ca actiunea a a fost realizata

FP(a) [i\j] denota partea din preconditia de fezabilitate a lui a care reprezinta atitudini

mentale ale lui i.

Astfel agentul i care ii cere agentului j sa realizeze o anumita actiune respecta semantica

FIPA ACL daca: i) partea din preconditia de fezabilitate a lui a care reprezinta atitudini

mentale ale lui i este respectata; ii) agentul i are convingerea ca agentul care realizeaza

actiunea a este j (deci trimite cererea catre agentul corespunzator); iii) agentul i crede ca


coordonare agenţi

38/ 2/6/2009

agentul j nu intentioneaza in momentul curent sa realizeze a. Efectul rational (ceea ce i

doreste sa realizeze prin aceasta cerere) este ca actiunea a sa fie realizata.

Detalii despre sintaxa limbajului FIPA SL sunt incluse in [SL02]. In cele ce urmeaza

vom prezenta pe scurt gramatica FIPA SL.


coordonare agenţi

39/ 2/6/2009


coordonare agenţi

40/ 2/6/2009

Observatii: O formula bine formata (well formed formula – Wff) este construita dintr-o

formula atomica sau in mod recursiv prin aplicarea operatorilor de constructie sau

conectorilor logici. Pe langa operatorii logici uzuali (not, and, or, implies, equiv), apar si 4

operatori modali (B, U, I, PG) si 2 operatori de actiune (feasible, done), astfel:

(B <agent> <expression>)

Convingere. Este adevarat ca agentul agent crede ca expresia expression e adevarata.

(U <agent> <expression>)

Incertitudine. Este adevarat ca agentul agent are o incertitudine legata de adevarul expresiei

expression. Agentul agent nu are convingerea ca expression este nici adevarata nici falsa, dar

crede ca e mai probabil sa fie adevarata.

(I <agent> <expression>)

Intentie. Este adevarat ca agentul agent intentioneaza ca expresia expresion sa devina

adevarata si va planifica realizarea acestui lucru.

(PG <agent> <expression>)

Scop persistent. Este adevarat ca agentul agent are un scop persistent ca expresia expression

sa devina adevarata dar nu va planifica neaparat realizarea acestui lucru.


coordonare agenţi

41/ 2/6/2009

(feasible <ActionExpression> <Wff>)

Este adevarat ca ActionExpression poate avea loc, si imediat dupa Wff va fi adevarata.

(done <ActionExpression> <Wff>)

Este adevarat ca ActionExpression tocmai a avut loc, si imediat inainte Wff era adevarata.

4.1.4 Protocoale de interactiune

Protocoalele de interactiune sunt scenarii de comunicare care pot avea loc intre agenti

individuali, in cadrul unor sisteme multi-agent. Un proiectant al unor sisteme multi-agent are

optiunea sa-i faca pe agenti suficient de constienti despre semnificatia mesajelor, scopurilor,

credintelor si a altor atitudini mentale pe care le poseda agentul, permitand ca interactiunile sa

fie generate spontan pe baza alegerilor facute de catre agenti. Aceasta optiune, desi este destul

de intalnita in cadrul comunitatii de agenti, duce insa la cresterea complexitatii implementarii

agentilor. O alternativa mult mai pragmatica consta in prestabilirea unor protocoale de

interactiune, in asa fel incat sa permita unor implementari mult mai simple de agenti sa poata

avea conversatii semnificative cu alti agenti, respectand pur si simplu protocoale de

interactiune cunoscute. Un agent care initiaza o conversatie cu alti agenti poate indica

protocolul de interactiune pe care doreste sa-l urmeze, dupa care destinatarul, in cazul in care

cunoaste protocolul, va stii cum trebuie sa evolueze conversatia.

Prin natura lor, agentii pot lua parte simultan la mai multe dialoguri, posibil cu mai

multi agenti. Termenul conversatie este folosit pentru a denumi o instanta particulara a unui

astfel de dialog. Astfel, un agent poate fi angajat concurent in mai multe conversatii cu mai

multi agenti, folosind protocoale de interactiune diferite.

Pornind de la cercetarile prezentate in [Lux98] si [Hau94] FIPA a dezvoltat un set de

standarde de interactiune care descriu in totalitate conversatiile dintre agenti, servind pentru

atingerea unui efect precum licitatia, negocierea unor servicii de brokeraj, inregistrarea si

incheierea unor subscrieri. Lista completa a standardelor de interactiune dezvoltate de FIPA

este urmatoarea:

FIPA Request Interaction Protocol Specification (statut de standard)

FIPA Query Interaction Protocol Specification (statut de standard)

FIPA Request When Interaction Protocol Specification (statut de standard)

FIPA Contract Net Interaction Protocol Specification (statut de standard)

FIPA Iterated Contract Net Interaction Protocol Specification (statut de standard)

FIPA English Auction Interaction Protocol Specification (statut experimental)

FIPA Dutch Auction Interaction Protocol Specification (statut experimental)

FIPA Brokering Interaction Protocol Specification (statut de standard)

FIPA Recruiting Interaction Protocol Specification (statut de standard)

FIPA Subscribe Interaction Protocol Specification (statut de standard)

FIPA Propose Interaction Protocol Specification(statut de standard)

Specificatiile mesajelor individuale care formeaza un protocol de interactiune sunt in

mod necesar relaxate: de obicei sunt descrise numai functia mesajului, emitatorul si

destinatarul. Acest lucru se datoreaza faptului ca protocolul de interactiune este o descriere

generica a sablonului de interactiune. Continutul efectiv al mesajelor va fi insa diferit de la o


coordonare agenţi

42/ 2/6/2009

executie a unui protocol la alta. Mai mult, actiunile locale executate de un agent, precum si

deciziile luate de acesta sunt in mod traditional nereprezentate, chiar daca acestea au legatura

cu desfasurarea protocolului.

FIPA Request Interaction Protocol [RIP01] permite unui agent, numit Initiator, sa ceara

unui alt agent, numit Participant, sa efectueze o anumita actiune. Participantul proceseaza

cererea si decide daca accepta sau refuza cererea. Reprezentarea protocolului este ilustrata in

figura 4.2.4.1. pe baza extensiilor la UML 1.x [Ode01].

Figura 4.2.4.1. FIPA Request Interaction Protocol


coordonare agenţi

43/ 2/6/2009

In cazul in care conditiile indica furnizarea unui acord explicit (adica „notification

necessary” are valoarea true) atunci Participantul trebuie sa comunice un mesaj agree. In

functie de circumstante, acest acord este optional, cum ar fi in cazul in care actiunea ceruta

este foarte rapida si se poate efectua inainte de momentul specificat in parametrul reply-by. O

data ce s-a convenit asupra cererii, Participantul trebuie sa comunice unul din urmatoarele:

Un mesaj failure daca esueaza in incercarea de a indeplini cererea,

Un mesaj inform-done daca a indeplinit cererea cu succes si doreste numai sa

comunice acest lucru, sau

Un mesaj inform-result daca doreste sa anunte ca a efectuat cererea cu succes si sa

notifice Initiatorul care au fost rezultatele.

Interactiunile care folosesc acest protocol de interactiune sunt identificate folosind

parametrul conversational_id. Parametrul are o valoare nenula, unica in sistem, fiind asignata

de Initiator si setata in structura mesajului ACL. Agentii implicati in interactiune trebuie sa-si

eticheteze toate mesajele lor cu acest identificator pentru conversatie. Acest lucru ofera

fiecarui agent posibilitatea gestionarii activitatilor si strategiilor de comunicare. De exemplu,

etichetarea mesajelor permite unui agent sa identifice conversatiile individuale si sa rationeze

pe baza istoricului conversatiilor.

In orice moment din cadrul protocolului de interactiune, destinatarul unui mesaj il

poate informa pe expeditor ca nu a inteles ce se dorea comunicat. Acest lucru este realizat prin

trimiterea unui mesaj not-understood. Acest lucru nu este ilustrat in figura 4.2.4.1. deoarece

un mesaj not-understood poate aparea oricand in cadrul protocolului de interactiune.

Transmiterea unui mesaj non-understood in cadrul unui protocol de interactiune poate incheia

intreaga interactiune si acest lucru poate implica faptul ca toate angajamentele luate in timpul

interactiunii sunt nule.

Suplimentar, in orice moment din cadrul protocolui, Initiatorul poate anula

interactiunea prin initierea protocolului FIPA Cancel Meta-Protocol ilustrat in figura 4.2.4.2.

Parametrul conversation-id al interactiunii de anulare este identic cu parametrul

conversational-id al interactiunii pe care Initiatorul doreste sa o anuleze. Semantica anularii

trebuie interpretata in general ca insemnand ca Initiatorul nu mai este interesat in continuarea

interactiunii si ca ar trebui incheiata intr-o maniera acceptabila atat pentru Initiator si

Participant. Participantul informeaza Initiatorul fie ca interactiunea e incheiata folosind un

mesaj inform-done, fie indica esuarea anularii folosind un mesaj failure.


coordonare agenţi

44/ 2/6/2009

Figura 4.2.4.2. FIPA Cancel Meta-Protocol

In FIPA Dutch Auction Interaction Protocol [DAP01], vanzatorul incearca sa gaseasca

pretul pietei pentru un bun incepand licitatia de la un pret mult mai mare decat valoarea de

piata asteptata, reducand apoi progresiv pretul pana cand unul dintre cumparatori accepta

pretul. Rata cu care este redus pretul depinde de vanzator, care de obicei are un pret limita,

sub care nu va cobora. Daca licitatia reduce pretul pana la pretul limita fara a aparea

cumparatori atunci licitatia se incheie.

Termenul de „Licitatie Olandeza” provine din pietele de flori din Olanda, unde este

metoda predominanta de determinare a valorii de piata pentru diverse cantitati de flori. In

modelarea licitatiei olandeze din piata de flori, precum si din alte piete, exista cateva

complexitati suplimentare.

Mai intai, bunul poate fi portionat: de exemplu vanzatorul poate vinde zece cutii de

lalele la un anumit pret P si un cumparator poate cumpara numai sapte dintre acestea. Licitatia

continua in acest caz cu urmatorul pret sub P, pana cand si restul bunului este vandut sau

pretul limita este atins. Astfel de vanzari partiale sunt intalnite numai pe anumite piete, in

altele cumparatorul trebuie sa liciteze pentru intregul bun.

In al doilea rand, mecanismul pietei de flori se asigura ca nu se mai poate face o alta

oferta dupa ce prima oferta a fost facuta. Ofertele de vanzare si cumparare sunt ferme, de

aceea nu exista nici un protocol pentru acceptarea sau rejectarea unei oferte. In cazul unui

agent nu este posibil sa presupunem ca astfel de conditii pot fi aplicabile, ceea ce ar fi si foarte

restrictiv de altfel. Asa ca este posibil ca doua sau mai multe oferte pentru acelasi bun sa fie

primite de catre adjudecator. De aceea protocolul permite ca o oferta sa fie rejectata, dar acest


coordonare agenţi

45/ 2/6/2009

lucru este destinat numai cazului in care sunt receptionate simultan mai multe oferte aflate in

competitie. Protocolul FIPA nu specifica insa care este mecanismul folosit pentru rezolvarea

acestui conflict. In general, agentii nu ar trebui sa faca nici o alta presupune in afara regulii

„primul venit, primul servit”, dar in anumite domenii se pot aplica alte reguli.

Figura 4.2.4.3. FIPA Dutch Auction Interaction Protocol

Acest protocol reprezinta un sablon pentru o interactiune simpla. In majoritatea

cazurilor va fi nevoie de o dezvoltare a acestui sablon pentru a specifica toate cazurile care

pot aparea intr-o interactiune reala intre agenti. Situatii din lumea reala, precum anularea

actiunilor, asincronie, incheierea anormala sau neasteptata a interactiunii, interactiuni

imbricate, nu sunt adresate in mod explicit.

Un agent care respecta standardul FIPA-ACL nu trebuie sa implementeze nici unul

dintre protocoalele de interactiune din standardele FIPA si nici nu i se restrictioneaza folosirea

unui alt nume pentru protocol. Daca insa e folosit unul din numele standard atunci agentul

trebuie sa se comporte conform specificatiile din respectivul standard.

Standardele FIPA nu intentioneaza sa acopere toate tipurile de interactiuni necesare.

Un protocol de interactiune nu trateaza un numar de situatii din lumea reala a interactiunilor


coordonare agenţi

46/ 2/6/2009

dintre agenti, precum tratarea exceptiilor, mesajelor care sosesc fara sa respecte ordinea,

mesaje pierdute, intarzieri. Mai degraba, standardele FIPA ar trebui vazute ca sabloane de

interactiune care trebuiesc dezvoltate in functie de contextul unei aplicatii individuale.

Aceasta strategie implica faptul ca aderarea la un protocol de interactiune cunoscut nu asigura

in mod necesar interoperabilitatea, fiind nevoie de intelegeri suplimentare intre agenti cu

privire la situatiile mentionate anterior pentru a se asigura interoperabilitatea in toate cazurile.


coordonare agenţi

47/ 2/6/2009

5 Platforme de agenti FIPA – JADE

5.1 Despre JADE

JADE (Java Agent DEvelopment Framework) este un framework pentru dezvoltarea de

aplicatii bazate pe agenti respectand standardele impuse de FIPA pentru sisteme multiagent.

Scopul este simplificarea procesului de dezvoltare asigurand in acelasi timp respectarea

standardelor printr-un set de cuprinzator de servicii si agenti.

JADE poate fi considerat un middleware pentru agenti care implementeaza o Platforma

agent (Agent Platform) si este si un mediu de dezvoltare (un framework). Ascunde

programatorului toate acele detalii de implementare tipice pentru agenti, independente de

aplicatie (nivelul transport, encodare si parsare, life cycle) si il lasa sa se concentreze asupra

logicii de rulare, asupra comportamentului ce trebuie impus agentilor. Deasemenea sunt

furnizate si metode de debug si vizualizare grafica a platformei.

Acesta este un framework gratuit distribuit de Telecom Italia sub licenta LGPL ( Lesser

General Public License Version 2). Alte companii si-au manifestat interesul in dezvoltarea si

promovarea platformei si fac acum parte din comitetul JADE:Motorola, Whitestein

Technologies AG, Profactor GmbH si France Telecom R&D.

In Internet modelul de referinta pentru interactiunea dintre masini este Client-Server.

Este o arhitectura bazata pe distinctia rigida dintre nodurile client (cei care cer resurse) si

nodurile server (cei care furnizeaza resurse). Rolul de server face ca aceasta masina sa nu

poata avea decat actiuni reactive la cererile initiate de clienti. Pe de alta parte, clientii

inglobeaza toate initiativele de comunicatie din sistem. Din aceste cauze, clientii au libertatea

de mobilitate, functionare temporara si sub diferite aliasuri in timp ce serverele trebuie sa

furnizeze garantii de stabilitate, securitate, trebuie sa raspunda la aceleasi adrese si pe porturi

stabilite.

Exista aplicatii distribuite care nu se mapeaza bine pe acest model: chat-uri, file sharing

sau multiplayer games trebuie sa comunice in mod direct si orice capat de comunicatie trebuie

sa fie capabil sa inceapa o comunicatie deoarece cunostintele sunt distribuite in retea. Acest

model se numeste “peer-to-peer”. Aceasta arhitectura are avantajul ca oricare dintre entitati

poate intra sau parasi o retea, poate initia o comunicatie si poate primi requesturi in acelasi

timp. Reteaua este descentralizata, logica si resursele fiind egal distribuite. Aici apare

problema descoperiri celor ce fac parte din retea. Astfel exista 2 tipuri de P2P. Cele total

descentralizate (c) in care modelul poate fi considerat ca o retea ad-hoc sau cele hibride in

care exita servere centrale ce ofera servicii de white si yellow pages.

http://www.telecomitalia.com/

http://www.motorola.com/

http://www.whitestein.com/





http://www.profactor.at/

http://www.francetelecom.com/en_EN/innovation/


coordonare agenţi

48/ 2/6/2009

Fig. Tipuri de arhitecturi de retele

Paradigma agentilor aplica concepte din inteligenta artificiala si tehnici de limbaj pe

tehnologia de aplicatii distribuite. Paradigma este bazata pe abstractizarea cu agenti,

componete software care sunt autonome (au un grad de libertate si pot lua decizii singuri),

proactive (pot influienta mediul pentru a-si atinge scopurile) si sociale (interactioneaza cu alti

agenti). Acestia sunt urmatoarea generatie de aplicatii ce vor popula Internetul pentru ca sunt

flexibili, detin avantajele arhitecturii P2P si pot interactiona cu alti agenti pentru a-si indeplini

misiunea.

5.2 Arhitectura

FIPA a propus o arhitectura pentru agenti pentru a se asigura interactiunea intre

software-uri scrise de diferiti developeri in diferite limbaje de programare. Este important ca

doi agenti ce vor sa comunice sa se gaseasca in Internet in primul rand, sa se inteleaga asupra

limbajului pe care il vor folosi si sa dea sensuri comune termenilor din conversatie. Aici

intervine FIPA prin setul de standardizari propus. Arhitectura generala arata ca in figura 2.

Fig. Arhitectura generica FIPA a unui AP


coordonare agenţi

49/ 2/6/2009

Fiecare platforma Agent trebuie sa cuprinda un nivel de transport, un limbaj de

comunicare interagent, si metode de descoperire a agentilor si a serviciilor oferite.

Agentul este un proces computational implementat in asa fel incat sa aiba o

comportare autonoma si sa fie capabil sa comunice (socializeze) cu alti agenti printr-

un limbaj (Agent Communication Language). Acesta este actorul fundamental dintr-o

platforma agent ce poate implementa si furniza servicii, dupa cum e specificat in

descriptorul de servicii.

Un Directory Facilitator (DF) este o componenta optionala ce ofera servicii de

yellow pages agentilor. Agentii isi inregistreaza serviciile la DF sau pot interoga DF

cu privire la serviciile oferite de alti agenti.

Un Agent Management System (AMS) este o componenta obligatorie din AP. El

supervizeaza acesul agentilor la AP si mentine o lista a AID-urilor (Agent IDs) valide

si adrese unde se regasesc agentii. Astfel AMS reprezinta un serviciu de white pages

pentru agenti.

Message Transport Service (MTS) este nivelul unic de transport al mesajelor intre

AP-uri

Un Agent Platform (AP) este infrastructura fizica in care agentii pot fi executati. Este

constituit din masina fizica, sistem de operare si framwork de rulare.

JADE se angajeaza sa respecte specificatiile FIPA si sa implementeze o platforma

bazata pe agenti in care si serviciile de yellow si white pages sa fie implementate de niste

agenti predefiniti. Serviciul de regasire a agentilor si serviciilor este implementat prin 2 agenti

speciali numiti AMS si DF. Nivelul transport trebuie sa asigure comunicarea cu cat mai multi

agenti, indiferent de limbajul in care sunt scrisi. JADE suporta diferite protocolul de

comunicatie poate fi oricare dintre cei consacrati (Java RMI, IIOP, SOAP, HTTP, etc) dar

poate fi si extins cu alte librarii.

Agentii rezida in containere, entitati logice ce faciliteaza gruparea lor. O platforma

poate fi gazduita pe mai multe masini fiind compusa din containere independente dintre care

unul singur poate fi „main” si cuprinde AMS-ul iar restul sunt secundare. Containerele si

agentii pot fi porniti remote de pe alte calculatoare. Deasemenea, agentii de pe diferite

calculatoare pot interactiona (acesta fiind de fapt scopul principal).

Fiecare agent are alocat un thread in AP si poate contine in interiorul lui alte threaduri

datorita suportului oferit de Java. Insa JADE o alternativa lightweight prin implementarea

inteligenta a unui scheduler pentru comportamente cooperative (behaviours). Mai concret, se

defineste o lista de event handleri pt agenti care vor fi chemati la momentul oportun de unicul

thread al agentului. Aceste metode se vor executa serial insa vor mima executia paralela a mai

multe fire de executie necesare agentului. Este inclus si suport pentru JESS, limbajul de

descriere a modului de ratiune pentru un soft.


coordonare agenţi

50/ 2/6/2009

Fig. Arhitectura unui Agent in JADE

5.3 Framework de baza

Pentru a mosteni proprietatile fundamentale ale unui agent (mecanismul de

comunicatie), o clasa trebuie sa extinda jade.core.Agent . In metoda setup() se introduce codul

particular comportamentului fiecarui agent. Un “Hello World!” foarte simplu este descris in

continuare.

import jade.core.Agent;

public class HelloAgent extends Agent

{

protected void setup()

{

System.out.println("Hello World. ");

System.out.println("My name is "+ getLocalName());

}

}

Pentru compilare se vor include in CLASSPATH toate librariile din JADE si se executa

linia: javac HelloAgent.java. Apoi se poate lansa agentul in contextul unui nou container prin

comanda

java jade.Boot agent_name:HelloAgent.


coordonare agenţi

51/ 2/6/2009

Acest nou container este cel principal si doar unul singur poate exista pe platforma

agent curenta. Celelalte containere secundare vor fi lansate cu o comanda de genul:

java jade.Boot –container agent_name2:HelloAgent

Daca se vrea lansarea unui agent pe o alta masina din retea, se poate specifica in linia de

comanda o optiune in care se indica numele de retea al masinii ce gazduieste containerul

„main”.

java jade.Boot –container –host nume_retea agent_name2:HelloAgent

Agentii au in general interactiuni paralele cu alti agenti si cu mediul. Din aceasta cauza

este necesar un mecanism multithreaded care este implementat printr-o lista de

comportamente specifica fiecarei instante. Aceste comportamente (bihaviours) sunt niste

handleri sub forma de clase ce sunt apelati de catre threadul principal al agentului. Sunt deja

definite in JADE o serie de comportamente predefinite care pot fi si extinse. La expirare de

timere sau la eventuri (primire de mesaje) aceasta lista este parcursa si metodele sunt apelate

pe rand. Orice behaviour poate fi scos din lista de executie pt o perioada prin apelul functiei

block(). Acesta va fi reintrodus in lista la expirarea timerului specificat ca parametru sau la

primirea unui mesaj. Forma generala este:

import jade.core.Agent;

import jade.core.behaviours.*;

public class Simple1 extends Agent

{


{

addBehaviour( // -------- Anonymous SimpleBehaviour

new SimpleBehaviour( this )

{

int n=0;

public void action()

{

System.out.println( "Hello World! My name is " +

myAgent.getLocalName() );

n++;

}

public boolean done() { return n>=3; }

}

);

} // --- setup ---


coordonare agenţi

52/ 2/6/2009

} // --- class Simple1

Dupa cum se vede, s-a creat un behaviour de tip SimpleBihaviour. Acesta se va executa

pana cand functia done() se evalueaza la false. Output-ul pt aceast agent este:

java jade.Boot x:Simple1

Hello World! My name is x



Un agent poate primi si parametri la creare sub prin specificarea lor intre paranteze

rotunde in linia de comanda:

java jade.Boot x:Simple1(“alias”, 3)

si vor fi preluati prin intermediul functiei getArguments() care returneaza un Object[].

Deoarece comunicatia dintre agenti poate avea latente mari intre o cerere si un raspuns

si deasemenea pot exista mai multe comunicatii simultane, nu se pot implementa metode de

receptie a mesajelor prin blocare. O metoda eficienta este combinarea mecanismului de

comportamente cu o masina de stari pt fiecare tip de comunicatie. Cu alte cuvinte, fiecare

behaviour va avea in interior descrierea unei masini cu stari pentru a ghida fluxul de

comunicatie. Pentru comunicatia intre un EPOS si o banca se poate asocia urmatorul cod:

class EPOSQuery extends SimpleBehaviour

{

int state = 1;


{

switch( state ) {

case 1:

Communicate amount, client data

Block();

break;

case 2:

receive(msg);

if(msg==ok)

print “Ok”;

else

print “Failed”;

doDelete(); // applies to the Agent

break;

}

state++;

}


coordonare agenţi

53/ 2/6/2009

private boolean finished = false;

public boolean done() { return finished; }

}

doDelete() apeleaza metoda takeDown() a agentului si determina terminarea acestuia.

5.4 Comunicarea intre agenti

Comunicatia se realizeaza printr-un ACL (Agent Communication Language) ce

compune mesaje cu urmatoarele campuri:

Performative – tipuri de mesaje standardizate de FIPA (INFORM, QUERY,

PROPOSE,...)

Addressing

o Receiver

o Sender

Content – corpul mesajului

ConversationID – folosit pentru a inlantui mesajele unei conversatii

Language

Ontology

Protocol – specifica protocolul

ReplyWith – specificarea unui tip de raspuns asteptat

InReplyTo - marcarea unui mesaj ca fiind un raspuns

ReplyBy – timeout pt raspuns

Mai sus s-a scris un comentariu in codul EPOS-ului ce tinea loc de codul pentru

trimiterea unei interogari. Iata cum ar arata acest mesaj:

switch( state ) {

case 1:

// Communicate amount, client data

ACLMessage msg = new ACLMessage( ACLMessage.QUERY );

msg.setContent("Amount: 10EUR; clientID=143563536RO35;

bank=BANK");

AID dest = getDest();

msg.addReceiver(dest);

send(msg);


coordonare agenţi

54/ 2/6/2009

Block();

break;

Pot exista mai multi destinatari pentru un mesaj.

Un mesaj se poate receptiona fie prin blocarea si asteptarea lui cu blockingReceive sau

prin interogarea cozii de mesaje printr-un apel neblocant cu receive().

Un corespondent al agentului EPOS ar fi banca:

public class Bank extends Agent

{


{

addBehaviour(new CyclicBehaviour(this)

{


{

ACLMessage msg= receive();

if (msg!=null)

{

ACLMessage reply = ComputeMessage(msg);

send(reply);

}

block();

}

private ACLMessage ComputeMessage(ACLMessage msg)

{

String content = msg.getContent();

ACLMessage reply = msg.createReply();

reply.setPerformative(ACLMessage.INFORM);

if(checkSold(content))

reply.setContent(“ok”);

else

reply.setContent(“failed”);

return reply;

}

});

}

}


coordonare agenţi

55/ 2/6/2009

createReply() poate alcatui automat un mesaj de raspuns cu sender si destinatari

completati, precum si un communicationID daca este cazul.

Pentru a cauta un agent in paginile albe ale AP-ului, se vor apela functii API specifice

AMS-ului:

// Required imports

import jade.domain.AMSService;

import jade.domain.FIPAAgentManagement.*;

...

AMSAgentDescription [] agents = null;

try {

SearchConstraints c = new SearchConstraints();

c.setMaxResults ( new Long(-1) );

agents = AMSService.search( this, new AMSAgentDescription (), c );

}

catch (Exception e) { ... }

5.5 Comportamentul agentilor (Agent Behaviour)

Un agent trebuie sa fie capabil sa execute sarcini ca raspuns la diferitele evenimente

externe.Sarcina efectiva pe care un agent o are de efectuat este de obicei programata in

metoda “action” a claselor de tip Behaviour (clasa comportamentala). O instanta a unei

asemenea clase se va numi obiect comportamental.

Clasa de baza Behaviour din pachetul jade.core.behaviours contine :

Constructori

Behaviour()

Behaviour(Agent a)

Obiectul comportamental se ataseaza agentului a.

Metode

abstract void action()

defineste actjiunea realizata de agent

abstract boolean done()

metoda “action” se executa cat timp metoda “done” returneaza false

block()

suspenda executia metodei “action”.

block(long dt)

planifica urmatoarea executie a metodei action dupa dt milisecunde.

Campuri


coordonare agenţi

56/ 2/6/2009

• protected Agent myAgent

referinta la agentul caruia ii apartine obiectul comportamental.

Agentului i se atribuie un obiect comportamental prin metoda

“addBehaviour(Behaviour b)” iar prin “removeBehaviour(Behaviour b)” se ia agentului

obiectul comportamental.

Planificarea execuţiei obiectelor comportamentale se face ne-preemtiv, in sensul ca

metoda „action” nu este intrerupta niciodata pentru a permite executia celorlalte obiecte

comportamentale. Controlul este transferat unui alt obiect comportamental doar in momentul

in care metoda „action” a obiectului comportamental curent se termina.

Exista mai multe tipuri de clase comportamentale predefinite :


coordonare agenţi

57/ 2/6/2009

OneShotBehaviour (se executa action o singura data)

CyclicBehavior ( action se executa la infinit )

WakerBehaviour (se executa o singura data, dupa un interval de timp precizat la

instantierea obiectului)

TickerBehaviour (se executa periodic, cu perioada specificata la instantierea

obiectului)

clase comportamentale complexe : contin mai multe clase comportamentale simple

Fig. Modelul claselor comportamentale Jade


coordonare agenţi

58/ 2/6/2009

Bibliografie

[AA08] Apache Axis2, 2008, http://ws.apache.org/axis2/

[ACKM04] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services: Concepts, Architecture and

Applications, Springer Verlag, 2004

[ACL02] FIPA ACL Message Structure Specification, Foundation for Intelligent Physical Agents, 2002,

http://www.fipa.org/specs/fipa00061/

[ACT02] FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2002,


[Aus62] J.L. Austin, How To Do Things With Words. Oxford University Press, Oxford, 1962.

[Bre97] P. Bretier and D. Sadek, A rational agent as the kernel of a cooperative spoken dialogue system:

implementing a logical theory of interaction, Intelligent Agents, III, LNAI Volume 1193, Springer, Berlin, 1997,

pp. 189-204.

[CCL01] FIPA CCL Content Language Specification. Foundation for Intelligent Physical Agents, 2001,


[Coh79] P.R. Cohen and C.R. Perrault, Elements of a plan based theory of speech acts, Cognitive Science, 3,

1979, pp. 177-212.

[Coh90] P.R. Cohen and H.J. Levesque, Rational interaction as the basis for communication, Intentions in

Communication, MIT Press, Cambridge, MA, 1990, pp. 221-256.

[DAP01] FIPA Dutch Auction Interaction Protocol Specification. Foundation for Intelligent Physical Agents,

2001, http://www.fipa.org/specs/fipa00032/

[Hau94] H. Haugeneder (Ed). IMAGINE Final Project Report, IMAGINE Technical Report Series, 1994.

[KIF03] FIPA KIF Content Language Specification. Foundation for Intelligent Physical Agents, 2003,


[KSE93] Knowledge Sharing Effort, http://www.cs.umbc.edu/kse/, 1993.

[Lux98] A.Lux and D. Steiner, Understanding Cooperation: An Agent’s Perspective, Readings in Agents,

Morgan Kaufmann, 1998, pp. 234-238.

[OA-WS08] OASIS Committees for Web Services, 2008, http://www.oasis-

open.org/committees/tc_cat.php?cat=ws, accesat in noiembrie 2008

[Ode01] Odell, James, Van Dyke Parunak, H. and Bauer, B., Representing Agent Interaction Protocols in UML.

Agent-Oriented Software Engineering, Springer, Berlin, 2001, pp. 121-140.

[RDF01] FIPA RDF Content Language Specification. Foundation for Intelligent Physical Agents, 2001,


[RIP01] FIPA Request Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2001,


[SAWSDL07] Semantic Annotations for Web Services Description Language Working Group, 2007,

http://www.w3.org/2002/ws/sawsdl/, accesat in octombrie 2008

http://ws.apache.org/axis2/






http://www.cs.umbc.edu/kse/

http://www.oasis-open.org/committees/tc_cat.php?cat=ws

http://www.oasis-open.org/committees/tc_cat.php?cat=ws



http://www.w3.org/2002/ws/sawsdl/


coordonare agenţi

59/ 2/6/2009

[Sea69] J.R. Searle, Speech Acts: an Essay in the Philosophy of Language. Cambridge University Press,

Cambridge, 1969.

[SL02] FIPA SL Content Language Specification. Foundation for Intelligent Physical Agents, 2002.


[SOA07] Simple Object Access Protocol, 2007, http://www.w3.org/TR/soap/.

[SM05] A.-M. Sassen, C. Macmillan. The service engineering area: An overview of its current state and a vision

of its future, EUROPEAN COMMISSION, Information Society and Media Directorate-General, 2005

[SWS08] Semantic Web Services Interest Group, 2008, http://www.w3.org/2002/ws/swsig/, accesat in octombrie

2008

[UOS08] UDDI Oasis Standard, 2007, http://uddi.xml.org/

[Woo02] M. Wooldridge, An introduction to multiagent systems, Wiley, 2002.

[WSACT08] Web Services Activity, 2008, http://www.w3.org/2002/ws/, accesat in octombrie 2008

[WSARCH04] Web Services Architecture, 2004, http://www.w3.org/TR/ws-arch/, accesat in noiembrie 2008

[WSAREQ04] Web Services Architecture Requirements, 2004, http://www.w3.org/TR/wsa-reqs/, accesat in

noiembrie 2008

[WSD07] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 2007,

http://www.w3.org/TR/wsdl20/.

[XML08] Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008, http://www.w3.org/TR/REC-xml/.

[BEV03] Beavers, G., H.Hexmoor. Types and Limits of Agent Autonomy. În Proc. of the Workshop on

Computational Autonomy, Autonomy 2003, Melbourne, Australia, 2003.

[CAS00] Castefranchi, C. Founding Agent's 'Autonomy' On Dependence Theory. În Proc. of 14th European

Conf. on Artificial Intelligence, IOS Press, 2000, p.353-357.

[CCD99] Conte, R., C.Castelfranchi, F.Dignum. Autonomous Norm-Acceptance. În J. Muller, M. Singh and A.

Rao (eds.), Intelligent Agents V, LNAI 1555, Springer-Verlag, 1999, p.319-334.

[FEB95] Ferber, J. Les systèmes multi-agents: Vers une intelligence collective, InterEditions, 1995

[FRA96] Franklin, S., A. Graesser. Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents.

Proc of the Third International Workshop on Agent Theories, Architectures, and Languages, Springer-Verlag,

1996. Disponibil la http://www.msci.memphis.edu/~franklin/AgentProg.html

[GRE01] Greenwald, A., P. Stone. Autonomous bidding agents în the trading agent competition. IEEE Internet

Computing, March-April 2001, p.52-60

[LUC98] Luck, M., M.d'Inverno. Motivated Behaviour for Goal Adoption. În Multi-Agent Systems: Theories,

Languages and Applications – Proc, of the 4th Australian Workshop on Distributed Artificial Intelligence, Zhang

and Lukose (eds.), LNAI 1544, Springer-Verlag, 1998, p.58-73

[RUS97] Russell, S.J.. Rationality and intelligence, Artificial Intelligence, Vol. 94, 1997. p.57-77.

[SHO93] Shoham, Y. Agent-oriented programming, Artificial Intelligence, Vol. 60, 1993. p.51-92


http://www.w3.org/TR/soap/

http://www.w3.org/2002/ws/swsig/

http://uddi.xml.org/

http://www.w3.org/2002/ws/

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/wsa-reqs/

http://www.w3.org/TR/wsdl20/

http://www.w3.org/TR/REC-xml/

http://www.msci.memphis.edu/~franklin/AgentProg.html


coordonare agenţi

60/ 2/6/2009

[VEN99] Verhagen, H., M.Boman. Adjustable Autonomy, Norms and Pronouncers. AAAI Spring Symposium

on Agents with Adjustable Autonomy, 1999

[WOO95] Wooldridge, M., N. R. Jennings. Agent theories, architectures, and languages, În Intelligent Agents,

M. Wooldridge et N. R. Jennings (eds), Springer Verlag, 1995. p.1-22.

SCIPA - Studiul si evaluarea standardelor actuale in reprezentarea cunostintelor pentru Web

semantic

SCIPA

Servicii software semantice de Colaborare şi



Studiul şi evaluarea standardelor actuale în reprezentarea

cunoştinţelor pentru Web semantic

Autori Universitatea Politehnică Bucureşti

Contract nr. 12118/01.10.2008


Contact: [email protected]

Pagina Web: www.aimas.cs.pub.ro

mailto:[email protected]

http://www.aimas.cs.pub.ro/

SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web

semantic

2

Rezumat

În cadrul iniţiativei de generalizare a Web-ului Semantic, structură care se doreşte a fi

capabilă să interconecteze informaţiile din World Wide Web în aşa fel încât să poată fi

prelucrate automat, la scară globală, este necesară o evaluare riguroasă a standardelor

actuale folosite pentru reprezentarea cunoştiinţelor.

Natura cunostintelor este o problema veche şi de-a lungul timpului au existat

numeroase incercari de a gasi moduri de reprezentare. Fizica si matematica depind de

limbaje simbolice specifice, existand multe abordari ale inteligentei artificiale pentru gasirea

celei mai bune soluţii de reprezentare. Aparitia ontologiilor a demostrat faptul ca acestea

reprezinta o modalitate convenabila de reprezentare a cunostintelor in diferite domenii: web

semantic, aplicatii de gestiunea cunostintelor sau chiar aplicatiile din domeniul afacerilor.

Cercetarea in domeniul reprezentarii cunostintelor si a proceselor de inferenta este in

general axata pe metode care ofera descrieri de nivel inalt ale universului cunostintelor care

pot fi utilizate pentru a construi aplicatii inteligente. In acest context, “inteligenta” se refera

la capacitatea unui sistem de a gasi consecinte implicite pe baza cunostintelor reprezentate

explicit.

Lucrarea de faţă tratează câteva dintre cele mai importante formalisme de reprezentare

a cunoştiinţelor, începând de la reprezentarea atribut-valoare până la structurarea semantică

a informaţiei.


semantic

3

CUPRINS

1 Web Semantic .................................................................................................................... 5

1.1 Reprezentarea informatiei pe Web: XML, XML Scema ............................................. 5 1.1.1 XML ..................................................................................................................... 5 1.1.2 XML Schema ....................................................................................................... 7

1.2 Reprezentarea cunostintelor pe Web: ontologii .......................................................... 9 2 Ontologii ........................................................................................................................... 11

2.1 Reprezentarea cunostintelor prin ontologii ................................................................ 11 2.2 Limbaje de descriere a ontologiilor ........................................................................... 12 2.3 Ontologii de nivel si de domeniu ............................................................................... 14 2.4 Concluzii .................................................................................................................... 15

3 Logici de descriere ........................................................................................................... 16

3.1 Limbaje de descriere DL ........................................................................................... 17

3.1.1 Limbajul de descriere ................................................................................. 17

3.1.2 Familia de limbaje ...................................................................................... 17 3.1.3 Axiome terminologice si definitii ...................................................................... 18 3.1.4 ABox .................................................................................................................. 18

3.2 Inferente in DL .......................................................................................................... 18

3.2.1 Inferente pentru concepte ................................................................................... 18 3.2.2 Inferente pentru ABox ........................................................................................ 19

3.3 Algoritmi de rationament ........................................................................................... 20

3.4 Extensii ale limbajelor DL ......................................................................................... 20 3.4.1 Constructori de rol .............................................................................................. 20

3.4.2 Restrictii numerice expresive ............................................................................. 21 3.4.3 Harti rol-valoare ................................................................................................. 21

3.5 Concluzii .................................................................................................................... 22 4 Limbajul OWL ................................................................................................................. 23

4.1 XML Schema şi RDF ................................................................................................ 23 4.1.1 XML Schema ..................................................................................................... 23 4.1.2 RDF (Resource Description Framework) .......................................................... 24

4.2 Elemente de bază în OWL ......................................................................................... 25

4.2.1 Definiţie OWL .................................................................................................... 25 4.2.2 Componente de bază .......................................................................................... 27

4.3 Inferenţe în OWL ....................................................................................................... 30 4.3.1 Utilizarea unui reasoner ..................................................................................... 31 4.3.2 Lanţuri de proprietăţi .......................................................................................... 32

4.3.3 Ipotezele pe care se bazează ............................................................................... 32 4.3.4 Editoare OWL .................................................................................................... 33

5 Reprezentarea cunostintelor prin reguli ........................................................................... 34 5.1 OPS5 .......................................................................................................................... 34 5.2 JESS ........................................................................................................................... 35 5.3 RuleML ...................................................................................................................... 37 5.4 SWRL ........................................................................................................................ 39

6 Inginerie ontologică .......................................................................................................... 41 6.1 Construirea ontologiilor ............................................................................................. 41

6.1.1 Constructia manuala a ontologiilor .................................................................... 41 6.1.2 Reutilizarea ontologiilor existente ..................................................................... 43


semantic

4

6.1.3 Folosirea metodelor semiautomate..................................................................... 43 6.2 Implementarea ontologiilor ....................................................................................... 44 6.3 Alinierea ontologiilor ..................................................................................................... 46

6.4 Dezvoltări actuale ...................................................................................................... 47 6.4.1 Medii de dezvoltare ............................................................................................ 47 6.4.2 Ontologii existente ............................................................................................. 48 6.4.3 Proiecte si standarde ........................................................................................... 50

6.5 Concluzii .................................................................................................................... 51

Bibliografie ............................................................................................................................... 52


semantic

5

1 Web Semantic

1.1 Reprezentarea informatiei pe Web: XML, XML Scema

Cea mai usoara modalitate de reprezentare a informatiilor pe Web o constituie

reprezentarea in forma atribut-valoare. Astfel un obiect este caracterizat de atributele sale,

fiecare atribut avand un domeniu fixat de valori. In acest mod un concept este specificat

printr-o categorie de obiecte reprezentate printr-o combinatie logica intre valorile atributelor.

1.1.1 XML

XML (eXtensible Markup Language) [XML08] este un meta-limbaj de marcare

recomandat de World Wide Web Consortium (W3C) [W3C08] pentru crearea de alte limbaje

de marcare, cum ar fi XHTML, RDF, RSS, MathML, SVG, OWL etc. Aceste limbaje

formează familia de limbaje XML. Meta-limbajul XML este o simplificare a limbajului

SGML (din care se trage şi HTML). El a fost proiectat in scopul transferului de date intre

aplicatii pe internet, descriind structura datelor. Totodata XML este şi un model de stocare a

datelor nestructurate şi semi-structurate în cadrul bazelor de date native XML.

Un document XML are doua niveluri de corectitudine:

bine format: un document este bine format daca respecta toate regulile de sintaxa

XML (de exemplu, in cazul in care un tag este deschis fara sa fie inchis, atunci documentul

XML nu este bine format).

valid: un document valid trebuie sa respecte anumite reguli semantice. Aceste reguli

pot fi reguli definite de utilizatori sau reguli incluse ca o scema XML, in special DTD

(Document Type Definition) (de exemplu, daca un document contine un element nedefinit,

atunci el nu este un document valid).

Un document XML este format din elemente specificate prin perechi atribut-valoare,

elemente care sunt incluse intr-o structura ierarhica arborescenta.

Document bine format.

Sintactic, fiecare element este deschis printr-un tag de forma <nume> si inchis prin tag-

ul corespunzator </nume>. Pentru a reflecta structura arborescenta elementele deschise

trebuie inchise in ordinea inversa deschiderii lor.

Un atribut este specificat in tag-ul de deschidere impreuna cu valoarea sa:

<nume atribut = “valoare”> ... </nume>

Daca un element XML nu are copii, atunci el poate fi scris ca:

<nume/> (echivalent cu <nume></nume>).

Structura XML foloseste structura calculului atributional [MIC00]. Astfel:

un selector este reprezentat printr-o pereche atribut-valoare;

intersectia (conjunctia) selectorilor corespunde unei liste de perechi atribute-valoare

asociata unui singur element;

reuniunea (disjunctia) regulilor corespunde crearii de copii asociati unui element.

http://ro.wikipedia.org/wiki/Limbaj_de_marcare

http://ro.wikipedia.org/wiki/World_Wide_Web_Consortium

http://ro.wikipedia.org/wiki/XHTML

http://ro.wikipedia.org/w/index.php?title=RDF&action=edit&redlink=1

http://ro.wikipedia.org/wiki/RSS

http://ro.wikipedia.org/w/index.php?title=MathML&action=edit&redlink=1

http://ro.wikipedia.org/w/index.php?title=SVG&action=edit&redlink=1

http://ro.wikipedia.org/w/index.php?title=OWL&action=edit&redlink=1

http://ro.wikipedia.org/w/index.php?title=SGML&action=edit&redlink=1

http://ro.wikipedia.org/wiki/HTML

http://ro.wikipedia.org/wiki/Internet

http://ro.wikipedia.org/w/index.php?title=Baze_de_date_native_XML&action=edit&redlink=1


semantic

6

Astfel un concept poate fi vazut ca un element care are zero sau mai multe reguli drept

elemente copil; un selector este o pereche atribut-valoare corespunzatoare unui

element regula. De exemplu, un concept poate fi descris ca:

<concept>

<regula ai=“wij” ... ak=”wkl”/>

<regula am=“wmn” ... ap=”wpq”/>

</concept>

ai reprezinta atributul i, wi este domeniul sau, wij face parte din Wi este o valoare

posibila a sa. Acest concept poate fi reprezentat grafic ca in Figura 1.

Figura 1. Reprezentarea grafica a unui concept

Exemplul 1: document XML pentru o adresa din Marea Britanie:

<?xml version="1.0" encoding="utf-8"?>

<Address xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="SimpleAddress.xsd">

<Recipient>Mr. Walter C. Brown</Recipient>

<House>49</House>

<Street>Featherstone Street</Street>

<Town>LONDON</Town>

<PostCode>EC1Y 8SY</PostCode>

<Country>UK</Country>

</Address>

Document valid.

Pentru ca elementele componente ale unui document XML sa poata fi accesate si

definite prin intermediul unei scheme sau DTD (Document Type Definition) [DTD08]. XML-

ul ofera o sintaxa pentru acest scop, limbaje bazate pe XML. Sintaxa generala a acestor

limbaje este rigida – documentele trebuie sa respecte regulile generale XML, asigurand faptul

ca orice soft bazat pe XML poate citi si intelege structura relativa a elementelor componente

dintr-un document XML. Schema completeaza regulile de sintaxa cu o multime de

constrangeri. De obicei schema restrictioneaza elementele si numele atributelor impreuna cu

ierarhia permisa pentru componente. Constrangerile din schema pot include asignari de tipuri

de date care afececteaza modul in care informatia este procesata. Un document XML care se

supune unei scheme particulare/DTD si este bine format reprezinta un document valid.

concept

Regula 1

selector S11

...

selector S1n1

Regula k

selector Sk1

...

selector Skn1

...


semantic

7

Reprezentarea prin atribut-valoare existenta in XML ofera o modalitate de

reprezentare a cunostintelor. Sunt folosite concepte din calculul atributional, dar nu pot fi

reprezentate toate conectivitatile logice. De exemplu, nu sunt acceptate structuri recursive sau

concepte bazate pe inductie care au numai conditii necesare. In plus nu exista cuantificatori

sau posibilitatea de negare, dar acestea pot fi implementate.

Reprezentarea de tip atribut-valoare folosita de XML poate fi aplicata pentru

reprezentarea cunostintelor numai in sistemele ce au domenii finite pentru valorile atributelor.

Pe baza celor enuntate mai sus, XML-ul ofera urmatoarele avantaje:

extensibilitate (se pot defini noi indicatori daca este nevoie);

validitate (se verifica corectitudinea structurala a datelor );

ofera utilizatorilor posibilitatea de a reprezenta datele intr-un mod independent de

aplicatie;

se foloseste standardul Unicode, astfel permitandu-se reprezentarea pentru aproape

orice informatie din limbajul natural;

pot fi reprezentate structurile de date principale: liste si arbori;

algoritmii pentru analiza sintactica sunt simpli, eficienti si consistenti;

XML-ul este folosit pentru stocare si procesarea documentelor atat online cat si

offline;

XML-il poate fi validat pe baza limbajeleor schema, care face mai usoara constructia

si implementarea;

1.1.2 XML Schema

Elementele unui document XML sunt declarate in DTD (Document type definition)

[DTD08] sau mai general in XML Scema (referita si sub denumire XSD – XML Schema

Definition) [XSD08]. Schema reprezinta o descriere a unui document XML, de obicei

exprimata in termeni de constrangeri asupra structurii si continutului acelui document,

constrangeri ce apar peste cele impuse de XML.

General o schema este formata dintr-o colectie de metadate, alcatuite dintr-o multime de

componente ale schemei: declaratii de elemente, atribute si definitii de tipuri simple si

complexe. De obicei aceste elemente sunt create prin procesarea unei colectii de scheme ale

documentelor, ce contin definitiile acestor componente. Schemele documentelor sunt

organizate pe baza namespace-urilor: toate componentele unei scheme apartin namespace-ului

destinatie, care apartine schemei documentului ca un intreg. Un document schema poate

include alte scheme de document pentru acelasi namespace si poate importa alte scheme

pentru namespace-uri diferite.

Pentru a valida instanta unui document fata de o schema, aceasta poate fi furnizata drept

parametru motorului ce face validarea sau poate fi referita direct din instanta documentului

prin folosirea a doua atribute speciale: xsi:schemaLocation si

xsi:noNamespaceSchemaLocation.

XML schema permite ca un element sau un atribut sa fie validat in raport cu un tip de

date. XSD pune la dispozitie o multime de 19 tipuri de date primitive, permitan de asemena

constructia de noi tipuri de date pornind de la cele de baza pe baza mecanismelor:

restrictie – reducerea multimii valorilor permise;

listare – permiterea numai a unei secvente de valori;

reuniune – permiterea selectarilor valorilor din diferite tipuri.


semantic

8

Dupa validarea bazata pe schema XML se pot exprima structura si continutul unui

document XML in termenii unui model de date care a fost implicit in faza de validare.

Modelul de date XML shema include :

vocabularul – numele elementelor si atributelor ;

modelul continutului – structura si relatiile;

tipurile de date.

Aceasta colectie de informatii poarta numele de Post Schema Validation Infoset (PSVI).

PSVI furnizeaza un document XML valid si permite folosirea documentului ca un obiect

folosind paradigmele programarii orientate obiect.

Exemplul 2: de XML schema pentru o adresa din Marea Britanie (corespunzatoare

documentului XML din Exemplul 1):

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="Address">

<xs:complexType>

<xs:sequence>

<xs:element name="Recipient" type="xs:string" />

<xs:element name="House" type="xs:string" />

<xs:element name="Street" type="xs:string" />

<xs:element name="Town" type="xs:string" />

<xs:element minOccurs="0" name="County"

type="xs:string" />

<xs:element name="PostCode" type="xs:string" />

<xs:element name="Country">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="FR" />

<xs:enumeration value="DE" />

<xs:enumeration value="ES" />

<xs:enumeration value="UK" />

<xs:enumeration value="US" />

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Elementul radacina al unui document XML este <xsd:schema>...</xsd:schema> (xsd

specifica namespace-ul XML xmlns al consortiului W3C [W3C08]:

xmlns:xsd=”http://www.w3.org/2001/XMLSchema‖

Schema documentului XML din Exemplul 1, pentru o adresa din Marea Britanie poate

fi reprezentata ca in Figura 2.

http://en.wikipedia.org/wiki/PSVI

http://en.wikipedia.org/wiki/XML_Schema_(W3C)#cite_note-0

http://www.w3.org/2001/XMLSchema


semantic

9

Figura 2. Reprezentarea documentului XML din Exemplul 1

Principalul scop pentru care a fost creat XML schema este acela de a descrie formal un

document XML. Insa schema astfel obtinuta poate fi folosita si in alte scopuri, cum ar fi:

generarea documentatiei;

generarea codului – XML Data Binding [XDB08] (acesta permite documentelor XML

sa fie tratate ca obiecte in mediul de programare).

1.2 Reprezentarea cunostintelor pe Web: ontologii

Principalul scop in reprezentarea cunostintelor il constituie reprezentarea acestora intr-

o maniera care sa faciliteze inferentele din cunostinte.

Principalele probleme rezultate din perspectiva inteligentei artificiale in reprezentarea

cunostintelor sunt: cum pot fi reprezentate cunostintele, care este natura cunostintelor si cum

poate fi reprezentata si anume o schema de reprezentare va fi caracteristica unui anumit

domeniu sau va fi generala, cat de expresiva este o schema de reprezentare sau un limbaj

formal, schema ar trebui sa fie declarativa sau procedurala?

Termenul de ontologie a aparut in filosofie pentru a denumi teoria asupra existentei,

asupra a ceea ce se considera ca exista de catre cel care intocmeste teoria. Construirea oricarui

sistem filosofic pleaca de la o ontologie, adica de la clarificarea problemelor referitoare la

categoriile de entitati din realitate si a relatiilor dintre ele [GRU08].

In stiinta calculatoarelor o ontologie este o reprezentare formala a unei multimi de

concepte dintr-un anumit domeniu impreuna cu relatiile dintre aceste concepte [GRU95]. Este

folosita in scopul de a intelege proprietatile acelui domeniu si de asemenea poate fi folosita

pentru a defini domeniul respectiv. Ontologiile sunt folosite in inteligenta artificiala, web

semantic, ingineria programarii, arhitectura, e-commerce, motoare de cautare, regasirea

informatiilor ca o forma de reprezentare a cunostintelor despre lumea inconjuratoare sau o

parte a lor.

In mod general o ontologie contine o descriere ierarhica a celor mai importante

concepte dintr-un domeniu si descrie principalele proprietati ale fiecarui concept pe baza unui

mecanism de tip atribut-valoare. In plus, pot fi descrise relatii viitoare intre concepte pe baza

http://en.wikipedia.org/wiki/XML_Data_Binding


semantic

10

propozitoiilor logice aditionale. In final, indivizii din domeniul de interes sunt asignati unuia

sau mai multor concepte in scopul de a le da un tip corespunzator.

Principalele componente ale unei ontologii:

indivizii: instante ale obiectelor (obiecte de baza) – includ obiecte concrete, de

exemplu oameni, animale, automobile, plante cat si obiecte abstracte, cum ar fi numere sau

cuvinte;

clase: multimi, colectii, concepte, tipuri ale obiectelor sau tipuri de lucruri – clasele

sunt obiecte abstracte ce sunt definite prin valorile aspectelor ce reprezinta constrangeri de

apartenenta la clasa respectiva - clasele pot clasifica indivizi, alte clase sau combinatii intre

acestea.

atribute: aspecte, proprietati, caracteristici sau parametrii obictelor; fiecare atribut

poate fi o clasa sau un individ; tipul unui obiect si tipul atributului determina relatia dintre ele;

relatii: modalitati prin care clasele si indivizii pot fi legati unul de celalalt;

termeni ai functiilor: structuri complexe formate din relatii sigure care pot fi folosite

intr-un termen al unui individ intr-o declaratie;

restrictii: descrieri formale pentru ce poate fi adevarat pentru o asertiune ce va fi

acceptata ca intrare;

reguli: declaratii de forma unei propozitii if-then (antecedent-consecvent) sentence

care descrie inferentele logice ce pot fi deduse dintr-o asertiune;

axiome: asertiuni (incluzand reguli);

evenimente: modificarea atributelor sau relatiilor;

Astfel o ontologie este o descriere formala, explicita a conceptelor dintr-un anumit

domeniu (clase), proprietati ale fiecarui concept ce descriu diferite caracteristici si atribute ale

conceptului (roluri sau proprietati) si restrictii asupra proprietatilor (numite si restrictii asupra

rolurilor).

O ontologie impreuna cu o multime de instante individuale ale claselor formeaza o baza

de cunostinte.

Ontologiile sunt implementate cu ajutorul limbajelor de ontologii, cum ar fi CycL

[CYL08], DAML – OIL {DAO08], OWL [OWL08].

http://en.wikipedia.org/wiki/Class




http://en.wikipedia.org/wiki/Attribute_(computing)

http://en.wikipedia.org/wiki/Relation_(mathematics)

http://en.wikipedia.org/wiki/Event_(philosophy)


semantic

11

2 Ontologii

O ontologie poate fi vazuta ca o reprezentare formala a unei multimi de concepte dintr-

un anumit domeniu, precum si a relatiilor dintre aceste concepte.

2.1 Reprezentarea cunostintelor prin ontologii

Principalele motive pentru care sunt necesare folosirea ontologiilor [NM01]:

pentru a avea o intelegere comuna asupra structurii informatiei - sa presupunem ca mai

multe site-uri Web diferite contin informatii medicale si furnizeaza servicii medicale de tip e-

commerce. Daca aceste site-uri au la baza aceeasi ontologie pentru termenii pe care ii

folosesc, atunci agentii Web pot extrage si compune informatia de pe aceste site-uri diferite.

Agentii pot folosi aceasta informatie compusa pentru a raspunde cererilor utilizatorului sau ca

si date de intrare ale altor aplicatii;

pentru a permite reutilizarea cunostintelor din domeniu- modelele din diferite domenii

trebuie sa aiba o reprezentare pentru notiunea de timp, reprezentare ce trebuie sa includa

notiunile de interval de timp, momente in timp, unitati de masura ale timpului, etc. Daca un

grup de cercetatori dezvolta o astfel de ontologie in detaliu, ceilalti pot pur si simplu sa o

utilizeze pentru domeniul lor. In plus, daca avem nevoie sa dezvoltam o ontologie complexa,

putem integra ontologiile existente ce descriu portiuni ale domeniului nostru;

pentru a explicita ipotezele utilizate in domeniul respectiv - face posibila schimbarea

facila a acestor ipoteze atunci cand cunostintele legate de domeniu se schimba. Ipotezele

codificate direct in aplicatia informatica fac nu numai ca acestea sa fie greu de detectat si

inteles ci si greu de schimbat. In plus, specificatiile explicite ale unui domeniu sunt utile

noilor utilizatori care trebuie sa invete termenii din domeniul respectiv;

pentru a separa cunostintele din domeniu de implementarea acestuia - putem descrie

sarcina de asamblare a unui produs oarecare din componentele sale conform unei specificatii

si sa implementam un program care realizeaza aceasta compunere independent de produs si de

componentele acestuia;

pentru a analiza cunostintele din domeniu - analiza formala a termenilor este extrem de

valoroasa atunci cand urmarim sa reutilizam ontologii deja existente sau sa le extindem

[MFR00].

Dezvoltarea unei ontologii este asemenea definirii unui set de date si a structurii

acestora pentru a fi utilizate de catre un program. Metodele de rezolvarea a unor clase de

probleme, aplicatiile independente de domeniu si agentii software utilizeaza ontologii si baze

de cunostinte construite din ontologii ca date de intrare.

Unele idei de proiectare a unei ontologii pornesc de la proiectarea orientata pe obiecte

[]RBP91], [BRJ97]. Totusi, dezvoltarea unei ontologii este diferita de proiectarea claselor si a

relatiilor din programarea orientata pe obiecte, aceasta centrandu-se in primul rand pe

metodele unei clase – un programator i-a deciziile pe baza proprietatilor operationale ale unei

clase - in timp ce un proiectant al unei ontologii ia deciziile pe baza proprietatilor structurale

ale unei clase.

Nu exista o singura metoda corecta de proiectare a ontologiilor. O ontologie este o

descriere formala explicita a conceptelor dintr-un domeniu: clase (sau concepte), a

proprietatilor fiecarui concept ce descriu diferite trasaturi si atribute ale conceptelor (numite


semantic

12

uneori atribute sau roluri) si caracteristici sau restrictii ale atributelor (implicatii, numite si

restrictii de rol).

2.2 Limbaje de descriere a ontologiilor

Un limbaj de descriere a ontologiilor este un limbaj formal folosint pentru

implementarea acesteia.

Limbajele de descriere a ontologiilor sunt clasificate in:

limbaje traditionale – principalele limbaje ce fac parte din aceasta categorie sunt:

CycL [CYC08], F-logic, OCML, Ontolingua (bazat pe limbajul KIF [KIF08]) [ONT08];

limbaje bazate pe web - DAML+OIL [DAO08], OWL [OWL08], RDF, RDF Schema

[RDF08], SHOE [SHO08];

limbaje bazate pe descrieri logice – aceste limbaje reprezinta o extensie a limbajelor

bazate pe frame-uri, fara a suporta logica predicatelor ―first order‖ – din aceasta categorie fac

parte limbajelele OWL [OWL08];

Limbaje bazate pe logica predicatelor ―first order‖ : CycL [CYC08], KIF [KIF08].

Dintre limbajele de descriere a ontologiilor prezentam in continuare cateva dintre

acestea:

Ontolingua [ONT08] este un limbaj pentru reprezentarea si partajarea ontologiilor

dezvoltat la KSL (Knowledge Systems Lab) la Universitatea Stanford. Ontolingua nu ofera

functionalitate de inferenta, acest limbaj fiind dezvoltat intr-un mediu ce pune la dispozitie

functii de dezvoltare a ontologiilor (afisare, creare, editare, modificare si folosirea

ontologiilor), precum si o biblioteca modulara de ontologii ce pot fi reutilizabile.De asemenea

acest limbaj a fost cheia limbajelor pentru reprezentarea ontologiilor pentru cativa ani, insa nu

a mai fost actualizat datorita aparitiei limbajelor bazate pe XML.

RDF (Resource Description Framework) [RDF08] este un mediu pentru descrierea

metadatelor dezvoltat de consortiul W3C [W3C08]. Acesta se bazeaza pe modelul triplet, de

forma: <obiect, atribut, valoare>, in care obiect este o resursa ce reprezinta o pagina web.

Un astfel de triplet poate fi un obiect si o valoare, valoarea poate fi un sir sau o resursa.

Obiectul si valoarea sunt considerate un nod, iar atributul o legatura intre noduri. Astfel un

model RDF formeaza o retea semantica. Sintaxa RDF este bazata pe sintaxa XML lucru care

face sa semene cu un limbaj comun bazat pe XML. Insa RDF este diferit de un astfel de

limbaj in sensul ca el este un model de reprezentare a datelor decat un limbaj, iar modelul

datelor este sub forma unei structuri incuibarite a informatiilor, modelul fiind bazat pe

proprietati. In cadrul RDF se pot crea noi reprezentari pentru date care sa contina

metainformatii care de obicei nu apar in datele originale. De exemplu, sa consideram ca data

un articol existent pe web. Acesta va contine numele autorului, de exemplu ―Riichiro

Mizoguchi‖. Daca se marcheaza acest lucru in text, pe baza limbajului XML, sub forrma:

<author> Riichiro Mizoguchi </author>

atunci acest lucru va desemna in mod explicit faptul ca acel sir reprezinta autorul articolului.

Pe de alta parte in reprezentarea RDF pentru metadate, de exemplu, autorul poate include si

data cand a fost publicat articolul, care nu apare explicit in cadrul articolului. Sa presupunem

ca articolul se afla la adresa

http://www.ei.sanken.osaka-u.ac.jp/pub/WI2001-Miz.pdf,


semantic

13

atunci descrierea RDF va fi:

<rdf:Description rdf:about="http://www.ei.sanken.osaka-

u.ac.jp/pub/WI2001-Miz.pdf">

<author>Riichiro Mizoguchi</author>

<pub-date>2001-10-23</pub-date>

</rdf:Description>

Desi RDF a fost proiectat pentru a modela reprezentarea metadatelor, el poate fi folosit si

pentru reprezentarea cunostintelor, astfel putem spune ca el este un fel de model semantic de

retea.

RDF Schema [RDF08] este un limbaj ce permite definirea tag-urilor (vocabularului) folosit de

RDF. Cele mai comune metadate, cum ar fi autorul si data crearii sunt definite in DC (Dublin

Core) [DC08], in care sunt definite 15 elemente metadata. RDF schema nu trebuuie sa le

defineasca pentru a le folosi in RDF ci pot fi imprumutate folosindu-se de ajutorul

namespace-ului dc:.

La o prima privire corespondenta dintre RDF si RDF Schema ar parea similara cu cea dintre

XML si XML schema. Insa acest lucru nu este adevarat. Rolul principal al XML schema este

de a constrange instanta careia ii este atasat. De cealalta parte, principalul rol al RDF Schema

este de a asocia tag-uri definitiilor si taxonomiei din RDF, totodata si a de a specifica

constrangeri asupra valorilor posibile din modelul triplet. Daca XML-ul se poate folosi fara

XML Schema RDF este inutil fara RDF Schema. RDF Schema are propriile clase si meta-

clase interne pe baza carora utilizatorii pot defini orice clasa si relatie. Rdfs:Resource

impreuna cu cele doua subclase: rdf:sClass si rdfs:Property sunt meta-clasele de baza. Orice

clasa definita in RDF Schema este o instanta a rdfs:Class. In acelasi mod, fiecare proprietate

si relatie definita in RDF schema este o instanta a rdfs:Property.

Web Ontology Language (OWL) [OWL08] este un limbaj dezvoltat tot de consortiul

W3C [W3C08]. OWL este proiectat ca un limbaj comun pentru reprezentarea ontologiilor,

fiind bazat pe DAML+OIL [DAML08]. OWL este o extensie a RDF Schema si de asemenea

se bazeaza pe modelul triplet. Principiul de proiectare se bazeaza pe dezvoltarea unui limbaj

standard de reprezentare a ontologiilor. Datele descriese de o ontologie OWL sunt

interpretate ca o multime de indivizi si o multime de proprietati, pe baza carora se inrudesc

acesti indivizi. O ontologie OWL consta dintr-o mulime de axiome pe baza carora se asociaza

constrangeri multimilor de indivizi si tipuri de relatii permise intre acestea. Aceste axiome

furnizeaza semantica ce permite sistemului sa deduca informatiile aditionale pe baza datelor

furnizate in mod explicit. De exemplu, o ontologie ce descrie informatii despre o familie, ar

trebui sa includa axiome de tipul, ca o proprietate "AreMama" este prezenta intre doi indivizi,

numai in conditiile in care exista proprietatea "AreParinti". In plus indivizi ai clasei

"AreGrupaSangeO" nu vor fi niciodata inruditi cu membrii clasei "AreGrupaSangeAB", prin

intermediul proprietatii "AreParinti". Daca un individ Mara este inrudit cu un individ Sanda,

prin intermediul relatiei "AreGrupaSangeO", atunci putem deduce ca Sanda nu este membru

al clasei "AreGrupaSangeAB".

Specificarea OWL include definirea a trei componente OWL [OWL08]:


semantic

14

OWL Lite a fost dezvoltat pentru a suporta clasificari ierarhice si constrangeri simple.

Cardinalitatea restrictiilor poate fi 0 sau 1, iar de asemenea se pot specifica o parte sau toate

valorile proprietatii asupra careia se aplica restrictia. De asemena se pot specifica clase sau

proprietati ce sunt echivalente (acest lucru este foarte folositor pentru a specifica faptul ca

doua concepte in ontologii diferite reprezinta acelasi lucru) si faptul ca proprietatile pot fi

functionale, simetrice, tranzitive sau inverse.

OWL DL este un limbaj mai avansat bazat pe o submultime decidabila a logicii

descriptive. In cadrul acestuia sunt posibile relatii pe disjunctii intre clase sau reuniune,

intersectie, complement intre clase. De asemena pot fi specificate cardinalitati pentru restrictii

sub forma oricarui numar natural.

OWL Full este bazat pe semantica OWL Lite si OWL DL si a fost construit astfel

incat sa pastreze o parte dintre compatibilitati cu RDF Schema. De exemplu, in OWL Full o

clasa poate fi tratata simultan ca o colectie de indivizi, dar si ca un individ singular (ceea ce

nu este permis in OWL DL). OWL Full permite ca o ontologie sa dezvolte intelesul

vocabularului predefinit (RDF or OWL).

Fiecare dintre aceste sublimbaje este o extensie sintactica a predecesorului sau mai simplu,

astfel:

Fiecare ontologie OWL Lite este o ontologie valida OWL DL;

Fiecare ontologie OWL DL este o ontologie valida OWL Full;

Uneltele pentru reprezentarea cunostintelor le rerezinta editoarele si API-urile. Dintre

cele mai importante unelte amintim:

Protégé [PRO08] este unealta cea mai cunosuta pentru dezvoltarea ontologiilor. Este

un editor de ontologii si un framework bazat pe cunostinte open-source, dezvoltat la

Universitatea Stanford. Protege este cea mai completa aplicatie de tipul sau, permite

construirea de plugin-uri, ofera un API complex si bine documentat. Initial Protege suporta

construirea numai de ontologii RDF sau in format propriu. Insa, pe baza plugin-urilor ofera

suport pentru OWL, DAML+OIL, XML, limbaje de reguli, unelte de vizualizare,

import/export de baze de date, dezvoltarea de ontologii web, WordNet, Prolog, UML. In plus

ofera si crearea unei interfete pentru baza de cunostinte. Toate aceste caracteristici fac ca

Protege sa fie unealta cea mai buna pentru gestiunea si reprezentarea cunostintelor.

Jena2 [JEN08] este un framework open-source pentru construirea aplicatiilor web

semantice dezvoltat de HP. El furnizeaza un API care permite construirea de ontologii

folosind RDF,OWL sau DAML+OIL, precum si importul/exportul diferitelor tipuri de

modele de ontologii. In Jena este posibil rationamentul. API-ul Jena este folosit de Proteje

pentru API-ul sau OWL.

2.3 Ontologii de nivel si de domeniu

Ontologiile de domeniu descriu vocabularul relativ la un domeniu generic (de exemplu,

medicina, automobile etc.). Ele modeleaza un anumit domeniu sau o parte a lumii. Ele

reprezinta sensul particular pentru termenii care se aplica domeniului respectiv. De exemplu,

cuvantul ―card‖ are diferite intelesuri. O ontologie pentru domeniul poker va modela sensul

cuvantului ―poker card‖, in timp ce o ontologie in domeniul calculatoarelor va modela sensul

cuvintelor ―video card‖ sau ―punch card‖.


semantic

15

Ontologiile de nivel descriu concepte foarte generale cum sunt: spatiul, timpul, materie,

obiect, eveniment, actiune etc., ce sunt independente de o problema particulara sau domeniu;

se pot aproxima aceste tipuri de ontologii pentru multe comunitati de utilizatori. O astfel de

ontologie este un model asupra obiectelor comune care sunt aplicabile in diferite ontologii de

domeniu. Dintre ontologiile de nivel existente amintim OpenCyc [OPC08], SUMO {SUo08],

WordNet [WON08].

Ontologia Gellish [GEL08] este un exemplu de combinare intre o ontologie de nivel si o

ontologie domeniu.

2.4 Concluzii

Ontologiile ce descriu cuvintele existente intr-o anumita limba (sau cuvinte din mai

multe limbi) pot fi combinate cu ontologii specifice unor domenii ducand la rezolvarea unor

probleme ale web-ului semantic al viitorului, si anume: clasificarea, indexarea si regasirea

mai precisa a cunostintelor (informatii sau imagini), dezvoltarea de interfeţe multilingve la

aplicaţiile specifice web-ului semantic, crearea de comunitati virtuale fara sa se tina cont de

de barierele lingvistice.


semantic

16

3 Logici de descriere

Cercetarea in domeniul reprezentarii cunostintelor si a proceselor de inferenta este in

general axata pe metode care ofera descrieri de nivel inalt ale universului cunostintelor care

pot fi utilizate pentru a construi aplicatii inteligente. In acest context, ―inteligenta‖ se refera la

capacitatea unui sistem de a gasi consecinte implicite pe baza cunostintelor reprezentate

explicit. Astfel de sisteme sunt numite sisteme bazate pe cunostinte ([NB]).

Logicile de descriere (DLs) ([BHS05], [BS01], [CGLN99]) reprezinta o familie de

limbaje de reprezentare a cunostintelor, care pot fi folosite pentru a reprezenta cunostintele

dintr-un anumit domeniu, intr-un mod structurat, formal si usor de inteles. Numele de ―logici

de descriere‖ poate fi explicat astfel: pe de o parte prin faptul ca notiuni importante referitoare

la domeniu sunt exprimate prin descriere de concepte si pe de alta parte prin faptul ca, logicile

de descriere, spre deosebire de predecesorii lor, retelele semantice si frame-urile, contin

semantici formale, bazate pe logica.

In Figura 1 prezentam arhitectura unui sistem de reprezentare a cunostintelor bazat pe

logici de descriere ([BN]):

Figura 1. Arhitectura unui sistem de reprezentare a cunostintelor bazat pe logici de

descriere

Un sistem de reprezentare a cunostintelor bazat pe logici de descriere permite crearea de

baze de cunostinte, modificarea lor si realizarea de inferente asupra continutului acestor baze

de cunostinte.

O baza de cunostinte (KB) este compusa din doua componente TBox si ABox. TBox

contine terminologia, adica vocabularul folosit pentru un anumit domeniu, iar ABox contine

asertiuni referitoare la anumiti indivizi, utilizand vocabularul din TBox. Un sistem de forma

celui prezentat mai sus ofera si servicii de inferenta asupra terminologiei si asertiunilor din

sistem.

Prezentul material are la baza prezentarea logicilor de descriere realizata in [BN].


semantic

17

3.1 Limbaje de descriere DL

Descriptorii elementari sunt conceptele (multimi de indivizi) si rolurile (relatii binare

intre indivizi). Descrierile mai complexe se pot realiza folosind descriptorii elementari si

constructori de concepte. Vom folosi A si B pentru concepte atomice, R pentru roluri si C si

D pentru descrieri de concepte. In aceasta sectiune prezentam familia de limbaje .

3.1.1 Limbajul de descriere

Limbajul ( = attributive language ) este considerat un limbaj minimal de interes

practic. Descrierile de concepte sunt formate folosind urmatoarele reguli:

Pentru a defini o semantica formala pentru conceptele , introducem notiunea de

interpretare. Interpretarea este compusa dintr-o multime nevida (domeniul

interpretarii) si o functie de interpretare, care asociaza fiecarui concept atomic A o multime

si fiecarui rol R o relatie binara . Functia de interpretare se extinde

la descrieri de concepte astfel:

Spunem ca doua concepte C, D sunt echivalente si scriem C ≡ D, daca =

pentru toate interpretarile .

3.1.2 Familia de limbaje

Pentru a obtine extensii ale limbajului introducem noi constructori:

- reuniunea a doua concepte (indicata in numele limbajului de litera ), scrisa :

- cuantificatorul existential (indicat in numele limbajului de litera ), scris :

- restrictii numerice (indicate in numele limbajului de litera ), scrise si :


semantic

18

.

- negatia conceptelor (nu neaparat atomice) (indicata in numele limbajului de litera ), scrisa

ca :

Adaugand constructorii de mai sus la limbajul , se obtin alte limbaje :

3.1.3 Axiome terminologice si definitii

Axiomele terminologice au urmatoarea forma:

sau

unde C si D sunt concepte, iar R si S sunt roluri. O interpretare satisface o incluziune

, daca ; o interpretare satisface o egalitate daca .

Daca este o multime de axiome, atunci satisface daca si numai daca sastisface

fiecare element din . Daca satisface o multime de axiome , se numeste model al

acelui set de axiome.

O egalitate a carei parte stanga este un concept atomic se numeste definitie. Definitiile

sunt folosite pentru a introduce nume simbolice pentru descrierile complexe.

3.1.4 ABox

In ABox se pot introduce indivizi, asociindu-le nume; in plus se pot asocia proprietati

acestor indivizi. Pentru un individ se folosesc nume ca a, b, c. Folosind conceptul C si rolul R,

se pot face asertiuni de urmatoarele tipuri: C(a) (asertiuni de concept) si R(b,c) (asertiuni de

rol).

Privita la modul general, un ABox este o instanta a unei baze de date relationale, care

are doar relatii unare si binare. Totusi, spre deosebire de ―principiul lumii inchise‖ (absenta

informatiei este considerata informatie negativa; informatia existenta este considerata

completa) folosit de bazele de date clasice, aici se foloseste ―principiul lumii deschise‖

(absenta informatiei indica lipsa informatiei; informatia existenta este considerata

incompleta).

O interpretare satisface ABox-ul daca satisface fiecare asertiune din . In

acest caz spunem ca este un model al ABox-ului .

3.2 Inferente in DL

Un sistem de reprezentare a cunostintelor bazat pe logici de descriere poate obtine noi

cunostinte din cele existente folosind inferente. O baza de cunostinte ce contine TBox si

ABox este echivalenta cu o multime de axiome din logica cu predicate de ordinul I. Astfel,

prin inferente, cunostintele implicite existente in baza de cunostinte pot deveni explicite.

3.2.1 Inferente pentru concepte

Fie un TBox. In continuare definim o serie de termeni:


semantic

19

- Satisfiabilitate: un concept C este satisfiabil referitor la daca exista un model al lui

astfel incat este nevid.

- Subsumare: un concept C este subsumat de un concept D referitor la daca

pentru toate modelele ale lui

- Echivalenta: doua concepte C si D sunt echivalente referitor la daca pentru

toate modelele ale lui

- Disjunctie: doua concepte C si D sunt disjuncte referitor la daca pentru

toate modelele ale lui

Avem urmatoarele rezultate referitoare la inferenta intr-un sistem de reprezentare a

cunostintelor bazat pe logici de descriere:

Propozitia 1 (Reducerea la subsumare)

Fie C si D doua concepte. Atunci:

a) C este nesatisfiabil C este subsumat de

b) C si D sunt echivalente C este subsumat de D si D este subsumat de C

c) C si D sunt disjuncte este subsumat de

Propozitia 2 (Reducerea la nesatisfiabilitate)

Fie C si D doua concepte. Atunci:

a) C este subsumat de D este nesatisfiabil

b) C si D sunt echivalente si sunt nesatisfiabile

c) C si D sunt disjuncte este nesatisfiabil

Propozitia 3 (Reducerea nesatisfiabilitatii)

Fie C un concept. Atunci urmatoarele afirmatii sunt echivalente:

a) C este nesatisfiabil

b) C este subsumat de

c) C si sunt equivalente

d) D si sunt disjuncte

3.2.2 Inferente pentru ABox

Intr-un ABox sunt doua tipuri de asertiuni, asertiuni de concept C(a) si asertiuni de rol

R(b,c). Reprezentarea cunostintelor trebuie sa fie consistenta pentru a nu rezulta in urma

inferentelor, concluzii gresite.

Un ABox este consistent referitor la un TBox , daca exista o interpretare care este

model atat pentru cat si pentru . Spunem ca o asertiune este legata de ABox-ul , si

scriem , daca orice interpretare care satisface , satisface pe . Avem

urmatoarele rezultate:

- este inconsistent.

- C este satisfiabil este consistent


semantic

20

3.3 Algoritmi de rationament

Numim algoritm stabil un algoritm cu proprietatea ca atunci cand gaseste o solutie

pentru o instanta a problemei, acea solutie este intr-adevar o solutie a problemei. Numim

algoritm complet un algoritm cu proprietatea ca de fiecare data cand o instanta a problemei

are solutie, algoritmul calculeaza acea solutie.

Putem spune ca toate problemele importante referitoare la inferenta se pot reduce la

problema consistentei pentru ABox-uri, presupunand ca logica de descriere permite

conjunctia si negatia.

Cu toate acestea, multe dintre sistemele bazate pe logici de descriere nu permit

utilizarea negatiei. Pentru astfel de logici de descriere, subsumarea conceptelor poate fi

realizata cu ajutorul algoritmilor de subsumare structurala (adica algoritmi care compara

structura sintactica a descrierilor de concepte). Un algoritm de subsumare structurala are doua

faze: in prima faza se normalizeaza descrierile care urmeaza sa fie testate pentru subsumare,

iar in a doua faza se compara structurile sintactice ale celor doua descrieri normalizate.

Desi algoritmii de subsumare structurala sunt foarte eficienti, ei sunt completi doar

pentru limbaje simple cu expresivitate scazuta. Logicile de descriere care permit negatie si

disjunctie nu pot fi abordate utilizand astfel de algoritmi. Pentru aceste logici se utilizeaza

tableau based algorithms. Un algoritm ‗tableau based‘ nu testeaza direct subsumarea

descrierilor de concepte, ci foloseste negatia pentru a reduce subsumarea la nesatisfiabilitatea

descrierilor de concepte: ‗C este subsumat de D este nesatisfiabil‘. Utilizand

ideea de la tableau based algorithms, au fost construiti mai multi algoritmi stabili si completi

pentru verificarea satisfiabilitatii (deci si a subsumarii).

In loc de a construi noi algoritmi pentru rationamente in sisteme bazate pe logici de

descriere, se poate incerca reducerea problemei studiate la o problema de inferenta din logica.

De exemplu, decidabilitatea problemelor de inferenta pentru si pentru multe alte logici

de descriere poate fi obtinuta ca o consecinta a rezultatelor referitoare la decidabilitatea pentru

formule de doua variabile din calculul cu predicate de ordinul I. Alti algoritmi pentru

rationamente in sisteme bazate pe logici de descriere pot fi obtinuti folosind legatura dintre

logicile de descriere si logicile modale propozitionale.

3.4 Extensii ale limbajelor DL

Desi limbajul poate fi privit ca un prototip pentru limbajele de descriere DL,

pentru multe aplicatii expresivitatea acestui limbaj nu este suficienta. Din acest motiv au fost

introdusi mai multi constructori de limbaj pentru a construi extensii ale limbajului .

3.4.1 Constructori de rol

Rolurile sunt vazute ca relatii binare. De aceea este natural sa fie folosite operatiile de baza

pentru relatii binare (operatori booleeni, compunere, inversare, inchidere tranzitiva).

Definitie (Constructori de rol)

Orice nume de rol este o descriere de rol (rol atomic), si daca R, S sunt descrieri de

roluri, atunci (intersectia), (reuniunea), (complementul),

(compunerea), (inchiderea tranzitiva) si (inversarea) sunt tot descrieri de roluri:

Fiind data o interpretare , aceasta poate fi extinsa la descrieri (complexe) de roluri astfel:


semantic

21

, adica este inchiderea tranzitiva pentru

3.4.2 Restrictii numerice expresive

Exista trei metode de a crea restricitii numerice expresive.

Prima metoda se refera la restrictiile numite restrictii numerice calificate, unde restrictia

numerica se refera la argumentele unui rol pentru un anumit concept. De exemplu, fiind dat

rolul hasChild, restrictia numerica introdusa mai sus, poate sa arate ca numarul de copii este

intre anumite limite, ca in conceptul . Restrictiile numerice

calificate pot, in plus, sa exprime ca sunt cel putin 2 baieti si 5 fete:

A doua metoda se refera la folosirea in interiorul restrictiilor numerice a expresiilor

complexe ce contin roluri. Astfel au fost studiate limbaje care permit utilizarea compunerii de

roluri in restrictiile numerice.

A treia metoda consta in inlocuirea numarului n, dat explicit in restrictia numerica, cu

variabile care tin locul unor numere naturale. Astfel, putem defini, de exemplu, conceptul

care reprezinta toate persoanele care au cel putin un numar de fii si de fiice, fara sa se spuna

explicit de ce numar e vorba:

3.4.3 Harti rol-valoare

Hartile pentru valorile rolurilor reprezinta o familie de constructori de concepte, foarte

expresivi.

Definitie

Un lant de roluri este o compunere de nume de roluri: . Daca R, S sunt

lanturi de roluri, atunci si sunt concepte (harti rol-valoare). Prima expresie

este numita harta rol-valoare de incluziune, iar a doua este numita harta rol-valoare de

egalitate.

O interpretare se extinde la harti rol-valoare astfel:


semantic

22

3.5 Concluzii

Inca de la aparitia lor, la sfarsitul anilor ‘70, ca remediu pentru problemele logice si

semantice care apareau ca urmare a folosirii reprezentarilor bazate pe frame-uri si retele

semantice, logicile de descriere au devenit un formalism unic de extrem de important in

istoria reprezentarii cunostintelor ([NB]).

Logicile de descriere ofera un formalism simplu si usor de folosit pentru reprezentarea

cunostintelor. O caracteristica importanta a logicilor de descriere este decidabilitatea lor

(pentru a fi exacti exista si logici de descriere care nu sunt decidabile, dar marea majoritate a

logicilor de descriere sunt decidabile).

Un domeniu important de utilizare a logicilor de descriere este webul semantic. Pentru

exemplificare, mentionam limbajul OWL-DL pentru reprezentarea ontologiilor. Acesta este

un limbaj suficient de expresiv pentru a avea o mare aplicabilitate in practica.


semantic

23

4 Limbajul OWL

4.1 XML Schema şi RDF

4.1.1 XML Schema

Limbajul XML (Extensible Markup Language) a apărut ca o variantă simplificată a

limbajului SGML (Standard Generalized Markup Language) şi vine în întâmpinarea nevoii

sistemelor informatice de partajare a datelor structurate (în special peste Internet), el fiind

folosit atât în codarea de documente, cât şi în serializarea datelor. Limbajul XML oferă

specificaţiile necesare ce permit utilizatorilor să îşi creeze propriile formate pentru stocarea şi

partajarea informaţiei. Întrucât aceştia îşi pot defini propriile elemente de limbaj, XML este

încadrat în categoria limbajelor extensibile (Extensible).

La zece ani de la apariţie, limbajul XML este extrem de popular în rândul

programatorilor, analiştilor de baze de date, autori ai literaturii de specialitate şi alţii,

ubicuitatea acestui limbaj făcându-i să ia in considerare necesitatea prelucrării XML în

business.

Aplicabilitatea XML

Succesul limbajului XML provine din convergenţa unei imense diversităţi de interese şi

domenii de aplicabilitate. Numai din sfera de business, spre exemplu, putem enumera

următoarele aplicaţii: XBRL (eXtensible Business Reporting Language) – un limbaj bazat pe

XML folosit în lumea financiară, folosirea tehnologiei XML in manualelor de întreţinere de

catre fabricanţii de maşini sau de avioane sau de catre instituţiile guvernamentale pentru

documentaţii. În plus, publicarea pe Web (Web publishing) sau căutarea pe Web (Web

searching) beneficiază, de asemenea, de pe urma folosirii formatului XML.

Înainte de apariţia limbajelor de descriere precum SGML sau XML, designerii de

software erau cei care işi defineau nişte formate speciale pentru fişiere sau mici limbaje

pentru a face posibilă partajarea datelor între programe. Toate acestea necesitau specificaţii

detaliate şi programe de scriere sau parsare specifice fiecărui tip în parte.

Structura regulată a limbajului XML şi regulile stricte de parsare permit designerilor

software să delege parsarea către instrumente standard şi să se concentreze asupra dezvoltării

propriilor reguli pentru date la un nivel relativ înalt de abstractizare.

XML Schema

XML Schema reprezintă descrierea unui tip de document XML. Această descriere se

exprimă de cele mai multe ori sub forma unor constrângeri asupra structurii şi conţinutului

unui anumit tip de documente, constrângeri ce se adaugă acelora impuse de însuşi limbajul

XML.

XML 1.0 includea o serie de instrumente pentru definirea stucturii unui document,

numite DTDs (Document Type Definitions). Deşi aceste instrumente permiteau definirea

structurii elementelor şi atributelor, ofereau mecanisme de setare a valorii implicite pentru

atribute precum şi pentru adaugarea unui fel de metadate, cerinţele multor dezvoltatori au

depăşit rapid capabilităţile oferite de DTDs.


semantic

24

Consorţiul World Wide Web (W3C) a reuşit să răspundă acestor cerinţe prin construirea

unui nou limbaj, care să ofere mai multă precizie în descrierea structurii şi conţinutului

documentelor XML, să suporte namespace-uri XML şi să poată folosi un vocabular XML

pentru a descrie alte vocabulare XML. Acest limbaj este XML Schema şi este descris prin

recomandările normative W3C „XML Schema Part 1: Structures” şi „Schema Part 2:

Datatypes” alături de recomandarea non-normativă „Part 0: Primer”.

Functiile principale ale XML Schema

Rolul principal al XML Schema este acela de validare a unui document XML. Validarea

este necesară atunci când se primeşte un document nou în vederea procesării sau în urma

producerii unui document (fie manual, fie de către o aplicaţie). Validarea are ca scop

reducerea riscului procesării unor documente care nu sunt conform specificaţiilor sau al

propagării erorilor în cazul transformărilor aplicate unui document în sistem de banda de

asamblare.

Există mai multe niveluri de validare: validarea structurală prin care se asigură structura

impusă elementelor şi atributelor, validarea datelor, care asigură conformitatea conţinutului

acestor structuri cu tipul de informaţie specificat, şi mai poate exista un set de reguli de

business care verifică relaţiile dintre informaţii la un nivel mai înalt, însă acestea intră mai

degrabă în domeniul verificărilor procedurale.

Chiar şi în cazurile în care validarea nu este necesară, XML Schema poate fi folosit

pentru documentarea vocabularelor XML. La publicarea specificaţiilor unui nou vocabular

XML, cel mai adesea, se ataşează şi o schemă XML. Schemele oferă o descriere formală a

vocabularului cu o precizie şi concizie care ar fi dificil de atins altfel.

Schemele au avantajul că pot fi interpretate de către sistemele informatice, iar

documentaţia pentru utilizatori se poate genera uşor pe baza descrierilor formale.

Întrucât cunoaşterea structurii unui document şi a tipurilor de date folosite poate creşte

eficienţa unor funcţii precum cele de căutare, sortare sau comparare, noile versiuni Xpath şi

XSLT, precum şi noul limbaj de interogare XQuery se bazează pe disponibilitatea acestor

caracteristici în XML Schema.

4.1.2 RDF (Resource Description Framework)

RDF reprezintă un formalism grafic cu o sintaxă XML şi o semantică asociată pentru

reprezentarea metadatelor, pentru descrierea semanticii informaţiilor într-un mod accesibil

pentru calculator.

Modelul de date RDF este compus din afirmaţii care descriu proprietăţi ale resurselor. O

resursă este orice obiect care poate fi indicat printr-un URI. Proprietăţile sunt şi ele la rândul

lor tot resurse (URI-uri).

În RDF există legături între afirmaţii, astfel încât, subiectul unei afirmaţii poate fi

obiectul alteia. O astfel de colecţie de afirmaţii formează un graf orientat şi etichetat.

RDF are o sintaxă XML cu o anumită semnificaţie: elementele „Description‖ descriu o

resursă iar orice atribut sau element imbricat al unui element „Description‖ este o proprietate

a acelei resurse.

Nu se face nici o distincţie între clase şi instanţe (indivizi) iar proprietăţile însele pot

avea la rândul lor proprietăţi. Spre exemplu: <hasDaughter,subPropertyOf,hasChild>

<hasDaughter,type,familyProperty>


semantic

25

Nu există nici o distincţie între constructorii de limbaj şi vocabularul ontologiei, astfel

încât constructorii se pot aplica asupra lor înşişi. <type,range,Class>

<Property,type,Class>

<type,subPropertyOf,subClassOf>

Aplicatii importante : owl

Una dintre influenţele majore în conceperea limbajului OWL au fost cerinţele de

menţinere, într-o măsură cât mai mare, a compatibilităţii cu limbajele deja existente, în special

cu RDF. Aceste cerinţe erau justificate întrucât RDF (mai precis RDF Schema) includea deja

unele dintre caracteristicile de bază ale unui limbaj de descriere a ontologiilor bazat pe clase şi

proprietăţi (spre exemplu, permite declararea relaţiilor de subclasă şi subproprietate). Mai

mult, dezvoltarea RDF a precedat-o pe cea a limbajului OWL, şi de aceea, era normal ca noul

limbaj să încerce să fie pe placul utilizatorilor din comunitatea deja existentă stabilită de RDF.

La început, părea suficientă alegerea pentru OWL a unei sintaxe bazate pe RDF. Ulterior, s-a

considerat necesară şi asigurarea unei semantici OWL compatibilă cu cea din RDF. În cele

din urmă, toate acestea s-au dovedit a fi destul de greu de implementat, dată fiind creşterea

puterii de exprimare oferită de OWL. [HPH03]

4.2 Elemente de bază în OWL

4.2.1 Definiţie OWL

Web Ontology Language este o familie de limbaje de reprezentare a cunostintelor

pentru crearea si gestionarea ontologiilor. OWL este un limbaj ce defineşte conceptele

specifice domeniului de discurs şi enunţă faptele pe care se bazează lumea descrisă.

Specii de OWL

Influenţele multiple manifestate de limbajele ce stau la baza OWL (Description Logics,

SHOE, DAML+OIL) asupra dezvoltării acestuia, au dus la apariţia a numeroase probleme de

sintaxă, semantică sau computaţionale. Deoarece dificultatea consta în rezolvarea

constrângerilor rezultate din combinarea tuturor acestor probleme, şi nu a fiecărei probleme în

parte, s-a găsit o soluţie viabilă prin lansarea a trei varietăţi OWL, fiecare dintre ele reuşind sa

îndeplinească aproape toate cerinţele impuse. Cele trei specii de OWL sunt: OWL DL, OWL

Lite şi OWL Full.

OWL DL are o sintaxă prietenoasă, inferenţele pot fi scrise într-o manieră

Description Logic şi sunt decidabile.

OWL Lite oferă o sintaxă mai simplă decât OWL DL şi inferenţe tractabile.

OWL Full oferă posibilitatea dezvoltării nerestricţionate de construcţii OWL,

asupra cărora însă nu se pot face inferenţe. OWL Full reprezintă o extensie sintactică şi

semantică a RDFS, aşadar este compatibil cu RDF şi RDFS. [HPH03]

În concluzie, există două stiluri în care poate fi folosit OWL. În primul, atunci când se

lucrează în OWL DL sau OWL Lite, numai anumite construcţii sunt permise, iar aceste

construcţii pot fi combinate numai într-un anunmit fel. Beneficiile pentru alegerea utilizării

acestui stil, în ciuda limitărilor impuse, constau în decidabilitatea inferenţelor şi posibilitatea

de a aborda limbajul OWL într-o manieră orientată asupra standardului.


semantic

26

În cel de-al doilea stil, lucrând în OWL Full, sunt permise toate grafurile RDF.

Avantajele acestui stil expansiv includ o mai mare putere de expresie şi compatibilitatea cu

RDF. [HPH03]

În timp ce mulţi suporteri ai OWL DL susţin ca Web-ul semantic nu are sens în absenţa

unei fundaţii logice clare, există şi cazuri în care are este suficientă exploatarea numai a

anumitor caracteristici ale limbajului OWL. Selectarea unei varietăţi OWL depinde de scopul

principal al utilizatorului : construirea unei taxonomii, a unor structuri de date sau a unor

modele complexe pentru reprezentarea cunoştinţelor. Spre exemplu, o ontologie destinată

comerţului electronic poate conţie clase de date despre clienţi împreună cu adresele şi

numerele de telefon. O primă versiune a unei astfel de ontologii nu necesită construcţii OWL

mai avansate decât specificarea domeniului şi al codomeniului. Aceste ontologii simple din

punct de vedere semantic sunt suficiente pentru a servi unei aplicaţii Web care generează

formulare pentru a interacţiona cu utilizatorul pe baza claselor definite şi pentru a descrie o

schemă care să poată fi integrată cu baze de date convenţionale. Mai departe în ciclul de viaţă

al ontologiei, dezvoltatorii pot să considere că au nevoie de şi mai multă expresivitate, spre

exemplu, pentru a îi clasifica pe clienţi în funcţie de ceea ce au cumpărat. [KHM05]

OWL DL (utilizarea OWL în stilul Description Logic) se bazează pe limbajul

SHOIN(D), un set de logici de descriere foarte expresive şi puternice – spre exemplu, cu

ajutorul lor se pot construi descrieri booleene folosind doar reuniunea şi complementul.

Această logică de descriere este oarecum dificil de prezentat utilizatorilor nefamiliarizaţi, de

aceea, a fost selectata doar o submulţime a OWL DL care să fie mai simplu de utilizat din

multe puncte de vedere. Această submulţime se numeşte OWL Lite.

OWL Lite interzice reuniunea şi folosirea mulţimilor complementare, restricţionează

intersecţiile la cele implicite din axiomele cadru pentru clase, limitează toate descrierile

incorporate la numele conceptelor, nu permite ca indivizii să apară în descrieri sau axiome de

clase iar cardinalitatea este limitată la 0 şi 1. Aceste restricţii fac versiunea Lite a limbajului

OWL să fie similară cu Description Logic SHIF(D). OWL Lite aduce o îmbunătăţire

semnificativă a tractabilităţii fără a pierde mult din puterea de expresie. Cu toate că sintaxa

OWL Lite este mult restricţionată faţă de cea a OWL DL, pot fi exprimate descrieri complexe

prin introducerea unor noi nume de clase şi exploatarea negaţiilor implicite introduse de

axiomele de disjuncţie. Folosind aceste tehnici, toate descrierile OWL DL pot fi cuprinse în

OWL Lite, cu excepţia celor ce fie conţin nume de indivizi sau au cardinalitatea mai mare ca

1. [HPH03]

OWL DL şi OWL Lite sunt extensii ale unei utilizări restrânse a RDF şi RDFS,

deoarece, spre deosebire de RDF şi RDFS, nu permit claselor să fie folosite drept indivizi iar

constructorii din limbaj nu pot fi aplicaţi limbajului însuşi. Pentru utilizatorii care au nevoie

de aceste capabilităţi, exită versiunea OWL Full care este compatibilă cu RDF şi RDFS. În

OWL Full, toţi combinatorii RDF şi RDFS sunt permişi. Spre exemplu, în OWL Full este

posibilă impunerea unei constrângeri de cardinalitate asupra rdfs:subClassOf , dacă asta se

doreşte. Deoarece restricţiile necesare pentru a păstra decidabilitatea în OWL DL nu se aplică

în OWL Full, acesta din urmă nu este decidabil. În al doilea rând, sintaxa abstractă folosită în

OWL DL este inadecvată pentru OWL Full, aşadar sintaxa oficială RDF/XML este cea care

trebuie folosită.


semantic

27

4.2.2 Componente de bază

Limbajul OWL oferă o semantică decidabilă pentru modelarea primitivelor şi

combinarea vocabularelor. Întrucât organizarea conceptelor într-o structură de arbore nu este

potrivită pentru modelarea realităţii, în OWL informaţiile sunt organizate sub formă de graf

etichetat (numit şi „cercuri şi săgeţi‖).

Indivizii reprezintă entităţile sau fenomenele concrete dintr-un domeniu de interes.

Clasele, în OWL, reprezintă un mecanism de abstractizare pentru gruparea indivizilor

având caracteristici similare. Există trei modalităţi pentru definirea unei clase: axiomatic, prin

extindere sau prin conotaţie. Axiomatic se refera la definirea unei clase prin simpla declarare a

acesteia (spre exemplu: clasa Om, clasa Maşină). A defini o clasă prin extindere înseamnă a

enumera toţi indivizii ce aparţin acelei clase, spre exemplu: {Germania, Italia, Franţa}. O

clasă definită prin conotaţie, este o clasă pentru care a fost stabilit un criteriu de apartenenţă,

spre exemplu, „să aibă culoarea roşie‖. Astfel, pot exista două clase având aceeaşi membri,

dar care să fie totuşi diferite. Un individ poate fi declarat explicit ca aparţinând unei clase.

Clasele pot fi organizate într-o ierarhie de subclase şi superclase. Dacă un individ este

membru al unei clase, el aparţine şi tuturor superclaselor aceste clase. O clasă poate fi

construită ca o subclasă a unei clase. Spre exemplu, dacă există clasa Bărbat inclusă în clasa

Om, înseamnă că o condiţie necesară pentru un individ să fie Bărbat este să fie Om. În cazul

în care o clasă este definită ca un echivalent (un „sinonim‖) al altei clase, spre exemplu,

, condiţia necesară şi suficientă pentru a fi SimpluMuritor este

apartenenţa la clasa Om. O clasă se poate construi şi prin intersecţia sau reuniunea a două sau

mai multe clase.

Dacă o clasă (spre exemplu NonHuman) este construită ca şi complement al altei clase

(Human), condiţia necesară şi suficientă pentru ca o entitate să aparţină clasei NonHuman este

să nu aparţină clasei Human.

Clase disjuncte Clasele disjuncte sunt cele care nu pot avea membri comuni.

În imaginea de mai sus, spre exemplu, o condiţie suficientă pentru a NU face parte din

clasa Bărbat este apartenenţa la clasa Femeie şi viceversa. [STA05]

Reuniunea dintre clasa Human şi Male

Intersecţia dintre clasa Human şi Male


semantic

28

Clasele Thing şi Nothing Condiţia necesară şi suficientă pentru apartenenţa la clasa Thing este întotdeauna

satisfăcută, ceea ce înseamnă că toate clasele sunt subclase ale clasei Thing şi că toţi indivizii

sunt membri ai aceste clase.

Condiţia necesară şi suficientă pentru apartenenţa la clasa Nothing nu este niciodată

îndeplinită, ceea ce înseamnă că această clasă este o subclasă a oricărei clase şi că nu poate

conţine nici un individ.

Clase anonime În OWL există şi conceptul de clase anonime. Membrii unei clase anonime sunt acei

indivizi care satisfac definiţiile logice ale clasei. O clasa anonimă poate fi construită cu

ajutorul următoarelor expresii logice:

- Reuniune sau Intersecţie (Or, And)

- Complement (Not)

- Enumerare (specificarea apartenenţei)

- Restricţii (prin utilizarea proprietăţilor) [REC04]

Proprietăţi Proprietăţile stabilesc o relaţie binară între doi indivizi sau între un individ şi o valoare,

putând fi definite însâ, independent de indivizi.

În exemplul de mai jos, s-a folosit reprezentarea cu „cercuri şi săgeţi‖ pentru a ilustra o

ontologie în care sunt definite cinci proprietăţi (name, hasCapitalCity, livesIn, hasBrother şi

hasAge).

În acest exemplu, hasCapitalCity este o proprietate de tip obiect, şi leagă doi indivizi, în

timp ce codomeniu pentru proprietatea hasAge este reprezentat de mulţimea numerelor

naturale, ceea ce înseamnă că hasAge este o proprietate care face legătura între un individ şi o

valoare. Pentru acest tip de proprietăţi codomeniul poate fi un tip de date sau un anumit tip


semantic

29

din XML Schema (ex: xsd:int, xsd:string, etc). Mai există şi Annotation Property utilă în

ataşarea de metadate claselor, proprietăţilor sau indivizilor.

Proprietăţile se organizează la randul lor într-o ierarhie de proprietăţi, ca şi clasele,

putând fi mai mult sau mai puţin specifice. Spre exemplu, proprietatea areFiică este inclusă în

proprietatea areCopil.

Proprietăţile pot fi tranzitive, inverse, simetrice, funcţionale sau funcţionale inverse.

Restricţii O restricţie defineşte un criteriul de apartenenţă în funcţie de o proprietate, un

cuantificator (universal sau existenţial) sau un filtru pentru valorile unei proprietăţi. Alte

restricţii utilizate în OWL sunt: hasValue, restricţia de cardinalitate sau restricţia obţinută prin

combinarea celor doi cuantificatori (universal şi existenţial).

Exemple:

Pentru a ilustra restricţia hasValue vom alege un exemplu în care se doreşte selectarea

tuturor persoanelor care sunt prietene cu individul Andrei. Asftel, se defineşte o clasă

anonimă (clasa prietenilor lui Andrei) iar condiţia necesară şi suficientă pentru ca o entitate să

aparţină acestei clase este să aibă relaţia isFriendWith cu Andrei.

În cazul restricţiilor de cardinalitate se defineşte o clasă anonimă pentru care, condiţia

necesară şi suficientă de apartenenţă pentru o entitate la această clasă este sa aibă definite un

anumit număr de relaţii cu alţi indivizi dintr-o clasă dată.

Pentru situaţiile în care se utilizează atât cuantificatorul existenţial cât şi cel universal,

avem următorul exemplu:

Din care se înţelege că un vegetarian este cineva care mănâncă mâncare vegetariană şi

mănâncă numai mâncare vegetariană.

Sintaxa OWL este un limbaj independent de sintaxă astfel încât există mai multe reprezentări.

Printre cele mai utilizate se numără Sintaxa abstractă, N3 şi RDF/XML. [DRU05]

Sintaxa abstractă pentru limbajul OWL este una dintre cele mai uşor de citit de către

utilizator. Iată un exemplu:

Class(SpicyPizza complete

annotation(rdfs:label "PizzaTemperada"@pt)

annotation(rdfs:comment "Any pizza that has a spicy

topping is a SpicyPizza"@en)

Pizza restriction(hasTopping

someValuesFrom(SpicyTopping))

)

N3 este sintaxa recomandată pentru fragmentele care ar trebui să poată fi citite de către

un utilizator uman. Exemplu: default:SpicyPizza

a owl:Class ;

rdfs:comment "Any pizza that has a spicy topping is a

SpicyPizza"@en ;


semantic

30

rdfs:label "PizzaTemperada"@pt ;

owl:equivalentClass

[ a owl:Class ;

owl:intersectionOf (default:Pizza [ a

owl:Restriction ;

owl:onProperty default:hasTopping

;

owl:someValuesFrom

default:SpicyTopping

])

] .

Sintaxa RDF/XML este recomandată în vederea serializării: <owl:Class rdf:ID="SpicyPizza">

<rdfs:label xml:lang="pt">PizzaTemperada</rdfs:label>

<rdfs:comment xml:lang="en">Any pizza that has a spicy

topping is a SpicyPizza</rdfs:comment>

<owl:equivalentClass>

<owl:Class>

<owl:intersectionOf rdf:parseType="Collection">

<owl:Class rdf:about="#Pizza"/>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#hasTopping"/>

</owl:onProperty>

<owl:someValuesFrom rdf:resource="#SpicyTopping"/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

4.3 Inferenţe în OWL

Unul dintre aspectele care diferenţiază limbajul OWL de RDF este capacitatea sa de a

suporta o mulţime extinsă de inferenţe. Unele dintre aceste inferenţe sunt destul de evidente,

şi de aceea par a fi uşor de calculat, altele însă sunt suficient de complexe încât să necesite

folosirea unui raţionament pe baza cazurilor similare rezolvate în trecut sau urmărirea

lanţurilor de proprietăţi.

Relaţiile dintre entităţile descrise în cadrul ontologiei sunt cele enunţate de utilizator,

prin definirea proprietăţilor ce leagă doi indivizi la care se adaugă relaţiile pe care limbajul

OWL ne permite să le obţinem prin inferenţe.


semantic

31

Pentru a infera informaţiile care nu sunt conţinute explicit în ontologie, se folosesc

programe numite generic reasoner; acestea pot fi întâlnite şi sub numele de clasificatoare.

În figura de mai sus sunt ilustrate relaţiile inferate pe baza relaţiilor declarate. Acestea

sunt inferenţe la nivelul proprietăţilor.

La nivel de clase, reasoner-ul îndeplineşte următoarele funcţii: verificarea subsumărilor

(dacă o clasă este subclasă a altei clase), clasificarea (determină clasele care subsumează

direct sau sunt subsumate de o anumită clasă), construirea taxonomiei (a ierarhiei explicite a

claselor) şi verificarea satisfiabilităţii pentru fiecare clasă.

La nivel de individ se verifică dacă un individ poate exista în modelul dat (consistenţă),

gradul de realizare (dându-se o descriere parţială a unui individ, găseşte clasa cea mai

specifică în care este descris) sau se pot căuta toţi indivizii ce aparţin unei clase date. [STA05]

4.3.1 Utilizarea unui reasoner

Pe parcursul construirii unei ontologii, reasoner-ul poate fi folosit ca şi compilator

pentru a se urmări dacă înţelesul este cel intenţionat. Folosirea reasoner-ului la momentul

publicării face ca relaţiile inferate să devină disponibile pentru aplicaţia utilizator. Pentru

interogarea unei ontologii (mai ales pentru ontologiile mai mici), este necesară folosirea

reasoner-ului la runtime.

Multe instrumentele de editare şi API-uri folosesc reasoner-i ce implementează interfaţa

DIG; aceasta înseamnă că reasoner-ul este independent de aplicaţia care îl foloseşte, şi deci,

poate fi ales în funcţie de necesităţi (unele pot fi optimizate, spre exemplu, în privinţa vitezei

şi a consumului de memorie, în timp ce altele pot oferi mai multe funcţionalităţi).

În general, reasoner-ii configurează un serviciu care să ruleze local sau pe un server la

distanţă. Spre exemplu, editorul de ontologii Protégé-OWL se poate conecta la reasoneri

printr-o conexiune http.

Exemple de reasoneri


semantic

32

În continuare vom trece în revistă câteva dintre variantele existente de reasoneri. Cel

mai popular pare a fi FaCT++, produs în cadrul proiectului WonderWeb [FAC08] . Acesta

este un reasoner DL care foloseşte o mare parte din tehnicile standard de optimizare precum şi

algortimi tableaux.

Pentru aplicaţiile orientate asupra semanticii care trebuie să reprezintre şi să raţioneze

asupra informaţiilor folosind OWL, Pellet este o opţiune demnă de luat în seamă pentru

sistemele în care un raţionament OWL DL complet şi corect este esenţial. Pellet include şi

suport pentru profile OWL 2 printre care şi OWL 2 EL. Are incorporate diverse tehnici de

optimizare precum optimizări novel pentru nominali, tehnici de răspuns la interogări

conjunctive sau raţionament incremental.

Un alt clasificator este RACER (Robust Server for Scalable Ontology Reasoning).

RACER suportă reguli, raţionament asupra constrângerilor şi o manieră expresivă de răspuns

la interogări (spre exemplu în sintaxă SPARQL).

Printre alte opţiuni de reasoneri se numără şi DPL [PRE08], KAON2 [KRO07] sau The

NeOn Toolkit [NEO07].

4.3.2 Lanţuri de proprietăţi

OWL 1 nu oferă mijloace pentru definirea proprietăţilor ca şi compuneri ale altor

proprietăţi. OWL 1 permite doar propagarea valorilor prin intermediul unei proprietăţi dacă

aceasta este tranzitivă, dar nu permite propagarea unei proprietăţi (ex: esteLocalizatIn)

împreună cu o altă proprietate (ex: faceParteDin) ceea ce ar fi foarte util, mai ales în biologie.

De asemenea, în OWL 1, utilizatorii nu pot defini proprietăţi ca şi lanţuri de relaţii (precum

proprietatea areUnchi, stiind că un unchi este fratele unui părinte).

OWL 2 permite înlănţuirea mai multor proprietăţi de obiecte cu ajutorul unei noi

construcţii numite PropertyChain. [OWL07]

4.3.3 Ipotezele pe care se bazează

Ipoteza lumii deschise (Open World Assumption)

Într-o lume închisă, precum bazele de date spre exemplu, se consideră că în afara

informaţiei conţinute mai există nimic. În contextul Web-ului semantic, însă, se doreşte ca

oamenii să poată extinde modelele existente. În această lume deschisă se presupune că

întotdeauna pot fi adăugate informaţii mai târziu.

Dacă o bază de date întoarce un răspuns negativ atunci când nu găseşte anumite

informaţii, reasonerul nu face nici un fel de presupuneri în privinţa completitudinii

informaţiilor. Reasonerul nu poate determina că ceva este fals decât dacă acest lucru este

specificat explicit în model. Cu alte cuvinte, dacă ceva a fost declarat se presupune că este

adevărat, în caz contrar, nu se poate şti nimic despre el.

Ipoteza numelor unice (Unique Name Assuption)

Prin Ipoteza Numelor Unice se presupune că oricare doi indivizi având nume diferite,

sunt diferiţi. In OWL nu se ţine cont de Ipoteza numelor unice, ci există mecanisme

specializate ale acestui limbaj ce pot fi folosite pentru a arăta că indivizii sunt diferiţi


semantic

33

(owl:differentFrom şi owl:AllDiferent). Totuşi, multi clasificatori care folosesc Description

Logic se bazează pe această ipoteză.

Spre exemplu, dacă în ontologie este enunţat faptul că Fred are doar un singur prieten şi

că este prieten şi cu John şi cu Jack, atunci, prin inferenţă ar trebui să rezulte că John şi Jack

trebuie să fie aceeaşi persoană. În cazul clasificatorului RACER (bazat pe DL) această

inferenţă nu va fi făcută, raportându-se o inconsistenţă, deoarece acest reasoner foloseşte

Ipoteza numelor unice. [BEC02]

4.3.4 Editoare OWL

Pentru construcţia unei ontologii în OWL au fost create mai multe editoare dintre care

amintim: Protégé-OWL, SWOOP, The Manchester OWL Syntax Editor şi Altova

SemanticWorks.

Protégé este un editor open source pentru ontologii dezvoltat de Centrul pentru

Cercetare Informatică în domeniul biomedical de la Universitatea de Medicină din Stanford

[PRO08]. Editorul Protégé-OWL este o extensie la Protégé pentru limbajul OWL.

SWOOP este un instrument pentru crearea, editarea şi depanarea ontologiilor OWL. A

fost produs de către laboratorul MIND al Universităţii din Maryland, College Park iar în acest

moment constituie un proiect open source având contribuitori de pretutindeni. [SWO08].

The Manchester OWL Syntax Editor oferă reprezintă un instrument pentru

vizualizarea şi editarea descrierilor claselor OWL în Protégé-OWL oferind multiple facilităţi

în interfaţa cu utilizatorul (lizibilitate, sublinierea cuvintelor cheie, auto-completare,

semnalarea erorilor, generare de sugestii, etc). [MOS05]

ALTOVA SemanticWorks include un editor RDF şi OWL pentru proiectarea într-un

mod vizual al aplicaţiilor pentru Web Semantic. Acesta permite transformarea automată în

cod RDF/XML a documentelor, vocabularelor şi ontologiilor proiectate în modul vizual.


semantic

34

5 Reprezentarea cunostintelor prin reguli

5.1 OPS5

OPS5 este un limbaj bazat pe reguli, care are ca fundament strategia de calcul generala

numita sistem bazat pe reguli sau sistem de productie.

OPS reprezinta abrevierea pentru ―Official Production System‖ si a fost dezvoltat la

sfarsitul anilor 1970 de catre Charles Forgy la Universitatea Carnegie Mellon. OPS5 este

primul limbaj bazat pe reguli, iar pornind de la acesta s-au dezvoltat celelalte sisteme bazate

pe reguli.

Componentele unui sistem bazat pe reguli sunt: baza de reguli, o baza de date numita

memoria de lucru si un interpretor de reguli ce reprezinta sistemul care ruleaza programul.

Interpretorul de reguli unifica datele cu reguli si alege regula care trebuie aplicata.

Un sistem bazat pe reguli foloseste inlantuirea inainte sau inlantuirea inapoi a regulilor.

Termenii ―inainte‖ si ―inapoi‖ se refera la directia de rezolvare a problemei. Un sistem cu

inlantuire inainte foloseste regulile pentru ca, pornind de la o multime de date initiala, sa

construiasca o concluzie. Un sistem cu inlantuire inapoi incepe cu concluzia dorita si

deriveaza reguli evidente pentru acea concluzie.

OPS5 este un limbaj bazat pe reguli cu inlantuire inainte, care poate fi folosit pentru

rezolvarea problemelor cu inlantuire inainte si inapoi.

OPS5 este utilizat pentru domenii in care este dificil de reprezentat o problema sub

forma unui algoritm, care necesita expresii simbolice, pentru care exista o baza de cunostinte

care creste dinamic sau care este in schimbare, sau in care solutia se exprima in mod natural

prin reguli IF-THEN. O problema rezolvata in acest limbaj nu reprezinta, in general, o solutie

optima.

Diferenta intre OPS5 si majoritatea limbajelor de programare este ca OPS5 nu foloseste

instructiuni de control explicite si codeaza starea programului ca fiind multimea intreaga de

elemente din baza de date [Coo88].

Memoria de lucru are o structura si instante actuale. Structura este definita prin clase de

elemente. Instantele actuale se numesc elementele memoriei de lucru.

Baza de reguli este o multime de reguli IF-THEN care au urmatoarea forma: daca o

multime de conditii exista in memoria de lucru, atunci se executa o multime de actiuni. Partea

IF a regulii sau partea stanga a regulii contine elemente conditionale pozitive sau negate, ce

descriu o multime de elemente din memoria de lucru care indeplinesc regula. Partea THEN a

regulii sau partea dreapta a regulii consta din actiuni care se executa cand regula a fost aleasa.

Partea stanga a regulilor poate folosi variabile, predicate, disjunctii si conjunctii pentru a

specifica valorile din elementele memoriei de lucru care unifica cu elementul conditional.

Ciclul recunoastere-actiune contine trei etape: identificare, selectie (rezolvarea

conflictelor) si actiune.

Prima etapa consta in identificarea intra-element intre fiecare element al memoriei de

lucru si fiecare element conditional, precum si identificarea inter-element care testeaza daca


semantic

35

aceleasi nume de variabile folosite in diferite elemente conditionale se identifica cu aceleasi

valori.

Rezolvarea conflictelor alege o instanta din multimea de conflicte, folosind diferite

criterii. Daca aceste criterii esueaza in alegerea unei instantieri unice, aceasta se alege arbitrar

dintre acelea care sunt recente si specifice.

In timpul celei de-a treia etape, actiunile din partea dreapta a regulii sunt executate in

ordinea in care au fost scrise. Orice schimbare din memoria de lucru se reflecta imediat in

multimea de conflicte.

OPS5 furnizeaza o multime de comenzi pe baza carora utilizatorul poate interactiona cu

programul si cu ciclul recunoastere-actiune. Interpretorul de comenzi executa aceste comenzi.

Din interpretorul de comenzi, se poate initializa memoria de lucru, se poate rula ciclul

recunoastere-actiune si se poate alege strategia folosita pentru rezolvarea conflictelor

[Coo88].

Mai jos se prezinta un fragment dintr-un sistem bazat pe reguli in OPS5, pentru

atribuirea camerelor de camin unor studenti.

;;O camera pentru un grup de studenti

(literalize room

number ; Unique room number

type ; For printout only:

; << SINGLE DOUBLE ... >>

sexes-are ; Gender of occupants << MALE FEMALE >>

smokers? ; Smoking preference << YES NO >>

capacity ; Maximum number of occupants: integer

vacancies ; Assignment openings for this room:

; integer

assignments ; Number of students already assigned:

; integer

occupants) ; Names of students assigned to this room

(vector-attribute occupants)

5.2 JESS

Unul dintre cele mai uzuale sisteme de reguli disponibile pentru utilizare necomerciala

este JESS (Java Expert System Shell). JESS este implementat in limbajul Java. A fost

dezvoltat pornind de la sistemul expert CLIPS, dar a evoluat intr-un sistem bazat pe reguli

complet si distinct. Folosind JESS, se pot scrie applet-uri si aplicatii Java care au capacitatea

de a rationa folosind cunostintele furnizate sub forma regulilor declarative. Sistemul JESS

este folosit in utilitarele bazate pe Protege. De exemplu SWRLJessTab, SweetJess, JessTab.


semantic

36

JESS este un mediu pentru dezvoltarea unui tip de software inteligent numit sistem

expert. Un sistem expert contine o multime de reguli care pot fi aplicate in mod repetat asupra

unei multimi de fapte. JESS foloseste un algoritm foarte eficient numit RETE pentru

unificarea regulilor cu faptele [Jess02].

Un sistem expert bazat pe algoritmul RETE construieste o retea de noduri, unde fiecare

nod, cu exceptia radacinii, corespunde unui sablon care apare in partea stanga a unei reguli.

Calea de la nodul radacina pana la un nod frunza defineste complet partea stanga a regulii.

Fiecare nod memoreaza faptele care satisfac acel sablon. In momentul cand fapte noi sunt

adaugate sau modificate, acestea se propaga de-a lungul retelei, adnotand nodurile cand faptul

unifica cu acel sablon. Cand un fapt sau o combinatie de fapte face ca toate sabloanele pentru

o anumita regula sa fie indeplinite, se ajunge la un nod frunza si regula respectiva este

executata.

Exista trei modalitati pentru reprezentarea cunostintelor in JESS:

reguli, care sunt in principal utilizate pentru cunostinte euristice bazate pe experienta;

functii, care sunt utilizate in principal pentru cunostinte procedurale;

programare orientata pe obiecte, care este de asemenea utilizata in principal pentru

cunostinte procedurale. Cele cinci caracteristici general acceptate ale programarii

orientate pe obiecte sunt recunoscute: clasele, abstractizarea, incapsularea,

mostenirea, polimorfismul.

JESS este un sistem expert, deoarece este un mediu complet pentru dezvoltarea

sistemelor expert, ce include caracteristici cum ar fi un editor integrat si un instrument de

depanare. JESS ofera elementele de baza ale unui sistem expert:

lista de fapte si lista de instante – memoria globala pentru date;

baza de cunostinte – contine toate regulile, baza de reguli;

motorul de inferenta – controleaza executia regulilor.

Un program scris in JESS poate contine reguli, fapte si obiecte. Motorul de inferenta

hotaraste ce reguli trebuie sa fie executate si cand trebuie ele executate. Un sistem expert

bazat pe reguli, scris in JESS este un program condus de date in care faptele si obiectele

reprezinta datele care genereaza executia, folosind motorul de inferenta.

O regula este similara unei instructiuni if-then dintr-un limbaj procedural. O regula if-

then poate fi exprimata astfel: daca anumite conditii sunt adevarate, atunci se executa

actiunile.

O parte a regulilor dintr-un sistem expert pentru miscarea unui robot, in functie de

culorile semaforului, sunt prezentate mai jos:

(defrule red-light

(light red)

=>

(printout t “Stop” crlf)

)

(defrule green-light


semantic

37

(light green)

=>

(printout t “Go” crlf)

)

(defrule take-a-walk

(status walking)

(walk-sign walk)

=>

(printout t “Go” crlf)

)

JESS executa intodeauna actiunile din partea dreapta a regulii cu cea mai mare

prioritate. Dupa aceea, aceasta regula este indepartata si se executa regula urmatoare, in

ordinea descrescatoare a prioritatilor.

JESS ofera doua modalitati diferite pentru rezolvarea conflictelor: in adancime (LIFO)

si in latime (FIFO). In cazul strategiei in adancime se folosesc regulile activate cel mai recent

inaintea regulilor activate mai putin recent si care au aceeasi prioritate. In cazul strategiei in

latime, regulile cu aceeasi prioritate se aplica in ordinea in care au fost activate. Este greu de

hotarat care strategie este mai buna, fara considerarea aplicatiei specifice.

Modulele permit partitionarea unei baze de cunostinte. Orice constructie definita trebuie

plasata intr-un modul. Programatorul poate controla in mod explicit ce constructii dintr-un

modul sunt vizibile altor module, precum si ce constructii din alte module sunt vizibile unui

modul. Vizibilitatea faptelor intre module poate fi controlata intr-o maniera similara.

Modulele pot fi utilizate de asemenea pentru controlul executiei regulilor.

5.3 RuleML

RuleML a aparut pe baza limbajelor de marcaje cu reguli existente si a generat deja alte

proiecte bazate pe marcaje cu reguli.

Initiativa RuleML a inceput in anul 2000 si a reunit echipe de experti din mai multe tari,

incluzand lideri din domeniile reprezentarii cunostintelor si limbaje cu marcaje.

Initiativa RuleML dezvolta un limbaj deschis bazat pe reguli XML/RDF. Aceasta va

permite schimbul regulilor intre sisteme diferite, incluzand componente software distribuite

pe Web, sisteme client-server eterogene care se gasesc in companiile mari. Limbajul RuleML

ofera sintaxa XML pentru reguli de reprezentare a cunostintelor interoperabile intre

principalele sisteme de reguli comerciale si necomerciale.

Un exemplu de regula in RuleML este prezentata mai jos:

<rulebase label=”myRules”>

<imp>

<_head><atom>

<rel>likes</rel>


semantic

38

<ind>John</ind>

<var>x</var>

</atom></_head>

<_body><atom>

<rel>likes</rel>

<var>x</var>

<ind>pictures</ind>

</atom></_body>

</imp>

</rulebase>

Limbajul RuleML contine o ierarhie de reguli, pornind de la reguli de reactie (reguli

eveniment-conditie-actiune), trecand prin reguli de constrangere a integritatilor (reguli de

pastrare a consistentei) si reguli de derivare (reguli de inferenta a implicatiei), pana la fapte

(reguli de derivare fara premize) [BTW07].

Ierarhia de reguli RuleML constituie o ordine partiala, al carei prim nivel sunt regulile

de reactie. Al doilea nivel principal este constituit din reguli de constrangere a integritatii si

din reguli de derivare. Al treilea nivel specializeaza reguli de derivare in fapte.

Figura 1. Ierarhia de reguli RuleML

Un sistem bazat pe reguli RuleML poate fi integrat intr-un model informatic sau baza de

reguli poate avea un atribut care specifica contextul sau, referindu-se la documentul XML

respectiv.

Specificarea RuleML constituie o familie modulara de sub-limbaje Web, ale carei

radacini acceseaza limbajul ca un intreg si ale carei membri identifica submultimi ale

limbajului care se pot adapta si combina. Fiecare dintre sublimbajele familiei are o definitie

XML Schema, o adresa Web identificata printr-un URI, care permite mostenirea intre

schemele de sub-limbaje si referinta precisa la expresivitatea ceruta [Bol07].

RuleML se remarca prin reguli de derivare, interogari, constrangeri de integritate, reguli

de productie si reactie. Hornlog RuleML adauga expresii functionale sub forma de termeni. In

Hornlog cu egalitate astfel de functii neinterpretate sunt complementate de functii interpretate.

Ramura de reguli de derivare se extinde in sus spre logica cu predicate de ordinul I si are

subramuri pentru: negatia ca esec, negatia puternica sau limbaje combinate [RuleML06].

Constrangeri de integritate Reguli de derivare

Fapte

Reguli de reactie


semantic

39

5.4 SWRL

OWL s-a dezvoltat ca un limbaj formal pentru construirea ontologiilor, ce furnizeaza o

descriere de nivel inalt a acestor resurse Web. Cercetarile recente s-au concentrat pe

adaugarea regulilor la OWL pentru a furniza un nivel aditional de expresivitate. SWRL

(Semantic Web Rule Language) este rezultatul acestor cercetari. SWRL permite utilizatorilor

sa scrie reguli tip Horn care pot fi exprimate in termenii conceptelor OWL si care pot rationa

despre indivizii OWL.

Un exemplu simplu de regula SWRL este prezentata mai jos:

hasBrother(?x1,?x2) hasAge(?x1,?age1) hasAge(?x2,?age2)

swrlb:greaterThan(?age2,?age1) hasOlderBrother(?x1,?x2)

SWRL se bazeaza pe o combinatie a sublimbajelor OWL DL si OWL Lite, care fac

parte din limbajul de ontologii Web OWL, impreuna cu sublimbajele Datalog RuleML unar si

binar ale limbajului de marcaje cu reguli. SWRL include o sintaxa abstracta de nivel inalt

pentru reguli de tip Horn in ambele sublimbaje OWL DL si OWL Lite ale limbajului OWL

[CTNDM06].

SWRLTab este un mediu de dezvoltare pentru lucrul cu reguli SWRL in Protege-OWL.

Acesta permite editarea si executarea regulilor SWRL. De asemenea, furnizeaza mecanisme

ce permit interoperabilitatea cu o multime de motoare de reguli si incorporarea bibliotecilor

de metode definite de utilizator care pot fi folosite in reguli. Mai multe biblioteci predefinite

sunt furnizate, ce includ multimi de operatori matematici, operatori pentru siruri si operatori

temporali, in plus fata de operatorii care pot fi folositi pentru a transforma efectiv SWRL intr-

un limbaj de interogari. Acest limbaj furnizeaza o posibilitate de extragere a informatiei din

ontologiile OWL.

SWRLTab furnizeaza o multime de API care permite construirea uneltelor ce lucreaza

cu reguli SWRL. Acesta are mai multe componente software ce includ:

un editor care permite crearea, editarea, citirea si scrierea regulilor SWRL in mod

interactiv;

un motor de reguli care ofera infrastructura necesara pentru a interactiona cu alte

motoare de reguli;

o cale predefinita care ofera un mecanism pentru definirea implimentarilor Java pentru

regulile predefinite SWRL;

o multime de biblioteci predefinite continand operatori matematici, operatori pentru

siruri, operatori temporali, ABox si TBox.

Editorul SWRL este o extensie la Protege-OWL, care permite editarea interactiva a

regulilor SWRL. Utilizatorii pot crea, edita, citi si scrie reguli SWRL. Cu exceptia expresiilor

OWL arbitrare, acest editor permite intreaga multime de caracteristici ale limbajului SWRL.

Este integrat cu Protege-OWL si este accesibil din acesta. In momentul editarii regulilor,

utilizatorii se pot referi direct la clasele OWL, proprietatile si indivizii dintr-o ontologie

OWL. De asemenea, utilizatorii au acces direct la toate tipurile de date XML Schema

[SWRL04].

Importarea datelor din bazele de date relationale in ontologii este ceruta in mod

frecvent, in special cand o ontologie se foloseste pentru a descrie semantic datele utilizate de


semantic

40

o aplicatie software. O alta categorie de aplicatii necesita integrarea si introperabilitatea intre

baza de date si ontologie, unde este necesara o relatie intre structura schemei bazei de date si

conceptele ontologiei.

SWRL intentioneaza sa fie limbajul bazat pe reguli al Web-ului semantic. SWRL se

bazeaza pe OWL. Toate regulile sunt exprimate in termenii conceptelor OWL.

SWRLTab este o extensie a Protege-OWL care permite crearea si executia regulilor

SWRL. Acesta permite inferente cu motorul de reguli JESS.


semantic

41

6 Inginerie ontologică

Ingineria ontologica se ocupa cu studiul metodelor pentru construirea ontologiilor:

procesul de dezvoltare a ontologiilor, ciclul de viata al ontologiilor, metodele de construire a

ontologiilor, precum limbajele de descriere a acestora si tool-urile de editare. Ingineria

ontologica consta dintr-o multime de task-uri pentru dezvoltarea ontologiilor pentru un

anumit domeniu, dar totodata ofera si o modalitate de rezolvare a problemelor de

interoperabilitate provenite datorita obstacolelor semantice (de exemplu, de a corela termeni

din domeniul afacerilor cu clase software).

6.1 Construirea ontologiilor

In proiectarea ontologiilor trebuie sa se tina cont de cateva reguli:

nu exista un mod corect de modelare a unui domeniu— exista intotdeauna alternative

viabile. Cea mai buna solutie depinde aproape intotdeauna de aplicatia pe care o avem in

minte si completarile pe care la anticipam;

dezvoltarea unei ontologii este un proces iterativ;

conceptele unei ontologii trebuie sa fie apropiate de obiectele (fizice sau logice) si relatiile

din domeniul de interes.

Ontologiile pot fi construite in diferite moduri:

manual;

prin refolosirea ontologiilor existente;

folosind metode semiautomate;

6.1.1 Constructia manuala a ontologiilor

Constructia manuala a unei ontologii presupune trecerea prin mai multe etape, etape ce

vor fi descrise in continuare ca in [NM01].

Determinarea domeniului si a scopului ontologiei

Mai intai trebuie definit domeniul ontologiei precum si scopul ei. Pentru aceasta se

poate raspunde la cateva intrebari de baza:

Care este domeniul pe care il va acoperi ontologia?

La ce va fi folosita ontologia?

La ce tipuri de intrebari va furniza raspunsuri informatia din ontologie?

Cine va folosi si va intretine ontologia?

Raspunsurile la aceste intrebari se pot schimba pe parcursul proiectarii ontologiei dar la

orice moment de timp ele vor ajuta la definirea si limitarea scopului modelarii.

In continuare se considera dezvoltarea unei ontologii ce va sugera combinatiile bune de

vin si mancare. In ontologie vor exista conceptele ce descriu diferitele tipuri de vinuri, tipurile

principale de mancare, notiunea de combinatie buna de vin si mancare si notiunea de

combinatie proasta. In schimb ontologia nu va contine concepte pentru gestiunea inventarului

dintr-o fabrica de vinuri sau angajatii dintr-un restaurant chiar daca aceste concepte sunt

cumva legate de notiunile de vin si mancare.


semantic

42

Daca ontologia ce este preiectata va fi utilizata pentru a asista procesarea bazata pe

limbaj a articolelor dintr-un magazin de vinuri poate fi importanta, de asemenea, includerea

sinonimelor si a informatiilor legate de vorbire pentru conceptele din ontologie. Daca

ontologia va fi utilizata pentru a ajuta un client al unui restaurant sa comande un vin, va trebui

sa includem informatii legate de pret. Daca este utilizata de cumparatorii de vinuri, pretul de

vanzare si disponibilitatea sunt necesare, iar daca cei care intretin ontologia descriu ontologia

intr-un limbaj care este diferit de cel al utilizatorilor ei va trebui sa furnizam si maparea dintre

limbaje.

O modalitate de a determina scopul unei ontologii este de a face o lista de intrebari

[GRF95], la care aplicatia bazata pe ontologia respectiva sa poata raspunde.

In domeniul vinului si al mancarii, pot fi puse urmatoarele intrebari de competenta:

Ce caracteristici sa iau in calcul cand aleg un vin?

Este Bordeaux vin rosu sau vin alb?

Vinul Cabernet Sauvignon merge bine cu carnea de miel?

Care este cea mai buna alegere de vin pentru carnea fripta?

Ce caracteristici ale unui vin duc la o proasta combinatie cu un fel de mancare?

Se schimba buchetul sau taria unui vin in functie de anul in care a fost cules?

Care sunt perioadele bune de cules pentru Napa Zinfandel?

Pe baza acestor intrebari, ontologia va include informatii despre diferite caracteristici

ale vinurilor, diferite tipuri de vinuri, anii in care a fost imbuteliat vinul — buni si slabi —

clasificarea mancarii care conteaza pentru alegerea unui vin adecvat, combinatiile

recomandate de vin si mancare.

Considerarea ontologiilor deja existente

Intotdeauna trebuie avut in vedere ceea ce exista deja realizat si trebuie verificat daca se

pot rafina si extinde sursele existente pentru un domeniu particular. Reutilizarea ontologiilor

deja existente poate fi o necesitate daca sistemul ce urmeaza a fi construit trebuie sa

interactioneze cu alte aplicatii care utilizeaza deja o anumita ontologie.

Enumerarea termenilor importanti in ontologie

In acest scop este utila alcatuirea unei liste cuprinzand toti termenii pentru care se

doresc sa fie facute anumite declaratii fie sa fie explicati unor utilizatori:

Care sunt termenii despre care dorim sa discutam?

Care sunt proprietatile pe care le au acestia?

Ce dorim sa spunem despre acesti termeni?

Initial este important de obtinut o lista cuprinzatoare de termeni fara teama de

suprapunere a conceptelor pe care acestia le reprezinta, relatiile dintre ei sau orice proprietati

pe care le poate avea conceptul.

Implementarea ontologiei si popularea acesteia

In acest pas se dezvoltarea ierarhia de clase si definirea proprietatilor conceptelor

(atributelor). Astfel conceptele sunt reprezentate in cadrul unui limbaj formal.


semantic

43

Documentarea

In aceasta etapa se prezinta definitiile formale si informale, presupunerile facute si

exemple care sunt esentiale in vedereea folosirii ontologiei sau refolosirea ulterioara a

acesteia. Documentatia are drept scop definirea mai exacta (decat este realizata in cadrul

ontologiei) pentru intelesul termenilor existenti in ontologie.

Evaluarea

In aceasta etapa se determina exactitatea ontologiei pentru scopul in care a fost

proiectata. Evaluation se realizeaza pentru a determina daca ontologia satisface cerintele

pentru care a fost proiectata, incluzand determinarea consistentei, daca este completa s nu

exista redundanta in definirea ontologiei.

6.1.2 Reutilizarea ontologiilor existente

Este greu de proiectat o ontologie de la inceput. Astfel este bine sa se tina cont de

ontologiile deja construite. Dintre ontologiile existente amintim:

ontologii in domeniul medical: ontologia in domeniul oncologic (National Cancer

Institute in the United States)

ontologii in domeniul cultural:

Art and Architecture Thesaurus (contine 125,000 termeni din domaniul cultural);

Union List of Artist Names (contine 220,000 de intrari);

Iconclass (contine 28,000 termeni pentru descrierea imaginilor culturale);

ontologii in domeniul geografic: Getty Thesaurus of Geographic Names (TGN)

Pe baza ontologiilor deja existente pot fi create noi onologii prin:

unificarea vocabularelor existente din acelasi domeniu intr-o singura resursa: Unified

Medical Language System contine 100 vocabulare din domeniul medical (contine 750,000

concepte, cu peste 10 milioane de legaturi intre ele);

unificarea vocabularelor din domenii diferite:

Cyc, (60,000 asertiuni si 6,000 concepte)

Standard Upperlevel Ontology

6.1.3 Folosirea metodelor semiautomate

Achizitia manuala a informatiilor in vederea construirii unei ontologii este un proces

costisitor si mare consumator de timp. Pentru inlaturarea acestor aspecte se folosesc

tehnici bazate pe invatare pentru:

achizitia sau extragerea cunostintelor;

intretinerea sau revizuirea cunostintelor;

extragerea ontologiilor, a datelor relationale si a metadatelor din datele existente pe Web;

unificarea si maparea ontologiilor prin analiza extinderilor pentru concepte;

intretinerea ontologiilor prin analiza instantelor datelor.


semantic

44

6.2 Implementarea ontologiilor

Exista cateva abordari posibile in ceea ce priveste dezvoltarea unei ierarhii de clase

[UGR96]:

Un proces de dezvoltare top-down incepe cu definirea conceptelor generale despre

domeniul respectiv urmatǎ de diferentierea ulterioarǎ a conceptelor. De exemplu, se creeaza

clasele pentru conceptele generale (Wine si Food). Apoi se defineste clasa Wine prin crearea

unor subclase ale sale: White wine, Red wine, Rosé wine. Mai departe poate fi clasificata

clasa Red wine in Syrah, Red Burgundy, Cabernet Sauvignon etc.

Un proces de dezvoltare bottom-up incepe cu definirea celor mai specializate clase,

frunzele ierarhiei, urmata de gruparea acestora in concepte mai generale. De exemplu, se

porneste de la definirea claselor pentru vinurile Pauillac si Margaux. Apoi se creeazaa o

superclasa a acestor doua clase, Medoc, care la randul ei va fi o subclasa a clasei Bordeaux.

Un proces de dezvoltare combinat este o combinatie a abordarilor top-down si bottom-up:

se definesc mai intai conceptele fundamentale si apoi ele sunt generalizate si specializate

corespunzator. De exemplu, se poate incepe cu cateva concepte importante (cum ar fi cel de

Wine) si cateva concepte specifice (ca Margaux), care apoi pot fi relationate cu un concept de

nivel intermediar, de exemplu Medoc. Dupa care se pot genera clasele pentru toate vinurile

regionale din Franta, astfel generand un numar de concepte de nivel mediu.

Niciuna din aceste trei metode nu este mai bunǎ decat celelalte. Abordarea aleasa

depinde mult de perspectiva personalǎ asupra domeniului. Abordarea combinata este adesea

cea mai usoara pentru multi proiectanti de ontologii, deoarece conceptele intermediare tind a

fi cele mai descriptive concepte din domeniu [ROS78].

Definirea claselor si a ierarhiei de clase

Dezvoltarea unei ontologii include:

definirea claselor din ontologie;

aranjarea claselor intr-o ierarhie taxonomica (subclasa–superclasa);

definirea atributelor si descrierea valorilor permise pentru acestea;

completarea valorilor pentru atribute si instante.

Clasele sunt cele mai importante componente ale celor mai multe ontologii. Ele descriu

conceptele dintr-un domeniu. De exemplu, o clasa de vinuri (de exemplu, Wine) reprezinta

toate vinurile. O clasa poate avea subclase care reprezinta concepte ce sunt mai specifice

decat superclasele. De exemplu, putem imparti clasa tuturor tipurilor de vin in vin rosu, vin

alb si vin roz. Sau o putem imparti in vinuri dulci si vinuri seci.

Atributele descriu proprietatile claselor si instantelor: vinul Chateau Lafite Rothschild

Pauillac este un vin tare; este produs de podgoria Chateau Lafite Rothschild. Sunt doua

atribute ce descriu vinul in exemplul nostru: un atribut „body‖ cu valoarea „full‖ si un atribut

„producer‖ cu valoarea „Chateau Lafite Rothschild‖. La nivel de clasa, putem spune ca

instantele clasei Wine vor avea atribute ce vor descrie aroma, nivelul de zahar, producatorul,

etc. Figura 1prezinta o parte din clase, instante si relatiile dintre ele in domeniul vinului (cu

negru sunt reprezentate clasele, iar cu rosu instantele, liniile drepte reprezinta atribute si

legaturi interne).


semantic

45

Figura 1. Exemplificare clase, instante si

relatiile dintre aceste – in domeniul vinului

Clasele singure nu pot furniza suficiente informatii. Odata ce au fost definite clasele,

trebuie descrisa structura interna a conceptelor.

In general existǎ cateva tipuri de proprietati ale obiectelor care pot deveni atribute intr-o

ontologie:

proprietati „intrinsece‖ (de exemplu aroma (flavor) unui vin;

proprietati „extrinsece‖ (de exemplu numele (name) sau zona (area) din care provine un

vin);

componente, daca obiectul este structurat; acestea pot fi atat componente fizice cat si

abstracte (de exemplu mesele unei zile);

relatii cu alti indivizi; acestea sunt legaturi intre membri individuali ai clasei cu alte

elemente (fabricantul (maker) unui vin, reprezentand relatia dintre un vin si o cramǎ, si

strugurele din care este fǎcut vinul).

Toate subclasele unei clase mostenesc atributele acesteia. Un atribut trebuie asociat

celei mai generale clase care poate avea proprietatea respectivǎ. Atributele pot avea diferite

proprietati care descriu tipul de date, valorile permise, numarul de valori (cardinalitatea) si

alte caracteristici ale valorilor pe care le poate lua un atribut. De exemplu, valoarea unui

atribut name (cu semnificatia de „numele unui vin‖) este un sir de caractere. Asta inseamna cǎ

name este un atribut cu tipul de date String. Un atribut produces (cu semnificatia „crama

produce aceste vinuri‖) poate avea valori multiple, iar valorile sunt instante ale clasei Wine.

Cu alte cuvinte, produces este un atribut cu tipul de date Instance a clasei Wine.

Principalele proprietati ale atributelor:

Cardinalitatea unui atribut - precizeaza numarul de valori pe care le poate avea un atribut.

Tipul de date al atributului - descrie tipurile de date din care poate lua valori atributul

respectiv. Cele mai utilizate tipuri de date:

String (Valoarea este un sir de caractere);

Number (Float – numar real sau Integer – numar intreg) descrie atributele

printr-o valoare numericǎ;

Boolean - indicatori simpli de tip DA/NU;

Enumerare - specifica o lista de valori permise pentru respectivul atribut;


semantic

46

Instanta - permit definirea relatiilor dintre entitati. Atributele cu valori de tip

Instantǎ trebuie de asemenea sǎ defineasca o listǎ a claselor care pot fi instantiate.

Domeniul unui atribut – la definirea domeniului de valori pentru un atribut trebuie gasita

cea mai generala clasa sau cele mai generale clase care pot fi domeniul atributului respectiv.

Atributele pot fi:

atribute inverse - valoarea unui atribut poate depinde de valoarea unui alt atribut;

valori implicite - multe sisteme permit specificarea de valori implicite pentru

atribute.Daca valoarea unui atribut este aceeasi pentru majoritatea instantelor clasei, se poate

defini acea valoare ca valoare implicita a atributului. La crearea unei noi instante a clasei

respective sistemul va completa automat atributul cu valoare lui implicita. Aceasta valoare

poate fi schimbata apoi cu alta valoare permisa.

Ultimul pas in implementarea unei ontologii il reprezinta crearea instantelor individuale

ale claselor din ierarhie. Definirea unei instante individuale a unei clase necesita:

alegerea clasei;

crearea unei instante individuale a acelei clase;

completarea cu valori a atributelor.

Ontologia nu trebuie sa contina toate informatiile posibile din domeniu: nu trebuie sa

specializam sau sa generalizam mai mult decat este nevoie pentru aplicatia noastra. In mod

similar, ontologia nu trebuie sa contina toate proprietatile si diferentele dintre clasele din

ierarhie.

6.3 Alinierea ontologiilor

Ontologiile de domeniu reprezinta concepte intr-un mod foarte specific, adesea acestea

sunt incompatibile pe baza reprezentarii informatiilor existente. Pe masura ce sistemele ce se

bazeaza pe ontologii de domeniu se extind, este necesar sa se unifice mai multe ontologii de

domeniu intr-o reprezentare mult mai generala. Acest lucru nu constituie un proces foarte

usor. Ontologii diferite din acelasi domeniu pot rezulta pe baza perceptiilor diferite ale

aceluiasi domeniu in functie de cunostintele culturale, educationale, ideologice sau datorita

limbajului de reprezentare diferit ales in reprezentarea ontologiei.

Unificarea ontologiilor se poate realiza prin:

unificare simpla - ontologia rezultata prin unificarea mai multor ontologii existente

(ontologiile existente descriu acelasi domeniu sau domeniice se suprapun);

alinierea ontologiilor - ontologiile existente ce se aliniaza raman in continuare,

adaugandu-se legaturi intre elementele componente ale ontologiilor initiale. Alinierea

ontologiilor se realizeaza in cazul in care ontologiile specifica domenii complementare.

Fie doua ontologii o si o', diferitele tipuri de relatii ce pot fi definite intre termenii

acestor ontologii poarta numele de aliniere [WKI08a]. Aceste relatii pot fi

caracterizate prin diferite dimensiuni:

similaritate versus logica: echivalenta logica sau incluziune;


semantic

47

atomic versus complex: alinierea este reprezentata unu la unu sau poate

implica mai multi termeni;

omogen versus heterogen: elementele ce sunt aliniate sunt de acelasi tip

(clasele se inrudesc cu clase, indivizii cu indivizi, etc) sau se permit relatii intre

elemente eterogene;

tipul alinierii: relatia asociata este de echivalenta, disjunctie, parte a sau

orice alt tip de relatie definit de utilizator.

Alinierea intre cele doua ontologii o si o' poate fi descrisa ca [ALN08] o multime de

corespondente <e, e', r, n> in care:

e and e' sunt entitati in cele doua ontologii intre care se asociaza o noua

relatie (de exemplu, clase, indivizi, etc);

r este relatia asociatainta e si e' (poate fi orice fel de relatie intre cele

doua entitati, de exemplu, relatia de echivalenta);

n este gradul de similaritate al alinierii (al potrivirii intre elementele

intre care s-a realizat corespondenta).

Problema alinierii consta in calcularea potrivirilor si apoi maparea (asocierea de noi

relatii) inttr-o maniera automata pe baza acestor potriviri calculate. Pentru a compara

abordarile existente in alinierea ontologiilor a fost creata o organizatie Ontology Alignment

Evaluation Initiative [OAE08] care compara cele mai bune abordari.

6.4 Dezvoltări actuale

6.4.1 Medii de dezvoltare

In continuare prezentam mai multe medii de dezvoltare pentru OWL, RuleML si

SWRL.

Protégé ([Protégé]): Protégé este o platforma open-source, free, care ofera comunitatii

stiintifice mai multe unelte pentru a construi modele de domenii si aplicatii bazate pe

cunostinte folosind ontologii. Protégé suporta doua moduri de a modela ontologii: Protégé-

Frames editor care permite utilizatorilor sa creeze si sa populeze ontologii bazate pe frame-

uri si Protégé-OWL editor care permite utilizatorilor sa construiasca ontologii pentru webul

semantic, in special pentru limbajul OWL. SWRLTab ([SWRL Tab]) este o extensie pt

Protégé care suporta editarea si executia regulilor SWRL. Taxonomic RuleML Tab ([TX

RuleML]) este o extentie pentru Protégé care converteste fisiere RuleML in ierarhii de clase

taxonomice si invers; in plus poate fi folosit ca un validator pentru fisierul RuleML,

recunoscand si raportand erorile, cum ar fi taguri incorecte sau simboluri nevalide.

TopBraid Composer ([TopBraid Composer]) este un mediu pentru dezvoltarea

ontologiilor pentru webul semantic si pentru construirea aplicatiilor semantice. Are suport

complet pentru OWL si editor pentru SWRL ([Wiki Ontology Editor]).

Bossam Rule/OWL Reasoner ([Bossam]) este un motor de inferenta pentru webul

semantic. Este un motor de reguli bazat pe RETE cu suport pentru rationamente pentru

ontologii OWL, ontologii SWRL si reguli RuleML.

Hoolet ([Hoolet]) este o implementare a unui motor de inferenta OWL-DL. Ontologia

este tradusa intr-o colectie de axiome (bazate pe semantica OWL) si aceasta colectie de

http://ralyx.inria.fr/2007/Raweb/exmo/aligndef.html

http://oaei.ontologymatching.org/


semantic

48

axiome este data unui demonstrator pt predicate de ordinul I pentru testarea consistentei.

Deoarece motorul de inferenta este bazat pe traducerea folosind predicate de ordinul I, este

usor de extins implementarea pentru extensii ale OWL, cum ar fi SWRL. Hoolet a fost extins

pentru a fi utilizat pentru reguli prin adaugarea unui parser pentru reguli cu sintaxa RDF si

prin extinderea translatorului si pentru reguli.

Pellet ([Pellet]) este un motor de inferenta OWL-DL bazat pe Java cu support pentru

SWRL ([Wiki SWRL]). Pellet suporta in totalitate specificarea initiala OWL DL. OWL 2 este

o noua versiune a standardului international produsa de catre W3C pentru ontologii web-

friendly. Pellet suporta in acest moment majoritatea facilitatilor propuse de OWL 2.

KAON2 ([KAON2]) este o infrastructura pentru lucrul cu ontologii OWL-DL, SWRL

si F-Logic. KAON2 este un urmas al proiectului KAON (uneori numit si KAON1). Principala

diferenta dintre cele doua proiecte este limbajul pentru ontologii acceptat: KAON folosea o

varianta de RDFS, in timp ce KAON2 este bazat pe OWL-DL si F-Logic. Cu toate acestea,

KAON2 este un sistem complet nou, necompatibil cu KAON.

RACER este abrevierea pentru Renamed ABox and Concept Expression Reasoner.

RacerPro ([RacerPro]) este numele commercial al software-ului. Originile sistemului

RacerPro provin din logicile de descriere. RacerPro poate fi utilizat ca un sistem pentru lucrul

cu ontologii pentru webul semantic bazate pe OWL (de exemplu, poate fi utilizat ca motor de

inferenta pentru editoare de ontologii, cum ar fi Protégé). RacerPro suporta procesarea

regulilor descrise folosind o sintaxa bazata pe SWRL ([Wiki SWRL]). In plus, RacerPro poate

fi privit si ca mediu de stocare a informatiilor din webul semantic cu un motor de cautare

optimizat pentru ca poate fi utilizat pentru mari cantitati de date (definite folosind RDF). De

asemenea, RacerPro poate fi folosit pentru logici modale cum ar fi Km .

6.4.2 Ontologii existente

Dintre ontologiile existente amintim:

Cell Cycle Ontology (CCO) [CCO08] care extinde ontologiile existente pentru

cunostintele legate de ciclul celulei. CCO integreaza si gestioneaza cunostintele despre

componentele si aspectele obisnuite ale ciclului celulei in OBO, OWL, RDF . Aceste

cunostinte folosesc resurse deja existente (GO, UniProt, IntAct, GOA, NCBI

taxonomy, and so forth), iar prin combinarea acestor cunostinte se furnizeaza o

imagine a procesului de diviziune a celulei. Acest nou model al ciclului celului, intr-o

mai buna reprezentare, nu este obtinut numai prin combinarea informatiilor existente

deja, ci si prin folosirea Ontology Design Patterns aplicata in OWL.

Customer Complaint Ontology (Ccontology) [CON08] ontologie ce a fost

dezvoltata in scopul suportarii managementului online compatibil cu utilizatorul. In

acest scop a fost dezvoltat un portal , in care fiecare utilizator putea inregistra o

plangere impotriva unei parti, referitor la orice problema, in 11 limbaje. Ontologia este

construita pentru reprezentarea problemelor cumulate pe acest portal: clasificarea

plangerilor, clasificarea rezolvarilor plangerilor depuse, reclamantii, reclamatii, cele

mai bune practici. Aceasta ontologie este o ontologie domeniu ce contine baza pentru

elementele de plangere, ce pot fi extinse de orice companie sau grup de companii.

http://obo.sf.net/

http://www.w3.org/2004/OWL/

http://www.w3.org/RDF/

http://geneontology.org/

http://www.expasy.uniprot.org/

http://www.ebi.ac.uk/intact/site/

http://www.ebi.ac.uk/GOA/

http://www.ncbi.nlm.nih.gov/Taxonomy/taxonomyhome.html/



http://odps.sourceforge.net/


semantic

49

OpenCyc [OPC08] este versiunea open-source pentru tehnologia Cyc

[CYC08], cea mai larga si completa baza de cunstinte si motor de rationament.

OpenCyc include:

ontologia Cyc ce contine sute de mii de termeni si milioane de

asertiuni, pe baza carora se inrudesc termenii intre ei, formand o ontologie de

nivel a carui domeniu este reprezentat de intreg consensul realitatii umane;

siruri in engleza ce corespund tuturor conceptelor, folosite la cautare si

afisare;

versiunea completa pentru Cyc Inference Engine and the Cyc

Knowledge Base Browser;

documentatie pentru o buna intelegere a reprezentarii cunostintelor si a

dezvoltarii aplicatiilor folosind Cyc;

specificarea limbajului CycL, limbajul in care sunt scrise ata Cyc cat si

OpenCyc;

specificatia API-ului Cyc pentru dezvoltarea aplicatiilor;

legaturi intre conceptele Cyc si ‖synset‖-urile WordNet.

OpenCyc poate fi folosit ca baza intr-o serie de aplicatii, cum ar fi:

dezvoltarea rapida a unei ontologii;

prioritizarea, rutarea, sumarizarea si anotarea email-urilor;

sisteme expert;

jocuri.

WordNet [WON08] este un lexicon semantic pentru limba engleza. El

gupeaza cuvintele in mutimi de sinonime numite ―synsets‖, care reprezinta odefinitie

scurta si generala. Totodata sunt referite relatiite semantice dintre aceste multimi de

sinonime. Scopul acestei ontoloii este de a produce o combinatie intre un dictionar si

un tezaur de cuvinte care sa fie mai intuitiv de folosit si totodata de a suporta analiza

automata a textului. Substantivele, verbele, adjectivele si adverbele sunt grupate in

multimi de sinonime ―synsets‖, fiecare exprimand un concept distinct. Synsets-urile

sunt inlantuite cu ajutorul lexicale si semantice conceptuale. Reteaua rezultata ce

contine cuvinte si concepte cu intelesuri inrudite reprezinta o unealta folositoare

pentru lingvistica computationala precum si pentru prelucrarea limbajului natural.

Gene ontology [GEO08] furnizeaza un vocabular pentru descrierea genelor si

a atributelor acestora in orice organism. Acesta este compus din 3 ontologii ce descrie

produsele de gene in termeni de procese biologice asociate, componente celulare si

functii moleculare independenta de specii. In scopul realizarii acestor ontologii a

trebui sa se aiba in vedere: (i) dezvoltarea si intretinerea ontologiilor, (ii) adnotarea

produselor de gene pe baza carora se fac asocieri intre gene, produse de gene si bazele

de date colaborative, (iii) dezvoltarea de unelte care sa faciliteze crearea, intretinerea

si folosirea ontologiilor. Folosirea bazelor de date colaborative faciliteaza interogarea

uniforma a acestora. Ontologiile pot fi interogate la diferite niveluri, in functie de

nivelul de cunoastere al entitatii respective.

Gellish English Dictionary [GEL08] (numita si STEPlib) este un dictionar

electronic ce contine definitii pentru concepte, fiecare dintre acestea fiind identificat

de un identificator unic (un numar alocat de gestionarul limbajului) care pot fi referite

prin unul sau mai multe nume, ce reprezinta termeni in engleza existenti in orice

dictionar. Toate definitiile nu au doar asociate o descriere textuala, ci si cel putin o

relatie explicita cu conceptul (sau conceptele) superioare corespunzatoare. Astfel este

formata o ierarhie consistenta de concepte. Pornind de la modelul acestui dictionar pot

http://www.cyc.com/cyc/technology/whatiscyc




semantic

50

fi construite dictionare specializate pentru anumite domenii sau dictionare in alte

limbi.

Plant Ontology (PO) [PLO08] reprezinta o ontologie care sa descrie structura

plantelor si etapele de crestere ale acestora cu legaturi intre diferite specii.

Cancer ontology [CAO08] Ontologia cuprinde informatii despre boli,

medicamente, substante chimice, diagnostice, tratamente, anatomie, organisme si

proteine.

Enterprise ontology [ENO08]reprezinta o colectie de termeni si definitii din

domeniul firmelor.

Exista o serie de ontologii existente ce ofera si facilitati de cautare. Dintre acestea

amintim:

DAML Ontology Library [DAM08] cuprinde o serie de ontologii DAML.

Protege Ontology Library [PRO08] contine o multime de ontologii OWL sau in alte

formate.

SchemaWeb [SCW08] este un director de informatii reprezentate in RDFS, OWL si

DAML+OIL.

6.4.3 Proiecte si standarde

Dintre proiectele existente amintim:

Ontology Metada Vocabulary [OMV08] - Majoritatea ontologiilor existente

sunt definite intr-o forma pura fara a avea asociate informatii aditionale. Acest proiect

isi propune sa creeze un standard de metadate.

American President Ontology [APO08] - ontologia despre presedintii

americani, ilustrand modul in care aspectele temporale pot fi modelate intr-o

ontologie. Ontologia modeleaza perioadele de guvernare ale presedintilor americani,

titlurile academice ale acestora, evenimente, cum ar fi razboaie, scandaluri, etc ce au

avut loc in timpul presidentiei fiecaruia.

Text2Onto [T2O08] – este succesorul TextToOnto [TTO08], care reprezinta

un cadru de invatare a ontologiei dintr-un text (achizitia de informatii prin tehnici

automate). Un alt proiect similar LexO (Learning Expressive Ontologies) [LEO08] ce

transforma definitii din limbaj natural in axiome OWL DL.

NeOn [NEO08] – folosirea ontologiilor in aplicatii semantice pe scara larga,

in organizatii distribuite.

Ontologii pentru SOA [SOA08] – faciliteaza alinierea intre comunitatile din

domeniul afacerilor si cel al tehnologiei informatiilor. Acest proiect:

defineste conceptele, terminologia si semantica SOA atat in termeni de

afaceri cat si in termeni tehnici, in scopul de a:

crea o baza pentru lucrul intr-o zona specifica domeniului;

da posibilitatea comunicarii intre oamenii de afaceri si cei din domeniul

ethnic;

da posibilitatea intelegerii conceptelor SOA in comunitatile de afaceri

si in cele tehnice;

contribuie la implementarea bazata pe SOA, care va facilita adoptarea

SOA.


semantic

51

Proiectul va furniza ontologii formale ce va contine definitiile conceptelor SOA si a

relatiilor dintre acestea.

Dintre standardele existente amintim:

Standard Upper Ontology(SUO) [SUO08] Suggested Upper Merged

Ontology (SUMO) este o ontologie de nivel ce a fost propusa ca un document de

pornire pentru ―The Standard Upper Ontology Working Group‖, un grup IEEE-

sanctioned ce cuprinde cercetatori din domeniul ingineriei, filosofiei si stiintei

informatice. SUMO furnizeaza definitii pentru termeni in sens general si are rolul de a

furniza diferite ontologii de domeniu. Ontologia reprezinta un standard deschis ce

poate fi folosita gratis atat in scopuri academece cat si comerciale, permitand

adaugarea de ontologii de domeniu suplimentare. Principalul scop al acestui standard

a fost sa poata fi folosit in inferente automate, interoperabilitate semantica intre

sisteme de heterogene de informatii si aplicatii de prelucrare a limbajului natural.

6.5 Concluzii

Exista mai multe medii de dezvoltare pentru OWL, RuleML si SWRL. Mediul care

ofera cele mai multe facilitati este Protégé, el oferind suport pentru toate cele 3 limbaje. Cele

mai multe dintre mediile prezentate mai sus, ofera suport pentru OWL.

Unele medii reprezinta doar motoare de inferenta (Bossam Rule/OWL Reasoner,

Hoolet, Pellet). Astfel de motoare de inferenta pot fi utilizate in conjunctie cu medii mai

complexe pentru construirea aplicatiilor. De exemplu, Pellet poate fi folosit impreuna cu

Protégé pentru crearea de aplicatii bazate pe OWL.


semantic

52

Bibliografie

[ALN08] http://ralyx.inria.fr/2007/Raweb/exmo/aligndef.html, accesat 2008

[APO08] http://ontoware.org/projects/presidents/, accesat 2008

[BRJ97]G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language user guide: Addison-Wesley,

1997.

[CAO08] http://www.mindswap.org/2003/CancerOntology/, accesat 2008

[CCO08] http://www.cellcycleontology.org/, accesat 08

[CON08] http://www.jarrar.info/CContology/, accesat 2008

[CYC08] http://www.cyc.com/doc/, accesat 2008

[DTD08] http://www.w3schools.com/dtd/default.asp, accesat 2008

[DAO08] http://www.daml.org/2001/03/daml+oil-index, accesat 2008

[DAM08] http://www.daml.org/ontologies/, accesat 2008

[DC08] http://dublincore.org/, accesat 2008

[ENO08] http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html, accesat 2008

[GEL08] http://sourceforge.net/projects/gellish, accesat 2008

[GEO08] http://www.geneontology.org/, accesat 2008

[GRF95] M. Gruninger, M.S. Fox. Methodology for the Design and Evaluation of Ontologies, Proceedings of the Workshop

on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, 1995.

[GRU95] T. R. Gruber, T. R., Toward Principles for the Design of Ontologies Used for Knowledge Sharing,

International Journal Human-Computer Studies, Italia, Vol. 43, 1995, pp. 907-928.

[GRU08] http://tomgruber.org/writing/ontology-definition-2007.htm, accesat 2008

[JEN08] http://www.hpl.hp.com/semweb/jena.htm, accesat 2008

[KIF08] http://www.ksl.stanford.edu/knowledge-sharing/kif/, accesat 2008

[LEO08] http://ontoware.org/projects/neon-toolkit, accesat 2008

[MIC00] R.S. Michalski, Learnable Evolution Model: Evolutionary processes guided by machine learning,

Special issue on multistrategy learning, Volum 38, 2000, pp. 9 – 40.

[MFR00] D.L.McGuinness, R. Fikes, J. Rice, S. Wilder. An Environment for Merging and Testing Large

Ontologies. Principles of Knowledge Representation and Reasoning, Proceedings of the Seventh International

Conference (KR2000), San Francisco, CA, Morgan Kaufmann Publishers, 2000.

[NEO08] http://ontoware.org/projects/neon-toolkit, accesat 2008

[NM01] N. F. Noy, D. L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology,

Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics

Technical Report SMI-2001-0880, Martie 2001.




http://ontoware.org/projects/presidents/

http://www.mindswap.org/2003/CancerOntology/

http://www.mindswap.org/2003/CancerOntology/









http://www.cyc.com/cycdoc/ref/cycl-syntax.html

http://www.w3schools.com/dtd/default.asp

http://www.daml.org/2001/03/daml+oil-index

http://www.daml.org/ontologies/

http://dublincore.org/

http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html



http://suo.ieee.org/







http://www.geneontology.org/



http://tomgruber.org/writing/onto-design.htm

http://tomgruber.org/writing/ontology-definition-2007.htm

http://www.hpl.hp.com/semweb/jena.htm



http://www.ksl.stanford.edu/knowledge-sharing/kif/

http://ontoware.org/projects/neon-toolkit



http://smi-web.stanford.edu/people/noy

http://smi-web.stanford.edu/people/noy

http://www.ksl.stanford.edu/KSL_Abstracts/KSL-01-05.html


semantic

53

[OAE08] http://oaei.ontologymatching.org/, accesat 2008

[OMV08] http://omv.ontoware.org/, accesat 2008

[ONT08] http://www.ksl.stanford.edu/software/ontolingua/, accesat 2008

[OPC08] http://opencyc.org/, accesat 2008

[OWL08] http://www.w3.org/TR/owl-ref/, accesat 2008

[PLO08] http://www.plantontology.org/, accesat 2008

[PRO08] http://protege.stanford.edu/, accesat 2008

[RBP91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-oriented modeling and design,

Englewood Cliffs, New Jersey: Prentice Hall, 1991.

[RDF08] http://www.w3.org/RDF/, accesat 2008

[ROS78] E. Rosch, Principles of Categorization. Cognition and Categorization. R. E. and B. B. Lloyd, editors.

Hillside, NJ, Lawrence Erlbaum Publishers, 1978, pp. 27-48.

[SOA08] http://www.opengroup.org/projects/soa/doc.tpl?CALLER=index.tpl&gdid=10952, accesat 2008

[SCW08] http://www.schemaweb.info/, accesat 2008

[SHO08] http://www.cs.umd.edu/projects/plus/SHOE/, accesat 2008

[SUO08] http://suo.ieee.org/, accesat 2008

[T2O08] http://ontoware.org/projects/text2onto, accesat 2008

[TTO08] http://sourceforge.net/projects/texttoonto/, accesat 2008

[UGR96] M. Uschold, M. Gruninger. Ontologies: Principles, Methods and Applications, Knowledge Engineering Review,

1996.

[XDB08] http://www.rpbourret.com/xml/XMLDataBinding.htm, accesat 2008

[XML08] http://www.w3.org/XML/, accesat 2008

[XSD08] http://www.w3schools.com/Schema/default.asp, accesat 2008

[W3C08] http://www.w3.org/, accesat 2008

[WON08] http://wordnet.princeton.edu/, accesat 2008

[WKI08a] http://en.wikipedia.org/wiki/Ontology_alignment, accesat 2008

[SJR07] A.B. Smith, C.D. Jones, and E.F. Roberts, Article Title, Journal, Publisher, Location, Date … 2007, pp.

1-10.

[Jon07] C.D.Jones. Book Title, Publisher, Location, Date.

[NB] D. Nardi, R.J. Brachman, ―An Introduction to Description Logics‖

[BN] F. Baader, W. Nutt, ―Basic Description Logics‖





http://omv.ontoware.org/



http://www.ksl.stanford.edu/software/ontolingua/

http://opencyc.org/

http://opencyc.org/

http://opencyc.org/

http://www.w3.org/TR/owl-ref/

http://www.plantontology.org/



http://protege.stanford.edu/



http://www.w3.org/RDF/

http://www.opengroup.org/projects/soa/doc.tpl?CALLER=index.tpl&gdid=10952

http://www.schemaweb.info/

http://www.cs.umd.edu/projects/plus/SHOE/







http://ontoware.org/projects/text2onto




http://sourceforge.net/projects/texttoonto/



http://www.rpbourret.com/xml/XMLDataBinding.htm

http://www.w3.org/XML/

http://www.w3schools.com/Schema/default.asp

http://www.w3.org/

http://wordnet.princeton.edu/

http://en.wikipedia.org/wiki/Ontology_alignment


semantic

54

[BHS05] F. Baader, I. Horrocks, and U. Sattler, ―Description Logics as Ontology Languages for the Semantic

Web‖. In Dieter Hutter and Werner Stephan, editors, Mechanizing Mathematical Reasoning: Essays in Honor of

Jörg Siekmann on the Occasion of His 60th Birthday, no. 2605 in Lecture Notes in Artificial Intelligence, pp

228-248, Springer, 2005.

[BS01] F. Baader, U. Sattler, ―An Overview of Tableau Algorithms for Description Logics‖, Studia Logica, vol.

69, no. 1, pp. 5-40, Springer, 2001

[CGLN99] D. Calvanese, G. De Giacomo, M. Lenzerini, and D. Nardi, ―Reasoning in Expressive Description

Logics‖. In A. Robinson and A. Voronkov, editors, Handbook of Automated Reasoning, chapter 12, Elsevier

Science Publishers (North-Holland), Amsterdam, 1999

[STA05] OWL Tutorial Final – Stanislav Pokraev & Rogier Brussee, Telematica Instituut, 2005

[BEC02] OWL and Inference: Practical examples - Sean Bechhofer

[HPH03] From SHIQ and RDF to OWL: The Making of a Web Ontology Language - Ian Horrocks, Peter F.

Patel-Schneider and Frank van Harmelen

[OWL07] http://www.w3.org/2007/OWL/wiki/Requirements#F8:_Property_chain_inclusion – accesat 2008

[DRU05] Introduction to Ontologies - Nick Drummond

[REC04] A Practical Introduction to Ontologies & OWL – The University of Manchester

[KHM05] The Protégé OWL Experience – Holger Knublauch, Matthew Horridge, Mark Musen, Alan Rector

[GRI05] Closed World Reasoning in the Semantic Web through Epistemic Operators – Stephan Grimm and

Boris Motik

[HAA05] An Introduction to the Ontology Web Language (OWL) – Volker Haarslev

[TSA06] FaCT++ Description Logic Reasoner: System Description – Dmitry Tsarkov and Ian Horrocks

[PRE08] http://c4i.gmu.edu/ursw/2008/papers/URSW2008_P1_Predoiu.pdf accesat 2008

[KRO07] KAON2 - Practical Reasoning with OWL and Rules - Markus Krötzsch

[NEO07] The NeOn Toolkit – www. Neon-toolkit.org – accesat 2008

[FAC08] http://owl.cs.manchester.ac.uk/fact++/ accesat 2008

[PRO08] http://protege.stanford.edu/ accesat 2008

[SWO08] http://code.google.com/p/swoop/ accesat 2008

[MOS05] http://www.co-ode.org/downloads/manchesterowlsyntaxeditor/ accesat 2008

http://www.w3.org/2007/OWL/wiki/Requirements#F8:_Property_chain_inclusion

http://c4i.gmu.edu/ursw/2008/papers/URSW2008_P1_Predoiu.pdf

http://owl.cs.manchester.ac.uk/fact++/


http://code.google.com/p/swoop/

http://www.co-ode.org/downloads/manchesterowlsyntaxeditor/

SCIPA - Standarde actuale în limbajele de modelare a proceselor de business

SCIPA

Servicii software semantice de Colaborare şi



Standarde actuale în limbajele de modelare a proceselor de business

Viorel Negru, Dana Petcu, Alexandru Cicortaş, Florin-Teodor

Fortiş, Daniel Pop Universitatea de Vest Timişoara

Universitatea de Vest Timişoara, Bd. V. Pârvan, nr. 4,

Timişoara 300223, România

Email: {vnegru, petcu, cico, fortis, danielpop}@info.uvt.ro

Pagina Web: http://www.uvt.ro, http://www.math.uvt.ro


2

Rezumat

Pentru a modela, specifica şi executa workflow-uri într-o platformă integrată este

necesară analiza tehnologiilor existente. Domeniul tehnologiilor workflow este unul foarte

dinamic şi în continuă evoluţie, ce conţine numeroase tehnologii disponibile. Au fost analizate

şi evaluate cele mai semnificative dintre aceste tehnologii pentru a putea selecta pe cea mai

potrivită pentru necesităţile proiectului SCIPA.

Rezultatele acestei analize sunt prezentate în prezentul document. Primul capitol

prezintă un sinteză a celor mai importante organizaţii şi structuri de standadizare din

domeniu, cu tehnologiile şi standardele workflow pe care acestea le dezvoltă, astfel încăt

cititorii pot obţine o înţelegere globală asupra organizaţiilor active şi a diverselor direcţii. În

continuare sunt evaluate cele mai semnificative tehnologii, fiecare într-o secţiune distinctă

urmărind un şablon prestabilit. La început, sunt prezentate informaţii generale despre

tehnologie şi poziţia acesteia pe piaţă. Cele mai importante concepte tehnice ale tehnologiei

sunt prezentate în continuare pentru a ilustra cât mai bine posibilităţile şi limitările fiecăarei

tehnologii. În final, este oferit un rezumat al avantajelor şi dezavantajelor tehnologiei

respective, precum şi o recomandare cu privire la utilizarea tehnologiei în cadrul proiectului

SCIPA.

Documentul acesta îşi propune să ofere unele intuiţii asupra numeroaselor standarde şi

tehnologii workflow existente, în special asupra celor ce par să fie promiţătoare. Analizele

făcute sunt organizate în patru capitole principale: primul prezintă metodologiile de

modelare şi standardele pentru notaţiile grafice, urmat de limbajele de coregrafie şi

orchestrare. Ultimul capitol prezintă alte standarde relevante pentru acest proiect.

Acest document poate fi privit ca un document de referinţă, şi nu unul care trebuie

lecturat de la un capăt la altul. Documentul a fost astfel structurat încât să permită cititorilor

să regăsească cu uşurinţă informaţia de care au nevoie în complexitatea tehnologiilor legate

de workflow-uri. Secţiunea bibliografică conţine numeroase intrări care să permită cititorilor

interesaţi să urmeze detaliile de care au nevoie.


3

CUPRINS

1 Organizaţii şi structuri de standardizare ............................................................................. 7

1.1 OASIS .......................................................................................................................... 7

1.1.1 Standarde suportate ............................................................................................. 8

1.2 Business Process Management Initiative (BPMI) ....................................................... 8

1.2.1 Standarde suportate ............................................................................................. 9

1.3 Object Management Group (OMG) ........................................................................... 10

1.3.1 Standarde suportate ........................................................................................... 11

1.4 World Wide Web Consortium (W3C) ....................................................................... 12

1.4.1 Standarde suportate ........................................................................................... 12

1.5 Workflow Management Coalition (WfMC)............................................................... 13

1.5.1 Supported StandardsStandarde suportate ......................................................... 13

1.6 RosettaNet .................................................................................................................. 14

1.7 Open Applications Group (OAGi) ............................................................................. 15

2 Limbaje de modelare şi notaţii grafice ............................................................................. 19

2.1 Unified Modeling Language (UML) .......................................................................... 19

2.1.1 Criterii de piaţă ................................................................................................. 20

2.1.2 Criterii tehnice .................................................................................................. 20

2.1.3 Aplicabilitate..................................................................................................... 27

2.1.4 Rezumat ............................................................................................................ 28

2.2 Notaţia de modelare a proceselor de afaceri (BPMN) ............................................... 28



2.2.3 Aplicabilitate..................................................................................................... 35

2.2.4 Rezumat ............................................................................................................ 35

2.3 Concluzii .................................................................................................................... 36

3 Limbaje de coregrafie ....................................................................................................... 38

3.1 Orchestrare versus coregrafie ..................................................................................... 38

3.2 Interfaţa comportamentală ......................................................................................... 39

3.3 WS-CDL .................................................................................................................... 41

3.3.1 Concluzii ........................................................................................................... 46

3.4 Detalii coregrafie ........................................................................................................ 47

3.5 SOA ............................................................................................................................ 49

4 Limbaje de orchestrare ..................................................................................................... 51

4.1 Web Services Business Process Execution Language (WSBPEL) ............................ 53



4.1.3 Aplicabilitate..................................................................................................... 58

4.1.4 Rezumat ............................................................................................................ 59

4.2 XML Process Definition Language (XPDL) ............................................................. 60



4.2.3 Aplicabilitate..................................................................................................... 66

4.2.4 Rezumat ............................................................................................................ 66

4.3 ebXML Collaboration Protocol Profile and Agreement (CPPA) .............................. 67



4.3.3 Aplicabilitate..................................................................................................... 73


4

4.3.4 Rezumat ............................................................................................................ 74

4.4 Concluzii .................................................................................................................... 74

5 Alte standarde asociate tehnologiilor orientate spre fluxuri de activităţi ......................... 77

5.1 Business Transaction Protocol (BTP) ........................................................................ 78



5.1.3 Aplicabilitate..................................................................................................... 84

5.1.4 Rezumat ............................................................................................................ 84

5.2 XML Based Protocol for Run-Time Integration of Process Engines (Wf-XML) ..... 85



5.2.3 Aplicabilitate..................................................................................................... 89

5.2.4 Rezumat ............................................................................................................ 89

5.3 Universal Business Language (UBL)......................................................................... 91



5.3.3 Aplicabilitate..................................................................................................... 96

5.3.4 Rezumat ............................................................................................................ 96

5.4 Asynchronous Service Access Protocol (ASAP) ....................................................... 97


5.4.2 Aplicabilitate................................................................................................... 101

5.4.3 Rezumat .......................................................................................................... 101

5.5 ebXML Messaging Service (ebMS)......................................................................... 102

5.6 Concluzii .................................................................................................................. 104

Bibliografie ............................................................................................................................. 107


5

LISTA DE TABELE

Tabela 1 Criteriile de piaţă utilizate la evaluarea standardelor de orchestrare ......................... 51

Tabela 2 Criteriile tehnice utilizate la evaluarea standardelor de orchestrare .......................... 52

Tabela 3 Criterii de piaţă BPEL4WS / WSBPEL .................................................................... 55

Tabela 4 Criterii tehnice BPEL4WS / WSBPEL ..................................................................... 59

Tabela 5 Criterii de piaţă XPDL .............................................................................................. 62

Tabela 6 Criterii tehnice XPDL ............................................................................................... 66

Tabela 7 Criterii de piaţă CPPA ............................................................................................... 69

Tabela 8 Criterii tehnice CPPA ................................................................................................ 73

Tabela 9 Sinteza analizei de piaţă pentru evaluarea standardelor de orchestrare .................... 75

Tabela 10 Sinteza analizei tehnice pentru evaluarea standardelor de orchestrare ................... 76

Tabela 11 Recomandări finale ............................................................................................... 106


6

LISTA DE FIGURI

Figura 1 Tipuri de standarde şi relaţiile dintre ele ..................................................................... 7

Figura 2 BPMI.org - stiva de standarde BPM ............................................................................ 9

Figura 3 SEQ, limbajul canonic OAGIS .................................................................................. 16

Figura 4 SEQ Reprezantarea grafica a unui BOD .................................................................... 17

Figura 5 Diagramă de activitate ............................................................................................... 25

Figura 6 Principalele construcţii într-o diagramă de activitate ................................................ 25

Figura 7 Diagrama unui proces de colaborare de afaceri prin specificaţia BPMN .................. 32

Figura 8 Tipuri de markere care pot fi adăugate la evenimente de bază BPMN ..................... 33

Figura 9 Un exemplu de specificaţie BPMN ........................................................................... 34

Figura 10 Interfaţa comportamentală pentru o cerere .............................................................. 39

Figura 11 Interfaţa comportamentală pentru o comandă (o poziţie dintr-o comanda) ............. 40

Figura 12 O alternativă pentru interfaţa prezentată în Figura 11 ............................................. 41

Figura 13 Nivelele WS-CDL .................................................................................................... 42

Figura 14 Elementele şi structura WS_CDL ............................................................................ 43

Figura 15 Activitaţi în WS-CDL .............................................................................................. 44

Figura 16 Exemplu de interacţiune în WS-CDL ...................................................................... 45

Figura 17 Exemplu de tip canal în WS-CDL ........................................................................... 46

Figura 18 Coregrafia unui model de proces ............................................................................. 48

Figura 19 Procesul de onorare a unei comenzi din perspectiva coregrafiei ............................. 48

Figura 20 Exemplu de colaborare RosettaNet .......................................................................... 50

Figura 21 Activităţi WSBPEL.................................................................................................. 56

Figura 22 WfMC Workflow Reference Model ........................................................................ 60

Figura 23 Structura CPP şi a specificaţiei procesului în ebXML Registry .............................. 68

Figura 24 Vedere generală asupra Collaboration-Protocol Profiles (CPP) .............................. 70

Figura 25 Vedere generală Collaboration-Protocol Agreements (CPA) .................................. 71

Figura 26 Business Transations cu doi inferiori ....................................................................... 81

Figura 27 Tipuri de resurse ale unui serviciu web asincron şi metodele utilizate .................101


7

1 Organizaţii şi structuri de standardizare

Cele mai multe standarde cu privire la managementul proceselor de bussines au fost

introduse de către principalele consorţii industriale, sau de către principalele instituţii de

standardizare aşa cum se poate vedea în figura următoare. Acest capitol va prezenta

principalele tipuri de standarde şi relaţiile dintre ele.

Process

Modelling

Process

Choreography

Process

Orchestration

Workflow

Adminstration

Workflow

Extensions

Information

Models

Service

Descriptions

Communication

s

UMM UML MDA /

BPDMBPMN

BPSS WS-CDLWSBPEL

(abstract)WSCI WSCL

OASIS

ebXMLOMG BPMI W3C WfMC

WSBPEL

(executable)XPDLBPMLebXML CPPA

BPQL WfXML

UBL

BPXL

WSDL

SOAP

Standards

Bodies

Activities

ASAP

BTP

BPSM

OAGISRosettaNet

PIP

OAGi RosettaNet

Figura 1 Tipuri de standarde şi relaţiile dintre ele

1.1 OASIS

OASIS (Organisations for the Advancement of Structured Information Standards) este o

organizatie non-profit, un consorţiu global care conduce şi gestionează modalitatea de

dezvoltare, convergenţa şi adoptarea stanadardelor de e-bussines. OASIS produce standarde

pentru standarde pentru securitate, servicii WEB, conformitatea documentelor XML,

tranzacţii de business, publicarea documentelor electronice şi interoperabilitate. OASIS a

fost fondată în 1993 sub numele de SGML Open ca un consorţiu de utilizatori care

intenţionau dezvoltarea unui ghid de lucru pentru definirea interoperabilităţii pentru


8

produse care suportă standard Generalized Markup Language (SGML). OASIS şi-a

schimbat numele în anul 1998 pentru a reflecta scopul muncii sale tehnice. La acest

moment OASIS are mai mult de 5000 de participanţi reprezentând peste 600 de organizaţii

şi membrii individuali din 100 de ţări.

1.1.1 Standarde suportate

Mai multe standarde legate de Business Process Management Systems (BPMS) ca

BPEL4WS sau BPMI s BPML au fost propuse la OASIS să devină fundamentul unei limbaj

standard de bussines process execution – Web Service Business Execution Language

(WSBPEL), care a fost finalizat de către comitetul tehnic OASIS WSBPEL în 2006. Un

proiect al comitetului WSBPEL versiunea 2.0 a fost finalizat în 21 decembrie 2005.

În noiembrie 1999, UN / CEFACT şi OASIS au început să dezvolte iniţiativa ebXML-

ul (http://www.ebxml.org). Viziunea despre ebXML este de a crea o piaţă electronică unde

firmele se pot găsi unele pe altele, dându-şi acordul să devină parteneri comerciali şi de

conduită de afaceri. Toate operaţiunile sunt efectuate în mod automat prin schimbul de

documente XML. OASIS ebXML Buisness Process Specification Schema (BPSS) se bazează

pe concepte introduse de UN / CEFACT Modelarea Metodologiei (UMM). UMM este o

metodologie pentru definirea aspectului afacerii dintr-o colaborare B2B care este bazată pe

UML. BPSS poate fi considerată o reprezentare XML a unui subset de UMM.

Sub WSBPEL şi UMM următoarele standarde sunt considerate pentru acest proiect:

BPSS: OASIS ebXML Business Process Specification Schema pentru a descrie

automatizarea şi previziunea de schimbul de afaceri de colaborare utilizând XML.

CPPA: OASIS ebXML Profil Protocolul de Colaborare şi Agreement, descrie modul în

care parteneri de afaceri se angajeză în afaceri electronice colaborarand prin schimbul de

mesaje electronice.

BTP: OASIS Buisness Transaction Protocolul defineşte modul de a gestiona complexe

B2B de tranzacţii pe Internet.

ASAP OASIS Asynchronous Service Access Protocol este un protocol pentru a începe,

administra, şi monitoriză procese mari ruland.

1.2 Business Process Management Initiative (BPMI)

Business Process Management Initiative (BPMI.org - http://www.bpmi.org/) este o

corporaţie non-profit, care are scopul de a împuternici companii pentru a dezvolta şi opera

procesele de afaceri care deţin mai multe aplicaţii şi parteneri de afaceri pe Internet. Iniţiativa

de bază este de a promova şi dezvolta drepturi de autor bazate pe standardele XML deschise,

complete şi gratuite care ofera suppoort şi ―deschide‖ procesul de gestionare a afacerii în

industrie. BPMI.org abordează standardele existente, acolo unde este cazul, de lucru cu

standardele complementare, cum ar fi organismele de OMG, şi WfMC OASIS. În zonele în

care nu există standarde, BPMI.org se concentrează asupra standardelor de dezvoltare pentru

a sprijini întregul ciclu de viaţă al procesului de gestionare a afacerilor - de la proiectare, prin

detaşare, executare, întreţinere, şi optimizare.

În iunie 2005, Business Process Management Initiative (BPMI) şi Object Management

Group (OMG) a anunţat dorinţa de fuziune pentru procesul de gestionare a activităţilor de

afaceri. Combinările de activităţi vor fi efectuate în OMG Business Modeling şi Integration


9

Domain Task Force (BMI DTF). Ele sunt continuarea muncii BPMI şi OMG şi sunt axate pe

toate aspectele legate de procesul de management al afacerilor, inclusiv:

Livrare Busisness Process Definition Metamodel (BPDM)

Definitie de limbaj de afaceri, vocabular, precum şi reguli

Informaţii de Managementul Afacerilor (BIM)

Enterprise Application Integration (EAI)

Colaborare Business-to-Business (B2B)

Servicii Web de informaţii şi procese

Politicii de securitate şi de gestionare

Rafinament, de educaţie şi de promovare a principiilor, abordări şi tenets de Business

Process Management din cadrul mai larg de comunitatea de afaceri

BMI DTF va integra şi va refolosi sisteme complementare de integrare şi servicii Web,

cum ar fi standardele WS-BPEL de la OASIS, WSDL, şi XML Schema de la W3C.


BPMI.org a finalizat specificaţiile Business Process Modeling Language (BPML) în

2002 şi ale lui BPMN în 2004. O caracteristică fundamentala, esenţiala şi distinctivă a BPMI

standard este că acestea au fost dezvoltate cu o fundaţie matematica solidă. A fost folosită

ramura de calcul Pi a proceselor de calcul. Aceasta este o metoda de calcul formal care

formează fundamentul pentru procesele dinamice şi mobile. Aceasta înseamnă că procesele

de afaceri proiectate folosind standardele BPMN pot fi manipulate direct şi limba poate fi

creeată şi făcuta disponibilă pentru executare imediat.

Figura 2 BPMI.org - stiva de standarde BPM


10

BPML a fost lansat de către BPMI în noiembrie 2002. După cum este prezentat în

Figura 2 din 2004, BPMI.org a oprit suportul pentru acest standard şi a favorizat BPEL.

BPML a fost proiectat ca un Pi-de calcule pe bază standard de descriere a unui proces de

afaceri.

“Specificaţiile BPML oferă un model abstract pentru procesele de afaceri şi sprijinirea

entităţilor. BPML defineşte un model formal pentru a exprima abstract, procesele executabile

care detin toate aspectele legate de întreprindere procese de afaceri, inclusiv activităţi de

complexitate diferita, şi de tranzacţiile lor de compensare, de administrare a datelor,

concurenta, excepţii de manipulare şi operaţionale semantica. BPML oferă, de asemenea, o

gramatica, sub formă de o schemă XML pentru a permite persistenţa şi schimbul reciproc de

definiţii dealungul sistemelor eterogene instrumente de modelare. "[BPML]

BPMN a fost lansat ca un proiect de lucru de către BPMI.org în august 2003 şi ca o

specificaţie finală în mai 2004. BPMN este în prezent pe cale de a deveni un standard al

OMG. Termenul limită pentru "Adopted Final Specification" a fost pe 6 februarie 2006.

În cea de-a doua fază a activităţii BPMI, au fost planificate să se dezvolte standarde

viitoare:

BPSM: Busisness Process Semantic Model a fost dezvoltat pentru a defini un cadru

pentru definirea formală a Semanticii pentru procesele de afaceri.

BPXL: Busisness Process eXtension Layer este o extensie a BPEL care acoperă, de

exemplu, tranzacţii, reguli de afaceri, de management .

BPQL: Business Process Query Language se propune a fi un standard de limbaj de

interogare pentru procesele de afaceri, bazate pe definiţiile WSDL. BPQL a fost

proiectat pentru a fi o interfaţa de management la un proces de gestionare a

infrastructurii de afaceri, care include o facilitate a procesului de execuţie şi de

facilitatea procesului de implementare. Interfata BPQL ar trebui să permită analize de

afaceri şi a controla executarea de procese gestionate de instanţe în procesul de server.

Interfaţa este bazată pe Simple Object Access Protocol (SOAP).

Dezvoltarea acestor standarde a fost oprită, după fuziunea BPMI şi OMG.

1.3 Object Management Group (OMG)

Object Management Group (OMG - http://www.omg.org) este o alianta deschisa, non-

profit, un consorţiu care produce şi menţine industria software, specificaţii pentru aplicaţii de

intreprindere interoperabile. Alianţa include fiecare mare companie din industria software şi

alte sute de companii mai mici.

Cele mai importante specificatii sunt multi-platforma - Model Driven Architecture

(MDA). Ea se bazează pe specificaţiile de modelare Meta Object Facility (MF), de UML,

XMI, şi de Common Warehouse Metamodel (CWM). PlatformaOMG intermediara este

CORBA, care include Interface Definition Language IDL OMG şi protocolul IIOP. Object

Management Architecture (OMA) defineşte standardul de servicii, care vor reporta în MDA

rezultatele muncii în scurt timp. OMG Task Forces standardizează facilităţi din domeniul

industrial precum servicii de îngrijire medicală, de fabricaţie, de telecomunicaţii, şi altele.


11

Misiunea OMG (BMI DTF http://bmi.omg.org) este de a dezvolta modele de

specificaţii pentru suport integrat de gestionare a unei întreprinderi. Aceste specificaţii vor

promova inter-şi intra - intreprinderii servicii de integrare şi colaborare de oameni, sisteme,

procese şi de informaţii din cadrul întreprinderii, inclusiv clienţii şi partenerii de afaceri.

Principalele domenii de interes sunt:

Planificarea de afaceri şi motivaţia de modelare

Business Process Management

Reguli de afaceri

Business Modeling

Limbaj şi vocabular de business

BMI DTF este axat pe semantica de bussines şi recunoaşte că este nevoie să se

coordononeze cu alte organisme de standardizare. Business Process Definition Metamodel

(BPDM) este în prezent în curs de dezvoltare în BMI DTF. Termenul limită pentru depunerea

finală a fost aprilie 2006.


BMI DTF continuă BPMI.org şi OMG şi este concentrata pe toate aspectele legate de

Business Process Management. BPMI.org-i utilizate pe scară largă standard pentru modelare

de afaceri, Buisness Proces Modeling Notation (BPMN), a început perioada de comentariu

solicitate de către OMG-rapid urmări "Cerere pentru comentarii" (RFC) adoptarea de proces,

în septembrie 2005, aşa cum a făcut-Business Motivation Model (BMM) a contribuit prin

Regulamentul Grupului de afaceri. Separat, un nou standard de definind Semantica de afaceri

Vocabular de afaceri şi de Reguli (SVBR) a completat evaluarea membru şi a început o serie

de voturi care să conducă la adoptarea formală.

BMM: Business Motivation Model este un standard, care oferă un metamodel pentru

modele de enterprise- specificatii . BMM conţine:

o Un set de construit concepte care definesc elementele unor planuri de afaceri.

Ele sunt asociate într-o structură care este metodologic neutra; va sprijini o

gamă largă de abordări pentru crearea şi menţinerea unui BMM pentru o

întreprindere, şi este deosebit de puternic în sprijinirea proceselor de afaceri ce

sunt conduse de schimbare.

o Roluri în structura pentru trei concepte esenţiale: Bussines Process, Bussines

Rule şi Organization Unit. Ei participa în asociaţii cu BMM, dar şi în alte

asociaţii în afara domeniului său de aplicare - cum este cazul în SVBR. Ele

sunt considerate ca referiri la elementele care vor fi definite şi menţinute în

afara unei întreprinderi de BMM.

SVBR: Un vocabular de afaceri conţine toţi termenii de specialitate şi definiţii de

concepte pe care o anumită organizaţie data sau comunitate le utilizează în scris şi

vorbit în cursul procesului de bussines. Semantica Vocabularului de afaceri şi de

Reguli (SVBR) include doua vocabulare de specialitate:

o SBVR "Vocabularul pentru descrierea vocabularelor de afaceri" se ocupa cu

tot felul de termeni şi sensuri. El se bazează pe standardele ISO terminologice.

o SBVR "Vocabular pentru Descrierea Regulilor de afaceri" se ocupa cu caietul

de sarcini, în sensul de afaceri se bazează pe reguli şi pe "Vocabular pentru

Descrierea vocabularului de afaceri".


12

Cele două vocabulare au fost separate, astfel încât "Vocabularul pentru descrierea

vocabularelor de afaceri" ar putea fi utilizat independent - de exemplu, ca bază pentru

vocabularul pentru procese de afaceri sau de organizare de roluri.

Standardul conţine metamodel SVBR, un model de MOF creat prin combinaţie de

SVBR Logical Formulation şi Semantica Vocabularului, "Vocabular pentru Descrierea

vocabularului de afaceri" şi ghidat de la "Vocabulary-to-MOF/XMI Mapare Set de Reguli ".

1.4 World Wide Web Consortium (W3C)

World Wide Web Consortium (W3C - http://www.w3.org) este un consorţiu

internaţional unde organizaţiile membru, un personal full-time, precum şi publicul lucrează

împreună pentru a dezvolta standardele web. Misiunea lui W3C este de a conduce World

Wide Web la întregul său potenţial, prin dezvoltarea de protocoale şi linii directoare care să

asigure creşterea pe termen lung pentru Web.

În primul rand, prin misiunea sa, W3C, urmăreşte crearea de standarde şi linii directoare

web. Din 1994, W3C a publicat mai mult de nouăzeci astfel de standarde, denumite

Recomandări W3C. W3C angajează de asemenea, în educaţie şi deschidere, dezvoltă aplicaţii

software, şi de asemenea un forum deschis pentru discutii despre Web. Pentru ca Web-ul să

ajunga la întregul său potenţial, cele mai fundamentale tehnologii web trebuie să fie

compatibile una cu cealaltă şi să permită oricarui hardware şi software acessul la Web pentru

a lucra împreună. W3C se referă la acest obiectiv prin termenul de ―interoperabilitate Web".

Prin publicarea standardelor deschise pentru limbaje Web şi protocoale, W3C caută să evite

fragmentarea pieţei.


W3C a publicat standarde diferite cu privire la serviciile web şi arhitecturi workflow

de afaceri. De interes special, sunt:

WS-CDL: Web Service Coregraphy Definition Language WS-CDL este un limbaj

bazat pe XML, care descrie colaborări peer-to-peer de participanţi, prin definirea,

dintr-un punct de vedere global, a unui comportament observabil şi complementar

comun. Specificaţiile de servicii web oferă o punte de comunicare între medii

eterogene computaţionale folosite pentru a dezvolta aplicaţii gazdă. WS-CDL permite

specificarea de termen lung, a colaborării peer-to-peer între serviciile participante.

WSDL: Web Service Description Language WSDL Version 2.0 (WSDL 2.0) oferă un

model şi un format XML pentru descrierea serviciilor web. WSDL 2.0 permite

separarea descrierii, a funcţionalitaţilor abstracte oferită de un serviciu de la detalii

concrete, a unui serviciu de descriere, cum ar fi "cum" şi "unde", care este oferit de

funcţionalitate. Recomandarea W3C candidată a fost publicată în ianuarie 2006.

SOAP: Simple Object Access Protocol SOAP Version 1.2 prevede definiţia XML pe

bază de informaţii care pot fi folosite pentru schimbul de informaţii structurate şi scris

într-o între colegii descentralizate, distribuite de mediu. SOAP PART1 explică faptul

că un mesaj SOAP, este formal, specificat ca un Infoset XML, care oferă o descriere

abstract, a conţinutul său. SOAP este în esenţă stateless (lipsit de stare), cu un singur

mod de schimb mesaj, dar aplicatiile pot crea mai multe aplicatii complexe de modele

de interacţiune (de exemplu: cerere / răspuns, cererea / răspunsuri multiple, etc), prin

combinarea unei astfel de mod de schimburi cu facilităţile oferite de o bază de

protocol şi / sau aplicarea unor informaţii specifice. SOAP este silenţios pe semantică

de orice cerere de date specifice , pe probleme cum ar fi de dirijare a mesajelor SOAP,


13

sigură de transfer de date, firewall, traversal, etc Cu toate acestea, SOAP furnizează

cadre de aplicare specifice cu informaţii care pot fi transmise într-o manieră

extensibilă.

1.5 Workflow Management Coalition (WfMC)

Workflow Management Coalition (WfMC - http://www.wfmc.org), a fost înfiinţată în

august 1993, este o organizaţie non-profit de furnizori sisteme workflow, utilizatori, analişti

şi grupuri de cercetare. Misiunea coaliţiei este de a promova dezvoltarea şi utilizarea fluxului

de lucru prin stabilirea de standarde pentru software, a unei terminologii, interoperabilitate şi

conectivitate între produsele de lucru. Format din peste 300 de membri în întreaga lume,

WfMC este principalul organism de standarde pentru această semnificativă piaţă de software.

Principalele obiective WfMC sunt:

De a creşte valoarea clienţilor prin utilizarea tehnologiilor workflow.

Reducerea riscului produselor workflow.

Creşterea pieţei de produse workflow.

1.5.1 Supported StandardsStandarde suportate

Munca initiala a WfMC s-a axat pe publicarea Modelului de Referinţă WFMC şi a unui

glosar, definirea unei arhitecturi comune şi a unei terminologii pentru industrie. O

importantă etapă a fost realizata cu prima publicare a specificaţiilor WorkFlow API

(WAPI), care acoperă WorkFlow Client Application Interface, şi de WorkFlow

Interoperability. Specificaţia Audit Data a fost adăugată în 1997, fiind urmată de specificaţia

Process Definition Import / Export.

O nouă versiune a WAPI acoperă Application Invocation API, completând livrabilele

WfMC legate de cele cinci funcţii de interfaţă de referinţă definite în model. Munca din

etapa urmatoare s-a axat pe completarea modelului comun de obiecte cu sisteme de legare

de obiecte ca IDL şi OLE precum şi adăugarea de extensii de securitate şi modele de

interopearbilitate.

WfMC a validat utilizarea specificatiilor proprii prin implementarile de prototipuri şi

demonstraţiile directe. În ceea ce priveşte standardele majore WfMC acestea sunt:

XPDL: XML Process Definition Language. WfMC a identificat cinci interfeţe

funcţionale la un proces sau serviciu workflow, ca parte a programului său de

standardizare. XPDL face parte din documentatia referitoare la "Interfaţa unu" -

sprijinirea Process Definition Import şi Export. Aceasta include o interfaţă comună

pentru un metamodel care descrie procesul de definiţie (utilizăm XPDL) de

companie şi de asemenea, o schemă XML pentru a defini procesul de succesiune.

XPDL versiunea 2.0 este compatibilă cu versiunea 1.0, şi este destinat să fie folosit

ca un format de fişier pentru BPMN. Scopul original al XPDL este menţinut şi

consolidat prin cea de-a doua versiune. XPDL şi BPMN abordează aceeaşi problemă

de modelare din perspective diferite. XPDL oferă un format de fişier XML care pot

fi folosite pentru a alterna între procesul de modele de instrumente. BPMN oferă o

grafică de notaţie complexă de procese de afaceri umană, pentru a facilita

comunicarea între utilizatorii de afaceri şi tehnice utilizatori. Există un număr de

elemente care sunt prezente în BPMN versiunea 1.0, care nu au fost prezente în

XPDL versiunea 1.0. Acestea au fost încorporate în versiunea 2.0 a XPDL.


14

Wf-XML: WF-XML pentru servicii Web este un protocol care pot fi folosite pentru

a controla un proces motor de la distanţă, cu scopul de a trimite sau a recuperat

procesul de definiţii. Procesul definiţii, care sunt descrise de limbaje ca WSBPEL

sau XPDL sunt de aşteptat să fie instalat intr-un proces de executie pentru motor.

Limbajul natural în sine nu defineşte modul de instalare a defini în motor. În

schimb, acesta este rolul WF-XML.

Conceptul central este că acolo va fi procesul de instrumente de design care se

specializa în permite unui utilizator de a edita un proces de definiţie, care pot produce în

consum şi un format standard. Vor fi motoarele de proces, care o pot executa. Procesul de

design instrument utilizează XML pentru WF prima lista de procesul de definiţii, care sunt

încărcate în procesul de motor, şi apoi de a primii un anumit proces de definiţie. WF-XML

prevede, de asemenea, un mod de a defini procesul de actualizare, precum şi de a instala noul

proces de definiţii.

1.6 RosettaNet

RosettaNet (http://www.rosettanet.org/), o subsidiară a lui ―GSI US‖ (http://www.uc-

council.org/gs1us.html), este o organizaţie non profit dedicata dezvoltarii colaborative şi a

dislocării rapide de proceduri standard de e-business care aliniază procesele inauntrul

retelelor globale de comert.

Standardele şi serviciile RosettaNet furnizează un limbaj comun pentru tranzactiile e-

business şi fundaţia pentru integrarea de procese critice între partenerii din lanţul global de

furnizori. Companiile care folosesc standardele RosetttaNet beneficiază de imbunătăţiri în

comunicaţiile de tip e-business cu partenerii de comerţ, îmbunătăţiri la mangemetnul

capabilităţilor ciclului de viaţă al produselor furnizate şi o satisfacţie mai mare a clientului.

Din 1998 RosettaNet a fost folosită şi aprobată de mai mult de 500 de companii din jurul

lumii, companii cu activităţi din domeniile IT (Tehnologia Informatiei), Componente

Electronice, Semiconductori şi Furnizori de Solutii, companii care lucrează impreună ca să

creeze, să implementeze şi să promoveze standarde de e-business liber. RosettaNet este

numită după Rosetta Stone, nume care ―cioplit‖ în trei limbi a dus la intelegerea hieroglifelor.

Standardele RosettaStone furnizează cadre pentru afaceri care dau voie companiilor

individuale să işi imbunătăţească interoperabilitata proceselor de afaceri de-a lungul lanţului

global de furnizori.Aceste standarde transpun soluţii proprietare în piaţă. De fapt RosettaNet

imprumută protocoale, ghiduri şi specificaţii pentru a crea standarde rapide pentru

comunicaţii eficiente în afaceri pe platforme,aplicaţii şi reţele multiple.

Standardele RosettaNet sunt libere şi globale. Ele ne invaţă cum să implementăm

processe colaborative de tip business între partenerii din lanţul de furnizare, folosind aplicaţii

prin reţea. Aceste specificaţii includ definiţiile procedurilor de afaceri şi elemente tehnice

pentru interoperabilitate şi comunicaţie.

Interfaţa Partener pentru Procese RosettaNet (PIPs) sunt dialoguri bazate pe XML şi

speciliazate în transfer de tip system-to-system care definesc procedurile de afaceri

dintre partenerii de comert.PIP-ul standardizează automatizarea procedurilor publice

de afaceri pin standardizare documentelor şi a secventei de trimitere a acestor

documente, şi a atributelor fizice al mesajului care defineste calitatea serviciului.Astfel

fiecare specificare de PIP include un document de tip business cu vocabularul său şi o

procedura de afaceri cu coregrafia mesajului din dialog.

http://www.rosettanet.org/

http://www.uc-council.org/gs1us.html

http://www.uc-council.org/gs1us.html


15

De asemenea RosettaNet defineste sistemul de mesagerie folosit pentru trimiterea şi

primirea acelor documente.Cadrul de Implementare RosettaNet (RNIF) furnizează

protocoale de schimb pentru o implementare rapidă şi eficientă a standardelor

RosettaNet.RNIF-ul specifică schimbul de informaţii dintre servere partenere care

folosesc XML ,acoperind transportul,dirijarea şi impachetarea; securitatea semnalelor

şi inţelegerea partenerilor de comerţ.

În legătură cu PIP-ul website-ul RosettaNet declară: “PIP-urile sunt organizate în sapte

grupări principale de proceduri de afaceri care reprezintă baza retelei de comert. Fiecare

grupare este impărţită în segmente – proceduri de intreprindere care implică mai multe

tipuri de parteneri de comerţ. Inăuntrul fiecarui segment sunt PIP-uri individuale.

Gruparile PIP sunt:

Gruparea 1: Revizuirea Produselor şi a Serviciilor Partenere. Permite colecţionarea

de informaţii, intreţinerea şi distribuţia pentru dezvoltare a profilelor partenerilor de

comert şi a subscrierilor produs-informaţie.

Gruparea 2: Informaţii despre Produs. Permite distribuţia şi reînnoirea periodică a

produsului şi a informaţiilor detaliate de design, incluzând notiţele cu schimbările

care au fost făcute asupra produselor şi detaliile tehnice despre produs.

Gruparea 3: Suport pentru Managementul de Comandă. Oferă suport pentru aria

afacerilor de tip management de comandă, incepând de la preţ – livrare şi trecand

prin initierea comenzii de cumparare, reportare statsului şi managementul

acestora.De asemenea facturarea comenzii,plata şi notificarea discrepantelor sunt

administrate prin aceasta grupare de proceduri.

Gruparea 4: Administrarea inventarului. Ingaduie managementul inventarului

incluzand colaborarea, umplerea acestuia, protejarea preturilor, reportarea şi

alocarea produselor constranse.

Gruparea 5: Mangementul Informatiilor de Marketing. Permite comunicarea

informaţiilor de marketing, incluzand planuri de campanii, informaţii de varf şi

inregistrarea designului.

Gruparea 6: Suportul de Servicii. Furnizează suport tehnic după vanzare, garantia

servicilor şi competente de management al bunurilor.

Guprarea 7: Fabricarea. Permite schimbul de design-uri, configuratii, proceduri,

calitaţi şi alte informaţii de fabricatie care să suporte acest 'mediu virtual de

fabricare'.”

Aproximativ 125 de specificatii de PIP pot fi preluate din directorul PIP. Aceste

specificatii sunt numite ―validate‖ dacă au fost aplicate cu succes între parteneri de comert. În

momentul de fata aproximativ 50 de specificatii au acest status.

1.7 Open Applications Group (OAGi)

Open Applications Group, Inc. (OAGi - http://www.openapplications.org) este un grup

non-profit cu standarde libere XML bazate pe proceduri pentru integrarile de tip A2A şi B2B.

OAGi a fost format la sfarsitul lui 1994 ca prima organizaţie post-EDI (Electronic Data

Interchange) care se concentra asupra imbunatatirii starii de integrare a aplicatiilor. Abordarea

neutra fata de tehnologie a lui OAGi fata de construirea standardului ―Open Applications

Group Integration Sepcification‖ (OAGIS) se asigură că atât clienţii de vârf cât şi furnizorii


16

de solutii folosesc un standard XML comun care poate fi dispus folosind serviciul web

ebXML sau un cadru de lucru la alegere. Standardul OAGIS XML este complet gratuit.

OAGIS este un limbaj de afaceri XML care permite crearea unui model informatic

canonic între diferite afaceri sau organizatii administrative. Modelul canonic furnizează un

limbaj de afaceri comun pe care organizatiile ce îl pot folosi ca să rezolve problema de

integrare dintre n organizaţii eterogene care vorbesc limbaje specifice. Soluţia OAGIS XML

este arhitecturală, pentru a suporta integrarea de care este nevoie atat între intreprinderi cat şi

inauntrul intreprinderilor. În opt ani a fost alcatuit un set de definitii procedurale şi definiţii de

mesaje XML (Figura 3).

Figura 3 SEQ, limbajul canonic OAGIS

Versiunea curenta (9.0) include:

434 Documente Obiect Business (BOD)

77 Substantive

BOD-uri noi pentru Managementul Relatiilor cu Clientii, Logistica, şi Sarbanes-

Oxley, printre altele

Adoptarea a UN/CEFACT/ISO-CCTS 2.01

Adoptarea şi includerea a Componentelor de Bază aprobate şi armonizate din

UN/CEFACT TBG 17

Imbunatatiri pentru a furniza un suport mai bun al serviciilor web

BOD-urile sunt definite în prezent ca o schema XML; un model UML echivalent va

aparea în curand.

Conceptele OAGi se bazează pe modele obiect de afaceri virtuale, bazat pe continut

care permit aplicatiilor pentru intreprinderi să construiasca un obiect virtual care să se muleze

în jurul lor prin folosirea API-urilor compatibile cu OAGi. Aceasta interoperabilitate este

realizata cu avantaje orientate pe obiecte fără necesitatea de a implementa o aplicatie software

într-o tehnologie orientata pe obiecte specifica. Pentru a permite comunicarea între

componentele software-urilor de afaceri, evenimentele sunt comunicate printr - o coloana

vertebrala integrata folosind interfete obiect virtuale BOD-urilor compatibile cu OAGi.

Coloana vertebrala integrata suporta paradigme de comunicare cum ar fi publica şi aboneaza-

te, cere şi raspunde, şi mecanisme de transport, unelte de mapare de date, ghidare pentru


17

integrare şi capabilitatii de logare. Documentatiea pentru OAGIS ,versiunea 9, explica un

BOD şi termenele Substantiv şi Verb după cum urmeaza:

―BOD-ul este o arhitectură orizontală de mesagerie.BOD-urile sunt mesajele de afaceri

sau documentele de afaceri care sunt schimbate între aplicatiile software sau componentele;

între companii, peste lanturi de furnizare, şi între lanturi de furnizare.

În scopul de a face acest lucru BOD-ul trebuie să poată să informeze sistemul primitor

despre tipul de mesaj la care trebuie să se astepte. De multe ori există o interacţiune dublă

între cel care trimite şi cel care primeşte, din acest motive BOD-ul trebuie să fi apt să

comunice statusul şi condiţiile de eroare.Este de asemenea necesar să furnizeze pentru

multiple actiuni asupra unui obiect comun de afaceri(Substantiv).Din acest motiv BOD-urile

au fost proiectate să se foloseasca de Substantivele comune care dacă primesc o actiune

(Verb) pot fi aplicate.

Arhitectura de mesaj BOD este independenta de mecanismul de comunicare.Poate fi

folosita cu protocoale de transport simple cum ar fi HTTP şi SMTP dar mai poate fi folosit în

protocoale de transport mai complexe cum ar fi SOAP,ebXML Transport şi Ghidare, sau

orice alte Sistem de Integrare al Intreprinderilor de Afaceri.”

Figura 4 SEQ Reprezantarea grafica a unui BOD

Părţile unui BOD sunt definite după cum urmează (Figura 4):

Cel mai de dinafară strat al BOD-ului identifică Verbele, Substantivele, reviziile şi

mediul de rulare

Application Area comunica informaţia în asa fel incat să poata fi folosita de

infrastructura pentru a comunica mesajele


18

Data area contine sarcina utila specifica afacerii sau data care este comunicata de

BOD

Verbs(verbe) identifica actiunea care este realizata de un substantiv specific al BOD-

ului

Nouns(substantive) identifica data specifica a afacerii care este comunicata, de

exemplu Ordinul de Cumparare, Ordinul de Vanzare, Ruta, Transportul. Ele contin

componentele care sunt descrise mai jos.Substantivele sunt extensibile ca să poata

suporta nevoile unor industrii specifice.

Components sunt blocuri extensibile din care este construit un substantiv, de exemplu

Header-ul Ordinului de Cumparare, Linia Ordinului de Cumparare, Adresa. Ele contin

compusi şi campuri, care sunt descrise mai jos.Componentele sunt extensibile.

Compunds sunt cele mai de bază blocuri de constructie care sunt folosite de toate

BOD-urile, de exemplu Cantitatea. Ele sunt extensibile prin folosire contextuală dar

nu şi cu campuri în plus, de exemplu OrderedQuantity, ShippedQuantity,

BackOrderedQuantity.

Fields sunt cele mai de jos elemente definite în OAGIS.Fields sunt elemente

fundamentale care sunt folosite pentra a crea Compounds şi Components,de exemplu

Description,Name.


19

2 Limbaje de modelare şi notaţii grafice

Acest capitol prezintă metodologia de modelare şi standardele de notaţie grafică

selectate pentru analiză şi evaluare. Aceste standarde sunt cele considerate a fi relevante

pentru în analiza tehnologii workflow de afaceri. Cele patru standarde din acest capitol

prezintă diferite aspecte şi abordări şi, care, astfel, nu sunt comparabile cu altele, spre

deosebire de cazul standardele pentru limbajele de coregrafia şi orchestraţie. Fiecare standard

de acolo a fost analizat în funcţie de contextul său special şi obiectivele într-un mod

independent de evaluat şi apoi pentru a relevanţei sale SCIPA.

UMM este o metodologie de modelare bazată pe UML şi dezvoltată pentru a modela

procese de afaceri pentru utilizarea în relaţiile de e-afaceri. Este de interes special deoarece

este un standard ONU/ CEFACT dezvoltat pentru utilizare în schimburi electronice de date şi

este sprijinit de mai multe grupuri industriale. UML este un standard de modelare care se

aplică în general în dezvoltarea de software. Este evaluat aici pentru aplicarea sa în context

SCIPA. În continuare se fac referinţe, de asemenea, la MDA, abordarea archtecturala condusa

de model (Model Driven Architecture) propusă de OMG, care prevede un mijloc de a adopta

modele de dezvoltare pe tot parcursul ciclului de viaţă, de la abstract la o tehnologie specifică.

BPDM este dezvoltat de către OMG ca un metamodel UML pentru definirea de procese de

afaceri, independent de orice tehnologie specifică. BPMN este o notaţie grafică pentru

fluxurile de proces de afaceri care se bazează pe diagrame tradiţional cunoscute analiştilor de

afaceri. Deoarece poate fi mapat la BPEL, poate oferi o punte de legătură între viziunea

bazată pe afaceri şi cea tehnică, şi, astfel, ocupă o poziţie strategică în stiva BPM.

2.1 Unified Modeling Language (UML)

UML este un standard relativ deschis, controlat de Object Management Group

(OMG), un consorţiu non-profit, constituit pentru produce şi menţine specificaţii în industria

calculatoarelor pentru aplicaţii de întreprindere interoperabile. Specificatia OMG caiet de

sarcini prevede:

"The Unified Modeling Language (UML) este un limbaj grafic pentru vizualizarea,

specificarea, construirea, şi documentare comportarii unui sistem software-intensiv. UML

oferă o modalitate standard de a scrie un blueprint al sistemului, inclusiv conceptual lucruri,

cum ar fi procesele de afaceri şi funcţiile sistemului, precum şi lucruri concrete, cum ar fi

declaraţiile limbaj de programare, scheme de baze de date, software şi de componente

refolosibile. "[ISO/IEC19501]

Dezvoltarea Unified Modeling Language (UML) a început în 1994 de către Rational

Software Corporation. În 1995, Object Management Group (OMG) a emis o cerere de ofertă

(RFP) pentru el. Mai târziu, Rational a stabilit consorţiul Partenerilor UML incluzand mai

multe companii care să lucreze pentru definirea UML 1.0. Consorţiul a inclus Rational

Software, Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON

Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Texas Instruments, şi Unisys.

Acest consorţiu a prezentat OMGului, în ianuarie 1997, un prim răspuns la cererea de ofertă.

A fuzionat apoi şi actualizat prin propunerile de la IBM, ObjecTime, Platinum Technologies,

Ptech, Taskon, Reich Technologies, şi Softeam, care au aderat la UML Parteneri. La sfârsitul

lui 1997, după mai multe revizuiri şi comentarii publice, UML 1.1 a fost aprobat de către

OMG.


20

În ultimii ani, UML a fost revizuit şi a crescut. Au fost publicate mai multe versiuni

(majore au fost cele UML 1.3 şi 1.5), care au adaugat noi capabilităţi. UML a devenit foarte

popular şi multe companii din industrie au contribuit la standard.

UML 1.4.2 este acceptat ca specificaţie ISO "ISO / IEC 19501:2005 Tehnologia

informaţiei – Procesare distribuita deschisă - Unified Modeling Language (UML) Versiunea

1.4.2".

Versiunea curentă a standardului este UML 2.0, care a înlocuit UML 1.5. UML 2.0 este

un caiet de sarcini mari şi constă din patru părţi:

UML 2.0 Superstructure [UML20_SS]. Aceasta defineşte şase diagrame de structura, trei

de comportament, patru de interacţiune, şi elementele pe care le cuprinde (parte a limbii

ce este întâlnita în uneltele compatibile cu UML 2.0).

UML 2.0 Infrastructure [UML20_I]. Infrastructura defineşte clase de bază care formează

temelie nu numai pentru UML 2.0 suprastructură, dar, de asemenea, pentru MOF 2.0.

UML 2.0 Object Constraint Language (OCL) [UML20_OCL]. Aceasta permite stabilirea

de pre-şi post-condiţii, invarianti, şi alte condiţii.

UML 2.0 Diagram Interchange [UML20_DI]. Această specificaţie extinde metamodelul

UML cu un pachet suplimentar pentru informaţii orientate grafic, care să permită un

schimb de modele pentru a fi depozitate sau / şi apoi preluate şi afişate ca au fost iniţial.

Adoptarea UML 2.0 Suprastructura este completă [UML21_SS]; adoptarea de celelalte

trei părţi ale UML 2.0 este aproape completă.

2.1.1 Criterii de piaţă

Unified Modeling Language este în prezent standardul de-facto pentru construirea de

software orientat pe obiecte. UML 1.4.2 a devenit un standard ISO. Multe companii, inclusiv

membrii ai OMG, ofera training în UML. OMG a organizat propriul sau program de

certificare profesionala în UML

Există mai multe instrumente de modelare UML pe piaţă, inclusiv cele mai recente

instrumente de sprijin al versiunii 2.0. Unele dintre ele sunt instrumente cu sursă deschisă, dar

în cele mai bune instrumente de UML sunt comerciale.

UML poate fi folosit pentru modelarea proceselor de afaceri. Cu toate acestea, este de

multe ori ca fiind prea "tehnic" pentru analiştii de afaceri şi se pare mai puţin popular decât de

modelare pentru afaceri BPMN.

2.1.2 Criterii tehnice

Principalele concepte utilizate

UML utilizează următoarele concepte, care pot fi grupate în patru mari părţi:

A) Concepte legate de modelare de structură:

actor. Specifică rolul jucat de către un utilizator sau de orice alt sistem care

interacţionează cu subiectul şi ofera un stimul sistemului. De exemplu, fără un client

(un actor) la un restaurant, procesul de impunere a produselor alimentare nu poate

începe.

atribut. Un atribut este o caracteristică abstracta a unei entitati.


21

clasa. O clasa descrie un set de obiecte care partajează aceleaşi specificaţii de

caracteristici, constrângeri, şi semantică.

componentă. O componentă reprezinta o parte modulara a unui sistem care

incapsulează conţinutul său şi a cărei manifestare este înlocuibila în mediu sau. O

componentă îşi defineşte comportament în termeni interfeţe oferite şi solicitate.

interfaţă. O interfaţă este un fel de clasificator care reprezintă o declaraţie de un set

coerent de caracteristici şi de obligaţiile publice. O interfaţă specifică un contract;

orice instanţă a unui clasificator care realizează interfaţa trebuie să-şi îndeplinească

contractul. Obligaţiile care pot fi asociate cu o interfaţă sunt sub formă de diverse

tipuri de constrângeri (cum ar fi pre-şi post-condiţiile) sau de specificaţiile de

protocol, care pot impune restricţii privind interacţiunile de comanda prin

intermediul interfeţei. Deoarece interfeţele sunt declaraţii, ele nu sunt instantiable.

În schimb, o specificatie de interfaţă este pusa în aplicare de către o instanţă a unui

clasificator instantiabil, ceea ce înseamnă că clasificatorul instantiabil prezintă o

interfaţă publica care se conformează specificaţiilor de interfaţă. Un anumit

clasificator poate implementa mai mult de o interfaţă şi o interfaţă care poate fi

implementata de un număr de diferite clasificatoarele.

obiect. Un obiect este un mcanism suportat de limbaj pentru a lega strans datele de

metodele care operează pe care date.

pachet. Un pachet este utilizat pentru a grupa elemente, şi oferă un spaţiu de nume

pentru elementele grupate. De obicei, un pachet grupează clase relationate sau de

clase cu funcţionalitate relationata.

B) Concepte legate de modelare de comportament:

activitate. O activitate este o specificatie a unui comportament parametrizat ca şi

coordonat de secvenţiere unitaţi subordonate ale căror elemente sunt acţiunile

individuale. Baza conceptuala a unei activitate a fost schimbata între versiunile 1.5

şi 2.0. În UML 2.0 o activitate nu mai este bazata pe o diagramă de stare; mai

degrabă aceasta se bazează pe un mecanism de coordonare de tip retea Petri

eveniment. Un eveniment este specificatia unor apariţii care pot declanşa potenţial

efecte de către un obiect.

mesaj. Un mesaj este un element într-un model care poate avea un nume care

defineşte o anumită fel de comunicare într-o interacţiune.

metodă. Metoda este o descriere de comportament care pune în aplicare

comportamentale facilitate. Pot exista cel mult o comportare pentru o pereche

particulara dintre un clasificator (în calitate de proprietar de comportament) şi o

caracteristică comportamentala (ca specificaţie de comportament).

operaţie. O operaţie este o trăsătură de comportament a unui clasificator care

specifică numele, tipul, parametrii, şi constrângeri pentru a invoca un comportament

asociat.

stare. O stare modelează o situaţie în care o anumita condiţie invarianta (de obicei

implicita) are loc. Invariantul poate reprezenta o situaţie statică, cum ar fi un obiect

care aşteapta să apara un eveniment extern. Cu toate acestea, poate, de asemenea,

modela condiţii dinamice, cum ar fi procesul de efectuare a unui comportament (de

exemplu modelul de element luat în considerare intră în stare cand comportament

începe şi-l lasă de îndată ce comportamentul este complet).

caz de utilizare. Un caz de utilizare este o specificatie a unui set de acţiuni efectuate

de către un sistem, care conduce la un rezultat vizibil, care este, de obicei, de

valoare pentru unul sau mai multe actori sau alte părţi interesate a sistemului.


22

C) Concepte legate de modelare de relatii:

agregare. O agregare este parte de relaţie. Agregarile sunt utilizate pentru a descrie

elementele care sunt constituite din componente mai mici. Relaţiile de agregare sunt

prezentate printr-o indicatie spre clasa ţintă sau părinte.

asociere. O asociere specifică o relaţie semantică care poate apărea între instanţe cu

tip. Ea are cel puţin două capete reprezentate de proprietăţi, fiecare dintre care este

conectat la tipul capătului. Mai multe capete ale asociaţiei poate avea acelaşi tip. O

instanta aunei asociaţie este numita link.

compoziţie. O compoziţie (compozit de agregare) este o formă de agregare mai

puternica. Este utilizat în cazul în care componentele pot fi incluse în maximum o

compoziţie la un moment dat, pentru că numai o singură componentă, la un moment

dat, poate avea responsabilitatea de viaţă pentru o altă componentă. Compoziţii sunt

relaţii tranzitive, asimetrice şi pot fi recursive.

dependenţă. O dependenţă este o relaţie care semnifică faptul că un singur sau un set

de elemente de model necesită alte elemente ale modelului pentru specificatie sau

implementare. Aceasta înseamnă că semantica completă a elementelor dependente

este dependenta semantic sau structural de definiţia elementului(elor) de la furnizor.

generalizare (sau moştenire). O generalizare este o relaţie taxonomitrica între un

clasificator general şi un clasificator specific. Fiecare instanţă a clasificatorului

specific este de asemenea o instanta indirectă a unui clasificator general. Astfel, un

clasificator specific moşteneşte caracteristicile clasificatorului general.

D) Concepte de suplimentare:

stereotip. Un stereotip defineşte modul în care o metaclasă existentă poate fi

prelungită, şi permite utilizarea terminologiei sau notaţiei specifice platformei sau

domeniului în loc de, sau în plus faţă de, cele utilizate pentru metaclasa extinsă.

multiplicitate. Multiplicitatea este o definiţie cuprinzătoare a unui interval de non-

negativ de intregi care începe cu o limită inferioară şi se încheie cu o limită (posibil

infinită) superioară, de exemplu, 1, 0 .. 1, 1 ..*. Un element al multiplicarii include

aceste informaţii pentru a specifica cardinalitatile permise pentru instanţierea

acestui element.

rol. Termenul de rol poate indica un rol de asociere sau un rol de colaborare, care

este un rol jucat de o instanţă a unei clase într-o colaborare.

Modelarea tipurilor de diagramă

UML 2.0 oferă o varietate de notatii de modelare puternice şi utile, şi fiecare dintre

aceste notatii vizează şi este accesibila şi inteligibila pentru o audienţă limitată. UML 2.0

suportă 13 viziuni (sau tipuri de diagrame de modelare) variinde de la diagrame de utilizare de

nivel înalt, care descriu interacţiunile şi relaţiile dintre actori (umani) şi funcţiile majore de

afaceri, la diagrame obiecte de nivel scăzut care capturează instanţe ale obiectelor de date

individuale, elemntele de date constituente şi valorile lor, precum şi relaţiile acestora cu alte

obiecte de date. Aceste diagrame pot fi clasificate ierarhic în trei categorii:

1) Diagrame de structură care definesc arhitectura statică a unui model:


23

Diagrama Clasa descrie tipurile de obiecte din sistem şi diferitele tipuri de relaţii

statice care sunt utilizate pentru a construi un model complet. Acesta diagrama este

cea mai des utilizata diagrama UML.

Diagrama Componenta este folosita pentru a arăta organizarea şi dependenţele

componentelor prin interfeţe bine definite.

Diagrame Obiect arată un set de obiecte şi relatiile dintre ele.

Diagrama de Structura Compusa arată detalii de interior, construcţie şi de relaţii,

descompunand ierarhic un obiect în structurile interne.

Diagrama de lansare arată nivelul fizic al sistemului, descriind produsului software

pe hardware: pe care piese de hardware se executa piese de software.

Diagrama pachet arată pachetele şi interacţiunile între ele la un nivel ridicat.

2) Diagramele de comportament definesc ceea ce se întâmplă în sistemul modelat:

Diagrama de Activitate descrie logica procedurală, procesul de afaceri, şi de fluxul

de lucru.

Diagrame de Caz de Utilizare descrie interacţiunile tipice între sistem şi utilizatori

(sau mediu). Se defineşte comportamentul, cerinţele şi constrângerile sub formă de

script-uri sau de scenarii. Aceste diagrame adresează o viziune statică a unui sistem.

Avantajul de a utiliza modelarea studiului de caz este acela că de permite o definiţie

externă a sistemului prin identificarea actorilor care pot participa în sistemul viitor,

precum şi principalele exemple de implementare.

Diagrama Masina cu Stari este o tehnică de familiare pentru a descrie

comportamentul unui sistem. Este extrem de utila pentru descrierea sistemelor

reactive prin indicarea succesiunii de evenimente la care reacţionează un obiect şi

comportamentul rezultat.

3) Diagrame de interacţiune, un subset de diagrame de comportament, pun în evidenţă fluxul

de control şi de date între componentele sistemului modelat:

Diagrama de Secvenţa descrie colaborarea în termenii unui singur scenariu prin

indicarea secvenţei de mesaje pasate între obiecte folosind o linie cronologică

verticală. Este un fel de diagrama de interacţiune cu accent pe ordonarea în timp a

mesajelor.

Diagrama de Comunicare arată legăturile de date între diferiţi participanţii la

interacţiune în timpul rulării. A fost numită Diagrama de Colaborare în UML 1.x. În

general, se arată instanţele de clase, interrelatiile lor, şi fluxul de mesaje dintre ele.

Diagrama de Ansamblu a Interacţiunii afişează o imagine de ansamblu a interacţiuni

pentru un caz de utilizare complex sau pentru intregul sistem. Este o alaturare a

Diagramelor de Activitate, şi a Diagramelor de Secvenţe. Ea se axează pe

evenimente în loc de acţiuni, faţă de o Diagrama de Activitate care permite ca

fragmente de interacţiune să fie uşor de combinat cu puncte de decizie şi fluxuri.

Diagrama de Termene este o altă formă de Diagrama de Interacţiune care oferă o

imagine a stării unui obiect în timp, şi a mesajelor care modifică acea stare.

Unele dintre aceste diagrame sunt adecvate pentru procesul de modelare de afaceri:

Diagramele UML de Caz de Utilizare pot descrie segmente de afaceri. Participanţii în

cazul de utilizare pot reprezenta rolurile partenerilor care interacţionează cu procesul.

Diagramele UML de Componente pot fi folosite pentru a rafina dependenţele descrise

în diagramele cazuri de utilizare. În acest sens, componenta simbol este utilizata


24

pentru a ilustra un serviciu Web. Atat participanţii la procesul de afaceri cat şi

procesul în sine de afaceri pot fi modelaţi ca servicii Web.

Diagramele UML de Comunicare pot fi utilizate pentru modelarea straturilor de

afaceri şi de piaţă. Ele pot oferi o vedere de ansamblu a unui proces de colaborare de

afaceri între participanţi şi relaţiile acestora.

Diagrame UML de Activitate sunt adecvate pentru modelarea protocoalelor şi

proceselor de afaceri pentru servicii Web. În afara de elemnetele de control a fluxului

(de decizie, fork, join, etc), conţin activităţile de bază necesare pentru interactiunea cu

serviciile partenere. Poate, de asemenea, defini procese tranzacţionale, care rafinează

colaborări definite de Diagrama UML de Comunicare. Diagramele de activitate sunt

cele mai detaliate forme de modelare de procese în termeni UML.

Diagramele UML de Clasa sunt adecvate pentru definirea structurii de date manipulate

de către procesele de afaceri: atribute de obiecte şi conţinut de mesaje, pasat între

obiecte. De asemenea, ele pot furniza detalii cu privire ale diferitelor tipuri de port,

prin definirea operaţiunilor lor şi a parametrilor în cauză.

Diagramele UML Masina cu Stare pot să definească de obiecte care sunt folosite ca

pre-şi post-condiţiile de tranzacţii.

Diagramele UML de Interacţiune afişează o prezentare generală a interacţiunilor

pentru un caz complex de utilizare sau un sistem. Acestea mixează o Diagramă de

Activitate şi o Diagramă de Secvenţă, concentrându-se asupra evenimentelor în loc de

acţiuni, comparativ cu o Diagramă de activitate.

Diagrame de activitate

Diagramele de Activitate sunt în zona de UML care a primit o atenţie deosebită.

Motivul pentru aceasta este sunt adecvate pentru a oferi mijloacele de nivel înalt pentru

modelarea comportamentului unui sistem dinamic, şi, în consecinţă, pentru procesul de

modelare a afacerilor. Diagramele UML de Activitate pot descrie logica procedurală, procesul

de afaceri şi fluxul de lucru prin afişarea secvenţei de activităţi. Flowcharts joacă acelaşi rol

într-o anumită măsură, dar Diagramele de activitate pot fi folosite pentru a descrie

comportamente paralele. Figura 5 prezintă un exemplu de Diagramă de activitate.

Sintaxa Diagramelor UML de Activitate este bine adaptată pentru specificarea

comportamentului, pentru că permite proceselor să fie reprezentate de actori, roluri, activităţi,

flux de executie şi flux de date într-un mod grafic şi cuprinzător.

În Diagramele UML de Activitate, unitatea fundamentală de specificare a

comportamentului este Acţiunea. O Acţiune preia un set de intrari şi-l transformă intr-un set

de iesiri, chiar dacă una sau ambele seturi poate fi goale. Acţiunile pot, de asemenea, modifica

starea sistemului. Limbajul oferă o taxonomie a acţiunilor foarte detaliata, prin identificarea a

mai mult de 40 de tipuri diferite de acţiune, în detaliu. Cele mai relevante tipuri de acţiuni

pentru modelarea proceselor de afaceri sunt conceptul generic de Acţiune, Eveniment de

Acceptare, Trimite Semnal, şi constructorii de Acţiune Comportament la Apel. Aceste tipuri

de acţiuni sunt prezentate în Figura 6.


25

Figura 5 Diagramă de activitate

Figura 6 Principalele construcţii într-o diagramă de activitate

În scopul de a reprezenta comportamentul de ansamblu al unui sistem, este utilizat

conceptul de Activitate. Activităţile pot include orice număr de noduri de activitate, cum ar fi

acţiunile individuale, nodurile de control (de exemplu, split şi join), noduri obiect şi / sau alte

activităţi şi definesc dependenţelor dintre elementele lor. Grafic, ele sunt compuse din noduri

şi muchii. Muchiile conectează nodurile în ordinea secvenţiala. Nodurile reprezintă Actiuni,

Activităţi, Obiecte de date, sau noduri de control. Aceste noduri pot fi aranjate pentru a forma

procese concurente sau secvenţiale, şi mai multe Diagrame de Activitate pot fi conectate

pentru a descrie procesele mai mare. Diferitele tipuri de noduri de control sunt prezentate în

Figura 3-6b.

Utilizarea Diagramelor UML 2.0 pentru modelarea proceselor de afaceri a fost

investigata în [Russell06]. Evaluarea este bazata pe Sabloane de Fluxuri de lucru, o

taxonomie a construcţiilor generice şi recurente, iniţial concepute pentru a evalua sisteme

workflow, şi, mai recent, folosite cu succes pentru a evalua standardele de lucru, limbaje ale

proceselor de afaceri şi sisteme de informare conştiente de procese, în general. Autorii acestor

evaluări de sabloane au ajuns la concluzia următoare: "În timp ce Diagamele UML 2.0 de

Activitate au meritul ca o notaţie pentru procesul de modelare de afaceri, ele nu sunt potrivite

pentru toate aspectele legate de acest tip de modelare. Ele oferă suport complet pentru


26

controlul debitului şi perspective de date care permit ca majoritatea construcţiilor întâlnite la

analizarea acestor perspective să fie capturate direct. Cu toate acestea, adecvare lor pentru

modelare aspectelor legate de resurse sau organizarea proceselor de afaceri este extrem de

limitata. Este interesant de observat că acestea nu sunt în stare de a capta multe din construcţii

naturale întâlnite în procesele de afaceri, precum noţiunea de cazuri de interacţiune cu mediul

operaţional în care procesul funcţiozeza. Acestea sunt limitări pe care le partajează cu cele

mai multe formalisme de modelare pentru afaceri şi reflectă accentul copleşitor pus pe

perspectivele controlul de flux şi de date în notatiile contemporane de modelare".

Tratarea Erorilor şi Tranzactii

Excepţiile reprezintă evenimente nedorite care se întâmpla într-un mod neprevizibil. O

Diagrama de Activitate efectuează o activitate de tratare a excepţiilor printr-o regiunea

interruptibila care înconjoară una sau mai multe activităţi. Dacă ceva, fie finalizarea unei

activităţi sau primirea unui semnal, provoacă un token pentru a parcurge o muchie de

întreruperea, atunci toate activităţile din regiune va fi oprit, şi fluxul va continua numai pe

muchia de intrerupere.

UML sprijină modelarea de tranzacţii. Diagramele UML de Interacţiune pot specifica

detaliile unei tranzacţii în termeni de schimburi de mesaje între participanţi, astfel rafinand

tranzacţiile individuale ale modelului de activitate.

Executie asincronă şi concurentă

UML 2.0 suportă executarea concomitenta şi asincrone de activităţi. O activitate sau o

finalizare a unui proces poate fi setată să depindă de finalizarea unor activităţi multiple şi

concomitente. Mesajele şi evenimentele pot fi trimise sincron sau asincron şi pot fi primite

asincron.

Extensibilitate

UML oferă facilităţi de extensie (stereotipuri, valorile etichetate şi constrângeri), care

permite să fie construite profiluri UML pentru domenii specifice de aplicare, şi pentru a

permite interoperabilitatea prin formatul standardizat, open-source XML Metadata

Interchange (XMI).

Maparea la BPEL4WS

Nu există nici un standard de mapare a Diagramelor UML 2.0 de Activitate la BPEL.


27

Arhitectura condusă de model şi UML

Model Driven Architecture (MDA) este un cadru pentru dezvoltarea de software

introdus de către Grupul de Management Obiect (OMG). MDA distinge trei straturi de

modele:

1) Modelul Independent de Calcul (CIM). Acesta este modelul cel mai abstract, în termeni de

MDA, deoarece este independent de tehnologia computaţională.

2) Modelul Independent de Platforma (PIM). Acest model este definit la un nivel ridicat de

captare; acesta este independent de orice tehnologie de implementare. Se descrie un sistem

software care suportă anumite afaceri. Într-un PIM, sistemul este modelat din punct de vedere

al modului în care acesta acceptă cele mai bune afaceri.

3) Modelul Specific Platformei (PSM). Ca pas urmator, constructorii de implementare a

sistemului vor fi disponibili într-o tehnologie specifica de implementare. Un PIM este

transformat într-un PSM pentru fiecare platformă tehnologica specifica. Cele mai multe

sisteme de azi se refera la mai multe tehnologii; prin urmare, pot exista mai multe PSMs

pentru un PIM. Ultimul pas în dezvoltare este transformarea fiecarui PSM intr-un cod. Pentru

că un PSM este adecvat unei tehnologii această transformare este relativ simpla.

În abordarea MDA, UML poate fi folosit pentru a face modelul executabil. Utilizează

pentru definitia sistemului şi claselor, cazuri de utilizarea a unui sistem. Apoi, identifică

relaţia şi interacţiunile dintre clase, urmat de definirea comportamentului a sistemului şi, în

final, generatoare de cod executabil pentru a pune în aplicare a modelului. De exemplu, un

cod BPEL cod poate fi generate dintr-un model UML.

2.1.3 Aplicabilitate

UML 2.0 oferă un metamodel şi o notaţie grafică pentru definirea de procese de

afaceri pe baza diagramelor de activitate, deoarece acestea suporta şi încurajează

comportamentul paralel. Acest lucru il face un instrument de lucru valors pentru workflow şi

procesul de modelare. Standardul este public şi este disponibil pentru descărcare de pe site-ul

OMG. Multe instrumente de modelare, inclusiv instrumente open source, suportă acest

standard.

Diagramele UML 2.0 de Activitate sunt similare cu BPMN, deoarece acestea sunt

concepute pentru a rezolva aceeaşi problemă de bază: diagramarea proceselor procedurale de

afaceri. Diferenţele între cele două diagrame sunt prezente din cauza utilizatorii de diagrame.

BPMN este orientat spre oamenii de afaceri. Diagrama de Activitate este încă orientată mai

multtehnic, deşi OMG doreste să upgradeze Diagrama de Activitate în termeni de utilizarea

sa pentru oamenii de afaceri. În general, UML 2.0 este potrivit pentru SCIPA.


28

2.1.4 Rezumat

Avantaje

UML 2.0 este un standard de modelare foarte popular şi foarte bine cunoscute.

UML 2.0 este larg acceptate de către furnizorii de instrumente software.

Poate fi utilizat în asociere cu abordarea MDA.

Protocoalele şi procese de afaceri pentru servicii Web pot fi modelate cu Diagrame de

activitate.

Analiştii de business pot să utilizeze aceleaşi notaţii şi instrumente pentru documentarea

proceselor de afaceri precum arhitectii şi designerii de software în documentarea

sistemelor software.

Dezavantaje

Este mai mult orientat spre programare orientate-obiect decât spre definirea de procese de

afaceri.

Este mai mult orientat tehnic decât BPMN.

Nu există nici un standard de mapare de la Diagrama UML 2.0 de Activitate pentru BPEL.

Aptitudinii de modelare UML 2.0 pentru aspecte legate de resurse sau organizare a

proceselor de afaceri este extrem de limitat.

Recomandări

UML ca un limbaj de notare grafica potrivita pentru modelarea proceselor de afaceri

poate fi văzut ca o alternativă la BPMN şi poate fi recomandat pentru utilizare în SCIPA

pentru specificarea grafica de coregrafie a proceselor de afaceri.

2.2 Notaţia de modelare a proceselor de afaceri (BPMN)

Business Process Modeling Notation (BPMN) este un standard care a fost elaborat de

către organizaţia non-profit Business Process Management Initiative (BPMI.org), care a fost

înfiinţata în august 2000, în scopul de a promova dezvoltarea şi utilizarea de Business Process

Management (BPM) prin stabilirea de standarde deschise pentru procesul de proiectare,

implementare, executare, întreţinere, şi optimizare. A început prin specificatii deschise pentru

Business Process Modeling Language (BPML) şi Business Process Query Language (BPQL).

În timpul dezvoltării de BPML, membrii BPMI.org au discutat ideea de a crea o

notaţie pentru a completa BPML deoarce nu exista niciun standard acceptat pentru notaţie

proceselor de afaceri. Au fost, şi încă mai sunt, numeroase notatii proprietare pentru modelare

proceselor de afaceri. Scopul Grupului de lucru pentru Notaţii în dezvoltarea BPMN a fost de

a lua cele mai bune idei de la aceste notatii diverse pentru a oferi o notaţie standard care ar

putea fi înţelesa şi utilizata de către toţi cei implicaţi în procesul de modelare de afaceri, nu

numai de dezvoltatorii tehnici, ci şi de analiştii de afaceri. Scopul a fost o notaţie care să

uneasca cele două lumi a designului de procese de afaceri şi a implementarii proceselor de

afaceri.


29

În august 2001, a Grupului de lucru notaţie sub prezidentia lui Stephen White, IBM, a

fost insarcinat să creeze notatia cu participarea altor firme, cum ar fi Intalio, CSC, MEGA

International, Casewise, Popkin Software şi webMethods. În noiembrie 2002, specificatia

BPMN 0.9 a fost lansată către public şi, în mai 2004, specificatia versiunii 1.0 a BPMN a fost

publicata oficial [BPMN]. Această versiune a inclus o mapare de la BPMN la BPEL4WS, o

indicaţie a faptului că inca de atunci BPMI.org a recunoscut importanţa BPEL4WS,

comparativ cu propriile sale BPML. O versiune 1.x de BPMN a fost dezvoltata ca o eliberare

de neconcordanţele constatate ulterior. S-a mai lucrat de asemenea la standardizarea seturilor

de Artifacts pentru a sprijini modelarea generala a afacerilor şi pe verticală a domenii de

afaceri (de exemplu, asigurări, producţie, finanţe) [White04b].

În iunie 2005 BPMI.org şi OMG si-au fuzionat activităţile lor legate de BPM, plasand

responsabilitatea pentru specificatiile BPMN (si în prezent) în cadrul OMG, la unitatea

Business Modeling and Integration Domain Task Force. Din septembrie 2005, grupul de

lucru era compus din 58 de membri reprezentând 35 companii [White05b]. Specificatia

BPMN 1.0 a fost publicat ca document OMG. Varianta finala adoptata de OMG ca

specificatia BPMN a fost lansata în februarie 2006 ca document de OMG [BPMN06].

În ceea ce priveşte relaţia cu alte organizaţii este de standardizare în cauză, BPMI.org a

dezvoltat BPMN cu scopul de a fi parte dintr-o stivă, iniţial cu BPML propriu, dar apoi cu

BPEL4WS mai târziu, dar şi alte mapările au fost avute în vedere. Acum, că OMG-a luat

BPMN în proprietate, nu există în mod clar intenţia de a stabili relaţii mai strânse între BPMN

şi alte OMG de lucru [White05b]. De exemplu, este de asteptat ca BPDM ar putea servi ca

metamodel pentru BPMN pentru a folosite şi pentru a genera o schemă BPMN pentru

schimbul de informaţii semantice BPMN. Sunt de asteptat de asemenea fuzionarea BPMN şi

Diagramelor UML de Activitate pentru a aduce împreună cele două sectoare de modelare a

proceselor de afaceri şi de analiză şi design software. Nucleul versiunii curente de BPMN

este compatibil cu o Diagrama UML 2.0 de Activitate şi este posibilitatea de construi un

BPMN într-un profil de Diagrame UML 2.0 de Activitate este luată în considerare.

Versiunile 1.x ale BPMN stabilesc specificaţiile pentru erori şi inconsecvenţe şi adaugă

/ modifică elemente [entru modelarea procesele de colaborare bazate pe sugestiile primite de

la Comitetul tehnic OASIS pentru procese de afaceri ebXML, şi este posibil să existe o

mapare pentru alte versiuni de BPEL, cum ar fi WS-BPEL 2.0. Este posibil de asemenea să

fie construit un Metamodel (BPDM şi / sau XPDL) pentru BPMN pentru a genera o schemă

de a păstra şi transporta în diagrama de informaţii semantice şi pentru a utiliza XMI pentru a

face schimb de informaţii de cadru a Diagramelor BPMN. Nu există muncă avute în vedere,

pe cât de explorare executiv şi alte niveluri de afaceri de modelare a extinde sau stratificat

sunt în partea de sus a BPMN [White05b].

Un proces de afaceri nu este neapărat implementat ca un proces automatizat de afaceri

într-un limbaj de executie. În acest caz, procesele de afaceri şi participanţii pot fi mapaţi la

construcţii, cum ar fi utilizarea de modele comportamentale şi cazuri în UML.

BPMN a fost conceput pentru modelarea proceselor de afaceri în general şi are ca ţintă

o gamă largă de utilizatori care au nevoie de de a comunica procesele de afaceri cu alţii şi,

astfel, au nevoie de un standard de notaţie. Notaţia grafica este destinata să fie intuitiva

pentru utilizatori din mediul de afaceri, care ar trebui să poată uşor citit şi înţelege o diagramă

BPMN, care are, de asemenea, posibilitatea de a reprezenta semantica pentru proces complex

pentru implementorii procesului, care pot utiliza caracteristicile extinse ale notaţiei pentru a

reprezenta o proces implementabil. Este prima notaţie în procesele de afaceri care oferă o

viziune comuna modelatorilor proceselor de afaceri precum implementatorilor de procese.


30

BPMN este destinat să fie mapat cu uşurinţă la orice limbaj de executie a proceselor de

afaceri, dar şi pentru a fi utilizate în modelarea de procese de afaceri fără a le executa

neapărat. Se bazează pe tehnicile fluxurilor din procesele de afaceri utilizate de către analişti

şi furnizate într-o varietate de instrumente proprietare, astfel încât analiştii de afaceri de

modelare ce sunt obisnuiţi să utilizeze pentru una dintre aceste limbi nu vor avea prea multe

probleme în conversie. Scopul a fost de a crea un mecanism simplu pentru crearea de modele

de proces de afaceri, şi în acelaşi timp, pentru a se putea ocupa de complexitatea inerentă de a

proceselor de afaceri [White 04b].


BPMN a fost acceptat în industrie ca notaţie pentru de utilizare şi procesare a

modelelor în instrumente produse de vendori. Alternative la BPMN sunt sisteme proprier sau

text simplu. Aproximativ 65% din procesul de modelare întreprinse în cele mai multe

companii se bazează pe text, şi de multi manageri care folosesc procesul de diagrame grafice

de utilizare, utilizează fie PowerPoint fie Visio [Harmon05]. Astfel, este clar că BPMN

trebuie să fie evaluat împotriva unui astfel de fond. În Europa, se pare că BPMN este cu

siguranţă la toată lumea pe lista de cerinţe. Cu toate acestea, nu a fost îmbrăţişat de către un

număr mare de organizaţii încă. Este într-o situaţie similară cu BPEL pentru care numărul de

adoptari este încă în fază incipientă. Se asteapta să mai dureze ceva timp înainte de BPMN

devine un standard real [Casewise05]. În prezent, BPMN este singura notaţie standard grafica

pentru modelare proceselor de afaceri. Nu este probabil să fie înlocuit de către orice alt

standard, dar este foarte probabil că va evolua pentru a fi compatibil cu alte standarde ale

OMG.

BPMN este un standard deschis şi specificatia este disponibila pentru descărcare de pe

site-ul OMG. Conform acestui site web, există în prezent peste treizeci de implementări de

BPMN. Cele mai multe instrumente sunt produse comerciale, dar sunt disponibile şi unele

instrumente open source. De exemplu, M1 Global Convergence Studio, menţionate pe site-ul

OMG, este un plug-in Eclipse, pe baza standardului BPMN. BPMN Package of Plugins

(proiect Sorceforge) oferă un şablon Visio pentru BPDs folosind BPMN.


BPMN a fost proiectat pentru o descriere stndard bazata pe π-calcul pentru procese de

afaceri. Notaţia utilizata pentru BPMN este o notaţie grafică pentru exprimarea proceselor de

afaceri într-o Diagrama a Proceselor de Afaceri (BPD), care se bazează pe diagrame

tradiţional cunoscute de cei mai multi analişti de afaceri. Texte adnotări pot fi adăugate la

oricare elemente ale modelului pentru a oferi informaţii şi detalii suplimentare. BPMN este

independent de orice metodologie de modelare proces de afaceri specifice.

Tipuri de procese care pot fi modelate

Trei tipuri de bază modelul pot fi create cu un BPD [BPMN].

Colaborare (globale) – procesele B2B care arată interacţiunea între două sau mai multe

entităţi de afaceri. Interacţiunile dintre participanţi sunt definite ca o succesiune de

activităţi, reprezentând sabloanelor schimburilor de mesaje între acestia. Aceste procese


31

sunt aproape de limbajele de coregrafiere şi a fost de aşteptat ca acolo ar fi mapările la

diferite limbaje de colaborare, cum ar fi ebXML, BPSS, RosettaNet Limbajul de

Coregrafie al W3C (care nu au fost disponibile la lansarea versiunii 1.0).

Privat (intern) – procesele de afaceri se concentrează asupra activităţilor unei singure

organizaţii de afaceri, care, deşi arată interacţiuni cu interne participanţi, nu sunt vizibile

pentru public şi sunt astfel activităţi private. Un proces de afaceri privat poate fi mapate la

una sau mai multe documente BPEL4WS.

Abstract (publice) – procese care arată activităţi pe care un proces de afaceri privat le

utilizează pentru a comunica cu un alt participant sau de proces, dar nu şi de activităţile

interne ale procesului de afaceri privat. Un astfel de proces poate fi mapat la un singur

proces BPEL4WS abstract (imposibil în versiunea 1.0 a BPMN).

Principalele concepte utilizate

BPMN fiind menit să sprijine atât analişti de afaceri, precum şi implementorii de

procese, elementele diagramei de elemente în BPMN au fost organizate în două categorii.

Nucleul set de elemente permite să fie produse BPDs care sunt familiariare analiştilor de

afaceri deoarece sunt bazate pe diagrame de fluxuri. Această gamă cuprinde următoarele

elemente:

Debit de obiecte:

o Evenimentele sunt utilizate pentru a reprezenta faptul că se întâmplă ceva şi, de

obicei, au o cauză şi un rezultat şi pot începe, întrerupe sau termina un proces de

flux.

o Activităţile reprezinta lucrul care se realizează în cadrul unui proces de afaceri, ele

pot fi descompuse în sub-activităţi şi sarcini. Ciclarea activtatilor este permisa.

Noţiunea de "stare" nu este folosit astfel incat starea unei activităţi nu poate fi

modelata.

o Gateway modelează decizii de afaceri şi permite branşare, bifurcare, fuzionare şi

aderare a drumurilor. Mai multe tipuri de Gateway sunt acceptate, şi se face o

distincţie între gateway-XOR pe bază de date şi pe bază de eveniment.

Obiecte de conectare:

o Ordinea curgerii arată ordinea de activităţi într-un proces.

o Curgerea mesajelor arată fluxul de mesaje între entităţi. Un mesaj nu este

considerat un eveniment în sine; un eveniment este caz primirea sau trimiterea

mesajului.

o Asocierea asociază informaţii / date, text şi altele cu obiectele flux..

Swimlanes

o Bazin reprezinta un participant la proces, astfel încât un set de activităţi pot fi

partitionate în diferite bazine. Bazinele pot reprezenta organizaţii, în special a

entităţi diferite de afaceri în contexte B2B.

o Banda este o sub-partiţie a unui Bazin utilizate pentru a organiza şi categorisi

activităţi separate într-un Bazin, de obicei, prin rol sau funcţie. Banda poate

reprezenta departamente din cadrul unei organizaţii, precum şi anumite funcţii sau

sisteme.

Artefact


32

o Obiecte de date furnizează informaţii despre modul în care documente, date şi alte

obiecte sunt utilizate şi actualizate într-un un proces. Ele sunt conectate la

Activităţi prin intermediul Asociaţiilor.

o Adnotările Text sunt un mecanism care permite unui modelator să furnizeze

informaţii suplimentare pentru un cititor de diagramă BPMN

o Grupurile furnizează un mecanism de a organiza activităţi şi pot fi folosite pentru

scopuri de analiză sau de documentaţie, dar nu afectează ordinea curgerii.

Figura următoare oferă un exemplu pentru specificatia BPMN pentru un proces de

colaborare de afaceri a folosind elemente grafice de baza. BPDul este uşor de citit şi de

elemente de bază sunt adecvate pentru modelatorii care crează modele ale proceselor de

afaceri pentru scopuri de documentare şi de comunicare scopuri.

Figura 7 Diagrama unui proces de colaborare de afaceri prin specificaţia BPMN

Pentru cei care au nevoie pentru a produce procesul de modele la un nivel mai mare de

detaliu, în continuare se pot face adăugiri la elemente de bază. Markeri interni, de exemplu

pentru Mesaj, Timpul, Excepţie, Anulare, Compensare, Regula, Link, Terminare, şi Multiple,

pot fi adăugaţi la Evenimente pentru a arăta tipul de Eveniment (Figura 8). Markeri pot fi

adăugate la Activităţi pentru a distinge Buclă, Instanţă multipla, Compensare, precum şi

activităţi Ad-Hoc. BPMN pot fi folosite pentru a crea procese de nivel înalt, precum şi

procese complexe cu mai multe niveluri de detaliu. Pot să includă procese de instrucţie cu

puncte de vedere în nivele mai scăzute de detaliu separate, cu diagrame.


33

Figura 8 Tipuri de markere care pot fi adăugate la evenimente de bază BPMN

Specificatiile BPMN se referă la sabloane şi arată cum BPMNurile se pot ocupa de

cerinţe de tratare simple şi complexe pentru modelarea proceselor de afaceri. Se pot considera

bifurcatii ale curgerii, unirii ale curgerii, divizarea curgerii, instalarea curgerii, şi ciclari,

precum şi un flux de excepţie. [White04a] a investigat măsura în care Diagrama BPMN a

proceselor de afaceri (şi în UML 2.0 Diagrama de Activitate) poate reprezenta modele de flux

de lucru elaborate de van der Aalst et al [Aalst03c]. Pentru fiecare sablon, cele două notations

sunt comparate cât de bine tratează sablonul. Este arătat că fiecare sablon poate fi reprezentat

în mod adecvat de către BPMN, deşi [Wohed05] consideră că există anumite probleme cu

soluţia propusa şi că anumite limitări ale BPMN exista când întreaga gamă de modele este

examinata.

Figura 9 arată că fluxul este folosit ca un exemplu ilustrativ în [BPMN] pentru

caracteristicile extinse ale BPMN.


34

Figura 9 Un exemplu de specificaţie BPMN

Tratarea erorilor, tranzacţii, asistenţă la compensare

Tratarea excepţiilor este posibilă; evenimente intermediare ataşate la limita unei

activităţi reprezintă generatoare ca început de activitate. Lucrul în activitate va fi oprit şi se va

continua fluxul de la Eveniment. Se pot genera cronometre, excepţii, mesaje, etc. O

Tranzacţie este o activitate descrisa de o frontieră dubla. Diverse fluxuri pot fi modelate,

pentru o permite finalizarea cu succes a tranzacţiei, o anulare de finalizare, sau o excepţie de

tranzacţie cauzând eroare. Compensarea este, de asemenea, sprijinita, atunci când este nevoie

să se revina la unele dintre activităţi prin activităţi care invocă anularea efectelelor activitate

initiale. Activităţile utilizat cu markerul de compensare sunt în afara fluxului normal al

procesului şi sunt considerate a fi activităţi normale asociate.

Extensibilitate

BPMN este extensibil. În speciificatii se afirmă că: "Extensiile pot fi făcute în

elementele Diagrama prin noi markeri sau indicatori markeri asociaţi cu elemente grafice

curent. Aceşti markeri sau indicatori ar putea fi utilizaţi pentru a evidenţia un anumit atribut

al unei activităţi pentru a crea un nou tip de eveniment, de exemplu. În plus, Extensiile ar

putea include, de asemenea, un obiect de colorat sau a schimba o linie de stil a unui obiect,

cu condiţia că nu trebuie să între în conflict cu orice linie de stil BPMN definita anterior. ...

Orice număr de artefacte, constând dintr-o varietate de forme, poate fi adăugată la o


35

diagrama, cu condiţia ca forma artefactul nu trebuie să între în conflict cu orice alta forma

de obiect sau marcator deja definit." [BPMN]

[White05a] introduce pictograme, care nu sunt parte a notaţie standard BPMN pentru a

demonstra extensibilitatea BPMN. Aceasta înseamnă că modelatorii pot crea artefacte

necesare pentru scopul lor specifice, posibil adăugand mai multe detalii la o activitate care

este în curs de efectuat.

Maparea la BPEL4WS

Specificaţia BPMN oferă o mapare la BPEL4WS versiunea 1.1 pentru a arăta cum

obiectele BPMN şi relaţiile dintre aceste obiecte pot fi mapate la BPEL4WS. Deşi BPMN nu

poate fi considerat aproape de un limbaj de coregrafie mai mult decât un limbaj de

orchestraţie, nu a existat nici un limbaj de coregrafie de disponibil atunci când a fost elaborat

specificatia. Când o mapare este considerata terbuie decis unde să fie mapata la un format

BPEL4WS bazat pe structura grafica BPEL4WS (elementul flux), sau pe structura BPEL4WS

bloc (element de ordine). Specificatia BPMN adoptă o abordare de mapare la elementele

BPEL4WS în principal folosind elemente şi structuri de bloc, iar în [White05a] este adoptata

o structura de tip graf pentru mapare. Anexa A a specificatiei prevede codul complet

BPEL4WS cod pentru exemplul din corp principal a specificatiei.

Nu tot BPMN poate fi descris în BPEL4WS deci este posibil să se reprezinte procese în

BPMN care nu pot fi mapate la BPEL4WS. Cu toate acestea, maparea la BPEL4WS nu este

întotdeauna necesara deoarece un proces de afaceri nu este neapărat destinat a fi puse în

aplicare ca un proces automatizat de afaceri într-un limbaj de executie a proceselor. Ea poate

fi produsă la începutul procesului de design al software-ului pentru a înţelege cerinţele privind

designul sistemul.


BPMN oferă un standard de notatie grafică pentru modelarea proceselor de afaceri. Nu

are nici o alt concurent ca standard, exceptand instrumentele proprietate. Ca o notaţie de

modelare pentru afaceri, este aplicabil la SCIPA pentru acele zone de lucru în care o astfel de

notaţie este necesară. Este clar compatibil cu BPEL (4WS) şi exists o serie de instrumente

software, care permit ca realizarea maparii în mod automat.

2.2.4 Rezumat

Avantaje

BPMN este singura notaţie standard grafica pentru modelarea de procese de afaceri.

Este destinat să permita atât la nivel înalt de afaceri procesul de proiectare, precum şi

acordarea de asistenţă pentru modelarea procese de afaceri mai complexe, cat şi maparea la un

limbaj de executatie. Este destul de intuitiv pentru acei analişti de afaceri cu cunoştinţe

privind notaţia grafică a procesului tradiţional de afaceri şi în acelasi timp permite construirea

de procese complexe. Ea se extinde mai mult decât notatiile tradiţionale de afaceri în multe

privinţe, nu numai legat de maparea la un limbaj de executie, dar sprijina de asemenea

conceptul de proces B2B, inclusiv procese publice şi private, precum şi interacţiunele între

două entităţi de afaceri. Se permite, de asemenea, tratarea excepţiilor, operaţiuni de

compensare.


36

Un alt punct forte al BPMN este suportul său pentru trimite mesaje de modelare între

două entităţi. BPMN poate, de asemenea, descrie fluxurile de mesaje şi oferă o notaţie de

obiecte de date care pot fi asociate cu activităţi. Spre deosebire de cele mai multe notatii

pentru procesele de afaceri BPMN permite obiectelor de date să fie reprezentate şi modelatorii

pot arată cum datele, documentele şi alte obiecte sunt folosite şi actualizate în timpul unui

flux al procesului. Odată cu creşterea cererii de modelare a procesului de afaceri tip B2B,

BPMN creste în semnificaţie. Cum un procesul de modelare de afaceri este implicat în

tratarea datelor în cauză, BPMN oferă un avantaj faţă de alte notatii în cazul în care

modelatorii trebuie să utilizeze soluţii sau faca presupuneri în care sunt implicite necesitati.

BPMN nu este, totuşi, o notaţie pentru diagrame de flux de date. Modele de date şi informaţii

nu sunt incluse în specificatii.

Specificatia BPMN oferă o mapare la BPEL4WS şi o serie de instrumente sunt

disponibile pentru a suporta aceasta mapare, care permite astfel ca BPMN să fie utilizat într-

un lanţ de instrumente. Aceasta este în mod important pentru mediul SCIPA. Deoarece

BPMN este parte a OMG, link-uri sale către alte specificaţii şi standarde vor fi consolidate.

Dezavantaje

Specificaţia nu prevede un metamodel sau de un mecanism de schimb al diagramelor. A

fost destinat pentru a defini acest mecanism într-o etapă ulterioară [BPMN]. Acest lucru face

dificil schimbul de modele între instrumente de lucru BPMN şi pot conduse la probleme

severe atunci când o varietate de instrumente este utilizat de către diferiţi modelatori. Decizia

de a dezvolta BPDM ca un metamodel pentru BPMN [Frankel06] va consolida poziţia şi

această slăbiciune speciala va fi eliminata.

BPMN nu oferă o notaţie pentru reprezintarea arhitecturii organizatorice la nivel de

proces. Structurile organizaţionale şi de resurse, strategie, rolurile în afaceri sunt în mod

specific excluse din domeniul de aplicare a standardului şi luate în considerare ca o problemă

deschisă pentru a fi rezolvata. Nu există nici o schemă XML asociata cu BPMN. Specificaţia

BPMN ca un nivel limbaj XML deasupra limbajelor de exceutie BPM a fost considerată o

problemă deschisă în continuare pentru studiu.

Recomandări

Ca un standard de notatie grafica în modelarea proceselor de afaceri, el poate fi

recomandat pentru utilizare la SCIPA în fazele timpurii ale sistemului de proiectare.

Coregrafia acestor procese de afaceri pot fi specificate folosind notaţia BPMN.

2.3 Concluzii

Acest capitol a evaluat patru standarde din domeniul metodologiei de modelare şi de

notaţia grafică. Informaţiile furnizate în fiecare dintre secţiunile a oferit o bază pe care să facă

o recomandare cu privire dacă adoptarea standardelor pentru mediul SCIPA.

UMM este o tehnologie puternica de modelare pentru procese de afaceri şi modele de

informaţii şi este un standard deschis. Acesta a fost dezvoltat în mod specific pentru

construcţia de procese de afaceri şi modele de informaţii şi este bazat pe UML 1.x. A fost

adoptată de către diferite grupuri de utilizatori din industrie, dar nu este bine susţinut de

instrumente şi cunoştinţele despre UMM nu sunt larg răspândite. Este considerat complex şi


37

necesită un nivel ridicat de expertiză pentru a-l utiliza. Prin urmare, nu este recomandat pentru

utilizare la SCIPA.

UML este un limbaj orientat-obiect pentru modelare de la OMG pentru specificarea,

vizualizarea, documentarea şi de modelarea de sisteme software. Este un standard deschis

care a evoluat în ultimii ani, iar versiunea 2.0 este în curs de adoptare de către furnizorii de

instrumente. A devenit satndardul de facto pentru modelare aplicabil la orice proiect de

dezvoltare software, iar cunoştinţele de UML sunt larg răspândite. În modelarea proceselor de

afaceri pentru SCIPA, Diagrama UML de Activitate este de interes deosebit, în special pentru

coregrafia în modelarea proceselor de afaceri. Prin urmare, este recomandat pe tot parcursul

ciclului de viaţă SCIPA în dezvoltarea software.

BPDM este un standard deschis oferind un model abstract de modelare pentru

procesele de afaceri care este dezvoltat de către OMG. Acesta a fost în curs de dezvoltare

pentru o vreme, aparent cu întârziere datorate discutiilor dacă ar trebui să se bazeze pe UML,

BPEL sau BPMN [Frankel06]. BPDM este de interes special pentru a SCIPA ca un potenţial

metamodel pentru BPMN. Cu toate acestea, standardul nu poate fi recomandat pentru mediul

de lucru SCIPA curent, fiind încă în curs de dezvoltare şi nu există instrumente de sprijin.

BPMN este o notaţie standard grafica şi deschisa pentru procesul de modelare de

afaceri care a fost dezvoltat de BPMI, acum fuzionat cu OMG. El se bazează pe bine-

cunoscuta noatie flowchart şi, astfel, este destul de intuitiv pentru analiştii de afaceri.

Specificatia prevede, de asemenea, o notaţie pentru mai multe procese complexe şi o mapare

la BPEL (4WS), care îi permite să fie folosit în primul pas în procesul de dezvoltare a ciclului

de viaţă. Exista instrumente de sprijin, în special pentru mapare la BPEL, dar, de asemenea,

pentru XPDL, de asemenea de interes pentru SCIPA. Prin urmare, poate fi recomandat pentru

utilizare ca notatie grafica la SCIPA pentru etapa de design a procesului de afaceri, în special,

în modelarea coregrafiei proceselor de afaceri.


38

3 Limbaje de coregrafie

Standardele pentru compunerea serviciilor pot să fie considerate ca fiind în conexiune

cu [Barros05b]:

coregrafia - aceasta contine procese care colaborează (colaborative) implicand diferite

servicii iar interactiunile dinter aceste servicii pot fi vazute dintr-o perspectiva globala.

interfaţa de comportament (care poate să fie considerata ca fiind un proces abstract în

BPEL şi ca un profil de protocol de colaborare în ebXML) capturează dependentele

comportamentale dintre interactiunile care permit ca un anumit serviciu să fie utilizat;

orchestratia (proces executabil în BPEL) - operează cu descrierea interactiunilor generate

prin care un anumit serviciu poate fi implicat precum şi cu descrierea activităţilor interne

care permit aceste interactiuni (ca de exemplu prezentarea datelor în anumite formate,

etc.).

3.1 Orchestrare versus coregrafie

Vom prezenta pe scurt orchesraţia şi coreografia [Pelz03].

Orchestratia prezinta modalitatea în care serviciile Web opt interactiona unul cu altul la

nivel de mesaj, incluzand logica procesului şi ordinea de executie a interactiunilor din

perspectiva şi sub controlul unic al unui singur participant. Orhestratia se refera la un proces

executabil care deriva dintr-un model de proces de lunga durata, tranzactional, multi-step.

Prin orchestratie, interactiunile procesului sunt controlate intotdeauna din perspectiva

(particulara, privata) a uneia dintre partile implicate în proces.

Coreografia se ocupa cu schimburile de masaje publice (global vizibile), reguli de

interactiune şi consensuri care trebuiesc realizate între mai multe procese (intre mai mulţi

parteneri).

Coreografia urmareste (coordoneaza) secventa de mesaje care pot implica mai multe

părţi şi mai multe surse, incluzand clienti, furnizori şi parteneri unde fiecare parte implicata în

proces prezinta (descrie) partea care o joaca în interactiune (si nu propriile actiuni).

Coreografia scoate în evidenta (ilustrează în esenta) colaborările. Ea descrie din perspectiva

tuturor partilor (viziune comuna) şi defineste în esenta a starilor de interactiune (partajate în

comun) dintre entitatile procesului. Aceasta viziune comuna poate fi utilizata pentru a

determina dreularea implementarii pentru fiecare entitate individuala. Coreografia ofera o

modalitate prin care regulile de participare ;a colaborare pot să fie clar definite şi agreeate de

catre toate partile. În acest fel fiecare entitate poate să-şi implementeze propria parte de

coregrafie rezultata din viziunea comuna.

Un model de tip coregrafie trebuie să descrie colaborarea dintre o colectie de servicii

care să permita realizarea (atingerea) unui anumit obiectiv. Ea caracterizează interactiunile în

care serviciile participante se implica pentru a asigura realizarea acestui obiectiv şi

dependentele dintre aceste interactiuni inclusiv dependentele de control pentru flux (ordinea

succesiunii realizarii interactiunilor), dependentele impuse de fluxul datelor, de corelare a

mesajelor, restrictii de timp depente tranzactionale şi altele [Barros05a].


39

Evident ca prin coregrafie nu sunt descrise interactiunile interne care se realizează intr-

un serviciu implicat (ca exemplu prelucrari-calcule interne) şi care nu au un efect vizibil în

exterior.

Coregrafia capturează interactiunile dintr-o perspectiva globala, fiecare participant fiind

tratat în mod normal, fără preferinte. Coregrafia cuprinde toate intractiunile dintre serviciile

participante care sunt relevante cu obiectivul coregrafiei.

Un punct de vedere particular dar foarte important consideram ca este urmatorul. În

coregrafie trebuiesa se accentueze interactiunea procesului cu serviciila care-i asigura

realizarea obiectivului.

O coregrafie este o comuniune (intelegere) dintre o multime de părţi prin care se reda

modalitatea în care o anumita colaborare trebuie să se realizeze.

3.2 Interfaţa comportamentală

Trebuie ca interfaţa comportamentala să fie conceputa într-o conexiune strictă cu

coregrafia. Interfaţa comportamentala vine să completeze descrierile interfetei sructurale inter

care cele suportate de WSDL care capturează interactiunile elementare în care un serviciu

poate fi imlicat, tipurile de mesaje şi politicile care guvernează schimburile de mesaje în

special în ceea ce privete securitatea şi siguranta.

Capturarea aspectelor comportamentale ale interactiunilor cu un anumit serviciu care

este solicitat să contribuie la realizarea obiectivului se realizează prin interfaţa

comportamentala. Trebuie accentuat faptul ca interfaţa comportamentala capturează

dependentelednter interactiuni: controlulu fluxului, constrangerile de timp, corelareal

mesajelor şi dependentale tranzactionale.

În absenta coregrafiei, interfaţa comportamentala se concenterază asupra perspectivei

doar din partea unui participant la intercomunicare, în consecinta ea nu recceptionează

interactiunile în totalitatea lor.

Figura 10 Interfaţa comportamentală pentru o cerere


40

Este deosbit de important să se tina cont de relatia coregrafie interfaţa comportamentala

pentru a avea certitudinea corectitudinii în executie.

Figura 11 Interfaţa comportamentală pentru o comandă (o poziţie dintr-o comanda)


41

Figura 12 O alternativă pentru interfaţa prezentată în Figura 11

Într-o colaborare de tip B2B un rol într-o coregrafie poate fi asociat cu interefete

comportamentale multiple şi în consecina şi interfete WSDL multiple. Avand o coregrafie şi

un rol în aceasta, va terbuie să fie definite un numar arbitrar de interfete comportamentale

care vor trebuie să se coreleze cu constrangerile impuse de coregrafie pentru acel rol.

3.3 WS-CDL

WS-CDL este un limbaj exprimabil în XML pentru a compune colaborări

interoperabile, de lunga durata, peer-to-peer între orice tip de "părţi" fără a tine cont de

platforma sau modelul de programare utilizat pentru implementarea la mediul care gazduieste.

WS-CDL viziunea globala a schimbului de mesaje ale tururor serviciilor (web) participante

care sunt implicate în colaborarea din proces.


42

Figura 13 Nivelele WS-CDL

WS-CDL este un limbaj reprezentabil pe nivele [Ross-Talbot04]. El asigură diferite

nivele pentru a decrie capacitatea de exprimare a unei ontologii. La cel mai inalt nivel pentru

orice WS_CDL este un package care contine toate celelalte elemente. Toate coreografiile

descrise în WS-CDL trebuie să includă un set minimal de roluri care sunt definite ca o

modalitate de comportare reprezentand astfel notiunea nunui serviciu în WS-CDL. Relatiile

între aceste roluri, canalele utilizate de roluri pentru a interactiona şi un bloc al coregrafiei

care foloseste canalele pentru a descrie interactiunea. Figura 13 prezintă structura pe nivele a

WS-CDL.

Prin utilizare WS-CDL se defineste un contract care contine o definire a conditiilor

comune de ordonare şi constrangeri prin care sunt schimbate (transmise) mesajele; acest

contract descrie din punct de vedere global comportarea "complementar" observabila a tuturor

partilor implicate.

Fiecare parte poate în consecinta să utilizeze definitia globala şi să testeze solitiile care

se conformează cu aceasta. WS-CDL se utilizează strict numai pentru "procese abstracte"

independente de platforma şi de limbajele de programare care snt utilizate pentru

implementarea participarii serviciilor.

În specificatia WS-CDL schimburile de mesaje se realizează în cadrul unui set de reguli

şi constrangeri în comun acceptate. Defintiile unei coreografii pot implica doi sau mai mulţi

participanti. WS-CDL descrie o viziune generala a schimburilor de mesaje fără a lua în

considerare nici un punct de vedere al verunui participant, pe cand în BPEL un proces abstract

rperzinta punctul de vedere al unui participant. WS-CDL (ca de altfel şi BPEL) seste o

specificatie de infrastructura care nu contrine semantici de proces (resurse, conventii,

intelegeri, etc.).

O definite de coregrafie în WS-CDL este intotdeauna o definitie abstracta de "roluri"

care ulterior vor fi atribuite "participantilor". Rolurile sunt legate între ele (unul cu altul) prin

"relatii" O relatie se defineste exact între doua roluri. Un participant poate implementa orice

număr de roluri care nu sunt în opozitie cu el, în coregrafie. Exemplu: un distribuitor poate


43

implementa rolurile: "cumparator_la_fabricant" şi "vanzator_la_client".care sunt diferite de

rolul "vanzator_la_distribuitor". Rolurile în WS-CDL sunt relativ similare cu <partnerLink>

din BPEL.

Un document WS-CDL este constituit dintr-un set de definitii. Definiţiile se numesc

constructii şi pot fi referite.În radacina exista un element <package> şi coreografia individuala

este definita în el. Un package WS-CDL contine un set de una sau mai mylte coreografii şi

una sau mai multe definitii de tipuri de colaborare. Constructia unui package WS-CDL

permite agregarea unui set de coreografii.

Elementele de bază şi structura WS-CDL se pot regasi în draftul WS-CDL v1.0, 22

Septembrie 2004 şi sunt prezentate în Figura 14 [WS-CDL04].

Figura 14 Elementele şi structura WS_CDL

Descrierile pentru coregrafia în WS-CDL asigura o viziune globala (sau nepartinica) a

interactiunilor dintre doua sau mai multe parti. Serviciile web care pto fi dezvoltate de mai

mulţi furnizori. Modalitatile de utilizare în combinatie cu alte servicii nu pot să fie descrise

prin WSDL.

Obiectivul propus de Grupul de lucru 4 este acela de scoate în evidenta necesitatea unor

mijolace general acceptate cum pot să fie utilizate serviciile web atat individual cat şi în

combinatii unul cu altul pentru a realiza obiectivele propuse.

Obiectivele WS_CDL sunt acelea de a defini contractele multi-parti, care derscriu

comportarea externa care este vizibila a serviciilor web şi clientii lor (alte servicii web) prin


44

descrierea schimburilor de mesaje dintre ele. Ca obiectiv general este acela prin care

coregrafia WS-CDL să fie utilizata pentru a genera scheltoane de cod pentru servicii web sau

procese abstracte BPEL.

O descriere a coregrafiei WS-CDL este continuta intr-un pachet şi formează în esenta

un container pentru o colectie de activităţi care pto să fie executate de catre unul sau mai mulţi

participanti.

În WS-CDL exista trei tipuri de activităţi (Figura 15): de control al fluxului, untiaţi de

lucru şi elementare.

Figura 15 Activitaţi în WS-CDL

Cel mai important element al WS-CDL este activitatea de interacţiune. O interacţiune

descrie un schimb de informaţie inter-părţi concentrată spre receptorul de informaţie.

Interacţiunile au trei obiective:

să emita o cerere (request)

să emita un raspuns (respond)

sau să emita o cerere care la randul său solicită un raspuns (request-respond).

O descrierea a activităţii de interactiune are în consecinta trei părţi care corespund:

participanţii implicati

informaţia care trebuie comunicată

canalul pentru comunicarea informaţiei.

În Figura 16 sunt prezentate doua activităţi de tip interacţiune aferente Figura 11.

De reţinut este faptul că descrierea activităţilor în WS-CDL este orientata mai mult spre

receptor decât spre emitor. Rolorile emitorului şi receptorului şi relatiile dinter acestea sunt

redate explicit în partea de "participare" a descrierii interactiunii. Este de asteptat ca

receptorul să execute cu informaţia pe care o primeste ceea ce trebuie.


45

Figura 16 Exemplu de interacţiune în WS-CDL

Variablilele în WS-CDL sunt utilizare pentru a reprezenta: informaţii dependente de

aplicatie, informaţie de stare şi informaţie referitoare la canal.

Variabilele au un tip specific. Variabilele canal sunt de tip canal. O descriere de tip

canal indică rolul receptorului pe care-l joacă şi ce comportare are pe acest canal.

Comportatile rolurilor sunt descrise (opţional) prin interfeţele WSDL.


46

Figura 17 Exemplu de tip canal în WS-CDL

Variabilele care sunt utilizate în activităţile coregrafiei sunt descrise în definitia

coregrafiei, deci domeniul lor de (existenta)valabilitate este la nivelul coregrafiei. Aceste

variabile de cu domeniul mare (coregrafie) pot să fie accesate sau utilizate în comun cu

coregrafiile apelate utilizand mecanismul de legare în activitatea de executat.

3.3.1 Concluzii

Una dintre cerintele WS-CDL este aceea de a sigura un sens pentru instrumentele care

validează conformitatea cu descrierile coregrafiei pentru a asigura interoperabilitatea între

serviciile web. Sunt necesare validari referitoare la prorietaitle de a fi vie (live), dealock sau

pentru a asigura le executie conformitatea comportarii participantilor în conformitate cu

panul coregrafiei. Pentru aceasta WS-CDL are la bază conteptele din pi-calculus [Milner99].

Pentru a asigura realizarea compunerii serviciilor web, WS-CDL utiliează WSDL, WSDL-

MEP (Message Exchange Patterns), WS-Reliable-Messaging.

În general desrierile coregrafiei prezinta într-o modalitate abstracta la un nivel mai inalt,

în termeni de capabilitate, iar la momentul executiei va trebui realizata selectionarea

participantilor în coregrafie care vor fi capabili să satisfaca acea capabilitate chiar

restrangand participarea în coregrafie a participantilor, utilizand pentru aceasta o interfaţa în

WSDL sau operatii WSDL.

De o mare importanta este consistenta semantica a coregrafiei globale şi a orchestrarii

proceselor locale. Definitia coregrafiei introduce ordonarea (emiterii) mesajelor şi

constrangerile vizavi de vederile interfetei proceselor locale prezente în orchestratie.


47

3.4 Detalii coregrafie

Coreografia se compune din activităţi. Principala activitate este "interacţiunea" şi

constituie blocul constructiv fundamentatal unei coreografii, care rezulta din schimbul de

mesaje dintre participanti, sincronizarile posibile dinter starile lor şi valorile actuale ale

informaţiei schimbate. Interactiunile precizează legatura între schimburile de mesaje dintre

roluri. O interactiune corespunde apelarii unui serviciu Web care operează asupra unui rol. Ca

urmare, o interactiune este definita ca o cerere ci zero sau mai multe raspunsuri. Interactiunile

pot implica activităţi de ordonare (secvente, paralele, alegeri) sau pot compune o alta

coregrafie în cadrul coregrafiei parinte.

Definitiile coregrafiei pot fi conduse de date (data-driven) adica, datele continute în

mesaje avand impact asupra ordonarii. Datele sunt modelate ca şi "variabile" care pot fi

asociate continutului mesajelor, un "canal" sau "starea" rolului implicat în coregrafie.

"Jetoanele" (tokens)sunt alias-uri care por reprezenta partile unei varabile. Jetoanele sunt

corelate cu conceptul prorietatii într-o multime de corelatie din BPEL.

În concluzie, o coregrafie poate să fie utilizată pentru mai multe obiective:

sa genereze interfaţa comportamentala în asa fel incat fiecare serviciu participant să poata

participa la o (într-o) colaborare. Interfaţa comportamentala generata poate fi utilizata pe

durata dezvoltarii serviciului.

pe durata proiectarii să se verifice dacă interfaţa comportamentala a unui serviciu se

conformează unei coregrafii şi astfel dacă serviciul în cauză este capabil să joace un rol

în aceasta coregrafie.

În mod similar o interfaţa comportamentala poate fi utilizata ca un punct de pornire

pentru a genera un schelet (cadru) pentru o orchestratie., care va fi definitivata cu detalii.

Pe de alta parte, o orchestratie existenta poate fi verificata de consistenta fata de o

(printr-o) interfaţa comportamentala existenta. În acest fel se pot scoate în evidenta situatiile

în care o orchestratie data nu trmitie mesajele în ordinea în care acestea sunt asteptate de catre

alte servicii.

Interfaţa comportamentală prezentată în Figura 12 va putea fi utilizată în locul uneia din

Figura 11 în contextul coregrafiei folosite ca şi exemplu. Interfata comportamentala

prezentata ca şi alternativa va avea aceeasi comportare ca şi cea din Figura 11, spre exemplu

mesajul de anuare a comenzii (ordinului) nu va fi transmis ncicodata unui participant care

joaca un rol de furnizor, datorita modului în care fost conceputa coregrafia.

Procesul pentru onorarea comenzii unui producator de catre furnizor din perspective

coregrafiei, este ilustrat în Figura 19.


48

Figura 18 Coregrafia unui model de proces

Figura 19 Procesul de onorare a unei comenzi din perspectiva coregrafiei


49

3.5 SOA

Arhitecturile orientate pe servicii permit realizarea controlului şi gestiunii proceselor

atat interne companiei cat şi celor între parteneri [Decker06]. Serviciile sunt utilizate ca să

execute taskuri între procese.Coreografia reperzinta protocolul de interactiune dintre mai

mulţi parteneri (de afaceri).

S-au facut eforturi pentru a identifica cele mai utile şi frecvente scenarii din prosepctiva

procesului finalizate în Service Interaction Patterns [Barros05b]. Sabloanele sunt prezentate

dupa nuarul de participanţi implicaţi în interactiune, dupa nuarul de schimburi, dupa

necesitatile de rutare sau dupa cerinta de a primi sau nu raspuns.

[Brogi04], [Busi05] şi [Gorrieri05] analizează formalismul coregrafiei pentru serviciile

web unele dintre ele utilizand algebre de proces, afirmand inttre altele ca pi-calculus nu este

necesar pentru descrierea coregrafiilor serviciului şi ca retelele Petri nu sunt adecvate în acest

scop, ultimele, ne putand reprezenta în totalitate sabloanele pentru workflow, recurgandu-se

la elaborarea unor instrumente mai adecvate, Yawl [Aalst03]. Lucrările mentionate anterior ca

de altfel şi WS-CDL, iau în considerare numai interactiunile simple: într-o singura directie şi

cea cu cerere-raspuns.

În pi-calculus [Barros05a] un mesaj este reprezentat printr-un nume şi este transmis

sincron şi receptionat, rezultand o interactiune (procesul care doreste să transmita un mesaj se

blochează pana cand procesul receptor primeste mesajul).În pi-calculus se considera

comunicarea sincrona ca fiind sigura şi livrarea mesajului fiind cazul implicit.

Coreografia prezinta sabloanele utilizate de interfaţa unui serviciu web. Aceste sabloane

prezinta modalitatea în care cunsumatorul va interactiona cu interfaţa serviciului web. O

problema o constituie modelarea coregrafiei independent de definirea workflow-ului pentru

care este utilizata. Independenta conduce la doua probleme[Haller06], [Haller06a]:

● daca orice modificare oaapre în workflow-ul intern, coreografia trebuie să fie sincronizata

manual cu definitia worflw-ului;

● nu exista posibilitatea de a verifica automat consistenta descirerii workflow-ului intern cu

interfetele (externe) ale coregrafiei.

Ca şi exemplu, în Figura 20 unde este reprezentată o colaborare în RosettaNet şi un

model de proces reprezentat printr-o diagrama de activtaţi în UML. Activităţile publice sunt

prezentate în negru iar activităţile private în alb. Coreografia distribuitorului (seller) este

formata din activităţile prezentate în negru în culoarul drept iar coreografia cumapratorului

prin activităţi în negru în culoarul din stanga.

Pentru a putea extrage automat interfaţa pentru coregrafie procesul intern trebuie să

contina informaţii necesare pentru procesele externe cu care el colaboreaza.


50

Figura 20 Exemplu de colaborare RosettaNet


51

4 Limbaje de orchestrare

Într-o arhitectură software care îşi propune să elaboreze un mediu bazat pe servicii Web

(interne şi externe) care interacţionează între ele, termenul de orchestrare a fost introdus

pentru a descrie fluxul acestor comunicaţii ca un proces business multi-pas, long-lived din

punctul de vedere al unui partener. Limbajele utilizate pentru a scrie aceste procese într-un

mod în care sistemele software (adică motoarele de execuţie) le pot executa se numesc

limbaje de orchestare.

În ultimii 15 ani s-au depus multe eforturi în domeniul limbajelor de orchestrare. Printre

primele propuneri se numără XLANG, proiectat de Microsoft pentru BizTalk Server sau

WSFL propus de IBM. Aceste două limbaje au fost înlocuite de către BPELWS creat de către

Microsoft împreună cu IBM şi BEA.

O altă direcţie urmată a fost cea propusă de WfMC care a rezultat în publicarea

limbajului XPDL versiunea 1.0 în 2002, iar pentru a fi pe deplin compatibil cu BRMN, acesta

a evoluat la versiunea 2.0 în 2005. În aprilie 2008, WfMC a ratificat XPDL 2.1 care suportă

BPMN 1.1.

Cea de-a treia importantă iniţiativă în domeniul standardelor de orchestrare a fost creată

de către OASIS, UN/CEFACT şi câteva corporaţii comerciale precum Intel şi SAP şi a dus la

publicarea familiei de standarde ebXML, cu CPPA pe post de limbaj de orchestrare.

Versiunea 2.0 a fost aprobată ca standard ISO 15000.

Scopul acestui capitol este de a trece în revistă şi de a compara standardele de

orchestrare cu scopul de a recomanda cele mai potrivite limbaje de orchestrare în cadrul

proiectului SCIPA. Fiecare dintre limbajele analizate va fi descris succint şi a fost evaluat pe

baza unor criterii de piaţă şi tehnice.

Tabela 1 prezintă criteriile de piaţă utilizate pentru evaluarea standardelor de coregrafie

şi orchestrare.

Criteriu de piaţă Explicaţie

Disponiblitatea unei versiuni stabile, mature

a specificaţiilor

Specificaţia este acceptată de organizaţie

Implementări open-source / comerciale

disponibile

Existenţa unor implementări open-source sau

comerciale

Standarde înlocuitoare Acest standard a fost înlocuit de alte

standarde

Evoluţia specificaţiilor Standardul va fi înlocuit de o versiune a altui

standard

Compatibilitate cu versiuni anterioare Standardul este compatibil cu versiunile

anterioare

Standard deschis Standardul este disponibil şi poate fi utilizat

gratuit

Experienţa consorţiului Membrii consorţiului SCIPA cunosc şi au

folosit/folosesc acest standard

Tabela 1 Criteriile de piaţă utilizate la evaluarea standardelor de orchestrare


52

Tabela 2 sumarizează criteriile tehnice folosite pentru evaluarea standardelor de

orchestrare, cu explicarea semnificaţiei fiecărui criteriu. Primele criterii tehnice sunt similare

cu cele folosite la coregrafie, în timp ce ultimele sunt specifice orchestrării.

Criteriu tehnic Explicaţie

Elemente de control (loop, choice, etc) Prezenţa elementelor de control

specifice limbajelor de programare

Fire de execuţie paralele Se pot specifica fluxuri paralele de

activităţi

Suport pentru structuri precum module/procese Suport pentru elemente reutilizabile,

precum modulele, procese predefinite

Suport pentru subfluxurilor (subflows) Permite folosirea subfluxurilor

Structuri complexe Permite specificarea şabloanelor de

flux complexe precum şi structuri de

date complexe

Fluxul de date Se pot specifica fluxuri de date în

cadrul proceselor

Compatibilitate cu WSDL Standardul este compatibil cu WSDL

Compatibilitate cu BPMN Standardul este compatibil cu BPMN

Selectarea binding-urilor / endpoint-urilor Permite specificarea protocoalelor şi

punctelor de conexiunea pentru

comunicaţii de nivel jos

Suport pentru tratarea erorilor Permite specificarea comportamentului

în cazurile de eroare

Suport pentru compensare Permite specificarea compensării

comportamentului eronat

Suport pentru procesarea tranzacţiilor Suportă comnucaţii tranzacţionale, de

exemplu proprietăţi tip ACID

Suport pentru interacţiunea cu roluri / utilizatori

umani

În plus faţă de servicii implemetate ca

procese, interacţiunea cu operatorii

umani este suportată

Exceutabil Un fişier pregătit poate fi executat de

către un motor (engine)

Definiţie formală Notaţia folosită, de exemplu scheme

XML

Extensibilitate Permite adăugarea de elemente noi,

nestandard

Independent de platformă Standardul nu este dedicate unei

platforme hardware sau software

Securitate Mecanismele de securitate sunt parte a

standardului

Constrângeri legate de timing Permite specificarea constrângerilor

legate de timing (de exemplu timeout-

uri)

Calitatea serviciilor / prioritizări Permite prioritizarea task-urilor

Suportă conceptul ―programming-in-the-small‖ Permite executarea în timpul unui flux

a unei bucăţi de cod scrisă într-un

limbaj de programare

Tabela 2 Criteriile tehnice utilizate la evaluarea standardelor de orchestrare


53

Aceste criterii sunt folosite pentru fiecare standard analizat în acest capitol astfel încât

cititorului îi este oferită o imagine de ansamblu care pune în evidenţă plusurile şi minusurile

fiecărui standard. Pentru toate criteriile care presupun un răspuns ―binary‖, s-au folosit

următoarele notaţii:

+ standardul satisface criteriul

- standardul nu satisface criteriul

0 standadrul satisface criteriul părţial

na crieteriul nu se aplică pentru acest standard

Există de asemenea criterii care necesită un răspuns ―textual‖, de exemplu care

standarde au fost înlocuite sau vor fi înlocuite de către standardul evaluat.

4.1 Web Services Business Process Execution Language (WSBPEL)

Standardul Web Services Business Process Execution Language WSBPEL, sau

BPEL4WS cum a fost numit în primele sale versiuni, a fost introdus de către BEA, IBM şi

Microsoft. BPEL4WS versiunea 1.0 a ieşit pe piaţă în iulie 2002 şi a fost o combinaţie între

limabjele WSFL (propus de Microsoft) şi Xlang (propus de IBM) [BPEL4WS10]. În aprilie

2003, un comitet tehnic a fost fondat în cadrul OASIS compus din BEA Systems, IBM,

Microsoft, SAP şi Siebel Systems cu scopul de a continua dezvoltarea idei BPEL4WS.

Versiunea 1.1 a fost publicată în mai 2003 [BPEL4WS11]. În continuare, în septembrie 2004,

comitetul a decis să schimbe denumirea noii versiuni în lucru (draft) a standardului la

WSBPEL 2.0. Modificarea numelui şi a versiunii reflectă diferenţele semnificative, şi în

multe cazuri incompatibile, între BPEL4WS 1.1 şi WSBPEL 2.0 [BPEL_WIKI]. WSBPEL

2.0 este ultima versiune a standardului şi este accesibilă aici [BPEL_oasisIntro]. În iunie

2007, Active Endpoints, Adobe, BEA, IBM, Oracle şi SAP au publicat specficaţiile pentru

BPEL4People şi WS-HumanTask care descriu modul în care poate fi implementată

interacţiunea cu utilitzatorul uman în procele BPEL.

WSBPEL 2.0 este un limbaj deschis, bazat pe XML, pentru specificarea formală a

proceselor de business, precum şi a protocoalelor de interacţiune business. Astfel, fiecare

organizaţie care suportă BPEL poate efectua unul sau mai mulţi paşi ai proceselor de business

în acelaşi mod. Standardul defineşte un model de integrare interoperabil care ar trebui să

permită expansiunea integrării proceselor automate atât în spaţiul intra-corporaţie cât şi în

spaţiul business-to-business [BPEL_santeon].

WSBPEL 2.0 suportă atât conceptul programming-in-the-large1 cât şi programming-in-

the-small. Logica generală a procesului poate fi implementată folosind programming-in-the-

large, care le permite analiştilor de business să-şi exprime ideile într-un mod formal, fără a fi

implicaţi în detaliile tehnice. Problemele arhitecturale şi detaliile de programare sunt tratate de

către programatori folosind abordarea programming-in-the-small.

1 Programming-in-the-large se poate referi cod program ce reprezintă tranziţiile de stare

de nivel înalt într-un system informatic.Această logică codifică informaţii precum momentul

când se aşteaptă mesaje, când se trimit mesaje, când se compensează tranzacţiile non-ACID

(Atomicity, Consistency, Isolation, and Durability) care au eşuat etc. Programming-in-the-

small tratează comportamentul de scurtă durată, deobicei executat ca o unică tranzacţie ACID

şi care permite accesul la resurse şi logică locală, cum ar fi fişierele, bazele de date etc.


54

Unul dintre scopurile WSBPEL 2.0 este de a ―diminua costul stabilirii proceselor de

business automate inter-întreprinderi (cross-enterprise)‖ [BPEL_ebpml].


Cum şi în ce domenii este folosit

―Grupul de lucru BPEL dă impresia că WSBPEL va fi focusat pe domeniul

relaţionărilor B2B‖ [BPEL_ebpml] WSBPEL poate fi aplicat în două moduri diferite,

deoarece un process WSBPEL poate defini:

Un protocol de business (coregrafie) folosind noţiunea de process abstract

Un process de business executabil (orchestrare), adică logica şi starea procesului vor

determina natura şi secvenţa interacţiunilor dintre serviciile Web executate la fiecare

partener şi astfel protocoalele de interacţiune.

Acceptanţa din partea clienţilor

Este posibilă convertirea automată a grafurilor BPMN la scripturi WSBPEL.

Există o largă acceptanţă a standardului WSBPEL de către mulţi utilizatori şi

dezvoltatori. După cum este exprimat în [BPELJ_ibmDN], “(…) BPEL va fi cel mai folosit

standard pentru procesele de business bazate pe servicii Web”.

Disponibilitatea produselor / uneltelor

Există mai multe produse software open-source care suportă BPEL, de exemplu:

Cape Clear suportă BPEL4WS 1.1, este o soluţie ―all în one‖, care include:

modelatorul de procese, motorul workflow, managerul şi monitorul; în data de

februarie 6, Cape Clear a fost achiziţionată de Workday Inc.

Oracle BPEL Process Manager implementează specificaţiile BPEL4WS versiunea 1.1

incluzând modelatorul, motorul de execuţie şi o unealtă de administrare

Borland Together Designer creează BPEL4WS din diagrame BPMN

Motorul ActiveBPEL, care suportă unele elementele din WSBPEL2.0

Standard deschis / închis

WSBPEL is este un standard deschis. Este disponibil în întregime, cu unele motoare şi

unelte open-source care îl folosesc. Standardul evoluează rapid şi există un mare interes în

jurul lui.

Standarde înlocuite

WSBPEL 2.0 este dezvoltat în continuare şi nu este prevăzut ca acest standard să fie

înlocuit cu altul în viitorul apropiat. Deoarece WSBPEL 2.0 a fost publicat ca standard

OASIS relativ recent, 11 aprilie 2007, nu există multe unelete care să suporte complet acest

standard. De exemplu, ActiveBPEL 2.0 suportă unele elemente ale noului standard, dar încă

nu este un produs compatibil 100%. Din acest motiv, unele companii (de exemplu IBM

[BPEL4WS11]) încă recomandă utilizarea BPEL4WS 1.1 ca limbaj de execuţie a proceselor

pentru aplicaţii dezvoltate pe arhitecturi SOA.

Unele funcţionalităţi ale BPEL4WS au fost eliminate din WSBPEL2.0, în timp ce altele

noi au fost introduse. De exemplu, conceptual de ―partener‖ nu mai există în WSBPEL


55

deoarece funcţionalităţile ―partnerLinks‖ sunt suficiente pentru a descrie procesele. Legăturile

nu mai pot depăşi graniţele scopurilor din cadrul activităţilor structurate. Acest lucru a fost

introdus pentru a simplifica schema rutinei (handler) de compensare. Sistemul de mesagerie

din BPEL4WS prezintă câteva aspecte nespecificate. În WSBPEL, o eroare standard numit

―missingReply‖ a fost adăugată pentru a trata lipsa de răspuns ca eroare, faţă de versiunea 1.1

a standardului în care acest caz era lăsat la latitudinea dezvoltatorilor. Un alt exemplu este

handler-ul de eveniment a cărui iniţializare nu mai este lăsată complet în seama

dezvoltatorilor. Tipurile de date în WSBPEL sunt mai bine controlate, fiind folosit un model

de date (data model) pentru reprezentarea variabilelor. Acest model de date este acompaniat

de un set de reguli pentru maparea lui pe diferite limbaje.

Deoarece există deosebiri importante între BPEL4WS şi WSBPEL, migrarea automată

între aceste două standarde nu este posibilă. Această migrarea necesită o reproiectare a

proceselor de business, iar efortul intelectual uman este esenţial pentru reuşita acestui transfer.

Criteriu de piaţă BPEL4WS

1.1

WSBPEL 2.0

Stabilitate, existenţa unei versiuni mature a

specificaţiilor

+ -

Disponibilitatea implementării

Open source/Comercială

+/+

-/

Înlocuit - -

În evoluţie + +

Backward compatible na -

Standard deschis + +

Experienţa consorţiului + -

Tabela 3 Criterii de piaţă BPEL4WS / WSBPEL


Concepte de bază

WSBPEL defineşte o notaţie pentru specificarea comportamentului procesului de

business folosind servicii Web. Procesul de business poate fi descris în două moduri:

Process de business executabil care modelează comportamentul efectiv al unui

participant într-o interacţiune de business.

Protocoalele de business, pe de altă parte, folosesc descrieri de procese care specifică,

pentru fiecare parte implicată în protocol, comportamentul pe baza schimbului mutual

de mesaje, fără a dezvălui comportamentul intern. Descrierile de procese pentru

protocoale de business se numesc procese abstracte.

WSBPEL modelează atât comportamentul proceselor executabile, cât şi al proceselor

abstracte. Standardul include:

Secvenţializarea activităţilor unui process, în mod special interacţiunile serviciilor

Web

Corelarea mesajelor şi a instanţelor de process

Modul de recuperare în cazul erorilor şi a condiţiilor excepţionale

Relaţii bilaterale bazate pe servicii Web între diferitele roluri de process


56

Granularitatea

Limbajul are o notaţie şi o organizare bazată pe XML. Elementele atomice ale

limbajului se numesc activităţi de bază, cum ar fi: ―receive‖, ―reply‖, ―invoke‖, ―assign‖,

―validate‖, ―empty‖, ―throw‖, ―rethrow‖, ―exit‖, ―wait‖, ―compensate‖, ―extensionActivity‖.

Există de asemenea activităţi structurate, cum sunt cele prezentate în Figura 21.

Figura 21 Activităţi WSBPEL

Notaţia folosită

WSBPEL oferă o notaţie XML şi semanică pentru specificarea comportamentului

proceselor business bazat pe servicii Web.

Extensibilitatea

Atribute calificate prin spaţii de nume pot fi specificate pentru orice element BPEL şi

elemente BPEL din alte spaţii de nume pot fi specificate în cadrul unui element BPEL.

Tratarea erorilor, suport pentru compensare

Activităţi pentru compensare şi tratarea erorilor sunt disponibile în standard. În plus,

―alarm events‖ pot fi invocate la expirarea termenului (timeout). Pentru a suporta recuperarea

din eroare în cazul unor procese de lungă durată (long-running), un model cu tranzacţii de

lungă-durată este definit.

Dependenţe / interoperabilitate cu alte limbaje / notaţii

Notaţia limbajului este bazată pe XML şi este posibil să se genereze cod WSBEL din

majoritatea diagramelor BPMN.


57

Orientarea pe servicii Web

Serviciile Web sunt modele pentru descompunerea şi asamblarea proceselor. WEBPEL

este bazat pe standarde ce ţin de serviciile Web într-un mod composabil şi modular.

Bazat pe XML sau alt formalism

WSBPEL este bazat pe XML.

Suport pentru structuri complexe sau şabloane

WSBEL oferă suport pentru următoarele structuri:

limbaj de execuţie a proceselor de business pentru şabloane de folosire, incluzând atât

descriptori pentru interfaţa procesului, cât şi modele de procese executabile

sunt disponibile implementări pentru activităţi structurate, de exemplu:

o flow: activităţile conţinute sunt executate în parallel, părţial ordonate prin legături

de control

o pick: blochează şi aşteaptă pentru sosirea unui mesaj potrivit sau expirarea

timpului

suport pentru imbricarea structurată a scopurilor

Suport pentru constrângeri de timp/timing

Sunt suportate constrângeri de timp la nivel de eveniment, care sunt declanşate de

apariţia timeout-urilor ca instanţe WSBPEL

Informaţii/tratarea datelor

Data Handlers. Procesele de business modelează interacţiuni bazate pe stări (stateful

interactions). O stare este formată din mesajele recepţionate şi trimise, plus alte date

relevante, cum ar fi valorile de timeout. Menţinerea stării procesului de business necesită

folosirea unor variabile de stare, care sunt denumite variabile în WSBPEL. În continuare,

datele unei stări sunt extrase şi combinate în moduri interesante pentru a controla

comporatamentul procesului, care necesită expresii de date. În final, actualizarea stării

necesită noţiunea de asignare. WSBPEL oferă aceste funcţionalităţi pentru tipurile de date

XML şi tipurile de mesaje WSDL. Familia de standarde XML în acest domeniu este în curs

de dezvoltare, şi folosind atribute la nivel de process pentru interogări şi limbaje de expresii

oferă o platformă pentru încorporarea standardelor viitoare.

Extensiile necesare pentru procesele abstracte sau executabile sunt concentrate în setul

de facilităţi pentru tratarea datelor (data handling). Proceselor executabile le este permis să

folosească valori nederministe. Procesele abstracte sunt restricţionate la manipularea limitată

a valorilor conţinute în proprietăţile mesajului, dar le este permisă folosirea valorilor

nedeterministe pentru a reflecta consecinţele comportamentului ascuns privat. Diferenţele

detaliate sunt explicate în secţiunile ce urmează.


58

Event Handlers. Un întreg proces, precum şi fiecare scop2, poate fi asociat cu un set de

handlere de eveniment care sunt invocate concurent la apariţia evenimentului respectiv.

Acţiunile executate în cadrul unui handler de eveniment pot fi orice tip de activitate, de

exemplu o secvenţă sau un flux (flow). Handlere de eveniment pot fi folosite pentru mesaje,

alarme, tratarea erorilor. Folosind handlere de eveniment, evenimentele pot fi activate,

procesate sau dezactivate.

Fault handlers. Tratarea erorilor într-un process de business poate fi văzută ca un

selector de mod din secvenţa normală de procesare. Tratarea erorilor în WSBPEL este

întotdeauna tratată ca ―reverse work‖ prin aceea că singurul ei scop este de a anula (undo)

lucrurile făcute părţial sau fără succes în scopul în care a apărut eroarea. Terminarea activităţii

unui fault handler, chiar dacă nu reactivează (rethrow) eroarea tratată, nu este niciodată

considerată ca o terminare cu succes a scopului în care a apărut şi compensarea nu este

activată niciodată pentru un scop în care a fost invocat un fault handler.

Compensation Handlers. Scopurile pot descrie o parte a comportamentului care se

presupune că poate fi reversibil într-un mod definit de aplicaţie prîntr-un handler de

compensare. Scopurile cu handlere de compensare şi tratare de erori pot fi încuibate fără nici

o constrângere legată de adâncime.


Există un număr seminificativ de produse care suportă acest standard. Unii dintre

partenerii proiectul SCIPA au experienţă în utlilizarea acestui standard dobândită în urma

participării în alte proiecte europene sau naţionale. WSBEL este un candidat serios cu

avantajele că este open-source (fapt ce va evita costurile de licenţiere), se oferă suport, poate

fi generat cod WSBPEL din diagrame BPMN şi, nu în ultimul rând, unii parteneri au o

experienţă considerabilă cu acest standard. În plus, întreţinerea codului scris WSBPEL va fi

suportată la nivel larg datorită popularităţii acestui standard. WSBPEL acoperă mai multe arii

ce ţin atât de coregrafie cât şi de orchestrare.

Criteriu tehnic BPEL4WS

1.1

WSBPEL 2.0

Elemente de control (loop, choice, etc) 0 0

Fire de execuţie paralele + +

Suport pentru structuri precum module/procese + +

Suport pentru subfluxurilor (subflows) 0 +

Structuri complexe 0 0

Fluxul de date + +

Compatibilitate cu WSDL + +

Compatibilitate cu BPMN 0 0

Selectarea binding-urilor / endpoint-urilor + +

Suport pentru tratarea erorilor + +

Suport pentru compensare + +

2 Scopul într-o secvenţă program este un set de linii imbricate între expresii speciale de

început, respectiv de sfârşit. În unele limbaje, scopurile determină scopul unei variabile sau

spaţii de nume.


59

Suport pentru procesarea tranzacţiilor + +

Suport pentru interacţiunea cu roluri / utilizatori umani - -

Exceutabil + +

Definiţie formală XML XML

Extensibilitate - 0

Independent de platformă - +

Securitate - -

Constrângeri legate de timing + +

Calitatea serviciilor / prioritizări - -

Suportă conceptul ―programming-in-the-small‖ - -

Tabela 4 Criterii tehnice BPEL4WS / WSBPEL

4.1.4 Rezumat

Avantaje

WSBPEL acoperă atât coregrafia cât şi orchestrarea. Permite analiştilor de piaţă să

descrie procesele de business, şi există extensii ale limbajului precum expressile XPath,

mecanisme şi motoare de execuţie. Deasemenea, există unelte pentru generarea automată a

codului WSBPEL din diagrame BPML. În versiunea originală, BPEL nu are legătură cu nici

un limbaj de tipul programming-in-the-small. Astfel, este abstractizat faţă de detaliile tehnice

şi este independent de platformă.

Dezavantaje

În versiunea originală, BPEL nu poate fi folosit cu succes pentru decrierea proceselor

in-the-small. Detaliile tehnice nu sunt în scopul acestui standard, astfel încât trebuie să fie

folosit un alt limbaj pentru a obţine cod exceutabil din descrierile BPEL. Uneltele BPEL

existente comliează codul BPEL în limbaje de programare precum Java şi permite

specificaţiilor BPEL să fie extinse prin fragmente de limbaj de programare.

Recomandări

BPEL poate fi folosit ca un limbaj de nivel jos pentru descrierea proceselor de business

ce implică relaţii atât B2B cât şi B2C. BPEL acţionează şi ca un ―bridge‖ între limbajele

graphice de nivel înalt (de ex BPML) şi limbajele ce suprotă doar paradigma programming-in-

the-small. Codul BPEL poate fi generat automat din diagramele BPML. BPEL este un

standard în evoluţie cu un puternic srijin din partea pieţei.

BPEL4WS 1.1 poate fi recomandat pentru SCIPA ca limbaj de nivel jos datorită

avantajelor sale: este gratuit, deschis, matur, suportat de majoritatea furnizorilor importanţi,

cum ar fi BEA sau IBM. Suportă majoritatea funcţionalităţilor care sunt importante pentru

SCIPA, cum ar fi servicii Web, tratarea erorilor sau constrângerile de temporizare.

Deasemnea, sunt numeroase unelte, atât open-source cât şi comericale, petru modelarea şi

exceuţia proceselor. Din nefericire, WSBPEL 2.0 este un standard foarte nou, nu este

compatibil cu versiunea anterioară (BPEL4WS 1.1), iar uneltele disponibile nu sunt foarte

numeroase.


60

4.2 XML Process Definition Language (XPDL)

Limbajul XPDL (XML Process Definition Language) este proiectat de către WfMC

(Workflow Management Coalition), o organizaţie care are peste 300 de membrii, printre care

IBM, Lucent Technologie, sau SAP AG, organizaţii de reprezintă toate faţetele procesului de

lucru, de la vânzători la utilizatori, de la academicieni la consultanţi.

Imediat după înfinţarea sa, WfMC a început lucrul la crearea unui limbaj sandardizat

pentru definirea proceselor de lucru (workflow3). Astfel, a rezultat Workflow Process

Definition Language (WPDL) prezentat întâia oară în 1999. Cu toate că mulţi vânzători au

pretins că respectă WPDL, puţini au făcut eforturile necesare pentru a suporta acest limbaj.

Între timp, XML a devenit standardul pentru schimbul de date. Deoarece WPDL nu era bazat

pe XML, plecând de la WPDL, WfMC a început lucrul la un nou limbaj denumit XML

Process Definition Language (XPDL). Oricum, XPDL nu trebuie considerată versiunea XML

a limbajului WPDL deoarece concepte noi au fost adăugate, iar unele concepte au fost

eliminate. Chiar WfMC nu are poziţie clară privind relaţia între XPDL şi WPDL. În

octombrie 2002, WfMC a făcut publică versiunea finală a XPDL 1.0 [XPDL1.0]. Versiunea

2.0 a XPDL a fost aprobată ca un standard oficial al WfMC în septembrie 2005 şi este

backward compatibilă cu versiunea 1.1 [XPDL2.0].

WfMC a dezvoltat modelul de referinţă pentru workflow-uri după cum este prezentat în

Figura 22. În acest model au fost identificate cinci interfeţe funcţionale ale unui proces sau

serviciu workflow, ca parte a programului de standardizare WfMC [WFMC_RM].

Figura 22 WfMC Workflow Reference Model

3 Datorită faptului că este un termen deja consacrat şi în limba română, pentru referirea la

procesele de lucru vom folosi termenul din engleză pe tot parcursul acestei lucrări.


61

Interface 1 suportă schimbul de descriptori de workflow, de exemplu modele,

coregrafii sau orchestraţii, între uneltele de modelare şi

alte unelte de modelare

depozite

unelte de execuţie a workflow-urilor.

Interface 2 suportă apelul motorului de execuţie de către clienţii workflow-ului.

Interfaţa poate fi implementată, de exemplu, ca o interfaţă WSDL îmbunătăţită sau ca o

interfaţă a unui limbaj de programare.

Interface 3 suportă apelul aplicaţiilor care execută activităţile externe specifice

workflow-ului. Această interfaţă poate fi implementată, de exemplu, ca o interfaţă WSDL

îmbunătăţită, ca o interfaţă a unui limbaj de programare sau prîntr-un mecanism de notificare

a actorului uman.

Interface 4 suportă colaborarea între workflow-uri, siutate posibil în alte domenii.

Interface 5 suportă administrarea şi monitorizarea workflow-urilor, inclusiv

managementul ciclului de viaţă a workflow-urilor distribuite.

XPDL 2.0 face parte din documentaţia legată de ―Interface 1 - supporting Process

Definition Import and Export‖.


Motoarele de exceuţie XPDL sunt incluse în produse utilizate de diverse organizaţii,

cum ar fi companii comericale (de exemplu, T-Mobile utilizează WfMOpen) sau agenţii

guvernamentale (de exemplu, CIA şi Terrorist Threat Information Center utilizează Zaplet ce

a adoptat Open Business Engine, iar unele entităţi ale guvernului olandez folosec InProcess de

la Brein BV).

Cum şi în ce domenii este folosit

XPDL este folosit pentru definirea de descrieri executabile de workflow-uri care pot fi

executate de căre motoarele de execuţie specializate, denumite wokflow engine.

Acceptanţa din partea clienţilor, uşurinţa înţelegrii, uşurinţa învăţarii

Analiştii de business (business analysts) Nu este un standard proiectat pentru

modelare, adtfel încât este dificil de înţeles fără un fundament tehnic, în special cunoaşterea

limbajului XML.

Dezvoltatorii (technical developers) XPDL este uşor de înţeles pentru dezvoltatori

deoarece este bazat pe XML. Toate denumirile atributelor şi elementelor sunt descriptive,

uşor de înţeles.

Produse şi unelte disponibile

Există numeroase motoare de execuţie a workflow-urilor care folosec XPDL ca limbaj

de implementare a proceselor, dintre care amintim unele open-source: Enhydra Shark,

WfMOpen, Open Business Engine. Modelarea este deasemenea suportată de numeroase

unelte, cum ar fi Open Source Enhydra JaWE.


62

Din nefericire, este dificil de a găsi unelte care suportă versiunea 2.0 a specificaţiilor.

Implementări disponibile includ Interstage Business Process Manager Studio de la Fujitsu şi

InProces de la Brein BV, dar ambele nu sunt disponibile gratuit şi nu sunt open-source.

Standard deschis/închis

Standardul este unul deschis.

Standarde pe care le înlocuieşte

XPDL este o versiune reproiectată a WPDL.

Criteriu de piaţă XPDL 1.0 XPDL 2.0


specificaţiilor

+ +



+/+

-/0

Înlocuit + -

În evoluţie + -

Backward compatible na +

Standard deschis + +

Experienţa consorţiului puţină -

Tabela 5 Criterii de piaţă XPDL


Concepte de bază

Specificaţia XPDL utilizează limbajul XML ca mecanism pentru inter-schimbul de

definiţii de proces. XPDL defineşte un standard de inter-schimb comun ce permite produselor

să continue utilizarea de reprezentări interne arbitrare pentru definirea proceselor, atât timp

cât oferă o funcţionalitate de import/export pentru a mapa din/către standardul comun de

inter-schimb.

Gramatica XPDL este direct realţionată la aceste obiecte şi atribute. Această abordare

are nevoie de 2 operaţii care trebuie să fie oferite de către vânzător:

Importul unei definiţii de proces din XPDL

Exportul unei definiţii de proces din reprezentarea internă în XPDL

Un vânzător poate folosi foi de stil XSL pentru a implementa aceste două operaţii. Un

pachet XPDL corespunde unei diagrame BPD (Business Process Diagram) din BPMN şi este

alcătuit dintr-o mulţime de definiţii de proces.

Definiţia unui proces poate să conţină referinţe la subflow-uri definite separat, care

alcătuiesc împreună definiţia globală a procesului. O definiţie iniţială a procesului va conţine

cel puţin setul minimal de obiecte şi atribute necesare pentru a iniţia şi suporta execuţia

procesului. Unele dintre aceste obiecte şi atribute vor fi moştenite de fiecare instanţă a

procesului.

Metamodelul descrie entităţile de nivel cel mai înalt (top-level) conţinute în cadrul unei

definiţii de proces, relaţionările dintre ele şi atributele, inclusiv unele ce pot fi definite în


63

scopul simulării sau monitorizării. Deasemenea, mai defineşte diverse convenţii pentru

gruparea definiţiilor de proces în modele de procese relaţionate, precum şi utilizarea

definiţiilor de date comune pentru diferite definiţii de proces sau modele.

Modelul procesului include diverse entităţi a căror scop poate fi mai larg decât o singură

definiţie de proces. În particular, definiţiile participanţilor, aplicaţiilor şi datelor relevante pot

fi referite din mai multe definiţii de proces. Metamodelul presupune utilizarea unui depozit

comun de definiţii de proces care va stoca diferitele tipuri de entităţi care alcătuiesc definiţia

procesului. În cadrul depozitului şi pentru a suporta transferul eficient a definiţiilor de proces

către/din depozit a fost introdus concepul de pachet. Un pachet este un container pentru

gruparea entităţilor comune din mai multe definiţii de proces diferite, pentru a evita

redefinirea în cadrul fiecărei definiţii de proces.

Pachetul oferă un container pentru păstrarea mai multor atribute comune definiţiilor de

proces, cum ar fi autorul, versiunea, starea etc. Fiecare definiţie de proces din cadrul

pachetului va moşteni automat toate atributele comune definite la nivel de pachet, exceptând

cazul în care ele sunt respecificate local în cadrul defintţiei de proces. Un pachet XPDL

corespunde unei diagrame de proces din BPMN.

În cadrul unui pachet, scopul definiţiilor de atribute este global şi aceste entităţi pot fi

referite din toate definiţiile de proces (plus activităţile şi tranziţiile asociate) conţinute în

cadrul pachetului.

Metamodelul pachetului identifică entităţile şi atributele pentru schimbul sau stocarea

modelelor de proces. El defineşte regulile de moştenire în vedera asocierii unei definiţii de

proces individuale cu definiţiile entităţilor pentru specificarea participanţilor, declararea

aplicaţiilor şi câmpurile de date relevante, care pot fi definite la nivelul pachetului în loc de

nivelul definiţiilor de proces individuale.

Granularitatea

XPDL permite specificarea fiecărei activităţi4 şi eventiment de la nivelul unui proces.

Notaţia folosită

XPDL foloseşte limbajul şi notaţia XML.

Extensibilitatea

Cu toatea că modelul şi XPDLul asociat conţin majoritatea construcţiilor care ar putea

să fie cerute în schimbul definiţiilor de proces, s-ar putea să existe cazuri în care informaţii

adiţionale (specifice utilizatorului) sunt necesare în cadrul definiţiei unui proces. Utilizatorii şi

vânzătorii sunt încurajaţi să lucreze pe cât posibil cu setul standard de entităţi şi atribute; în

cazul în care extensiile sunt necesare, schema XPDL oferă un mod standard pentru extinderea

ei cu extensii specifice utilizatorilor.

Metoda de bază pentru aceste extensii este utilizarea atributelor extinse. Atributele

extinse sunt acelea definite de utilizator sau vânzător pentru a exprima o caracteristică

4 O activitate reprezintă o unitate de lucru (de exemplu, ―send invoice‖), care va fi

procesată de o combinaţie de resurse (specificate prin asignarea participanţilor) şi / sau

aplicaţii informatice (specificate prin asignarea aplicaţiilor).


64

suplimentară a entităţilor. Schema XPDL suportă extensii calificate prin nume de spaţiu

pentru toate elementele XPDL. Elementele XPDL pot fi extinse prin adăugarea de elemente

fiu şi noi atribute [Shapiro05].


Versiunea XPDL 1.0 permite specificarea compensaţiei unei activităţi. Versiunea 2.0 a

adăugat capabilităţi pentru:

a specifica în ce condiţii se poate executa o compensare după terminarea normală a unui

proces

a defini evenimente pentru proces şi a arăta munca adiţională necesară compensaţiei

a prinde şi arunca erori şi pentru a încheia un proces prin generarea unei erori. Această

eroare va fi prinsă de către un eveniment numit Intermediate Event


XPDL foloseşte aceeaşi terminologie ca BPMN. Fluxurile de mesaje care sunt folosite

pentru a reprezenta comunicarea între pricese sunt bazate pe protocoale Web Services

Description Language (WSDL). Notaţia XPDL este bazată pe XML.


XPDL este orientat pe servicii Web. O activitate a unui proces poate apela un serviciu

Web. Elementul ExternalReference, definit în specifcaţiile XPDL, poate fi folosit ca o

referinţă la aplicaţii şi tipuri de date care sunt definite în documentele serviciilor Web

(WSDL). Este de asemenea posibil să se proceseze erorile generate de operaţiile serviciilor

Web. Sistemul de mesagerie în XPDL este bazat pe modelul WSDL.

Un alt concept definit în specificaţiile XPDL este Partner Link. Legăturile la parterneri

(partner link) defineşte o legătură între doi parteneri, fiecare asumându-şi un rol în

comunicare. Din perspectiva modelării, rolurile sunt date în mod normal de numele fondului

comun (pool) sau a benzii (lane). Dacă este folosit în acest mod, fluxul de mesaje dintre două

pool-uri va corespunde unei legături partener, cu fiecare rol corespunzând numelui pool-ului.

Relaţia furnizor – cumpărător, reprezentaţi prîntr-un pool sau rol, într-un protocol de tip lanţ

de distribuţie (supply chain) poate fi un bun exemplu de astfel de legături partener.

Legăturile partener sunt opţionale şi utilizate în mod normal pentru modelarea

comuncaţiei la un nivel abstract folosind WSDL şi tipuri de porturi. Un element special al

XPDL, mai precis operaţie de tip serviciu Web (WebServiceOperation), poate folosi o

legătură partener pentru modelarea abstractă a unui serviciu când un serviciu Web şi numele

portului sunt folosite în locul unui tip de port. Legăturile partener sunt definite la două nivele:

nivelul pachet: tipul legăturii partener defineşte un nume şi unul sau două roluri.

Informaţiilee de bază ale unei legături sunt definite la acest nivel.

nivelul proces: legătură însăşi este definită folosind tipul legăturii partener. Aceata

permite reutilizarea tipurilor de legături la nivelul pachetului.


XPDL este bazat pe XML.


65

Suport pentru structuri complexe sau şabloane

Şabloane ce pot fi descrise în XPDL (folosit workaround-uri uneori), pe baza

şabloanelor de workflow descrise în [Aalst03c]:

Şabloane de flux (flow patterns)

o Multiple Choice

o Synchronising merge

o Multiple Merge (doar XPDL 2.0)

o Discriminator (doar XPDL 2.0) [Wohed05] [Aalst03d]

Şabloane structurale (structural patterns):

o Arbitrary cycles

o Implicit termination [Aalst03d]

Şabloane pentru reprezentarea instanţelor multiple (multiple instances patterns):

o MI fără Synchronisation

o MI cu Priori Design Time Knowledge (doar XPDL 2.0)

o MI cu Priori Runtime Knowledge (doar XPDL 2.0) [Wohed05][Aalst03d]

Şabloane bazate pe stări (state-based patterns):

o Deferred Choice (doar XPDL 2.0)

o Interleaved Parallel Routing (doar XPDL 2.0) [Wohed05][Aalst03d]

Şabloane de reziliere (cancellation patterns):

o Cancel Activity (doar XPDL 2.0);

o Cancel Case (doar XPDL 2.0) [Wohed05][Aalst03d]


XPDL specification allows the definition of an estimated run time for a process (used

for simulation purposes). XPDL describes TriggerTimer, which allows a process to be started

or an event to be triggered at a specified time, and deadlines are used to raise an exception

upon the expiration of a specific period of time.


Există un set de tipuri de date standard care pot fi folosite ca parte a specificării datelor

pentru câmpurile de date relevante, parametrii formali şi procese. Un nou tip de dată poate fi

declarat în cadrul unui TypeDeclaration şi poate fi folosit în orice loc în care un tip de dată

standard este folosit.

XPDL permite definirea tipurilor de date complexe, cum ar fi tablouri, înregistrări,

uniuni, enumeraţii sau liste. Acestea sunt definite folosind SchemaType. Elementele

RecordType, UnionType, EnumerationType, ArrayType şi ListType care erau folosite în

trecut sunt deprecated în versiunea 2.0. SchemaType permite utilizatorilor să definească un tip

de dată folosind sintaxa schemei XML. Poate fi deasemenea folosit pentru a defini un şir de

caractere XML care este conform schemei.

XPDL defineşte un element DataObects care conţine variabile de tipuri descrise mai

sus. Variabilele proces şi definţiile de aplicaţie pot fi mapate pe XML şi servicii Web.

Tratarea evenimentelor

XPDL permite definirea a 3 tipuri principale de evenimente, în concordanţă cu BPNL:

Start, Intermediate şi End. Evenimentele de Start şi majoritatea evenimentelor Intermediate au

‖declanşatoare‖ care definesc cauza pentru acel eveniment. Există multe moduri în care aceste


66

evenimente pot fi declanşate, de exemplu ‖când temperatura este peste 20 grade sau după un

anumit interval de timp. Evenimentele de End pot defini un ‖rezultat‖ ca o consecinţă

terminării unui flux de secvenţe. Sunt diferite tipuri de rezultate care pot fi definite, de

exemplu Message, Compensation sau End [Shapiro05].


Acest standard este suportat de o serie de produse open-source. XPDL este un standard

deschis care nu pune probleme de costuri de licenţiere. Întreţinerea codului scris în XPDL va

fi sportată de majoritatea produselor datorită faptului că XPDL este popular în domeniul său.

XPDL 2.0 implementează complet toate elementele BPMN şi toate mesajele, plus

tipurile de date, respectă specificaţia WSDL.

Criteriu tehnic XPDL 1.0 XPDL 2.0

Elemente de control (loop, choice, etc) + +

Fire de execuţie paralele + +

Suport pentru structuri precum module/procese + +

Suport pentru subfluxurilor (subflows) + +

Structuri complexe + +

Fluxul de date + +

Compatibilitate cu WSDL + +

Compatibilitate cu BPMN 0 +

Selectarea binding-urilor / endpoint-urilor - +

Suport pentru tratarea erorilor 0 +

Suport pentru compensare 0 +

Suport pentru procesarea tranzacţiilor - 0

Suport pentru interacţiunea cu roluri / utilizatori umani + +

Exceutabil + +

Definiţie formală XML XML

Extensibilitate + +

Independent de platformă + +

Securitate - -

Constrângeri legate de timing + +

Calitatea serviciilor / prioritizări + +

Suportă conceptul ―programming-in-the-small‖ - -

Tabela 6 Criterii tehnice XPDL

4.2.4 Rezumat

Avantaje

respectă BPMN (complet doar în versiunea 2.0)

interacţiunile cu utilizatorul pot fi parte a definiţiei de proces business

integrare facilă cu serviciile Web

permite simularea fluxurilor

extensibil

există un număr considerabil de unelte care suportă XPDL

introduce conceptele de roluri şi de executanţi ai unei activităţi


67

controlul versiunilor (version control)

conceptul de ‖subflow‖ cu o interfaţă definită foarte clar între procesele apelant şi apelat

Dezavantaje

lipsa de maturitate a versiunii compatibile cu BPMN (septembrie 2005)

Recomandări

XPDL poate fi utilizat în cadrul proiectului SCIPA ca un limbaj de nivel jos pentru

implementarea workflow-urilor.

4.3 ebXML Collaboration Protocol Profile and Agreement (CPPA)

ebXML CPPA (e-business XML Collaboration-Protocol Profile) este un standard

OASIS care oferă definţii pentru seturile de informaţii care sunt folosite în colaborări

[ebXML_CPPA]. Sunt oferite două seturi de informaţii: profilul (profile) şi convenţia

(agreement). Profilul conţine datele despre capabilităţile tehnice ale unui partener pentru a se

angaja într-o colaborare. Convenţia conţine datele care au fost convenite pentru a configura

aspectele publice (partajate) a protocoalelor folosite în protocoalele de colaborare.

Descriere generală

ebXML a fost pornit ca o iniţiativă a grupurilor de standardizare OASIS şi

UN/CEFACT. Scopul proiectului original a fost de a livra 5 nivele a specificării datelor,

inclusiv un standard XML pentru convenţii de protocoale de colaborare (Collaboration

Protocol Agreements).

Dintre companiile şi organizaţiile care au fost implicate în dezvoltarea specificaţiilor

ebXML CPPA, amintim: Intel, Commerce One, E2open, TIBCO, SAP, IBM, IONA,

Mercator, Sun Microsystems, HP Company, Drummond Group, Collaborative Domain,

Cyclone Commerce, Sybase, IBM, SeeBeyond, Vitria, Sterling Commerce, webMethods etc.

Există alte grupuri de standardizare, precum şi grupuri industriale, implicate în general

în efortul ebXML, cum ar fi eBES, e_centreUK, Korea Institute for Electronic Commerce,

Open Applications Group, Open Travel Alliance, RosettaNet, Tradegate ECA.

Dezvoltarea ebXML a fost începută în 1999. Specificaţiile tehnice au fost publicate la

diferite date în anul 2001. ebXML CPPA versiunea 1.0 şi 2.0 sunt terminate, versiunea 2.0

este un standard aprobat OASIS. Deasemenea, ebXML CPPA 2.0 a fost aprobat de către ISO

şi publicat ca partea întâi a specificaţiilor tehnice ISO 15000 (http://www.oasis-

open.org/news/iso_app_ebxml_oasis_standards.pdf).

Cu toate că ebXML 1.0 şi 2.0 sunt terminate, o versiune de mentenanţă (2.1) a fost

dezvoltată pentru a repara unele erori minore din versiunea 2.0. Deasemenea, specificaţia de

negociere din ebXML CPPA (ebXML CPPA Negotiation) este în dezvoltare. Informaţi despre

starea curentă a ebXML CPPA poate fi găsită pe situl OASIS: http://www.oasis-

open.org/committees/ebxml-cppa/charter.php.

Ultimele modificări aduse specficaţiilor ebXML se referă la ‖ebXML Messaging

Services v3.0: Part 1, Core Features‖ şi ‖ebXML Business Process Specification Schema

Technical Specification v2.0.4‖, publicate în octombrie 2007, respectiv decembrie 2006.

Multe iniţiative bazate pe XML suportă ebXML şi integrează specificaţiile ebXML.

Global Commerce Initiative a ales sa-şi bazeze standardul de protocol Internet pentru

http://www.oasis-open.org/news/iso_app_ebxml_oasis_standards.pdf

http://www.oasis-open.org/news/iso_app_ebxml_oasis_standards.pdf

http://www.oasis-open.org/committees/ebxml-cppa/charter.php

http://www.oasis-open.org/committees/ebxml-cppa/charter.php


68

comercializarea modificărilor şi comunicaţiile B2B pe ebXML. Deasemenea, multe companii

industriale au participat activ la iniţiativa ebXML, cum ar fi grupul de standardizare EDI.

ebXML CPPA 2.0 este aliniată cu ebXML BPSS şi ebXML Messaging protocol

Există trei subcomitete ebXML CPPA: ebXML CPPA Automated Negatiation, ebXML

CPPA Transaction Capability Models şi ebXML CPPA Web Services Interaction.

ebXML este complementar pentru multe standarde existente, cum ar fi EDI, standardele

de documente bazate pe XML şi serviciile Web

ebXML a fost proiectat să fie independent de echipament, platformă software sau reţea

de comunicaţie. Atât timp cât un sistem suportă protocoalele standard de transport Internet şi

XML, ar trebui să suporte şi ebXML

Figura 23 Structura CPP şi a specificaţiei procesului în ebXML Registry5


Există un puternic suport pentru standardele ebXML, inclusiv BPSS.

Informaţii despre adoptarea ebXML de către diverse organizţii pot fi găsite la adresa

http://www.ebxml.org/documents/ebxml_adopt_update_122203.pdf. Deasemenea, există

o listă detaliată cu diversele implementări a standardelor ebXML. Până în decembrie

2003, au fost raportate cel puţin 105 implementări ebXML, dintre care cel puţin 40

foloseau ebXML CPPA, dintre care 12 implementări în produse comerciale.

ebXML CPPA conţine definiţiile pentru CPP (Collaboration Protocol Profile) şi CPA

(Collaboration Protocol Agreement). CPP defineşte capabilităţile schimbului de mesaje a

fiecărui partener, precum şi colaborările de business pe care un partener le acceptă. CPA

definşte modul de interacţiune între doi parteneri în scopul de a duce la bun sfârşit o

colaborare de business. Astfel, ebXML CPPA complementează utilizarea ebXML BPSS şi

5 Consultă şi Figure 1 în http://www.ebxml.org/specs/ebCCP.doc

Business

Collaboration

<PartyInfo PartyId=―N01‖>

<ProcessSpecification

xlink:href=―http://

<PartyInfo PartyId=―N02‖>

<ProcessSpecification

xlink:href=―http://

CPP(A)

Specificaţie proces (A1)

Specificaţie proces (A2)

Business

Collaboration

http://www.ebxml.org/documents/ebxml_adopt_update_122203.pdf

http://www.ebxml.org/specs/ebCCP.doc


69

principala sa utilizare este ca tehnologie de orchestrare. În plus, ebXML CPPA asigură

interoperabilitatea între parteneri chiar dacă utilizează sisteme software heterogene.

ebXML CPPA oferă deasemenea suport pentru transport, schimbul de documente şi chiar

specificarea proceselor (bazat pe ebXML BPSS).

ebXML CPPA şi ebXML BPSS ar trebui folosite indiferent de ce software compatibil

ebXML este specificat pentru executarea colaborărilor de busines (Business

Collaborations). Termenul generic pentru un astfel de software este Business Service

Interface (BSI). O BSI ar trebui să includă partea de negociere a CPPA.

Există un număr mare de produse sau/şi unelte care suportă ebXML CPPA, dintre care

amintim:

o http://edocs.bea.com/wli/docs70/ebxml/

o http://www.sonicsoftware.com/

o http://www.enterprise-component.com

o http://interstage.fujitsu.com

o http://www.iona.com

o http://visualscript.com

o http://www.stercomm.com

o http://www.rosettanet.org

o http://www.openxchange.org

o http://www.schlegel.li/ebXML/

o http://www.xeni.co.kr/

o http://www.freebxml.org

o http://openebxml.sourceforge.net

Pentru a implement stiva de specificaţii ebXML au fost dezvoltate un număr considerabil

de unelte open-source: http://www.ebxml.org/tools/index.htm. Exemple de implementări

ebXML, dintre care amintim General Motors, US Center for Disease Control sau

TransCanada Pipeline, pot fi vizualizate la adresa următoare:

http://www.ebxml.org/implementations.

Standardele ebXML, inclusiv ebXML CPPA, sunt oferite gratuit de către OASIS cu

scopul de a încuraja adoptarea standardului ebXML.

ebXML CPPA este strâns legat de celelalte standarde ebXML, cum ar fi ebXML BPSS,

ebXML Core Components, Registry/Repository Services şi Messaging Services.

ebXML intenţionează să ofere un suport de calitate pentru WSDL. Suportarea operaţiilor

WSDL este importantă pentru proiectarea colaborărilor business (Business

Collaborations) în care cel puţin unul dintre parteneri nu suportă interschimburile ebXML.

Criteriu de piaţă CPPA


specificaţiilor

+

disponibil ca standard ISO 15000



+ / +

Informaţia despre produsele disponibile

este destul de veche (dec 2003)

Înlocuit -

În evoluţie +

Backward compatible +

Standard deschis +

Experienţa consorţiului -

Tabela 7 Criterii de piaţă CPPA

http://edocs.bea.com/wli/docs70/ebxml/

http://www.sonicsoftware.com/

http://www.enterprise-component.com/

http://interstage.fujitsu.com/

http://www.iona.com/

http://visualscript.com/

http://www.stercomm.com/

http://www.rosettanet.org/

http://www.openxchange.org/

http://www.schlegel.li/ebXML/

http://www.xeni.co.kr/

http://www.freebxml.org/

http://openebxml.sourceforge.net/

http://www.ebxml.org/tools/index.htm

http://www.ebxml.org/implementations


70


Concepte de bază

ebXML CPP defineşte capabilităţile (tehnologice şi de business, exprimate în ce

colaborări de business sunt suportate) unui partener de a se angaja în afaceri electronice cu

alţi parteneri.

ebXML CPA defineşte capabilităţile asupra cărora doi parteneri trebuie să cadă de acord

pentru a se putea angaja într-un business electronic pentru scopul unui CPA particular. Un

CPA ar trebui să fie compus din două CPP-uri.

CPP foloseşte elementele ProcessSpecification, DeliveryChannel, DocExchange şi

Transport pentru a descrie modul de procesare al unei conversaţii (sau a unei unităţi de

business). Elementele folosite de CPP formează o structură pe mai multe straturi, similar cu

modelul stratificat din comunicaţii.

Stratul Process-Specification defineşte partea centrală a convenţiei dintre doi

parteneri: serviciile (sau tranzacţiile business) şi regulile de tranziţie folosite pentru a

determina ordinea cererilor. Acest strat este definit prîntr-un document Process-

Specification distinct, referenţiat atât de CPP cât şi de CPA.

Figura 24 Vedere generală asupra Collaboration-Protocol Profiles (CPP)6

Stratul Delivery Channel descrie caractersiticile legate de primirea mesajelor pentru

un partener şi este compus din definiţia schimbului de documente şi definiţia

transportului. Fiecare CPP poate defini câteva canale de livrare (delivery channel).

Stratul Document-Exchange acceptă un document de la stratul Process-Specification

la un parterner şi îl trimite stratului de transport pentru transmiterea sa la celălalt

partener. Acest nivel efectuează paşii în ordine inversă pentru fiecare mesaj primit.

6 Consultă şi figura 2 de la http://www.ebxml.org/specs/ebCCP.doc

Ce capabilităţi de

business poate

efectua când este

implicată într-o

Business

Collaboration cu

alţi parteneri

Partener

A

Informaţii despre partener

- nume

- informaţie de contact

- protocolul de transport

- protocolul de securitate

pentru transport

- protocolul de mesagerie

- legături la documentul de

specificare a procesului

- etc.

CPP

Descrie

Cree

ază



71

Opţiunile alese pentru acest strat sunt complementare celor alese pentru stratul de

transport.

Stratul Transport este responsabil pentru livrarea mesajelor folosind protocolul de

transport ales. Protocolul ales afectează alegerile selectate pentru stratul Document-

Exchange.

Structura ebXML CPP conţine următoarele elemente: CollaborationProtocolProfile,

PartyInfo, DocExchange, Packaging, ds:Signature şi Comment. La rândul ei, ebXML CPA

conţine următoarele elemente: CollaborationProtocolAgreement, Status, Start şi End pentru a

defini CPA Lifetime, ConversationConstraints, PartyInfo, ds:Signature şi Comment. Atât CPP

cât şi CPA includ artibutul Schema Location folosit pentru a activa parserul de validare şi

uneltele pentru validarea schemei, pentru a parsa şi proces corect documentele CPP şi CPA.

Figura 25 Vedere generală Collaboration-Protocol Agreements (CPA)7

Granularitatea

ebXML CPPA şi ebXML BPSS oferă aceeaşi granularitate. În timp ce BPSS defineşte

procesul în termenii de colecţii/coregrafii de tranzacţii şi activităţi, CPA identifică un BPSS

specific (ProcessSpecification) pentru un CollaborationRole dat. ServiceBinding-ul este

maparea tehnică a unui rol identificat pe BPSS.

Notaţia folosită

ebXML CPP şi ebXML CPA trebui să includă un atribut ce identifică Schema Location,

care este disponibilă ca notaţie XML. Astfel, notaţia trebuie să respecte XML.

7 Consultă şi figura 3 de la http://www.ebxml.org/specs/ebCCP.doc

CPA ID

- Informaţii partener

Partener A

Partener B

- Protocol de transport

- Securitate transport

- Protocol

DocExchange

- Legătura către spec de

proces

- etc.

CPP

pentru

Partenerul

A

CPP

pentru

Parterner

ul B

CPA

CPA

acceptat

CPA

contracta

t

1

negociază

2

negociază

3

A sosit

acceptarea

CPA-ului

3

A sosit

acceptarea

CPA-ului

4 Startul activităţilor bilaterale



72


Elementul DocExchange din CPP oferă informaţiile ce trebuie să fie acceptate de

comun acord de către parteneri relativ la schimbul de documente bilateral, inclusiv

proprietăţile serviciului de mesagerie. Elementul ebXMLBinding al DocExchange este folosit

pentru a descrie proprietăţile specifice ebMS (ebXML Message Service) şi include un element

ReliableMessaging şi unul NonRepudiation. Prin folosirea ReliableMessaging, un CPP

defineşte o schemă de fiabilitate pentru mesaje, ce vizează semantica livrărilor (―once and

only once‖ sau ―best effort‖), idempotenţa sau numărul de încercări permise.


ebXML CPPA asigură interoperabilitatea între doi parteneri în ciuda faptului că ei pot

folosi software din surse separate.


ebXML CPPA este orientat pe servicii Web şi are la bază ebMS (ebXML Message

Service). Specificaţia ebXML Message Service Specification oferă infrastructura pentru

identificarea mesajului/semnalului, tipizare şi integritate. De amintit că ebXML şi serviciile

Web sunt tehnologii arhitecturale complementare şi în practică diferite elementele sunt

implementate combinat.


ebXML este bazat pe UML. Oricum, ebXML CPPA este bazat pe XML, care introduce

un oarecare nivel de formalism pentru ebXML CPPA.


Deoarece toate tranzacţiile business trebuie să aibă o limtă de timp, au fost introduşi

parametrii de timeout asociaţi cu un răspuns şi cu fiecare dintre semnalele de înştiiţare. Dacă

expiră timpul înainte ca răspunsul sau semnalul să sosească, atunci tranzacţia este nulă. CPA

defineşte propria durată de viaţă folosind elementele Start şi End. Când este atins sfârşitul

duratei de viaţă, orice tranzacţie în curs este lăsată să se termine, dar nu vor mai fi pornite noi

tranzacţii. Conversaţia este terminată când toate tranzacţiile în progres a fiecărui partener sunt

terminate.


ebXML Business Service Interfaces (BSI) sunt configurate pentru a executa procesele

business specificate într-o Business Process Specification. Acest lucru se întâmplă prin

schimbul de mesaje ebXML şi semnale. Fiecare tranzacţie de business poate fi implementată

folosind unul dintre multele şabloane standard disponibile.

Suport pentru procese colaborative

ebXML oferă suport pentru procese colaborative prin intermediul CPP (Collaborative

Protocol Profile). Prin folosirea BPSS, CPP şi registre, standardele ebXML propun

standardizarea proceselor şi interacţiunilor dintre procese.


73

Posibilităţile de automatizare (automation)

ebXML CPPA oferă suport pentru negocierea automată a conţinutului unei CPA prin

folosirea specificaţiei ebXML CPPA Negotiation.

Scalabilitatea

Arhitectura bazată pe mesaje a ebXML este slab cuplată astfel încât permite scalabilitate

pe orizontală, queuing şi clustering.

Criteriu tehnic ebXML CPPA

Elemente de control (loop, choice, etc) 0

Fire de execuţie paralele +

Suport pentru structuri precum module/procese +

Suport pentru subfluxurilor (subflows) -

Structuri complexe +

Fluxul de date +

Compatibilitate cu WSDL +

Compatibilitate cu BPMN 0

Folosind extensii ebXML specifice

Selectarea binding-urilor / endpoint-urilor +

Suport pentru tratarea erorilor +

Suport pentru compensare Compensarea comportamentului eronat

poate fi specificată

Suport pentru procesarea tranzacţiilor +

Suport pentru interacţiunea cu roluri / utilizatori

umani

+

Exceutabil +

Definiţie formală +

Extensibilitate +

Independent de platformă +

Securitate +

Folosind un standard specific din

ebXML

Constrângeri legate de timing +

Calitatea serviciilor / prioritizări +

Suportă conceptul ―programming-in-the-small‖ Na

Tabela 8 Criterii tehnice CPPA


ebXML CPPA poate fi folosit într-un proiect tip e-business împreună cu tehnologiile

înrudite din platforma ebXML. Dacă implementarea colaborărilor dintre parteneri se doreşte

să fie definită în UBL, atunci tehnoogia ebXML CPPA poate fi folosită în acest scop.

Deasemenea, ebXML CPPA suportă foarte bine serviciile Web, precum şi colaborările şi

negocierile automated. Deoarece ultimele informaţiile legate de adoptarea acestui standard

sunt destul de vechi (decembrie 2003), nu se cunoaşte progresul din ultimii ani relativ la acest

standard. Cu toate că din punct de vedere tehnic standardul ebXML CPPA corespunde

cerinţelor SCIPA, utilizarea sa trebuie să fie făcută cu grijă relativ la evoluţiile acestuia.


74

4.3.4 Rezumat

Avantaje

ebXML CPPA suportă modularizarea definiţiilor de proces ca blocuri constructive

standard, ce pot fi folosite ulterior în dezvoltarea unor definiţii de procese mult mai detaliate

şi/sau colaborări complexe prin mecanismul de incluziune a pachetelor. Acest aspect conferă

o flexibilitate crescută comunităţilor de utilizatori interesaţi, în care aceştia au posibilitatea de

a adăuga noi capabilităţi sau funcţionalităţi proceselor şi documentelor într-un mod iterativ ce

se pliază pe necesităţile lor de evoluţie.

Flexibilitatea şi compozabilitatea sunt aspecte importante nu doar pentru adoptarea unui

standard dar şi pentru o livrare de succes într-un mediu eterogen sau între mai multe domenii.

Dezavantaje

Părţile reutilizabile trebuie tratate cu atenţie sportiă datorită numărului mare de unelte

care sunt folosite în acest tip de aplicaţii.

Dezvoltatorii trebuie să se asigure că dacă un mesaj livrat este într-o stare eronată în

modul de răspuns sincron, atunci nivelul de eroare al mesajului trebuie returnat. Datorită

acestor nivele răspândite în întreaga aplicaţie, acest lucru trebuie tratat cu atenţie.

Implementarea RosettaNet, în modul de lucru răspuns sincron (synchronous reply mode) nu

permite nerespingerea pentru mesajul de răspuns.

Cazul comunicaţiilor asincrone trebuie să fie folosit doar în situaţiile unde este strict

necesar.

Recomandări

ebXML CPPA, împreună cu ebXML şi celelalte tehnologii ebXML, poate fi folosit într-

un proiect de tip e-business. Dacă implementarea colaborărilor dintre parteneri se doreşte să

fie definită în UBL, atunci tehnoogia ebXML CPPA poate fi folosită în acest scop.

Deasemenea, ebXML CPPA suportă foarte bine serviciile Web, precum şi colaborările şi

negocierile automated.

4.4 Concluzii

În acest capitol au fost evaluate, atât din punct de vedere tehnic cât şi din punct de

vedere al pieţei, cele mai importante standarde de orchestrare. Tabela 9 prezintă sinteza

analizei de piaţă.

Pornind de la asumţia că doar standardele mature, deschise, cu un număr semnificativ

de implementări şi pentru care se mai oferă suport sunt luate în considerare, autorii nu

recomandă următoarele standarde: WSBPEL 2.0, XPDL 2.0, WSDL, PDL4J, JBI, JPDL şi

WWF. CPPA a fost foarte promiţător în momenul publicării sale, dar interesul arătat de piaţă

acum faţă de acest standard este destul de slab. Faptul că nici una dintre aplicaţiile evaluate nu

este bazată pe acest standard vine în sprijinul presupunerii anterioare.

Criteriu de piaţă Standard


75

BP

EL4

WS

1.1

WS

BP

EL

2.0

XP

DL

1.0

XP

DL

2.0

WS

FL

BP

ELJ

PD

4J

jPD

L JBI

CP

PA

W

WF

Stabilitate, existenţa unei

versiuni mature a

specificaţiilor

+ - + + + + - + + + 0

Disponibilitatea

implementării


+/+

-/-

+/+

-/0

-/+

+/+

-/-

+/-

+/+

+/+

-/+

Înlocuit - - + - + - - - - - -

În evoluţie + + + - - + - - - + -

Backward compatible na - na + - na Na na na + na

Standard deschis + + + + + + + - + + -

Experienţa consorţiului - - - - - - - - - 0 -

Tabela 9 Sinteza analizei de piaţă pentru evaluarea standardelor de orchestrare

Al doilea grup de criterii folosit în evaluarea standardelor de orchestrare este alcătuit din

criteriile tehnice. Rezultatul acestei evaluări este prezentat sintetic în Tabela 10.

Criteriu tehnic

Standard

BPE

L4

WS

1.1

WS

BPE

L

2.0

XPD

L

1.0

XPD

L

2.0

WS

FL

BPE

LJ

PD

4J

jPD

L

JBI CPP

A

WW

F

Elemente de control

(loop, choice, etc)

0 0 + + 0 0 + 0 na 0 +

Fire de execuţie

paralele

+ + + + + + + + na + +

Suport pentru structuri

precum module/procese

+ + + + + + - - na + +

Suport pentru

subfluxurilor

(subflows)

0 + + + - 0 - - na - -

Structuri complexe 0 0 + + 0 0 + 0 na + 0

Fluxul de date + + + + + + - + na + +

Compatibilitate cu

WSDL

+ + + + + + 0 0 + + +

Compatibilitate cu

BPMN

0 0 0 + - 0 - - - 0 -

Selectarea binding-

urilor / endpoint-urilor

+ + - + + + - - + + 0

Suport pentru tratarea

erorilor

+ + 0 + 0 + + 0 + + +

Suport pentru

compensare

+ + 0 + - + - 0 na + +


76

Criteriu tehnic

Standard

BPE

L4

WS

1.1

WS

BPE

L

2.0

XPD

L

1.0

XPD

L

2.0

WS

FL

BPE

LJ

PD

4J

jPD

L

JBI CPP

A

WW

F

Suport pentru

procesarea tranzacţiilor

+ + - 0 + + + 0 + + +

Suport pentru

interacţiunea cu roluri /

utilizatori umani

- - + + - - 0 + na + +

Exceutabil + + + + + + - + na + -

Definiţie formală XM

L

XM

L

XM

L

XM

L

+ XM

L

Jav

a

XM

L

Jav

a

XM

L

XM

L

Extensibilitate - 0 + + - - - + + + -

Independent de

platformă

+ + + + + - - - - + -

Securitate - - - - - - - - + + -

Constrângeri legate de

timing

+ + + + + + + + 0 + +

Calitatea serviciilor /

prioritizări

- - + + - - - - na + -

Suportă conceptul

―programming-in-the-

small‖

- - - - - + - - na Na -

Tabela 10 Sinteza analizei tehnice pentru evaluarea standardelor de orchestrare

Lista standardelor care nu au fost excluse după criteriile de piaţă este formată din

BPEL4WS 1.1, XPDL 1.0 şi BPELJ. Rezultatele evaluării tehnice arată că funcţionalităţile

cheie necesare pentru descrierea proceselor de business, cum ar fi fluxul datelor, tratarea

erorilor, compensarea şi constrângerile de timp, sunt incluse în fiecare standard din listă.

Dacă se doreşte utlizarea unor limbaje de nivel înalt în locul limbajelor de programare

tradiţionale, atunci BPELJ nu este recomandabil şi trebuie avut în vedere doar ca soluţie de

rezervă. În acest caz, recomandarea autorilor este utilizarea BPEL4WS 1.1 sau XPDL 1.0.

Dacă se doreşte dezvoltarea aplicaţiei într-un limbaj de programare tradiţional, de exemplu

Java, atunci recomandarea autorilor este tehnologia BPELJ care suportă lucrul cu procese

business din limbajul Java.


77

5 Alte standarde asociate tehnologiilor orientate spre fluxuri de activităţi

Scopul acestui capitol este de a introduce o serie de tehnologii care nu pot fi incluse în

capitolele referitoare la modelare, coregrafie sau orchestraţie, dar care pot oferi un plus de

valoare în contextul întregului proiect. Aceste standarde şi-au dovedit interoperabilitatea cu

standardele de bază din cadrul domeniului, şi pot fi clasificate în următoarele categorii:

Standarde orientate spre servicii web: SOAP, WSDL, ca standarde de-facto; ASAP,

Wf-XML, ca standarde implementând facilităţi de monitorizare, control şi comunicare

asincronă. Cu toate acestea, dat fiind caracterul lor de tehnologii fundamentale, SOAP

şi WSDL nu fac obiectul acestei analize.

Standarde orientate spre activităţi tipice de comerţ electronic: BTP, UBL

Standarde specifice fluxurilor de activităţi: BTP, Wf-XML

Standarde oferind modele de informaţii (cu o orientare puternică spre documente):

UBL

Diferite organizaţii de standardizare participă activ în dezvoltarea acestor tehnologii.

Astfel, ASAP, UBL şi BTP sunt standarde OASIS; Wf-XML este menţinut de WfMC iar

dezvoltarea SOAP şi WSDL este controlată de W3C.

BTP este un protocol bazat pe XML pentru ―reprezentarea şi gestionarea facilă a

tranzacţiilor complexe, multi-pas de tip B2B peste Internet‖8. Prin utilizarea BTP este posibilă

urmărirea şi gestiunea mesajelor XML complexe ca şi conversaţii „loosely coupled‖ între şi în

cadrul diferitelor (procese de) afaceri.

WSDL este ―un format XML pentru descrierea serviciilor de reţea ca un set de

endpoints care operează peste mesaje conţinând fie informaţii orientate spre documente ori

orientate spre proceduri‖9. WSDL este folosit mai degrabă pentru a defini o gramatică XML

pentru descrierea serviciilor de reţea ca o colecţie de puncte de comunicare, capabile să

suporte schimburi de mesaje.

Wf-XML este un protocol bazat pe XML pentru ―Run-Time Integration of Process

Engines‖. Prin Wf-XML 2.0 se urmăreşte integrarea facilă a motoarelor de execuţie a

proceselor peste internet şi intranet, oferind mijloacele necesare pentru interacţiunile dintre

acestea. Wf-XML 2.0 este construit peste suportul oferit de ASAP pentru a permite integrarea

motoarelor de execuţie a proceselor ca tipuri speciale de servicii asincrone.

UBL este o implementare ebXML CC, direcţionată spre dezvoltarea şi integrarea unei

biblioteci de documente XML orientate spre afaceri, într-o manieră deschisă. Astfel de

documente ar putea include ordine de cumpărare, facturi şi altele. Dezvoltată pentru a putea fi

integrată direct în afacerile existente, oferă suportul ideal pentru a facilita aplicaţiile de tip e-

commerce pentru întreprinderile mici şi mijlocii.

8 Bazat pe descrierea BTP la BTP Official site.

9 Bazat pe descrierea WSDL la WSDL Official site.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=business-transaction

http://www.w3.org/TR/wsdl


78

Ca standard de-facto, SOAP este ―un protocol uşor orientat spre schimbul de mesaje

structurate în medii descentralizate, distribuite‖10

.

Nu în ultimul rând, versiunea curentă ASAP este is o extensie SOAP al cărei scop este

de a permite realizarea de servicii web de lungă durată. Astfel, prin ASAP se urmăreşte

oferirea unei ―metode standard de a porni, gestiona şi monitoriza servicii de lungă durată‖11

.

5.1 Business Transaction Protocol (BTP)

În 2001 Comitetul tehnic pentru ―Business Transaction‖ de la OASIS, cu ajutorul unor

companii active în domneiu, incluzând BEA Systems, Bowstreet, Hewlett Packard,

Interwoven sau Sun Microsystems a început activitatea de dezvoltare a OASIS Business

Transaction Protocol (BTP), care urma să se adreseze nevoilor partenerilor comerciali

independenţi care schimbă date XML în cadrul comunicaţiilor de comerţ electronic de la

sistem la sistem. Absenţi acestui comitet tehnic, IBM şi Microsoft, îşi orientează eforturile

spre dezvoltarea unor specificaţii proprii: Web Services Coordination (WS-C) şi Web

Services Transactions (WS-Tx).

Standardul atinge un nivel de maturitate în Noiembrie, 2004, când OASIS anunţă

Versiunea 1.1 a standardului. Aceasta reprezintă o revizie importantă a versiunii 1.0, pe baza

feedback-ului obţinut şi a experienţelor de implementare realizate.

În [BTP_2004] protocolul este descris ca fiind independent de transport, proiectat

―pentru a permite coordonarea activităţii aplicaţiilor între parteneri multipli, autonomi şi

cooperanţi.‖ Acesta defineşte un protocol pentru schimburi care să asigure ca aplicaţia, în

ansamblul ei, să ofere rezultate consistente. Consistenţa poate fi definită a priori, când fie

întreaga activitate este confirmată, sau nicio activitate nu este confirmată (cazul tranzacţiilor

de afaceri atomice); sau poate fi determinată prin intervenţia aplicaţiei în selecţia activităţilor

care urmează să fie confirmate (tranzacţii coezive).

Specificaţia OASIS Business Transaction Protocol defineşte protocolul ―în termeni de

mesaje abstracte schematizate în XML. Acesta defineşte legăturile protocolului de

comunicaţie către SOAP, permiţând totodată transportul mesajelor BTP peste alte protocoale

de comunicaţie. BTP bazat pe o abordare minimală şi permisivă, unde constrângerile peste

posibilităţile de implementare sunt evitate.‖ BTP oferă, pe de altă parte, mijloacele necesare

pentru asocierea şi coordonarea cererilor, răspunsurilor, şi rezultatelor pentru elementele

aplicaţiilor distribuite. La un nivel simplu, BTP permite ca un set de apeluri la distanţă să

poată fi grupate iar rezultatele obţinută să poată fi relaţionate.

Pe baza informaţiilor din [BTP_PR_2002], BTP rezolvă probleme în medii cu

interacţiuni de afaceri complexe cu o infrastructură potenţial nesigură peste legături de

comunicaţie potenţial nesigure. Scopul unei interacţiuni de afaceri tipice este de a oferi a reală

terminare sau întrerupere, în contextul unor reguli de afaceri potenţial complexe care nu

trebuie (şi nu pot) să fie înţelese de toţi participanţii. Scopurile BTP includ:

Definirea unui model pentru tranzacţii pe internet, cu participanţi de la organizaţii

diferite.

10

Bazat pe descrierea versiunii curente SOAP la SOAP 1.2 Official site. De asemenea, pentru versiunea

precedentă, vezi SOAP 1.1 site. 11

ASAP description, found at the ASAP Official site.

http://www.w3.org/TR/soap12-part1/

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap


79

Compunerea şi coordonarea de rezultate sigure în condiţiile unor canale de

comunicaţie şi infrastructură potenţial nesigură.

Gestiunea ciclului de viaţă al tranzacţiilor.

Suportarea de tranzacţii între sisteme slab cuplate, comunicând într-o manieră

asincronă.

Suportarea tranzacţiilor de lungă durată, depăşind o durată rezonabilă de existenţă.

Coordonarea de interacţiuni multiple, înrudite.

Oferirea unei fundaţii pentru uneltele de modelare şi execuţie a proceselor şi

fluxurilor de activităţi.


Numărul de implementări

Există un număr relativ limitat de implementări ale BTP. HP Web Services Transactions

(HP-WST), oferă o implementare industrială a acestui protocol. HP-WST constă din trei părţi

complementare şi distincte:

HP-WST Coordinator care acţionează ca manager de tranzacţii central, şi rulează ca

un serviciu Web.

HP-WST Participants Libraries oferă un set de biblioteci participant Java BTP

participant libraries pentru servicii Web bazate pe Java. Aceste biblioteci oferă

dezvoltatorilor posibilitatea de a manipula logica legată de aspectele de tip BTP ale

proceselor de afaceri.

HP-WST Client Libraries oferă un set de biblioteci Java care sunt utilizate pentru a

creea aplicaţii client care apelează (se bazează pe) servicii Web tranzacţionale. Atât

clienţii cât şi participanţii într-o tranzacţie vor comunica cu un Coordonator folosind

SOAP/HTTP.

HP-WST suportă atât atomi BTP (tranzacţii de tip ACID), cât şi coeziuni BTP

(tranzacţii de tip ACID relaxate, unde regulile sunt utilizate pentru a specifica rezultatul

întregii tranzacţii ca o funcţiune a succesului sau eşecului participanţilor individuali). Nicio

versiune HP-WST nu este disponibilă însă pentru download.

Una dintre principalele implementări BTP este Java Open Transaction Manager

(JOTM). Aceasta este o implementare open source pentru un manager de tranzacţii,

implementat în Java. Oferă suportul necesar pentru mai multe modele de tranzacţii şi

specificaţii oferind suportul de tranzacţii pentru clienţi care utilizează platforme diverse

(J2EE, CORBA, Web Services). JOTM este un proiect suportat de ObjectWeb, sub licenţă de

tip BSD.

Arii de utilizare

BTP este o specificaţie orientată spre tranzacţiile de tip business-to-business în domenii

slab cuplate, cum ar fi serviciile Web, însă fără a oferi neapărat un suport orientat către

acestea.

Acceptare din partea clienţilor

Protocolul nu este complex, chiar dacă specificaţiile de bază sunt de circa 200 pagini.

Acesta ar putea fi unul dintre motivele pentru care există anumite dificultăţi de acceptare din


80

partea diferitelor categorii de utilizatori. Pe o scară de la 1 la 10, efortul necesar pentru citirea

şi înţelegerea BTP se poate situa la nivelul 7.5.

Este un standard deschis?

BTP este un standard deschis, a cărui dezvoltare este suportată de OASIS-OPEN.

Disponibilitate

Specificaţiile BTP [BTP_2002] sunt liber disponibile pentru download, la adresa oferită

de OASIS. Cu toate acestea, specificaţiile sunt relativ vechi, iar activitatea legată de protocol

este relativ scăzută.


Concepte utilizate

1. „Business Transaction” este definită ca [BTP_2002] „o schimabre consistentă în

starea unei relaţionări de afaceri între doi sau mai mulţi participanţi. O relaţionare de

afaceri reprezintă orice stare distribuită menţinută de părţi şi care este subiect al unor

constrângeri contractuale agreeate de aceste părţi.‖

2. BTP Node este o unitate logică, asociată cu o tranzacţie unică.

3. External Effects reprezintă schimbările de stare cauzate de schimburi de Application

Messages. Schimbările de stare sunt parte a unui Contract dintre părţile care folosesc

BTP. BTP cere ca participanţii BTP să fie capabili să suporte următoarele modificări

de stare:

Provisional Effect: reprezintă schimbările induse de o procesare completă sau

incompletă a unui set de proceduri de către un Actor.

Final Effect: este efectul potrivit, intenţionat să completeze sau finalizeze un

Provisional Effect. Odată cu confirmarea, efectul final face ca efectul

provizional să devină permanent.

Counter Effect: este un efect potrivit, intenţionat să contracareze un efect

provizional. În acest caz, contraefectul va anula efectul provizional.

4. Two-phase Outcome: este utilizat de BTP pentru a coordona schimbările de stare. În

primul rând, participanţii au la îndemână efectul provizional iar apoi, funcţie de

răspunsul altor participanţi şi de logica de afaceri, oricare dintre celelalte două efecte

pot fi angajate.

5. Conceptul de Role se referă strict la participarea într-o relaţionare particulară pentru o

anumită tranzacţie de afaceri. Agentul software care execută un rol se numeşte Actor.

Un Actor se distinge de alţi actori prin faptul că oferă o adresabilitate distinctă. Un

acelaşi actor poate executa roluri multiple într-o aceeaşi tranzacţie de afaceri, şi poate

de asemenea executa acelaşi rol sau roluri diferite în tranzacţii de afaceri multiple, fie

concurent fie secvenţial (consecutiv).

6. Superior este un rol BTP, abstractizare pentru coordonator; acceptă angajamente de la

un Inferior, stabilind o relaţionare Superior:Inferior. Un Superior poate avea

relaţionări cu mai mulţi Inferiori. Superioriul determină rezultatul aplicabil

Inferiorilor, care sunt angajaţi ai acestuia.


81

7. Inferior este un rol BTP, care este responsabil cu aplicarea Rezultatului (aşa cum a

fost recepţionat de la Superior, fie prin confirmare sau anulare) pentru un set de

operaţiuni. Un Inferior poate fi angajat al unui singur Superior.

8. Un Business Transaction Tree este un şablon care oferă coordonarea unei tranzacţii

distribuite. Acesta poate implica o combinaţie complexă de relaţionări

Superior:Inferior. Nu există o limitare fixată pentru numărul de Inferiori sau Superior,

sau numărul de nivele de intermediari care există între Superiorul cel mai de sus (care

nu poate fi Inferior al nimănui) şi Inferiorii la nivel de frunze. Crearea efectivă a

arboreului depinde de comportamentul şi cerinţele aplicaţiei. Astfel, Error!

Reference source not found. oferă un exemplu simplu de arbore asociat tranzacţiilor

de afaceri.

A

B C

Superior

Inferior Inferior

Figura 26 Business Transations cu doi inferiori

9. Un BTP Atom este o unitate atomică de lucru, în cadrul căreia fie toate sarcinile de

lucru sunt terminate, sau niciuna nu este terminată. Un Atom poate fi privit ca o

tranzacţie Atomică tradiţonală într-un sistem puternic cuplat, în sensul că va fi aplicată

o decizie globală pentru toţi participanţii înrolaţi într-un Atom. Aceasta se poate

implementa prin aplicarea unui protocol de realizare în două faze, tuturor Inferiorilor

înrolaţi, pentru obţinerea deciziei finale. Prin fiecare atom se poate gestiona unul sau

mai mulţi Inferiori, iar fiecare Inferior acţionează în numele unui Serviciu fie pentru a

confirma sau anula sarcina oferită de un Serviciu.

10. O BTP Cohesion reprezintă o mulţime de participanţi, care sunt Inferior direcţi ai unui

Nod BTP care poate recepţiona instrucţiuni care pot genera rezultate diferite pentru

fiecare participant. Rezultatele care sunt aplicate Inferiorilor înrolaţi într-o Coeziune

sunt obţinute prin intervenţia unei aplicaţii iar utilizatorul Coeziunii este cel care va

decide care este submulţimea de Inferiori pentru care se trimite o confirmare sau o

anulare. Prin această facilitate este posibil un control de nivel fin asupra coordonării

Inferiorilor dintr-o tranzacţie, permiţând utilizarea unei selecţii sau decizii întârziate a

unui utilizator final pentru a obţine rezultatele dorite.

11. Un Participant este un Rol al unui Actor BTP care este format dintr-un set de

proceduri, şi care este capabil să primească instrucţiuni de la un alt Actor BTP pentru

a pregăti, întrerupe sau confirma. Un participant este responsabil cu determinarea dacă

o condiţie preparată este posibilă atunci când un protocol de realizare în două faze este

iniţiat, iar apoi pentru aplicarea unei decizii globale la nivelul resursei.

12. Sub-composer este un Actor, care nu este nodul BTP superior al unei tranzacţii. Acesta

primeşte rezultatul de la superiorii săi şi decide rezultatul către ramurile imediate

asociate acestuia, pe baza regulilor de coeziune definite în specificaţiile sale. Este

caracterizat printr-un ciclu de viaţă, similar cu al coeziunii. Un Sub-composer poate

emite instrucţiuni pentru a prepara, întrerupe sau confirma ramurile individuale.


82

Aceste instrucţiuni iau forma unor mesaje BTP. De asemenea, un sub-composer

trebuie să fie dotat cu cel puţin o adresă BTP către care nodurile de nivel inferior vor

putea trimite mesaje BTP.

13. Sub-coordinator este un actor, care nu este nodul BTP superior al unei tranzacţii.

Acesta recepţionează un rezultat de la superiorul său şi va propaga rezultatul către

ramurile imediate asociate acestuia, pe baza regulilor Atomice definite în specificaţiile

sale. Este caracterizat printr-un ciclu de viaţă, similar cu al Atomului. Un sub-

coordinator poate emite instrucţiuni pentru a prepara, întrerupe sau confirma. Aceste

instrucţiuni iau forma unor mesaje BTP. De asemenea, un sub-coordinator trebuie să

fie dotat cu cel puţin o adresă BTP către care nodurile de nivel inferior vor putea

trimite mesaje BTP.

Notaţia utilizată

Notaţia utilizată este compatibilă XML şi SOAP.

Extensibilitate

Nici un mecanism specific nu este oferit pentru a permite introducerea unor mesaj

complet noi. Totuşi, pentru a simplifica interoperabilitatea între diferitele versiuni de BTP, se

poate folosi un parametru „must-be-understood‖.

Manipularea erorilor, suportul pentru compensare

Mecanismele de recuperare sunt descrise în detaliu în specificaţiile protocolului. BTP

identifică două categorii majore de eşec:

Eşec de comunicare, transmis fie de nivelele inferioare, sau care poate fi generat ca

urmare a expirării unui cronometru. În acest caz recuperarea presupune că toţi

participanţii sunt capabili să schimbe mesaje din nou, pentru continuarea tranzacţiilor.

Eşec de reţea, oferă în plus capabilitatea de a menţiona că starea unui participant ar

putea fi pierdută. Pentru protecţia împotriva acestei situaţii, BTP poate cere ca anumite

informaţii de stare să fie persistente, chiar dacă nodul de reţea eşuează. Natura

informaţiilor care urmează să fie persistente depinde de natura şi prerogativele

aplicaţiei.

Recuperarea în urma unui eşec al unui nod de reţea poate implica refacerea unui punct

de comunicaţie accesibil care are acces către informaţiile persistente, în cazul tranzacţiilor

incomplete. Aceasta se poate realiza astfel:

Recrearea actorului original folosind fie aceeaşi adresă fie o altă adresă.

Crearea unei entităţi de recuperare distincte, care poate accesa datele persistente, dar

este dotat cu o adresă distinctă.

BTP menţionează două tipuri de mesaje de recuperare:

1. Mesajele care sunt trimise atunci când un participant este într-o fază de finalizare.

Triggerul pentru retrimiterea ultimului mesaj este o excepţie de la un nivel inferior,

sau expirarea unui cronometru, restabilirea mijloacelor de comunicaţiei, etc.

2. Mesajele de recuperare care sunt trimise când participanţii se află într-o stare activă. În

această stare nu există un „ultim mesaj‖ potrivit care să poată fi determinat şi trimis.

BTP propune ca părţile să fie capabile să-şi interogheze reciproc stările, prin mesaje


83

de tip INFERIOR_STATE sau SUPERIOR_STATE. Aplicaţia receptoare va putea

răspunde prin trimiterea fie a mesajului complementar, fie a mesajului pierdut.

BTP propune de asemenea ca o adresă de redirectare să fie utilizată pentru a dirija

mesajele trimise de aplicaţia apelantă către adrese alternative după ce participantul de la

adresa iniţială şi-a încetat (temporar) activitate. Aceasta se poate implementa prin:

Schimburile de mesaje dintre participanţi pot utiliza un set de adrese care sunt

alternative, una dintre acestea urmând să fie utilizată ca adresă ţintă pentru mesajele

viitoare. Dacă apelantul determină că o adresă nu este funcţională, va putea utiliza o

adresă alternativă.

Un mesaj de redirectare ar putea fi utilizat pentru a informa participantul că adresa

anterioară nu mai este validă şi o nouă adresă, de înlocuire, urmează să fie specificată.

Mesajul ar putea fi trimis spontan, sau la cerere.

De asemenea, protocolul specifică tipul mesajelor care urmează să fie schimbate între

un Superior şi un Inferior atunci când Inferiorul alege să „contrazică‖ o decizie de confirmare

sau anulare din partea Superiorului.

Dependinţe şi interoperabilitate cu alte limbaje sau notaţii

Această caracteristică depinde de XML.

Interoperabilitatea cu SOAP 1.1: BTP poate fi suprapus peste diferite tehnologii de

transport, cum ar fi RosettaNet sau ebXML MS. BTP nu adresează cerinţe deosebite

legate de interoperabilitatea tranzacţiilor.

Servicii Web

Prin posibilitatea de a coordona servicii ale organizaţiilor autonome, oferită la nivel de

BTP, protocolul este adaptat pentru utilizarea într-un mediu orientat spre servicii Web. De

asemenea, poate fi utilizat ca un protocol de bază în cazul unor tranzacţii de tip business

foarte slab legate, unde semantica poate fi definită prin conversaţii şi standarde pentru

managementul proceselor.

Formalism

Formalismul utilizat este bazat pe XML.

Suportul pentru structuri complexe, şabloane

BTP nu oferă niciun suport pentru şabloane pentru tranzacţii.

Constrângeri de timp.

BTP foloseşte Qualifiers pentru a fixa constrângeri de timp. Un Qualifier este o metodă

de inserare a unor informaţii suplimentare într-un mesaj care este trimis într-o relaţionare

Superior:Inferior. Trei Calificatori sunt specificaţi în BTP:

Transaction Time Limit: Acest calificator este utilizat de un utilizator al BTP APO, pentru

a sugera a durată maximă pentru desfăşurarea unei tranzacţii. Un participant poate

folosi această posibilitate pentru a determina dacă un coordonator a eşuat, atunci când

nu sunt recepţionate mesaje.


84

Inferior Timeout: Un participant poate returna acest calificator către coordonator, cu un

mesaj prestabilit. Va indica perioada pentru care participantul va rămâne pregătit, şi

tipul de acţiune pe care-l va alege dacă perioada de timp expiră.

Minimum Inferior Timeout: Acest calificator este transmis de la coordonator către

participanţi şi va preciza durata minimă necesară unui participant pentru realizarea

unei tranzacţii. Dacă un participant nu poate satisface această cerinţă, vor încheia

activitatea cu Cancel.

Manipularea informaţiilor şi a datelor

Consistenţa şi izolarea datelor nu sunt impuse sau asumate de BTP.


BTP poate fi utilizat pentru a oferi suportul necesar pentru tranzacţii într-un mediu bazat

pe servicii Web. Acest suport este esenţial, în special în cazul unor sisteme trandiţionale cum

ar fi cele orientate spre baze de date. BTP poate fi utilizat în cadrul proiecutlui. Totuşi, este

posibil ca alte standarde şi tehnologii să fie mai potrivite pentru acest domeniu specific.

5.1.4 Rezumat

Avantaje

BTP este un protocol standardizat, capabil să aigure schimburi corecte între

participanţii la tranzacţii. Această facilitate este importantă în special într-un mediu

nesigur, unde resursele şi participanţii sunt deţinuţi de entităţi multiple cu grad de

siguranţă diferit.

Specificaţiile BTP sunt complete şi bine precizate.

BTP este bazat pe XML şi consistent cu SOAP.

Învăţarea este relativ simplă, având în vedere faptul că API-urile expuse de

implementările BTP vor fi similare celor ale sistemelor de tranzacţii tradiţionale.

Dezavantaje

BTP nu este Web services-specific. Nu implică arhitecturi orientate spre servicii Web,

nu conţine WSDL sau legări către transporturi specifice. Va fi necesar un anume efort

pentru a îndeplini aceste sarcini.

BTP cere ca deciziile la nivel de afaceri să fie încorporate în infrastructura

tranzacţiilor. Prin aceasta, va fi impusă o legătură puternică între utilizator şi

coordonator.

Există un număr relativ mic de implementări, inclusiv Open Source

BTP are un impact major asupra implementărilor, atât la nivelul tranzacţiilor cât şi la

nivel de utilizator sau serviciu. Jucătorii importanţi în dezvoltarea BTP şi-au orientat

atenţia către alte specificaţii, astfel încât este puţin probabil ca BTP să joace un rol

central în dezvoltările viitoare.

Specificaţia este destul de lungă, ceea ce îngreunează procesul de învăţare.

BTP nu oferă modele, pentru precizarea semanticii în cadrul protocolului.


85

Recomandări

BTP nu este un protocol tipic pentru servicii Web, şi nu se bucură de popularitate. Dacă

serviciile Web sunt o cerinţă centrală a proiectului, probabil alegerea BPT nu este una

potrivită.

5.2 XML Based Protocol for Run-Time Integration of Process Engines (Wf-XML)

Wf-XML este destinat integrării motoarelor de execuţie a proceselor peste Internet sau

intranet şi oferirii suportului necesar pentru interacţiunile dintre acestea. Un motor de execuţie

a proceselor, ca tip special de serviciu asincron, este dotat cu o serie de activităţi care

reprezintă paşi în execuţia serviciilor sale. Prin expunerea acestor paşi, apelantul unui serviciu

este acum capabil să obţină vederi adiţionale asupra stării serviciului

În timp ce ASAP oferă facilităţile de bază pentru controlul şi monitorizarea serviciilor

web asincrone pe baza unui suport SOAP, Wf-XML se construieşte peste ASAP şi extinde

interfaţa pentru cazul particular al serviciului reprezentat de motorul de execuţie. În acest fel

se poate obţine lista activităţilor aşteptate de un proces.

Câteva dintre obiectivele Wf-XML includ următoarele:

Consistenţa cu with XML Protocol şi SOAP, urmând liniile directoare originale ale

ASAP

Oferirea unui suport minim necesar pentru motorul de execuţie a proceselor

Extensibilitatea

Nu va necesita şi nici nu va face niciun fel de presupuneri legate de platforma şi/sau

tehnologiile necesare pentru implementarea serviciilor asincrone generice

Descriere generală

Wf-XML este dezvoltat de WfMC (Workflow Management Coalition), o organizaţie

internaţională non-profit. Dintre membrii WfMC implicaţi în dezvoltarea standardului

pot fi amintiţi Fujitsu Corp., Identitech, XEROX Park, IBM, Oracle Corp.

Dezvoltarea Wf-XML a început din 1999. Prima versiune stabilă a specificaţiei a fost

oferită în Oct. 2004. Versiunea curentă este 2.0 [WfXML20]

Specificaţiile Wf-XML curente se bazează pe ASAP pentru funcţionalităţile orientate

spre fluxuri de activităţi care pot fi incluse. De asemenea, în activităţile precedente au

fost utilizate SWAP (Simple Workflow Access Protocol) sau AWSP (Asynchronous

Web Services Protocol).

Dezvoltarea SOAP fiind ulterioară dezvoltării iniţiale Wf-XML, prima versiune a

standardului nu beneficiază de pe urma structurilor de mesaje SOAP. Cu toate acestea,

noile versiuni Wf-XML sunt compatibile SOAP, fiind bazate pe versiunile curente ale

acestora.

Wf-XML a fost creat pentru a fi un protocol generic pentru serviciul asincron oferit de

un motor de execuţie a proceselor. Wf-XML trebuie să ofere compatibilitae cu

protocoale compatibile cu ASAP, cum ar fi OASIS ebXML Message Services sau

OASIS Web Services Reliable Messaging (WSRM).

Wf-XML trebuie să ofere un înalt nivel de compatibilitate cu WMC XPDL (XML

Process Definition Language) precum şi cu OASIS WS-BPEL.


86

Wf-XML nu necesită şi nici nu face niciun fel de presupuneri asupra platformelor

şi/sau tehnologiilor necesare pentru implementarea serviciilor sale.


Implementări

Există un număr relativ mic de implementări Wf-XML, incluzând aplicaţii cum ar fi

jawe (http://jawe.objectweb.org/), shark (http://shark.objectweb.org) sau Carnot. Oferind o

implementare XPDL, este de aşteptat ca suportul pentru Wf-XML să existe într-o oarecare

măsură şi în cazul Bonita (http://bonita.objectweb.org). Aceeaşi supoziţie poate fi realizată

pentru diferite alte produse care suportă XPDL şi care, într-o oarecare măsură ar putea oferi

suportul necesar pentru Wf-XML. Implementările comerciale includ Advantys

(WorkflowGen) (http://www.advantys.com).

Arii de utilizare

Construit fiind pe baza ASAP, Wf-XML va fi un candidat ideal pentru invocarea

proceselor într-un motor de execuţie orientat spre BPM, şi pentru monitorizarea execuţiei

acestora. Cu toate acestea, Wf-XML este mai degrabă un standard utilizat pentru a facilita

interoperabilitatea dintre diferitele fluxuri de activităţi.

Wf-XML oferă o metodă standard de obţinere a definiţiei unui proces de la motorul de

execuţie BPM, şi de a oferi definiţii actualizate ale acestuia către motorul BPM. Wf-XML ar

putea fi utilizat în contextul unor unelte de design pentru a implementa parcurgerea proceselor

pe motoare de execuţie a proceselor aflate la distanţă.


Atunci când este adresat suportul SOAP, nu va fi o sarcină dificilă implementarea

operaţiilor necesare serviciilor web pentru utilizare cu Wf-XML. Cu toate acestea, pentru a

beneficia de pe urma suportului SOAP, cel puţin versiunea Wf-XML 2.0 va fi utilizată.

Efortul necesar pentru a citi/implementa sau învăţa standardul poate fi evaluat la uşor

spre mediu atât pentru analiştii de afaceri cât şi pentru dezvoltatorii tehnici. Cu toate acestea,

un anumit nivel de cunoştinţe legat de protocoalele de comunicare poate fi necesar.

Disponibilitate

Un număr relativ mic de produse suportă specificaţiile Wf-XML, majoritatea fiind

aplicaţii comerciale. O serie de aplicaţii open-source sunt disponibile prin intermediul

ObjectWEB (http://www.objectweb.org), unde sunt oferite diferite implementări ale unor

standarde semnificative în domeniu, standarde dezvoltate de WfMC, OMG sau OASIS.

Este standard deschis?

Wf-XML este un standard deschis, dezvoltat de WfMC. De asemenea, OASIS a

contribuit substanţial la dezvoltarea Wf-XML, ţinând seama de suportul ASAP oferit,

interoperabilitatea şi testele în această direcţie realizate în colaborare cu OASIS.

Standarde pe care le înlocuieşte

Wf-XML înlocuieşte SWAP (Simple Workflow Access Protocol, anterior dezvoltat de

IETF, Netscape, Oracle şi alţii).

http://jawe.objectweb.org/

http://shark.objectweb.org/

http://bonita.objectweb.org/

http://www.objectweb.org/


87


Concepte utilizate

Dintre noile concepte utilizate, se poate aminti:

Tipuri de resurse: instanţă, fabrică, observator, activitate.

Activităţile sunt adăugate pentru a extinde posibilităţile protocolului:

o Un proces este dotat cu activităţi: activităţile pot fi interogate pentru valorile lor

curente.

o O activitate însăşi poate reprezenta o invocare a unui alt serviciu aflat la distanţă,

şi ar putea fi necesară identificarea adresei acelui serviciu.

o Resursa activităţii reprezintă un loc în care procesul aşteaptă pentru intrări externe.

Pot exista mai multe astfel de resurse, dacă procesul suportă execuţia paralelă a

unui număr aleator de ramuri.

Fiecare resursă are o cheie URI prin care poate fi numit, şi care permite o identificare

unică a acesteia.

Versiunea curentă WF-XML foloseşte mecanisme care sunt adaptate din mecanismele

ASAP.

Informaţii generale:

o Programul extern care invocă un proces are nevoie doar de suportul AWSP

(ASAP) pentru activităţi de bază de pornire (a proceselor) şi monitorizare.

o Wf-XML se construieşte apoi peste şi extinde această interfaţă pentru cazul special

în care acest serviciu este un motor de execuţie a proceselor.

Modelul resurselor din Wf-XML permite detalierea diferitelor roluri care vin din

partea diferitelor servicii web.

Granularitate

Este suportată un anumit nivel de granularitate prin introducerea

o De sub-procese şi prin suportarea de sub-sub-procese

o De instanţe de proces.

Notaţii utilizate

Notaţiile sunt specifice WfMC

Sunt conforme cu cerinţele WfMC/extinzând standarde existente, ASAP şi AWSP

Extensibilitate

Pentru început, adăugarea de caracteristici noi depinde de specificaţiile care vor fi

produse pentru versiunile următoare de către WfMC.

Introducerea de modificări în implementări existente presupune un efort considerabil.

Bazat fiind pe ASAP, introducerea posibilităţilor SOAP presupune specificaţii

suplimentare, precum şi implementarea acestora.

Diferitele versiuni de Wf-XML trebuie să fie tratate cu atenţie pentru a garanta

compatibilitatea între diferitele versiuni existente.


88

Manipularea erorilor şi suportul pentru mecanisme de compensare

Toate mesajele oferă opţiunea de a returna o excepţie. Excepţiile sunt tratate într-o

manieră specifică SOAP 1.2 (sau versiunea SOAP pe baza căreia a fost construită

specificaţia Wf-XML).

Tranzacţiile multi-server: AWSP/ASAP nu include nicio posibilitate ca servere

multiple să fie capabile să participe la o aceeaşi tranzacţie. Diferitele sisteme

individuale trebuie să determine acţiunile necesare în cazul în care o cerere

AWSP/ASAP eşuează.

Anumite metode pot întoarce anvelope Fault conţinând elementul utilizat pentru

marcarea excepţiilor (această posibilitate este conformă cu standardul SOAP dar nu

este conformă cu codurile de eroare definite de către Workflow Management Coalition

pentru diferitele specificaţii Wf-MXL).

Funcţie de versiunea Wf-XML, suportul SOAP poate fi mai puţin puternic, cu

implicaţii majore asupra evoluţiei viitoare a produselor dezvoltate.

Dependinţe, interoperabilitate

Standardul este bazat pe AWSP, SOAP, ASAP şi suportă SOAP într-o oarecare

măsură.

ASAP şi Wf-XML sunt interoperabile, existând teste periodice pentru confirmarea

interoperabilităţii.

Orientare spre servicii web

Da, conform orientării standardelor de bază AWSP (ASAP).

Wf-XML asigură suportul pentru servicii web de bază, interoperabilitatea cu diferite

produse trebuie să fie efectivă.

Odată cu Wf-XML 2.0, definit pe baza WSDL, se poate afirma că Wf-XML 2.0 oferă

servicii web standard.

Formalismul utilizat

Este bazat pe XML, AWSP (ASAP), iar codurile de eroare sunt alese pentru a fi

conforme cu codurile de eroare definite de către Workflow Management Coalition în

diferitele specificaţii Wf-XML.

Suportul pentru structuri complexe, şabloane

Tipurile de date de bază sunt Boolean, integer, string, date/time, şi URI.

Prin utilizarea proceselor şi a sub-proceselor, este oferit suportul necesar pentru

definirea de structuri complexe.

În ASAP structurile mesajelor sunt clar definite.

Suport pentru constrângeri de timp

Ca o extensie, există o legătură către ASAP, care introduce noi capabilităţi legate de

servicii.

Activităţile se bazează pe utilizarea timpului pentru a oferi noi tratamente.


89


Protocolul nu suportă cantităţi mari de date, fiind limitat la cel mult 64K bytes per

instanţă de proces. În situaţia în care o instanţă de proces este mai mare decât această

valoare, va fi depozitată ca un document separat, pe un server HTTP.

Alte informaţii tehnice specifice

Wf-XML poate fi extins la cazul special în care serviciul asincron este invocat dintr-

un motor de execuţie a proceselor.

„Service Factory‖ se mapează către „Process Definition‖; „Service Instance‖ se

mapează către „Process Instance‖. Motoarele de execuţie a proceselor oferă

funcţionalităţi suplimentare pentru monitorizarea proceselor:

o Este oferită o diagramă asociată procesului care poate fi preluată pentru analiză

o Procesele sunt compuse din activităţi

o Intrările proceselor pot fi adăugate, eliminate sau editate.

Proprietăţile pentru PortTypes sunt adăugate celor oferite de AWSP, astfel încât

acestea vor cuprinde: string, instance, factory, observer, activity, ServiceRegistry.

Aplicaţiile care utilizează Wf-XML oferă anumite caracteristici specifice, care vor fi

gestionate cu atenţie.


Wf-XML oferă unelte puternice pentru integrarea Run-Time a motoarelor de execuţie a

proceselor. Este foarte probabil ca ASAP sau tehnologii similare cu ASAP să fie capabile să

ofere acelaşi nivel de suport cu Wf-XML. Proiectul trebuie să fie capabil să suporte integrarea

Wf-XML, însă acest standard nu este necesar pentru dezvoltarea iniţială a proiectului.

Wf-XML este un candidat potrivit pentru invocarea unui proces într-un motor de

execuţie orientat spre BPM, precum şi pentru monitorizarea execuţiei acestuia. Totuşi, Wf-

XML este un standard folosit mai degrabă pentru a implementa interoperabilitatea între

procese bazate pe fluxuri de activităţi.

Wf-XML oferă o metodă standard de obţinere a definiţiei proceselor dinspre un motor

BPM, dar şi de a oferi o definiţie actualizată a acestora către motorul BPM. Wf-XML poate fi

utilizat într-un lanţ de unelte de design pentru a parcurge procesele aflate pe motoare de

execuţie la distanţă.

Wf-XML funcţionează cel mai bine împreună cu alte standarde WfMC, cum ar fi

XPDL.

5.2.4 Rezumat

Informaţii generale

Necesităţile care au dus la crearea şi dezvoltarea unui protocol de tipul Wf-XML

includ următoarele:

o Este de aşteptat ca uneltele de editare ale proceselor şi motoarele de execuţie să

poată fi produse şi oferite de companii diferite.

o Prîntr-o metodă standard de obţinere a definiţiilor proceselor şi de trimitere a

definiţiilor acestora, utilizatorii vor avea posibilitatea de a identifica uneltele de

definire a proceselor şi motoarele de execuţie care se potrivesc cel mai bine cu


90

cerinţele acestora. Wf-XML oferă în acest sens o metodă standard prin care se

poate transmite o definiţie de proces de la unealta utilizată pentru definiţia

proceselor către motorul de execuţie a proceselor.

Programele externe care invocă procese vor avea nevoie doar de suportul

AWSP/ASAP pentru sarcinile de bază de pornire şi monitorizare. Wf-XML se

regăseşte peste acest suport, extinzând interfaţa pentru cazul special al unui serviciu

care este reprezentat de un motor de execuţie. O astfel de extensie oferă suportul

pentru regăsirea unei liste de activităţi pe care le aşteaptă procesele.

Activităţile pot oferi informaţii suplimentare legate de asignarea către activităţi şi

posibil despre sub-procesele la distanţă care au fost invocate pentru a duce la

îndeplinire activităţile.

AWSP/ASAP oferă o metodă de pornire a unei instanţe a unui serviciu web asincron,

de monitorizare, control şi notificare din partea acesteia.

Principalul aspect este legat de faptul că o instanţă de serviciu este un obiect care

trebuie să fie pornit de la distanţă, şi care ar putea necesita o perioadă mare de timp

pentru terminarea execuţiei. Serviciile de scurtă durată, sincrone, pot fi apelate cu

uşurinţă prin intermediul SOAP, spre deosebire de serviciile de lungă durată, cu

caracteristici asincrone şi cerinţe tipice.

Wf-XML oferă o extensie pentru cazul special în care serviciul asincron este invocat

de un motor de execuţie a proceselor.

Avantaje

A fost conceput ca extensie a AWSP şi este consistent cu XML şi SOAP. Wf-XML

oferă o extensie pentru cazul special în care serviciul asincron este invocat de un

motor de execuţie a proceselor.

Motoarele de execuţie a proceselor oferă capabilităţi suplimentare pentru

monitorizarea proceselor:

o O diagramă a proceselor care poate fi obţinută pentru analiză

o Procesele sunt compuse din activităţi

o Intrările proceselor pot fi adăugate, şterse sau editate

Wf-XML extinde ASAP prin oferirea de operaţii standard suplimentare pentru

serviciile web prin care este posibilă trimiterea sau regăsirea „programelor‖ sau

definiţiilor serviciilor care sunt oferite. Motorul de execuţie oferă un comportament

prin care sunt oferite servicii de lungă durată, şi este în plus programabil oferind

facilităţi de instalare a definiţiilor de procese.

Wf-XML oferă o metodă potrivită pentru un motor de execuţtie orientat spre BPM să

invoce un proces într-un alt motor BPM, şi să aştepte încheierea execuţiei acestuia.

Dezavantaje

Protocolul nu precizează niciun nivel de securitate. Prin urmare, acesta va adopta

protocoalele de securitate specifice pentru ASAP /SOAP atunci când securitatea este

necesară pentru implementarea unor servicii specifice.

Similar cu AWSP, Wf-XML nu a fost conceput pentru a manipula cantităţi mari de

date specifice proceselor.


91

Recomandări

Wf-XML este un candidat potrivit pentru invocarea proceselor de pe un motor de

execuţie a proceselor şi de monitorizare a execuţiei acestora. Cu toate acestea, Wf-XML este

mai degrabă un standard utilizat pentru a facilita interoperabilitatea fluxurilor de activităţi.

Acesta va fi utilizat, pe cât posibil, împreună cu XPDL. Totuşi, în contextul proiectului, se va

avea în vedere puternica interoperabilitate dintre Wf-XML şi ASAP, astfel încât decizia

preluării unuia dintre standarde va ţine seama de cerinţele existente ale proiectului.

5.3 Universal Business Language (UBL)

Universal Business Language (UBL) este un limbaj folosit pentru a surprinde

informaţiile de afaceri, utilizabile în scopul integrării sistemelor şi pentru partajarea de

informaţie cu partenerii comerciali. UBL a fost creat de la început pentru a permite utilizarea

diferitelor vocabulare sau experienţe disponibile în sistemele existente, sisteme care folosesc

EDI (Electronic Data Interchange), ebXML (Electronic Business XML), sau alte sisteme de

comerţ electronic sau bazate pe XML.

Într-o prezentare a limbajului realizată pe coverpages.com este precizat că ―UBL

defineşte o bibliotecă comună de documente de afaceri bazate pe XML, cum ar fi ordine de

cumpărare sau facturi, precum şi componentele reutilizabile pe baza cărora se pot construi

un număr nelimitat de documente.” 12

UBL a fost proiectat pentru a se potrivi direct cu practicile de afaceri, legale, de audit

sau de management a înregistrărilor (comerciale) existente, eliminând necesitatea re-

codificării datelor existente în lanţurile de aprovizionare bazate pe fax sau hârtie şi oferind un

punct de intrare în comerţul electronic pentru întreprinderile mici şi mijlocii.

UBL este un limbaj utilizat pentru a captura informaţiile de afacere, pentru utilizare în

integrarea sistemelor de afaceri şi pentru partajarea datelor între partenerii comerciali. UBL

defineşte o bibliotecă comună de documente de afaceri bazate pe XML precum şi componente

de date reutilizabile, pornind de la care este posibilă crearea unui număr nelimitat de noi

documente.

Câteva dintre obiectivele şi caracteristicile UBL includ, dar nu sunt limitate la

următoarele:

Trebuie să fie consistent cu tehnologiile de procesare XML, de fiecare dată când este

posibil.

UBL este bazat pe şi inspirat din xCBL. Totuşi, UBL nu trebuie considerat ca fiind un

subset xCBL, nici nu se va presupune o compatibilitate explicită cu acesta în orice fel.

Designul tipurilor de documente UBL document trebuie să conţină trăsături comune

într-o măsură cât mai mare posibilă. Documentele UBL vor fi, pe cât posibil, ―orientat

spre conţinut‖, spre deosebire de orientarea spre structură.

12

Universal Business Language (UBL) Version 1.0 Aprobat ca OASIS Standard, vezi coverpages.com,

http://xml.coverpages.org/ni2004-11-08-a.html.

http://xml.coverpages.org/ni2004-11-08-a.html


92

UBL este destinat pentru utilizare în aplicaţii sau pentru schimburi (de informaţie).

Documentele UBL trebuie să fie, într-o oarecare măsură, destul de clare pentru actorii

umani.

Nu se face nicio presupunere, şi nici nu necesită o anumiă platformă sau tehnologie

utilizată pentru a implementa limbajul.

UBL este un format pentru reprezetarea datelor de afaceri, destinat maşinii, din care se

poate genera în mod automat, la orice moment, o reprezentare pe hârtie, conform

standardelor internaţionale.

Descriere generală

UBL este dezvoltat de OASIS. Printre membrii OASIS implicaţi în dezvoltarea UBL

pot fi menţionaţi Capgemini, IBM, NEC Corp., NIST, Oracle Corp., SeeBeyond Tech.

Corp., Sun Microsystems, Boeing, Fujitsu Corp., CISCO Systems.

Comitetul Tehnic UBL a fost iniţial format în 2001, prima versiune (Beta Release 1.0;

Committee Specification) fiind publicată în Nov. 2003. Din 2004 UBL 1.0 este

standard oficial OASIS [UBL].

Versiunea 1.0 a standardului este complet dezvoltată. Versiunea 2.0 a standardului a

fost, de asemenea, acceptată ca standard OASIS în 2007.

UBL este legat de numeroase alte standarde care se referă la vocabulare pentru

desfăşurarea afacerilor. Majoritatea sunt bazate pe framework-uri EDI şi sunt

funcţionale în acest context. UBL este de asemenea înrudit cu standarde cum ar fi

ebXML, RosettaNet, OAGI sau VCA OASIS e-government.

Comitetul naţional Danez pentru XML a adoptat UBL ca un standard pentru

eCommerce în sectorul public. Numeroase guverne europene au susţinut dezvoltarea

versiunilor ulterioare.

Diferite alte standarde pentru schimbul de date oferă relaţii de lucru cu UBL: ACORD

(asigurări), ARTS (vanzare cu amănuntul), ebXML Asia Committee (ebXML),

e.centre (EAN.UCC), EIDX (electronice), HL7 (sănătate), NACS, the Open

Applications Group (OAGI), RosettaNet, SWIFT (bancar), UIG (utilităţi), VCA

(reţete), UN/CEFACT ATG, UN/CEFACT TBG, ASC X12, XBRL (contabilitate),

OASIS e-Government TC, sau OASIS CIQ TC.

UBL oferă prima implementare reală a specificaţiilor tehnice ebXML Core

Components.

Implementarea UBL nu necesită şi nu face niciun fel de presupuneri asupra

platformelor sau tehnologiilor utilizate.


Implementări

Una dintre principalele implementări este ―Danish Public Procurement Portal‖ (DOIP),

o piaţă electronică accesibilă pentru sistemul de achiziţii publice din Danemarca

(http://www.doip.dk). Alte implementări includ XSL-FO style sheets disponibile de la Crane

Softwrights, sau produse software bazate pe Java software peste fundaţia oferită de biblioteca

Crane şi disponibilă de la Ambrosoft (http://ambrosoft.com/) pentru a realiza transformări

directe de documente UBL în format HTML, conforme cu UN Layout Key.

http://www.doip.dk/

http://ambrosoft.com/


93

Una din primele implementări UBL a fost realizată de Impaq (http://www.impaq.co.uk/)

sau Q Associates (http://www.qassociates.co.uk/), un revânzător SUN.

De asemenea, Micah Dubinko a dezvoltat mai multe implementări XForms

(http://dubinko.info/writing/xforms/ubl/); de asemenea transformări XSLT şi ZPT către

HTML/PDF sunt disponibile de la Accountis plc (http://www.accountis.org/).

Domenii de utilizare

Domeniile de utilizare UBL sunt diverse, începând cu aplicaţii SOA (Service Oriented

Architecture) complexe până la soluţii simple pentru schimburi de documente, bazate pe

metode de comunicare tradiţionale. Totuşi, principala utilizare a limbajului este pentru a oferi

o versiune electronică documentelor de afaceri tradiţionale, oferind astfel şi mijloacele

necesare pentru schimburile de documente de afaceri.


UBL oferă un set de şabloane predefinite pentru documentele de afaceri. Terminologia

este astfel uşor de înţeles pentru analiştii de afaceri. Cu toate acestea, un anumit nivel de

cunoştinţe specifice XML sunt recomandate pentru a putea citi, înţelege şi învăţa standardul.

Efortul necesar pentru aceste activităţi poate fi evaluat la 5.5-6.5/10.

Pentru un dezvoltator tehnic pe de altă parte, limbajul de specialitate implicat este

relativ uşor de înţeles. În această situaţie efortul necesar poate fi estimat la 4/10.

Este standard deschis?

UBL este un standard deschis, dezvoltat şi menţinut de către OASIS.

Formalismul

UBL este bazat pe xCBL, însă a fost dezvoltat iniţial ca o implementare a ebXML

CCTS (Core Components Technical Specification). Biblioteca UBL este bazată pe BIE

(Business Information Entities). UBL este înrudit cu diferite standarde care oferă vocabulare

pentru conducerea afacerilor, fiind în relaţie în special cu standarde care funcţionează în

relaţie cu EDI. UBL este înrudit cu alte standarde sau notaţii, incluzând ebXML, RosettaNet,

OAGIS.

xCBL (XML Common Business Library) este un sed de structuri de bază XML şi un

framework pentru documente, care permite crearea de documente XML robuste, reutilizabile,

pentru a facilita schimburi comerciale globale. UBL înlocuieşte şi completează munca depusă

pentru dezvoltarea xCBL.


Concepte utilizate

Liste de coduri

Modele de date şi metadate pentru listele de coduri

Schemă de reprezentare pentru listele de coduri

Maparea modelelor de date

Uniform resource names (URN)

http://www.impaq.co.uk/

http://www.qassociates.co.uk/

http://dubinko.info/writing/xforms/ubl/

http://www.accountis.org/


94

Tipuri complexe ca şi clase UBL, de asemenea utilizează reguli (care sunt dotate cu o

schemă, constrângeri, sunt modulare), instanţe de documente

Definiţia de tipuri complexe pentru modelarea conţinuturilor oferă a secvenţă cu

referinţe spre elementele globale necesare, sau declaraţii de elemente locale, pentru a

reflecta fiecare proprietate din clasa sa aşa cum a fost aceasta definită în modelul UBL

corespunzător

UBL oferă două scheme normative pentru fiecare tranzacţie

UBL oferă BIE (Business Information Entities) ca un rezultat al instanţierii şi

contextualizării conceptelor abstracte UBL pentru un sector de activitate specific şi

pentru o anumită ţară. UBL oferă metodele necesare pentru contextualizare în

construcţia documentelor convenţionale.

Conceptele UBL comune pentru modelul componentelor include următoarele:

Address, Contract, Delivery, Document Reference, Hazardous Item, Item, Party,

Procurement şi Tax

Conceptele comune UBL pentru modelul de asamblare a documentelor include

următoarele: Order, Order Response, Order Response Simple, Order Change, Order

Cancellation, Despatch Advice, Receipt Advice şi Invoice. UBL 2.0 adaugă 23 noi

tipuri de documente ce admit scenarii extinse şi procese generale de transport.

Artefacte

Sunt suportate următoarele artefacte în cadrul procesului de dezvoltare (a

documentelor): model conceptual, model spreadsheet, scheme, model de

implementare.

Granularitatea

UBL permite ca documentele să fie structurate conform conceptelor XML.

Prin tipurile complexe ca şi clase este oferit suportul necesar pentru rafinarea

granularităţii.

UBL oferă componente ale documentelor, granularitatea sa este la nivel de informaţie;

de asemenea oferă suport pentru asamblarea de modele de documente şi pentru o

granularitate la nivel de proces.

Notaţii utilizate

Este recomandată utilizarea unei notaţii grafice, cum ar fi Diagrame de clasă UML,

pentru a oferi vederi de nivel înalt, extinse.

UBL foloseşte matrice spreadsheet. Cu toate acestea, este de preferat ca o bază de date

să poată fi construită având la bază metamodelul ca schemă a bazei de date.

Notaţia finală pentru biblioteca UBL Library este XML Schema. Prin aceasta se oferă

o implementare fizică pentru modelele logice UBL.

Extensibilitate

Interoperabilitate listelor de coduri interne se manifestă atunci când diferite specificaţii

sau aplicaţii folosesc aceleaşi seturi de valori enumerate (sau aliasuri ale acestora)

pentru a reprezenta concepte/obiecte identice. Prin partajarea schemelor XML (sau a


95

unor fragmente ale acestora) se poate obţine această interoperabilitate, dar nu este o

metodă obligatorie pentru a atinge acest scop.

În ceea ce priveşte interoperabilitatea internă, [UBLCLSC] menţionează ―abilitatea

organizaţiilor non-UBL de a creea module de scheme XSD care definesc liste de

coduri într-o manieră care să permită reutilizarea acestora în UBL fără modicări

asupra vreunei părţi a acestora.‖

Modelul pentru listele de coduri trebuie să fie capabil să ofere posibilităţi de extensie,

restricţie sau import al unor valori adiţionale.

Schemele UBL sunt modulare, reutilizabile, şi extensibile într-o manieră de tip XML.

Dependinţe şi interoperabilitate

UBL este primul implementare reală realizată pentru specificaţiile tehnice ebXML

Core Components (CCTS 2.01, aka ISO 15000-5). Biblioteca UBL constă din ebXML

CCTS Business Information Entities (BIEs). Schemele XML UBL sunt prin aplicarea

convenţiilor de numire şi design UBL (UBL Naming and Design Rules – NDRs)

asupra unui model de date mapat peste tipurile de componente de bază ebXML. UBL

poate funcţiona în legătură cu UN/CEFACT TBG17 pentru o mapare a UBL către o

eventuală bibliotecă standard de componente, dar şi cu UN/CEFACT ATG şi OAGI în

vederea dezvoltării unui standard internaţional unic pentru reprezentarea în XML a

tipurilor ebXML Core Component şi Unqualified Data.

UBL este interoperabil cu ebXML, XBRL, XACML. Totuşi, sarcinile de

interoperabilitate sunt rezolvate prin servicii web sau standarde ebXML specifice

(cum ar fi ebXML CPPA, XML Protocol—SOAP, ebMS).

Este orientat spre servicii Web?

UBL este puternic orientat către servicii Web. De fapt, UBL oferă o interoperabilitate

crescută pornind de la utilizarea serviciilor web.

Formalism

Deoarece utilizările listelor de coduri nu se încadrează exclusiv în domeniul XML,

este de dorit o separare a descrierilor modelului de date de forma de reprezentare

XML a documentelor.

UBL a fost conceput pentru a suporta ţintele UN/CEFACT în vederea suportării unei

singure abordări centrate pe document pentru conţinuturile XML.

Suportul pentru structuri complexe, şabloane:

Tipurile complexe UBL sunt clase de obiecte (în termeni ebXML CC). Fiecare

subelement al unui tip complex este o proprietate a unei clase de obiecte iar tipurile

legate de subelemente sunt la rândul lor clase de obiecte.

Mai multe şabloane derivate din modelul de componente şi modelele de asamblare ale

documentelor pot fi de asemenea disponibile. Acestea includ: Address, Contract,

Delivery, Document Reference, Hazardous Item, Item, Party, Procurement, Tax,

Order, Order Response, Order Response Simple, Order Change, Order Cancellation,

Despatch Advice, Receipt Advice sau Invoice.


96

Suport pentru constrângeri de timp

ebXML oferă un bun suport pentru constrângerile de timp, manipularea excepţiilor şi

controlul primitivelor de flux. Bazat fiind pe ebXML, este de aşteptat ca UBL să poată

oferi acelaşi suport.


Sunt oferite mulţimi restrânse de valori codificate, numite „liste de coduri‖, valori pe

baza cărora sunt populate câmpurile de date UBL. Listele de coduri sunt accesate prin

tehnologii diferite, inclusiv sisteme de gestiune a bazelor de date, aplicaţii sau

tehnologii bazate pe XML. Listele de coduri sunt exprimate în XML; pentru UBL este

folosită XML Schema atât pentru scopuri de creare a listelor de coduri cât şi pentru

validarea acestora.

Modelul de date este exprimat într-un format maşină: „Un model de date este o

abstractizare şi trebuie sş fie convertit la o reprezentare explicită pentru utilizare.‖

(OASIS Universal Business Language (UBL), Code List Representation). Utilizarea

principală anticipată printr-un asemenea efort este legată de schimburile de date XML.

O reprezentare în format maşină a modelelor de date oferă avantajul automatizării şi

simplificării sarcinilor de transfer.

Pentru necesităţi particulare, utilizatorii pot implementa liste de coduri private care

completează listele de coduri publice ale standardului.


Universal Business Language (UBL) este un limbaj utilizat pentru capturarea de

informaţii de afaceri pentru utilizarea acestora în integrarea sistemelor de afaceri şi pentru

partajarea de date între partenerii de afaceri. UBL a fost conceput de la început pentru a

permite reutilizarea deferitelor vocabulare şi experienţe disponibile în sisteme diverse care

folosesc EDI (Electronic Data Interchange), ebXML (Electronic Business XML), sau alte

sisteme bazate pe XML sau sisteme eCommerce bazate pe Web.

Orice fel de experienţă EDI sau ebXML poate oferi un punct de start important în

înţelegerea sau utilizarea limbajului.

5.3.4 Rezumat

Avantaje

UBL oferă un format de date standard pentru mesajele care urmează să fie schimbate

între infrastructuri de nouă generaţie bazate pe XML şi care implementează

funcţionalităţile EDI peste internet

Costuri reduse de integrare, atât între cât şi în cadrul întreprinderilor, prin reutilizarea

unor structuri de date comune.

Costuri reduse ale aplicaţiilor software comerciale (datorită suportului standard XML

şi a sintaxei relativ simple a standardului)

Abordarea este conformă cu obiectivul UBL de a se alinia cu specificaţiile tehnice ale

ebXML Core Component. Conform cu acestea, UBL se referă la componentele proprii

ca Business Information Entities (BIE).

O curbă de învăţare relativ uşoară, datorită numărului mic de biblioteci necesare

pentru a suporta procesul de învăţare

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl

http://ebxml.org/


97

Costuri mici de intrare, prin urmare adoptare rapidă, mai ales din partea

întreprinderilor mici şi mijlocii.

Existenţa de training-uri standardizate, posibilitatea de a obţine relativ uşor utilizatori

specializaţi

O plajă largă de integratori de sisteme este disponibilă

Standardizarea oferă unelte ieftine pentru introducerea şi obţinerea datelor.

Dezavantaje

Un dezavantaj major rezultă din notaţia tabelară (spreadsheet); în acest caz este

necesară intervenţia directă, manuală, pentru a controla impactul modificărilor

realizate.

Pentru legătura cu UMM, metodologia prescriptivă oferită de UMM nu descrie analiza

şi designul documentelor sau a componentelor. În plus, metamodelul CCTS nu include

facilităţile XML necesare pentru UBL.

Recomandări

Utilizarea UBL este interesantă în contextul proiectului având în vedere setul mic de

scheme XML oferite pentru a descrie documentele de afaceri comune, şi biblioteca în care

sunt descrise elementele de date comune pentru documentele de afaceri uzuale. UBL poate fi

utilizat în fluxurile de activităţi specifice proceselor de afaceri, în special în implementarea

componentelor şi conceptelor B2B.

5.4 Asynchronous Service Access Protocol (ASAP)

ASAP oferă o metodă de pornire a unor instanţe ale serviciilor web asincrone, de

monitorizare, control ale acestora, precum şi notificări legate de terminarea activităţii

acestora. Câteva dintre obiectivele ASAP includ următoarele:

Oferirea unui suport consistent cu XML Protocol şi SOAP

O uşoară includere în alte aplicaţii bazate pe protocoale SOAP, şi care necesită

comunicaţie asincronă

Oferirea suportului minim necesar pentru servicii asincrone generice (posibilitatea de

a porni, monitoriza, schimba date cu, sau oferirea controlului generic al serviciilor

asincrone pe un sistem diferit)

Extensibilitate

Nu va necesita şi nu va realiza nicio presupunere asupra platformei şi/sau tehnologiilor

folosite pentru implementarea serviciilor asincrone generice

Descriere generală

ASAP este un standard dezvoltat sub egida OASIS13

. Membrii OASIS implicaţi în

dezvoltarea specificaţiilor ASAP includ Fujitsu Corp., IWay Software, CISCO

Systems, Iopsis Software.

Dezvoltarea iniţială ASAP a început în Sept. 2003. Specificaţiile curente (versiunea

1.0) au fost elaborate şi finalizate în 2006.

13

http://www.oasis-open.org/committees/documents.php?wg_abbrev=asap


98

ASAP este un protocol bazat pe SOAP. Dezvoltarea sa este de asemenea bazată într-o

oarecare măsură pe activităţile legate de SWAP (Simple Workflow Access Protocol) şi

AWSP (Asynchronous Web Services Protocol).

Versiunea curentă Wf-XML este de asemenea construită pe suportul ASAP în vederea

includerii unor funcţionalităţi orientate spre fluxuri de activităţi.

Specificaţiile ASAP sunt de asemenea compatibile cu ebXML Message Services.

ASAP a fost creat pentru a oferi un protocol generic pentru servicii asincrone. Totuşi.

Specificaţiile ASAP sunt create pentru a fi complet compatibile cu eforturi similare,

cum ar fi cele realizate de WfMC, OASIS ebXML Message Services sau OASIS Web

Services Reliable Messaging (WSRM). De asemenea, ASAP intenţionează să ofere

posibilităţi asincrone generice care vor putea fi utilizate în fluxurile de activităţi sau

alte aplicaţii, incluzând procesele de afaceri. Nu ar trebui să apară probleme deosebite

în adăugarea suportului ASAP în BPEL sau peste alte protocoale orientate spre medii

de tip business (cum ar fi Oasis Business Transaction Protocol, BTP).

ASAP nu necesită şi nu realizează niciun fel de presupuneri legate de platforma sau

tehnologiile utilizate pentru implementarea serviciilor asincrone generice.

Criterii de piaţă

Implementări

Numărul de implementări existente pentru ASAP sau iniţiative în direcţia standardului

este relativ mic, având în vedere şi faptul că standardul este relativ nou. Probabil cea mai

importantă implementare este oferită de Wf-XML. Printre iniţiativele open-source pot fi

amintite AxisASAP pentru Java şi EasyASAP pentru C++. Din nefericire, pe baza acestor

informaţii putem trage concluzia că există o slabă reprezentare pe piaţa software a produsului.

Cu toate acestea există un număr important de demonstraţii de interoperabilitate

ASAP/Wf-XML, demonstraţii suportate de WfMC şi OASIS. De asemenea, OASIS ASAP

TC oferă specificaţiile ASAPServer şi ASAPClient pentru a suporta eventuale implementări

software.

Domenii de utilizare

ASAP este un protocol orientat spre schimbul de mesaje. Cu toate acestea, ASAP nu se

referă pur şi simplu la schimburi de mesaje asincrone, ţinta lui fiind mai degrabă serviciile

care se execută asincron. ASAP oferă suportul necesare pentru controlul (configurarea,

pornirea şi oprirea serviciilor, obţinerea de informaţii şi rezultate din partea serviciului) şi

monitorizarea serviciilor. Partea legată de schimbul de mesaje este bazată pe SOAP: ASAP

oferă un set nou de metode SOAP pentru a implementa controlul şi monitorizarea.

ASAP poate fi utilizat în administrarea şi monitorizarea serviciilor şi ca protocol pentru

schimbul de mesaje (printr-un nivel de extensie SOAP).


ASAP este bazat în bună măsură pe SOAP. De asemenea conţine elemente SWAP,

AWSL sau chiar WS Addressing. Astfel, pentru un client (fie analist de afaceri sau

dezvoltator tehnic) cu un nivel suficient de cunoştinţe legate de SOAP şi WS-Addressing,

înţelegerea, utilizarea şi instruirea ASAP va fi relativ uşoară. Efortul necesar pentru a însuşi

acest standard poate fi evaluat la 6.50/10 pentru un utilizator cu cunoştinţe minime SOAP sau

WS-Addressing.


99

Este standard deschis

ASAP este un standard deschis, dezvoltat de OASIS.

Standarde înlocuite

ASAP înlocuieşte mai multe standarde, incluzând SWAP şi AWSL în domeniul

serviciilor asincrone. De asemenea, ASAP extinde SOAP prin oferirea unor noi metode

SOAP.

Diferite demonstraţii de interoperabilitate au fost realizate sub conducerea organizaţiilor

OASIS şi WfMC.

Disponibilitate

Există mai multe iniţiative open-source care presupun implementarea ASAP, chiar dacă

rezultatele oferite sunt, în general, modeste. Diferite ‗endpoint‘ ASAP sunt disponibile. De

asemenea, există posibilitatea de integrare a ASAP în BPEL. În plus, unelte software cum ar

fi Enhydra JAWE (http://jawe.objectweb.org/) implementează ASAP împreună cu Wf-XML.


Concepte utilizate

1. Pentru a suporta serviciile web asincrone sunt utilizate noţiunile de Instance, Factory, şi

Observer. Scopul unei Instance Resource (sau serviciu) este de a permite ca activitatea să

aibă o desfăşurare asincronă relativ la apelant. Fiecare Instance reprezintă o unitate de

lucru, noi instanţe de Instance Resource trebuie să fie create când activitatea urmează să

se desfăşoare efectiv.

2. Resursele (endpoints), inclusiv Instance Endpoint, Factory Endpoint şi Observer

Endpoint, reprezintă grupuri primare de metode pentru interoperabilitate. Diferitele

Endpoints sunt oferite printr-un Model de Resurse (Endpoint).

Instance Endpoint este utilizat pentru a monitoriza progresul activităţilor realizate.

Aceste resurse permit ca monitorizarea şi controlul activităţii să se poată realiza.

Factory Endpoint este utilizat pentru a începe o nouă instanţă de serviciu, pentru a

lista sau căuta instanţe existente, sau pentru a oferi informaţii (definiţii) legate de

instanţe.

Observer Endpoint poate fi utilizat pentru notificări proactive ale modului în care

progresează activitatea.

O utilizare tipică a acestui protocol poate fi identificată în Figura 27 (vezi, de

asemenea [ASAP01], Figura 1):

http://jawe.objectweb.org/


100

Asyn

ch

ron

ou

s W

eb

se

rvic

e

Factory

InstanceObserver

creates

CreateInstance

GetProperties

ListInstances

ChangeState

GetProperties

SetProperties

Subscribe

Unsubscribe

Completed

GetProperties

StateChanged

Figura 27. Tipuri de resurse ale unui serviciu web asincron şi metodele utilizate

3. ContextData şi ResultData oferă iniţierea şi răspunsul unui serviciu asincron.

4. Integrarea şi interacţiunile permit ca serviciile să fie monitorizate şi controlate.

5. Sunt utilizate URI-uri pentru a furniza identificatori unici ai resurselor.

Notaţia utilizată

Este compatibilă cu XML, XPath, SOAP.

Extensibilitate

Implementările existente pentru resursele ASAP (ContextData, ResultData) oferă

posibilitatea de extindere a setului de proprietăţi returnat. Specificaţiile ASAP definesc setul

minim de proprietăţi necesare precum şi un set de proprietăţi opţionale. Fiecare implementare

va returna proprietăţile necesare. Implementările pot returna (opţional) proprietăţi

suplimentare. Acestea vor fi elemente plasate într-un spaţiu de nume diferit de spaţiul de

nume ASAP. Folosirea proprietăţilor extinse va fi realizată cu atenţie deoarece în acest mod

se pot limita posibilităţile de interoperare ale implementării ASAP.

Manipularea erorilor, suport pentru compensare

Codurile de eroare sunt alese pentru a se potrivi cu cele definite prin specificaţiile

WfMC Wf-XML 1.1, Wf-XML 2.0, şi pentru a fi armonizate cu SOAP.

Toate mesajele oferă posibilitatea de a returna o excepţie. Excepţiile sunt tratate în

maniera definită prin SOAP 1.2.

ASAP nu include nicio metodă prin care să se permită participarea unor servere

multiple în aceeaşi tranzacţie. Sistemele individuale trebuie să determine lanţul de

acţiuni în cazul în care o cerere ASAP eşuează.

Dependinţe/interoperabilitatea cu alte limbaje sau notaţii

Depinde de XML, SOAP şi Wf-XML.

Este interoperabil cu Wf-XML, ebXML, AWSP, jCAM. Cele mai importante rezultate

de interoperabilitate sunt legate de ASAP—Wf-XML.

Servicii web

Sunt oferite servicii web asincrone folosind două roluri corespunzătoare: Instance

Factory şi Observer.


101

Elementul rădăcină al unui mesaj ASAP este o anvelopă SOAP envelope, aşa cum este

definită prin standardul SOAP.

Mesajul trebuie să conţină un header SOAP, conform cu standardul, folosit pentru

scopuri uzuale cum ar fi adresare sau rutare de mesaje. Un mesaj ASAO va conţine în

interiorul headerului fie un element Request (mesajul de la un client) fie un element

Response (mesajul de la un server).

Formalismul suportat

Este bazat pe XML, SOAP, WSDL.

Suportul pentru structuri complexe şi şabloane

Mesajele ASAP sunt bazate pe SOAP. Prin urmare, suportul ASAP pentru structuri

complexe este moştenit de la protocolul SOAP utilizat ca protocol suport.

Şabloanele de interacţiune ASAP pot fi implementate prin ebXML messaging.

Constrângeri de timp

Proprietăţi specifice precizează cantitatea minimă de timp în care o instanţă de servici

rămâne accesibilă ca resursă după ce şi-a încheiat activitatea dintr-un motiv oarecare.

Acestea pot fi utilizate eventual într-o manieră dinamică, astfel încât dacă există

cerinţe asupra unor resurse, acestea vor fi avute în considerare ulterior în relaţie cu

aceste resurse.

Manipularea datelor şi a informaţiilor

Ca serviciu web asincron:

ASAP este însoţit de o informaţie de stare, definită printr-o proprietate specifică.

Un eveniment este o modificare de stare identificabilă extern, care poate să apară în

desfăşurarea serviciului asincron, şi pentru care sunt trimise notificări către un

observator pentru a-l informa asupra unui eveniment particular.


ASAP poate fi utilizat pentru sarcini de administrare şi monitorizare a serviciilor,

precum şi ca un protocol pentru schimbul de mesaje. Este bazat pe SOAP şi AWSP.

Demonstraţiile de interoperabilitate cu Wf-XML îl recomandă pentru utilizarea în

dezvoltarea de aplicaţii orientate spre fluxuri de activităţi. De asemenea este oferită o anumită

compatibilitate cu alte standarde OASIS, cum ar fi cele din stiva ebXML (ebXML Message

Services sau Web Services Reliable Messaging – WSRM).

5.4.3 Rezumat

Avantaje

ASAP oferă suportul minim necesar pentru servicii asincrone generice. Astfel,

protocolul este capabil să ofere suportul pentru pornirea, monitorizarea, schimbul de

date cu, sau controlul unor servicii asincrone generice aflate pe un sistem diferit.

ASAP este consistent cu XML Protocol şi SOAP.


102

Este destul de uşor pentru a putea fi integrat în alte protocoale bazate pe SOAP cu

destulă uşurinţă, de fiecare dată când cerinţele de comunciare asincronă pot fi

rezolvate prin facilităţile ASAP.

Oferă caracteristici cum ar fi uşurinţa de generare, înţelegere sau parcurgere.

ASAP este extensibil. Un sistem va trebui să fie capabil să suporte extensibilitatea

pentru a putea răspunde cerinţelor unui sistem specificat, astfel încât funcţionalităţile

de nivel înalt să poată fi comunicate prin interoperabilitatea cu sistemele care nu

suportă aceste extensii.

ASAP stă la baza Wf-XML, un protocol care oferă o metodă de trimitere sau obţinere

a definiţiilor proceselor. Serviciul ASAP poate fi considerat ca fiind o cutie neagră,

pre-configurată pentru a executa un anumit proces.

ASAP oferă suportul pentru structuri complexe.

Dezavantaje

ASAP nu oferă posibilitatea ca servere multiple să participe la o aceeaşi tranzacţie.

Sistemele individuale trebuie să determine ce se întâmplă dacă o cerere ASAP

eşuează.

Suportul open-source este mai degrabă modest.

Securitatea oferită prin diferitele versiuni ASAP trebuie să fie corelată cu diferitele

soluţii SOAP care se referă la aceasta.

Sistemele care utilizează ASAP vor rezolva prin metode proprii problemele legate de

serverele multiple care participă la aceeaşi tranzacţie şi situaţiile legate de eşecul

acestor cereri.

Recomandări

ASAP va însoţi SOAP de fiecare dată când există cerinţe specifice legate de

comunicarea asincronă. Acestea vor fi bazate pe posibilităţile de pornire, monitorizare,

schimb de date cu, sau control al unui serviciu asincron generic şi vor fi utilizate atunci când

este necesară implementarea unui anumit nivel de control.

O decizie legată de adoptarea ASAP în cadrul proiectului va avea în vedere cerinţele

specifice de interoperabilitate sau integrarea run-time a motoarelor de execuţie ale proceselor.

De menţionat faptul că suportul ASAP poate fi obţinut şi prin integrarea Wf-XML (XPDL).

5.5 ebXML Messaging Service (ebMS)

ebXML MS oferă facilităţi interesante din punctul de vedere al unui mediu de tip e-

business, incluzând securitatea şi siguranţa. Astfel de facilităţi nu sunt oferite de specificaţiile

SOAP, iar standarde orientate spre servicii web oferă abordări generice ale acestora.

Documentul [ebMS v2.0] precizează că , ebXML Message Service (ebMS) defineşte

metoda de ―împachetare‖ a mesajelor şi o schemă pentru capul documetelor utilizate pentru

transferul de mesaje ebXML peste protocoale de comunicaţie cum ar fi HTTP sau SMTP,

împreună cu comportamentul uneltelor software destinate trimiterii şi recepţionării de mesaje

ebXML. ebMS este conceput ca un set de extensii stratificate pentru specificaţiile SOAP

(Simple Object Access Protocol) şi SOAP cu ataşamente.


103

Standardul ebMS este orientat către schimbul de informaţii într-un mediu de afaceri. De

regulă aceste schimburi de informaţii erau bazate pe standarde EDI (electronic data

interchange). Obiectivul principal al ebMS este de a facilita schimburile de informaţii de

afaceri într-un cadru XML. Totuşi, mesajele schimbate nu sunt neapărat mesaje bazate pe

XML: ebMS va putea fi utilizat pentru a transporta atât mesaje bazate pe XML cât şi mesaje

specificate într-un format tradiţional EDI, sau alte tipuri de mesaje digitale utilizate pentru

schimburi de informaţii de afaceri.

ebMS, de asemenea cunoscut şi ca ebXML TRP (Transport Routing and Packaging), se

concentrează asupra mijloacelor pentru schimburile de documente între diferiţii parteneri,

posibil bazat pe un stil de operare „multi-hop‖. ebMS se referă la transmiterea securizată şi în

siguranţă a sarcinilor; pe de altă parte ebMS MSH (Message Service Handler) se regăseşte

îmtre protocolul de reţea (HTTP, SMTP sau altele, în cazul ebMS 3.0) şi procesul de afaceri,

la fiecare capăt al comunicaţiei. ebMS poate fi utilizat pentru a transmite orice fel de sarcini

peste orice fel de protocol de reţea. Totuşi, definiţia unei interfeţe de serviciu abstractă între

aplicaţia de afaceri şi nivelul MSH este absolut necesară.

Funcţionalităţile centrale ale ebMS se referă la:

împachetarea mesajelor ebXML Messages şi asocierea părţilor astfel încât acestea să

poată fi trimise peste un protocol de comunicaţie, cum ar fi HTTP sau SMTP

(suportate de toate versiunile ebMS)

extensiile pentru SOAP envelope necesare pentru un Serviciu de Mesage ebXML

Message Service, pentru generarea sau procesarea de mesaje ebXML

manipularea erorilor, detectarea erorilor şi raportare

semantici de securitate pentru mesajele ebXML

De asemenea, ebMS oferă facilităţi cum ar fi:

Transmiterea sigură de mesaje prin definirea unui protocol interoperabil în care două

implementări de Servicii de Mesaje pot schimba mesaje în siguranţă

Informaţii de stare a mesajelor, prin care un serviciu poate descoperi starea mesajelor

individuale sau starea altor servicii de manipulare a mesajelor (MSH)

Garantarea ordinii mesajelor la recepţie

Operare multi-hop la trimiterea de mesaje printr-un lanţ de noduri intermediare MSH.

Descriere generală

La fel ca întreaga stivă de standarde ebXML, ebMS este dezvoltat în cadrul

organizaţiei OASIS (www.oasis-open.org), o organizaţie non-profit internaţională.

Dezvoltarea ebMS (ebXML Messaging Services) a început în 1999. Versiunea 3.0 a

standardului a fost propusă în 2006. Versiunea precedentă, 2.0, a atins maturitatea în

2002, fiind aprobată ca standard OASIS şi făcând parte din stiva de standarde ISO

15000.

Implementări: un număr mare de unelte software oferă suport complet pentru ebMS

2.0. Cu toate acestea, un număr de peste 20 produse sunt certificate ca fiind

compatibile cu ebMS (vezi de exemplu rapoartele www.ebusinessready.org, sau

www.drummondgroup.com).

http://www.oasis-open.org/

http://www.ebusinessready.org/

http://www.drummondgroup.com/


104

Printre producătorii de dată recentă pot fi amintiţi Axway Software, Cleo

Communications, Cyclone Commerce, Inovis USA Inc., Oracle Corporation, Oxlo

Systems sau Sterling Commerce.

O implementare open-source, în continuă evoluţie (Hermes MSH) este dezvoltată ca

un proiect freebxml.org (http://www.freebxml.org/msh.htm). Acesta este un produs

open-source pentru Message Service Handler oferit sub licenţă GPL. Hermes MSH

este listat în rapoartele celor două site-uri amintite mai sus, ca fiind compatibil cu

specificaţiile ebMS. Dezvoltarea Hermes MSH este suportată de CECID14

: Hermes 2

oferă comunicare real-time via HTTP sau HTTPS pentru transmisii de date peste

Internet. În plus, acesta oferă securitatea necesară pentru transportul sarcinilor folosind

extensii Secure Multi-Purpose Internet Mail Extensions (S/MIME), semnături digitale

sau criptare, în timp ce alte facilităţi cum ar fi siguranţa sau non-repudierea sunt

obţinute prin utilizarea de confirmări de primire.

ebMS este bazat pe SOAP şi SOAP cu ataşamente. Îm timp ce ebMS 2.0 suportă doar

SOAP 1.1, ebMS 3.0 suportă construcţii SOAP 1.2.

ebMS 2.0 poate fi utilizat pentru a transporta mesaje peste HTTP sau SMTP. Totuşi,

arhitectura ebXML (vezi, de exemplu [ebXML_Reqs]) precizează că ebMS va trebui

să poată transporta mesaje peste orice protocol de comunicaţie disponibil.

ebMS se poate baza pe informaţii definite printr-un CPP sau CPA (cum ar fi cele

descrise prin ebXML CPPA), dar aceste informaţii nu sunt esenţiale pentru utilizarea

ebMS.

Specificaţiile [ebXML_Reqs] se referă de asemenea la necesitatea unor comunicaţii

securizate şi sigure. Aceste facilităţi sunt definite în ebMS în contextul protocoalelor

curente care sunt capabile să ofere suportul necesar pentru securitate şi siguranţă.

Message Service Handler (MSH) suportă conceptul de QoS (Quality of Service):

calitatea serviciilor trebuie să fie controlată printr-o înţelegere existentă între partenerii

implicaţi în schimbul de mesaje.

ebMS nu realizează niciun fel de presupuneri legate de platforma sau tehnologiile care

urmează să fie utilizate pentru implementarea serviciilor sale.

5.6 Concluzii

Secţiunea cuprinde o scurtă recapitulare a facilităţilor oferite de diferitele standarde

analizate în acest capitol, oferind indicaţii asupra posibilităţilor de utilizare şi aplicare ale

acestora în contextul proiectului.

BTP

Este o specificaţie orientată spre tranzacţii B2B în domenii vag cuplate cum ar fi

serviciile web, dar nu este neapărat orientată spre servicii web.

BTP poate fi utilizat pentru a oferi suportul necesar pentru trazacţii în aplicaţii bazate

pe servicii web. Suportul pentru tranzacţii poate fi interesant îndeosebi în cazul

utilizării unor sisteme tradiţionale cum ar fi sistemele orientate spre baze de date.

14

Center for e-Commerce Infrastructure Development,

http://www.cecid.hku.hk/release/Hermes2released_16Dec2005.php.

http://www.freebxml.org/msh.htm

http://www.cecid.hku.hk/release/Hermes2released_16Dec2005.php


105

BTP nu este un protocol specific orientat spre servicii web. Din acest punct de vedere,

alte standarde ar putea fi mai interesante, chiar dacă nivelul de maturitate al acestora

nu este comparabil cu BTP.

Wf-XML

Wf-XML oferă o unealtă puternică pentru integrarea Run-Time a motoarelor de

execuţie a proceselor. Cu toate acestea este posibil ca ASAP sau tehnologii de tipul

ASAP să ofere acelaşi nivel de suport ca Wf-XML. Wf-XML poate fi considerat în

contextul proiectului, chiar dacă adoptarea acestuia nu este o prioritate.

Wf-XML este un candidat potrivit pentru invocări de procese într-un motor de

execuţie BPM iar apoi pentru monitorizarea execuţiei acestora. Wf-XML oferă p

metodă standard pentru regăsirea definiţiilor de procese de la un motor de execuţie

BPM şi de a oferi actualizări ale definiţiilor de procese către aceste motoare. Wf-

XML poate fi utilizat prin uneltele de creare a proceselor pentru a permite parcurgerea

proceselor aflate pe servere BPM la distanţă.

Wf-XML este un standard utilizat pentru a facilita interoperabilitatea între diferitele

fluxuri de activităţi. Acesta va fi folosit de regulă împreună cu XPDL. Cu toate

acestea, dacă nu se urmăreşte o integrare run-time cu motoare de execuţie a

proceselor, suportul ASAP poate fi suficient.

Wf-XML este potrivit pentru domenii care includ serviciile web, administrarea

fluxurilor de activităţi sau monitorizarea acestora.

UBL

UBL (Universal Business Language) este un limbaj utilizat pentru a surprinde

informaţiile de afaceri care urmează să fie utilizate în cadrul sistemelor dedicate sau

pentru partajarea datelor între diferiţii parteneri de afaceri. UBL a fost gândit de la

început pentru a permite exploatarea diferitelor vocabulare şi experienţe disponibile în

sisteme utilizând standarde bazate pe EDI, ebXML, sau alte tipuri de sisteme de

comerţ electronic bazate pe web sau XML.

Domeniile de utilizare UBL pot acoperi sisteme complexe SOA (Service Oriented

Architecture) sau modele simple orientate spre schimbul de mesaje cum ar fi sistemele

tradiţionale de poştă electronică. Ca principală utilizare, UBL este folosit ca o versiune

electronică a documentelor tradiţionale de afaceri, oferind suportul necesar pentru

schimburile de documente într-un mediu electronic.

Datorită faptului că UBL oferă un set minimal de scheme XML pentru documentele de

afaceri uzuale şi o bibliotecă oferind date comune pentru documentele de afaceri

uzuale, UBL poate fi interesant în contextul proiectului pentru descrierea şi

implementarea elementelor B2B la nivelul documentelor de afaceri.

ASAP

ASAP poate fi utilizat pentru administrarea şi monitorizarea serviciilor şi a

protocoalelor utilizate pentru schimburi de mesaje (ca extensie a acestora). ASAP se

bazează pe SOAP dar şi pe AWSP.

ASAP poate fi considerat ca fiind un protocol pentru transmiterea de mesaje. Totuşi

acesta nu se referă la transmiterea asincronă a mesajelor, ci mai degrabă la servicii

care se execută într-o manieră asincronă.

ASAP oferă suport pentru controlul (setare, pornire şi terminarea serviciilor, obţinerea

de informaţii şi rezultate din partea serviciilor) şi monitorizarea serviciilor. Schimbul


106

de mesaje se bazează pe SOAP: ASAP oferă un set nou de metode SOAP pentru a

atinge ţintele de monitorizare şi control ale ASAP.

Prin demonstraţiile de interoperabilitate între ASAP şi Wf-XML, acesta devine un

candidat interesant pentru utilizarea în aplicaţii bazate pe fluxuri de activităţi.

ASAP va însoţi SOAP de fiecare dată când comunicarea asincronă este necesară.

Datorită faptului că într-o platformă orientată spre comerţ electronic comportamentul

asincron al serviciilor nu poate fi evitat, ASAP devine un candidat interesant prin

prisma proiectului.

Concluziile pot fi rezumate astfel:

Standard Recomandare de utilizare Arii de utilizare

BTP NU --

Wf-XML DE EVITAT

(recomandare slabă)

Poate fi avut în vedere dacă

facilităţile ASAP nu sunt

suficiente

Servicii web,

administrarea şi

monitorizarea fluxurilor

de activităţi

UBL DA Model de informaţii,

B2B supply chains

ASAP DA Servicii web,

administrarea şi

monitorizarea

serviciilor asincron

(incl. Fluxuri de

activităţi)

Tabela 11 Recomandări finale


107

Bibliografie

[Aalst03] van der Aalst, W.M.P., ter Hofstede, A.H.M.: YAWL: Yet Another Workflow

Language (Revised version. Technical Report FIT-TR-2003-04, Queensland

University of Technology, Brisbane (2003)

[Aalst03a] W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske, ―Business Process

Management: A Survey‖, Business Process Management International

Conference, BPM 2003, Eindhoven, The Netherlands, June 26-27, 2003,

Proceedings, ed. W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske,

LNCS 2678, pp. 1-12, Springer-Verlag, Berlin, 2003, also available as

http://is.tm.tue.nl/staff/wvdaalst/publications/p183.pdf.

[Aalst03b] W.M.P. van der Aalst, ―Business Process Management: Past, Present, Future‖,

Business Process Trends, February 2003, http://www.bptrends.com.

[Aalst03c] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros,

―Workflow Patterns‖, Distributed and Parallel Databases 14(3), pp. 5-51, July

2003, available at http://is.tm.tue.nl/research/patterns/documentation.htm.

[Aalst03d] W.M.P. van der Aalst, ―Patterns and XPDL: A Critical Evaluation of the XML

Process Definition Language‖, QUT Technical Report FIT-TR-2003-06,

Queensland University of Technology, Brisbane, 2003, available at

http://is.tm.tue.nl/research/patterns/documentation.htm.

[ASAP01] OASIS, Asynchronous Service Access Protocol, ASAP Working Draft 01,

September 2003, available at http://www.oasis-

open.org/committees/download.php/7137/wd-asap-spec-01g.pdf.

[ASAP10] OASIS, Asynchronous Service Access Protocol, (ASAP) Version 1.0, Proposed

Committee Draft, 18 May 2005, available at http://www.oasis-

open.org/committees/download.php/14210/wd-asap-spec-02e.doc .

[Barros05a] Barros, A.P., Dumas, M., ter Hofstede, A.H.M.: Service Interaction Patterns. In:

van der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F., eds.: Business

Process Management. Volume 3649. (2005) pp. 302–318.

[Barros05b] Barros, A., Dumas, M., Oaks P., A Critical Overview of the Web Services

Choreography Description Language (WS-CDL), BPTrends, March 2005.

[BPDM] OMG, Revised Submission to BEI RFP bei/2003-01-06; Business Process

Definition Metamodel, Document bei/2004-01-02, Version 1.0.2, January 2004,

available at http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-

Revision.pdf.

[BPDM_05] OMG, Revised Submission to BEI RFP bei/2003-01-06; Business Process

Definition Metamodel, Document bei/2005-12-01, Version 0.5, November 2005,

available only for OMG registered users.

[BPDM_RP] OMG, Business Process Definition Metamodel Request For Proposal, OMG

Document bei/2003-01-06, January 2003, available at

http://www.omg.org/cgi-bin/doc?bei/2003-1-6.

[BPEL_ebpml] http://www.ebpml.org/bpel_2_0.htm.

[BPELmigration] http://webservices.sys-con.com/read/155617.htm.

[BPEL_oasisIntro] http://www.oasis-open.org/committees/download.php/10347/wsbpel-specification-

draft-120204.htm#s.introduction.

http://is.tm.tue.nl/staff/wvdaalst/publications/p183.pdf

http://www.bptrends.com/

http://is.tm.tue.nl/research/patterns/documentation.htm

http://is.tm.tue.nl/research/patterns/documentation.htm

http://www.oasis-open.org/committees/download.php/7137/wd-asap-spec-01g.pdf

http://www.oasis-open.org/committees/download.php/7137/wd-asap-spec-01g.pdf

http://www.oasis-open.org/committees/download.php/14210/wd-asap-spec-02e.doc

http://www.oasis-open.org/committees/download.php/14210/wd-asap-spec-02e.doc

http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf

http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf

http://www.omg.org/cgi-bin/doc?bei/2003-1-6

http://www.ebpml.org/bpel_2_0.htm

http://webservices.sys-con.com/read/155617.htm

http://www.oasis-open.org/committees/download.php/10347/wsbpel-specification-draft-120204.htm#s.introduction

http://www.oasis-open.org/committees/download.php/10347/wsbpel-specification-draft-120204.htm#s.introduction


108

[BPEL_oasis] D. König, ―Web Services Business Process Execution Language (WS-BPEL)‖,

2005, available at http://www.oasis-

open.org/committees/download.php/15424/OASIS%20WS-BPEL%202.0.ppt.

[BPEL_santeon] http://www.santeon.com/technologies/businessprocessstandards.html.

[BPEL_WIKI] http://en.wikipedia.org/wiki/BPEL.

[BPEL4WS10] F. Curbera et al., Business Process Execution Language for Web Services, Version

1.0, 31 July 2002, available at

ftp://www6.software.ibm.com/software/developer/library/ws-bpel1.pdf.

[BPEL4WS11] T. Andrews et al., Business Process Execution Language for Web Services, Version

1.1, 5 May 2003, available at

ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf.

[BPELJ] BEA and IBM, BPELJ: BPEL for Java, March 2004, available at

ftp://www6.software.ibm.com/software/developer/library/ws-bpelj.pdf.

[BPELJ_ebpml] http://www.ebpml.org/bpel_2_0.htm.

[BPELJ_ibmDN] http://www-128.ibm.com/developerworks/library/specification/ws-bpelj/.

[BPELJ_idn] http://idevnews.com/IntegrationNews.asp?ID=109.

[BPML] Business Process Management Initiative, Business Process Modeling Language,

November 2002.

[BPMN] Business Process Management Initiative, Business Process Modelling Notation

(BPMN). Version 1.0, May 2004, available at

http://www.bpmn.org/Documents/BPMN%20V1-0%20May%203%202004.pdf.

[BPMNFAQ] Business Process Management Initiative, Business Process Modeling Notation

(BPMN) Information. Frequently Asked Questions (under Development), 2004,

http://www.bpmn.org/Documents/FAQ.htm.

[BPMN06] OMG, Business Process Modeling Notation (BPMN) Specification, OMG

Document dtc/06-02-01, Final Adopted Specification, February 2006, available at

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-

0%20Spec%2006-02-01.pdf.

[BPMI05] Business Process Management Initiative, ―BPMN Implementors and Quotes‖,

http://www.bpmn.org/BPMN_Supporters.htm, December 2005.

[BTP_2002] OASIS, Business Transaction Protocol Specification, Committee Specification,

version 1.0, June 2002, available at http://www.oasis-

open.org/committees/business-transactions/index.shtml.

[BTP_2004] OASIS, Business Transaction Protocol, version 1.1, Working Draft 05, November

2004, available at http://xml.coverpages.org/BTPv11-200411.pdf.

[BTP_PR_2002] OASIS, Business Transaction Protocol Primer, Committee Supporting Document,

version 1.0, June 2002, available at http://www.oasis-

open.org/committees/business-transactions/index.shtml.

[Brogi04] Brogi, A., Canal, C., Pimentel, E., Vallecillo, A.: Formalizing Web Service

Choreographies. In: Proceedings of First International Workshop on Web Services

and Formal Methods, Elsevier (2004).

[Busi05] Busi, N., Gorrieri, R., Guidi, C., Lucchi, R., Zavattaro, G.: Choreography and

Orchestration: A Synergic Approach for System Design. In: B. Benatallah, F.

Casati, and P. Traverso (Eds.): ICSOC 2005, LNCS 3826, Springer Verlag (2005),

228–240

http://www.oasis-open.org/committees/download.php/15424/OASIS%20WS-BPEL%202.0.ppt

http://www.oasis-open.org/committees/download.php/15424/OASIS%20WS-BPEL%202.0.ppt

http://www.santeon.com/technologies/businessprocessstandards.html

http://en.wikipedia.org/wiki/BPEL

http://www.ebpml.org/bpel_2_0.htm

http://www-128.ibm.com/developerworks/library/specification/ws-bpelj/

http://idevnews.com/IntegrationNews.asp?ID=109

http://www.bpmn.org/Documents/FAQ.htm

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-02-01.pdf

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-02-01.pdf

http://www.bpmn.org/BPMN_Supporters.htm

http://www.oasis-open.org/committees/business-transactions/index.shtml


http://xml.coverpages.org/BTPv11-200411.pdf




109

[Butler04] Butler Group, Business Process Management. A Guide to Navigating the Process

Minefield, Hull, UK, February 2004.

[Casewise05] Personal communication from Casewise representative, December 2005.

[Decker06] Decker, G., Puhlmann, F., Weske, M., Formalizing Service Interactions LNCS,

Vol. 4102, Springer Verlag, pp. 414-419, 2006.

[ebMS 2.0] OASIS, ebXML Message Service Specification, Version 2.0, April 2002, available

at http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf.

[ebXML_CPPA] OASIS, Collaboration-Protocol Profile and Agreement Specification, Version 2.0,

September 2002, available at http://www.oasis-

open.org/committees/download.php/204/ebcpp-2.0.pdf.

[ebXML_Reqs] OASIS, ebXML Requirements Specification, Version 1.06, May 2001, available at

http://www.ebxml.org/specs/ebREQ.pdf.

[Frankel06] D.S. Frankel, ―BPMI and OMG: The BPM Merger‖, MDA Journal, Business

Process Trends 4(2), February 2006, http://www.bptrends.com.

[Gorrieri05] Gorrieri, R., Guidi, C., Lucchi, R.: Reasoning About Interaction Patterns in

Choreography, In: M. Bravetti et al. (Eds.): Second International Workshop on

Web Services and Formal Methods, LNCS 3670, Springer Verlag (2005) 3pp. 33–

348.

[Haller06] Haller, A., Oren, E., m3pl: A Work-FLOWS ontology extension to extract

choreography interfaces, In Proceedings of the Workshop on Semantics for

Business Process Management Workshop at ESWC2006,

[Haller06a] Haller, A., Oren, E., Kotinurmi, P. (2006). m3po: An Ontology to Relate

Choreographies to Workflow Models. Services Computing (SCC '06). IEEE

International Conference, pp. 19-27.

[Harmon05] P. Harmon, ―Standardizing Business Process Notation‖, Email Advisor, Business

Process Trends 3(11), November 2005, http://www.bptrends.com.

[Milner99] Milner, R., Communicating and Mobile Systems: the Pi-Calculus, Cambridge

University Press, 1999.

[HP-SFS] Hewlett Packard, Core Services Framework, 2001, available at

http://www.hpl.hp.com/techreports/2001/HPL-2001-138.html.

[ISO/IEC19501] International Organization for Standardization, ISO/IEC 19501:2005, Information

technology -- Open Distributed Processing -- Unified Modeling Language (UML)

Version 1.4.2, April 2005.

[JBI10] Java Community Process, Java Business Integration, Version 1.0, August

2005, available at

http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html.

[jBPM] JBoss, Java Business Process Modelling, available at

http://www.jboss.com/products/jbpm.

[jBPM-jPdl] JBoss, jBPM 2.0 jPdl Reference Manual, available at

http://www.jboss.com/products/jbpm/docs/jpdl.

[JSR207] JSR 207 JCP homepage, http://www.jcp.org/en/jsr/detail?id=207.

[JBI-PS] Patricia Seybold Group, ―Netting It Out‖, available at

http://www.ebizq.net/topics/dev_tools/features/6188.html?&pp=1.

[Keen00] P. Keen and M. McDonald, The eProcess Edge, Osborne/McGraw-Hill, Berkeley,

2000.

http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf

http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf

http://www.ebxml.org/specs/ebREQ.pdf



http://www.hpl.hp.com/techreports/2001/HPL-2001-138.html

http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html

http://www.jboss.com/products/jbpm/docs/jpdl

http://www.jcp.org/en/jsr/detail?id=207

http://www.ebizq.net/topics/dev_tools/features/6188.html?&pp=1


110

[Khan05] R.M. Khan, ―What Standards Really Matter for BPM‖, Business Process Trends

3(5), May 2005, http://www.bptrends.com.

[Peltz03] C. Peltz, ―Web services orchestration and choreography‖, IEEE Computer, 36(10),

pp. 46–52, 2003.

[Pi4] Pi4 Technologies, WS-CDL implementation, available at http://www.pi4tech.com/.

[Pyke05] J. Pyke, ―BPM in Context: Now and in the Future‖, Business Process Trends 3(6),

June 2005, http://www.bptrends.com.

[Ross-Talbot04] Ross-Talbot, S., Orchestration and Choreography: Standards, Tools and Technologies

for Distributed Workflows

[Russell06] N. Russell, W.M.P. van der Aalst, A.H.M. ter Hofstede, and P. Wohed, ―On the

Suitability of UML 2.0 Activity Diagrams for Business Process Modelling‖, BPM

Center Report 06-03, 2006, available at

http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2006/BPM-06-03.pdf.

[SOAP11] W3C, SOAP Version 1.1, May 2000, available at http://www.w3c.org/TR/soap11.

[SOAP12] W3C, SOAP Version 1.2, June 2003, available at http://www.w3c.org/TR/soap12.

[Shapiro05] R. Shapiro, Examining XPDL 2.0 & the Interoperability of BPM Standards,

October 2005, http://www.delphigroup.com/events/05_bpx/presentations/shapiro-

10am.pdf

[UBL] OASIS, Universal Business Language UBL Version 1.0, September 2004,

available at http://docs.oasis-open.org/ubl/cd-UBL-1.0/.

[UBLCLSC] OASIS, Universal Business Language (UBL) Code List Representation, WD-

UBLCLSC-CODELIST-20040420, April 2004, available at http://www.oasis-

open.org/committees/sc_home.php?wg_abbrev=ubl-clsc.

[UML20_DI] OMG, Unified Modeling Language: Diagram Interchange, version 2.0, OMG

Document ptc/05-06-04, Convenience Document, June 2005, available at

http://www.omg.org/cgi-bin/doc?ptc/2005-06-04.

[UML20_I] OMG, Unified Modeling Language (UML) Specification: Infrastructure, version

2.0, OMG Document ptc/04-10-14, Finalized Convenience Document, November

2004, available at http://www.omg.org/cgi-bin/doc?ptc/2004-10-14.

[UML20_OCL] OMG, OCL 2.0 Specification, Version 2.0, OMG Document ptc/05-06-06, June

2005, available at http://www.omg.org/cgi-bin/doc?ptc/2005-06-06.

[UML20_SS] OMG, Unified Modeling Language: Superstructure, version 2.0, OMG Document

formal/05-07-04, August 2005, available at http://www.omg.org/cgi-

bin/doc?formal/05-07-04.

[UML21_SS] OMG, Unified Modeling Language: Superstructure, version 2.1, OMG Document

ptc/06-01-02, January 2006, available at http://www.omg.org/cgi-bin/doc?ptc/06-

01-02.

[UML_Gloss] Sparxsystems, Enterprise Architect 6.1 User Guide, available at

http://sparxsystems.com.au/bin/EAUserGuide.pdf.

[UMM] UN/CEFACT, UN/CEFACT’s Modelling Methodology, Draft,

CEFACT/TMWG/N090R10, November 2001, available at

http://www.unece.org/cefact/umm/umm_index.htm.

[UMM_UG] UN/CEFACT, UN/CEFACT Modelling Methodology (UMM) User Guide,

CEFACT/TMG/N093, September 2003, available at

http://www.unece.org/cefact/umm/umm_userguide.pdf.


http://www.pi4tech.com/


http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2006/BPM-06-03.pdf

http://www.w3c.org/TR/soap11

http://www.w3c.org/TR/soap12

http://www.delphigroup.com/events/05_bpx/presentations/shapiro-10am.pdf

http://www.delphigroup.com/events/05_bpx/presentations/shapiro-10am.pdf

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc

http://www.omg.org/cgi-bin/doc?ptc/2005-06-04



http://www.omg.org/cgi-bin/doc?formal/05-07-04

http://www.omg.org/cgi-bin/doc?formal/05-07-04



http://sparxsystems.com.au/bin/EAUserGuide.pdf

http://www.unece.org/cefact/umm/umm_index.htm

http://www.unece.org/cefact/umm/umm_userguide.pdf


111

[WfMC_Gloss] Workflow Management Coalition, Terminology & Glossary, Document Number

WFMC-TC-1011, Issue 3.0, February 1999, available at

http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.

[WFMC_RM] http://www.wfmc.org/standards/model.htm.

[WfXML11] Workflow Management Coalition, Workflow Standard – Interoperability Wf-XML

Binding, Final Version 1.1, November 2001, available at

http://www.wfmc.org/standards/docs/Wf-XML-11.pdf.

[WfXML20] Workflow Management Coalition, Wf-XML - XML Based Protocol for Run-Time

Integration of Process Engine, Draft Version 2, October 2004, available at

http://www.wfmc.org/standards/docs/WfXML20-200410c.pdf.

[White04a] S.A. White, ―Processing Modeling Notations and Workflow Patterns,‖ Business

Process Trends 2(3), March 2004, http://www.bptrends.com.

[White04b] S.A. White, ―Introduction to BPMN,‖ Business Process Trends 2(7), July 2004,

http://www.bptrends.com.

[White05a] S.A. White, ―Using BPMN to Model a BPEL Process,‖ Business Process Trends

3(3), March 2005, http://www.bptrends.com.

[White05b] S.A. White, ―BPMN Fundamentals,‖ OMF BEIDTF Meeting, Atlanta, 12

September 2005, available at

http://www.bpmn.org/Documents/BPMN%20Fundamentals.pdf.

[Wohed05] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell,

―Pattern-based Analysis of BPMN - an extensive evaluation of the Control-flow,

the Data and the Resource Perspectives‖, BPM Center Report BPM-05-26, 2005,

available at http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2005/BPM-5-

26.pdf.

[WS_Gloss] W3C, Web Services Glossary, W3C Working Group Note, 11 February 2004,

available at http://www.w3.org/TR/ws-gloss/.

[WSCDL] W3C, Web Services Choreography Description Language; Version 1.0, W3C

Candidate Recommendation, November 2005, available at

http://www.w3.org/TR/ws-cdl-10/.

[WS-CDL04] http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/ accessed 10.11.08.

[WSCI] W3C, Web Service Choreography Interface (WSCI) 1.0, W3C Note, August 2002,

available at http://www.w3.org/TR/wsci/.

[WSCI-XSD] W3C, WSCI schema definition, available at http://www.w3.org/2002/07/wsci10/.

[WSCL] W3C, Web Services Conversation Language (WSCL) 1.0, W3C Note, March 2002,

available at http://www.w3.org/TR/wscl10/.

[WSCL-XSD] W3C, XML schema definition of WSCL, available at

http://www.w3.org/2002/02/wscl10, also included in [WSCL].

[WSDL11] W3C, Web Services Description Language (WSDL) 1.1, W3C Note, March 2001,

available at http://www.w3.org/TR/wsdl.

[WSDL20] W3C, Web Services Description, Language (WSDL) Version 2.0 Part1: Core

Language, W3C Candidate Recommendation, January 2006, available at

http://www.w3.org/TR/wsdl20.

[WSDL-Sun] Sun Developer Network, Overview of WSDL, August 2001, available at

http://developers.sun.com/sw/building/tech_articles/overview_wsdl.html.

http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf

http://www.wfmc.org/standards/model.htm

http://www.wfmc.org/standards/docs/WfXML20-200410c.pdf




http://www.bpmn.org/Documents/BPMN%20Fundamentals.pdf



http://www.w3.org/TR/ws-gloss/

http://www.w3.org/TR/ws-cdl-10/

http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/

http://www.w3.org/TR/wsci/

http://www.w3.org/2002/07/wsci10/

http://www.w3.org/TR/wscl10/

http://www.w3.org/2002/02/wscl10

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl20

http://developers.sun.com/sw/building/tech_articles/overview_wsdl.html


112

[WSFL] IBM, Web Services Flow Language (WSFL 1.0), May 2001, available at

http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[WWF] WindowsVista Developer Center, Windows Workflow Foundation WWF,

available at http://msdn.microsoft.com/windowsvista/building/workflow/.

[XLANG] Microsoft, XLANG, Web Services for Business Process Design, 2001, available at

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm.

[XPDL1.0] Workflow Management Coalition, Workflow Process Definition Interface – XML

Process Definition Language (XPDL), Document Number WFMC-TC-1025,

Version 1.0, October 2002, available at http://www.wfmc.org/standards/docs/TC-

1025_10_xpdl_102502.pdf.

[XPDL2.0] Workflow Management Coalition, Workflow Management Coalition Workflow

Standard, Process Definition Interface -- XML Process Definition Language,

Document Number WFMC-TC-1025, Version 2.00, October 2005, available at

http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf

http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

http://msdn.microsoft.com/windowsvista/building/workflow/

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf

http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf

http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf

Raport Etapa I

Documents

Transcript of Raport Etapa I