Nu vreau sa scriu un post foarte tehnic, ci doar sa incerc sa explic in cuvinte cat mai simple si cat mai putine ce reprezinta aceasta solutie, cum poate ajuta o companie etc. Scuzati romgleza, dar asa ma manifest eu cand vorbesc despre IT

In primul rand, ce este SOA? Ca sa va scutesc de simpla cautare pe Gogoloi (asa il alint in momentele mele bune), va spun eu: Service-Oriented Architecture. Si acum… sa purcedem la lucruri mai serioase si mai complexe…

SOA este o infrastructura software care creeaza un layer intre resursele IT (server, sisteme de operare si mai ales aplicatii) si procesele de business. Cum? Pai… aplicatiile software sunt descompuse in componente mai mici care sunt recombinate si folosite ca servicii – componentele acestor servicii pot fi apoi recombinate pentru a raspunde la alte nevoi de business.

SOA este de fapt un stil de arhitectura, nu o arhitectura in sine. Intr-o arhitectura orientata pe servicii, datele sunt separate de procesarea lor, in contrast cu o arhitectura orientata pe obiecte, unde datele nu pot fi separate de procesarea lor. Un exemplu banal de orientare pe servicii este un CD player. Acelasi CD poate fi ascultat la un CD player portabil sau la CD playerul inclus in PC. In orientarea pe obiecte, fiecare CD ar trebui sa vina cu propriul CD player si nu ar putea fi separate.

De ce SOA? In primul rand, o companie are nevoie de suport IT pentru fiecare proces de business. Exista o cerere din ce in ce mai mare pentru tehnologii care sa fie destul de flexibile incat sa permita sharing-ul de informatii si resurse – SOA ofera aceasta flexibilitate prin faptul ca descompune orice aplicatie in blocuri mai mici care pot fi folosite independent de oamenii din interiorul sau din afara organizatiei.

Ce ar determina o companie sa aleaga SOA? Putem avea in vedere doua categorii:

1. Business drivers: conformitate cu legislatia (mai multa transparenta, mai multa flexibilitate – poate sa se adapteze usor la noi legislatii), ROI mare;

2. Technical drivers: service management, service lifecycle management (departamentul de IT isi da seama mai usor cand trebuie sa actualizeze serviciile sau sa le retraga).

Cat despre cerintele SOA, acestea sunt cat se poate de evidente:

a. Interoperabilitate – sa existe un protocol prin care aplicatiile sa comunice intre ele. Poate fi realizata prin intermediul serviciilor web;

b. Interfata sa fie clar definita;

c. Serviciile sa poata fi gasite si accesate usor.

Ce bine ar fi daca lucrurile ar fi atat de simple… dar de cele mai multe ori SOA aduce si unele dificultati: neintelegerea cerintelor de performanta specifice, lipsa unei fundatii bazate pe XML, lipsa unui plan de tranzitie la SOA, lipsa standardizarii, neintelegerea diferentelor dintre SOA si arhitecturile traditionale.

Sa revenim la lucruri realiste: pentru a folosi aplicatiile SOA e nevoie sa cumperi suficiente resurse hardware incat sa faci fata perioadelor foarte aglomerate. In afara acestor perioade, majoritatea resurselor raman nefolosite. Astfel, implementand SOA poti ajunge sa nu mai beneficiezi de economiile pe care le-ai putea obtine prin consolidare. Prin utility computing, de exemplu, poti folosi exact atatea resurse cate iti trebuie (mai multe in perioadele critice si mai putine in rest). Astfel, dupa ce implementeaza SOA, multe firme investesc in utility computing pentru a reduce costurile.

De ce este SOA atat de importanta? Aceasta solutie ne ofera posibilitatea de a alinia serviciile de IT la obiectivele strategice ale companiei.