SOA si basa essenzialmente su 4 principi fondamentali (Policy-Based Behavior Negotiation, Explicitness of Boundaries, Autonomy e Contract Exchange). All'interno di questi punti si cela il problema dell'identificazione delle entità fra i servizi 8senza ovviamente richiedere la duplicazione delle informazioni).

Vediamo un esempio concreto. Immaginiamo di avere un servizio dei contatti ed un al'tro di processazione ordini. Si immagina pertanto che il servizio degli ordini abbia in qualche modo un riferimento alle informazioni dei clienti (contatti). Ma quale informazione ?

Basterebbe avere un identificativo univoco, che permetta al servizio degli ordini di cercare puntualmente un determinato cliente. Se andiamo a guardare come censiamo i clienti nei nostri sistemi possiamo trovare due concetti di identificativo. Uno tecnico (un GUID piuttosto che un int) oppure uno funzionale (es codice fiscale).

In nessuno dei due casi sopracitati posso però garantire la vera univocità del contatto. Infatti la soluzione tecnica non mi definisce alcun contesto applicativo, mentre la soluzione due funziona solamente in Italia.

sarebbe quindi interessante introdurre oltre all'identificativo, anche il contesto. Ecco allora che un URI (Unifor Resource Identifier) può fare al caso nostro. vediamo un paio di esempi:

urn:mycompany:crm:contact:id:3456253426

urn:mycompany:contatti:codicefiscale:GPDNPP.....

http://www.mycompany.it/contatti/codicefiscale/GPDNPP.....

e così via. Chi utilizzerà i nostri servizi potrà anche pensare di ricercare un contatto con forme differenti, in base ad algoritmi differenti. Dal canto nostro (sviluppatori di servizi) potremmo adottare il pattern chain of responsability per definire quale algoritmo applicare in base alla richiesta.