Być może najprostszy przykład łączenia się między warstwami systemu informatycznego ma miejsce, gdy rozważamy operacje w ramach jednej firmy, która wprowadziła usługi sieciowe oprócz istniejących mechanizmów transakcyjnych. Widzieliśmy jeden przykład tego w przypadku serwerów detalicznych, w przypadku ODCB, który umożliwia serwerom sieciowym komunikowanie się z różnymi bazami danych różnych producentów. Część oprogramowania serwerowego prawie nieuchronnie zostanie przekazana pakietom programów, które wykonują takie zadania. Istnieje wiele proponowanych rozwiązań oprogramowania pośredniczącego, z których środowiska CORBA i korporacyjne środowiska JAVA są prawdopodobnie najbardziej ambitne. Omówimy je w poniższych sekcjach, ale ogólne zasady są takie same, niezależnie od zastosowanej metody: połączenie wzajemne można osiągnąć poprzez konstruowanie specjalistycznych łączników pomiędzy procesami. Konstruując lub nawet używając tych programów łączących należy zwrócić uwagę nie tylko na ich prawidłowe działanie, ale także na zapewnienie satysfakcjonującej wydajności i bezpieczeństwa. Można to zrobić bezpośrednio, uruchamiając zdalne wywołania funkcji lub procedur (RPC). Są to wiadomości przesyłane z jednego komputera do drugiego, które mogą wywoływać stosunkowo ograniczone działania na drugim, bezpośrednio przez zaporę.
Takie podejście, które jest rdzeniem architektur, takich jak Distributed Computing Environment (DCE) , umożliwia aplikacjom klienckim uruchamianie funkcji, zwykle napisanych w C, na zdalnym komputerze. Proste rozwiązania RPC, które obejmują wywoływanie ad hoc procesów działających na innych serwerach, można zaprojektować bez przyjmowania formalnego projektowania zorientowanego na komponenty lub obiekt. Są wygodne do prostszych zadań lub tam, gdzie mamy dobrą kontrolę nad środowiskiem zarówno na serwerze WWW, jak i na serwerze biznesowym. Jeśli jednak system IT jest skomplikowany technicznie lub firma istnieje w środowisku, w którym wiele tymczasowych sojuszy jest tworzonych i niszczonych w szybki i złożony sposób, wymagane jest bardziej ogólne i ustrukturyzowane podejście do przetwarzania rozproszonego. Podejście RPC do problemów tego rodzaju może być skomplikowane, a zatem trudne do utrzymania i niekoniecznie bardzo bezpieczne. Wraz ze wzrostem wykorzystania programowania obiektowego, preferowanym sposobem działania jest teraz wprowadzenie łącznika obiektowego między dwoma systemami
Komunikacja między serwerem WWW a procesem łączenia może wykorzystywać np. otwarty standard DCOM (rozsądnie) opracowany przez Microsoft. Firmy takie jak SAP (dostawca jednego z najpopularniejszych pakietów oprogramowania do planowania zasobów) dostarczają zestawy narzędzi, które umożliwiają projektantom tworzenie niezbędnych obiektów. Na przykład często wymagamy zdefiniowania obiektu „zamówienie”, który łączy się z procesami sprzedaży i dystrybucji w SAP, obiekt „klient” z procesów finansowo-księgowych i tak dalej. Zdalne wywołania funkcji mogą wywoływać te obiekty, ale działania, które następują po nich, są całkowicie definiowane przez charakterystykę obiektów, które są opracowywane i chronione za zaporą, a nie przez RFC, które są ujawniane na serwerze sieci Web. Takie podejście do korzystania z dobrze określonych interfejsów (niemal zawsze zorientowanych obiektowo) jest znane jako architektura komponentowa. Nawiasem mówiąc, chociaż twierdzi się, że dobrą wydajność można osiągnąć za pomocą obiektów składowych, czasami zaleca się również, aby lepszą praktyką było ograniczenie liczby dostępów z serwera WWW do serwera biznesowego tak bardzo, jak to możliwe. Na przykład może być lepiej utworzyć kopię katalogu produktów lokalnie obok serwera WWW, do użytku przez przeglądających klientów i dopiero po podjęciu przez nich decyzji o produkcie przekażą swoje zapytania do serwera biznesowego, aby sprawdzić dostępność itp. Miałoby to sens, zarówno pod względem wydajności, jak i bezpieczeństwa. Przyjrzymy się teraz niektórym architekturom komponentów.