Inne podejście do oprogramowania pośredniego opiera się na koncepcji ról. To podejście oferuje role jako abstrakcje pierwszego rzędu zachowania jednej strony w protokole interakcji. Obsługuje rozproszone tworzenie instancji ról w sesji interakcji i utrzymuje sesję jako węzły w ruchu sieci mobilnej. Podejście to jest oparte na oprogramowaniu pośredniczącym opartym na widokach, ale kwestia koordynacji w tym przypadku dotyczy utrzymania relacji behawioralnych między komponentami aplikacji, a nie gromadzenia i / lub rozpowszechniania informacji w istniejących podejściach oprogramowania pośredniego. Relacja behawioralna między komponentami aplikacji jest utrzymywana przez wymianę wielu powiązanych komunikatów, to znaczy protokołu. W tym podejściu co prawda rozpowszechnianie i gromadzenie informacji jest konieczne, ale nie jest warunkiem koniecznym. Istniejące podejścia do oprogramowania pośredniczącego (publikacja / subskrypcja i oparta na krotce) anonimowa komunikacja przetargowa (wiadomości są dostarczane na podstawie ich treści i lokalizacji nadawcy lub odbiorcy) i oferują komunikację 1 do n (jeden nadawca może dotrzeć do dowolnej liczby odbiorców, oraz nawzajem). Łącznie te właściwości zapewniają, że składniki aplikacji pozostają luźno powiązane i polegają na oprogramowaniu pośredniczącym, które rozwiązuje problemy niskiego poziomu związane z dostarczaniem wiadomości do zamierzonych odbiorców. Jednak ze względu na te właściwości tylko obecne techniki oprogramowania pośredniego zapewniają niewielkie wsparcie podczas obsługi protokołów. Powód, dla którego te podejścia w niewielkim stopniu obsługują protokoły, jest następujący: Po pierwsze, protokoły opierają się na identyfikacji ich partnerów interakcji, podczas gdy w systemach pub / sub; po prostu zdarzenie jest zgłaszane na podstawie zainteresowania odbiorcy bez ujawniania tożsamości wydawcy. Po drugie, komunikacja nie zawsze jest 1 do n, w przeciwieństwie do komunikacji zapewnianej przez pub / sub, która zawsze wynosi 1 do n. Wreszcie, protokoły są zorganizowane jako wiele powiązanych wiadomości, a obecne produkty pośrednie nie zapewniają wsparcia dla utrzymania tych struktur. W przypadku koordynacji opartej na protokołach role są używane do interakcji. Rola określa zachowanie jednej klasy partnerów interakcji w określonej interakcji. Podczas gdy rola ogólnie opisuje zachowanie partnera interakcji, instancja roli jest jednostką wykonawczą, która reprezentuje określony komponent w określonej sesji interakcji, a typ roli opisuje widok innego obiektu, jaki posiada jeden obiekt. Obiekt, który jest zgodny z danym typem roli, pełni rolę określoną przez ten typ roli i działa zgodnie ze specyfikacją typu. W dowolnym momencie obiekt może pełnić kilka różnych typów ról. W ten sposób różni klienci mogą mieć różne poglądy na temat obiektu. Ponadto różne obiekty mogą zapewniać zachowanie określone przez wspólny typ roli. Dla każdej interakcji istnieje jedna rola odpowiedzialna za czas trwania sesji interakcji. Ta rola jest nazywana rolą inicjatora. Rola inicjatora jest tworzona przez aplikację, gdy potrzebna jest nowa sesja interakcji. Po zakończeniu sesji interakcji lub osiągnięciu celu instancja roli inicjatora może zatrzymać sesję. Inny podwójny rodzaj roli, zwany rolą uczestnika, jest reaktywny. Oprogramowanie pośredniczące tworzy wystąpienie roli uczestnika w węźle, gdy instancja inicjatora wskazuje, że chce rozpocząć sesję z rolą uczestnika w węźle. Wystąpienie roli uczestnika pozostaje utworzone do momentu, gdy inicjator przerwie sesję lub uczestnik wyjdzie ze strefy interakcji. Rola inicjatora może określać, w których węzłach należy utworzyć instancję uczestników, deklarując typ roli uczestnika, identyfikowany przez nazwę, z którą inicjator oczekuje interakcji, oraz ograniczenie dotyczące właściwości węzłów, na których powinna zostać utworzona instancja roli uczestnika zwana strefą. Strefę można postrzegać jako rozproszoną grupę komunikacyjną składającą się z instancji inicjatora i uczestnika. W związku z tym strefa jest konstrukcją deklaratywną na szczycie prymitywu komunikacji grupowej multiemisji. Mechanizm ten zwalnia programistę aplikacji od konieczności zajmowania się jawnym dołączaniem i tworzeniem grup, a także umożliwia programiście deklarowanie grup na podstawie znaczącej semantyki na poziomie aplikacji. Podczas trwania sesji oprogramowanie pośredniczące monitoruje sieć i utrzymuje odpowiednie instancje uczestników, gdy zmieniają się właściwości węzłów. Jeśli węzeł wejdzie do strefy (tj. Jego właściwości zmienią się w taki sposób, że będzie zgodny z ograniczeniami strefy), w węźle tworzona jest instancja uczestnika (jeśli węzeł wdraża rolę uczestnika). Ponadto, jeśli węzeł opuści strefę, instancja uczestnika jest powiadamiana, że znajduje się poza strefą, a następnie usuwana. W obu sytuacjach zostanie również powiadomiona instancja inicjatora. Jeśli oprogramowanie pośredniczące wykryje, że wystąpienie uczestnika nie może komunikować się ze swoim wystąpieniem inicjatora, jest usuwane i powiadamia, że znajduje się poza strefą. Operacje te można z powodzeniem wykonywać za pomocą tradycyjnych protokołów komunikacji grupowej.