Zrób Sobie Firmę

Zauważ, że protokół TCP/IP ma na celu zapewnienie niezawodnej transmisji danych od nadawcy do odbiorcy. W przypadku wykrycia błędów protokół będzie wymagał ponownej transmisji danych, dopóki nie zostaną poprawnie odebrane. Może to skutkować wieloma powtórzeniami, zasadniczo bez względu na czas potrzebny. W konsekwencji specyfikacja jakości usług dla TCP/IP dotyczy jakości danych, ale nie dotyczy czasu potrzebnego na ich otrzymanie. Różni się to bardzo od specyfikacji telefonii, która ma na celu zapewnienie minimalnego opóźnienia od końca do końca. Usługi głosowe i strumieniowe przesyłanie wideo wymagają tego warunku, w przeciwieństwie do transmisji danych do przetwarzania nie w czasie rzeczywistym. Obecnie ten brak wymogu czasu rzeczywistego jest akceptowaną częścią praktycznie całego ruchu w publicznym Internecie. Ponieważ nie ma centralnej kontroli nad wszystkimi zaangażowanymi trasami i routerami, czas tranzytu jest całkowicie nieokreślony i nie ma łatwego sposobu na obejście problemu, pomimo wielu pomysłowych podejść. Z pewnością prawdą jest, że obecną sytuację można w pewnym stopniu poprawić: na przykład można próbować nakłonić routery zaangażowane w sesję, aby zgodziły się na próbę utrzymania otwartej ścieżki od końca do końca. W trakcie opracowywania są również protokoły, które przypisują różne etykiety „jakości usługi” do różnych rodzajów ruchu (na przykład głos, ruchome wideo o wysokim priorytecie). Ale to nie samo IP jest problemem; prawdziwym problemem jest zapewnienie pełnej odpowiedzialności handlowej za usługę na pluralistycznym rynku. To, co dzieje się z prywatnymi Internetami (intranetami) jest dość znaczące: tradycyjni dostawcy usług sieciowych (w tym operatorzy telekomunikacyjni) sprzedają sieci oparte na IP, ale z ostrożnym zarządzaniem ruchem, aby zminimalizować wąskie gardła. Często nie używają protokołu TCP do kontrolowania połączenia. Zamiast tego używają bardziej tradycyjnych platform przełączanych niż routowanych, na przykład zbudowanych w technologii Asynchronous Transfer Mode (ATM). Wszystko to jest bardzo aktywnym obszarem badań i rozwoju

Nad protokołem IP w warstwowym modelu architektonicznym znajduje się Internet Transmission Control Protocol (TCP), który jest przeznaczony do obsługi tego rodzaju problemów. Oczywiście komputery na obu końcach tej trasy nie chcą znać żadnych szczegółów dotyczących sposobu, w jaki pakiety przechodzą przez sieć. Jedyne, czego chcą, to zapewnienie między nimi niezawodnego transportu. W tym celu oba komputery nawiązują „połączenie”

Zakłada się, że komputer, który otrzyma dane, nasłuchuje w sieci żądań ustanowienia połączenia. Jeden jest wysyłany z drugiego komputera i potwierdza to. Oba komputery konfigurują teraz bufory transmisji i odbioru, liczniki/timery i sprawdzanie błędów. Następnie jeden komputer przesyła pewne dane, miejmy nadzieję, że odbiera je drugi host i ostatecznie przesyła „wiadomość z potwierdzeniem”. Pod warunkiem, że nastąpi to w określonym czasie, nadawca zakłada, że ​​wszystko jest w porządku i w ten sam sposób prześle dalsze dane. Mówi się, że cała ta aktywność ma miejsce podczas „połączenia”. Podczas gdy połączenie jest na miejscu, dwa hosty nieustannie sprawdzają poprawność danych i wysyłają potwierdzenia i retransmisje, jeśli wystąpią problemy. Ciekawe rzeczy mogą się nie udać. Na przykład pakiety danych, które zostały utracone w buforach pamięci używanych przez podsieć, mogą nagle wyskakiwać po tym, jak nadawca zrezygnował z nich i ponownie przesłał dane, ale wszystko to jest załatwiane przez uzgadnianie TCP osiągnięte poprzez potwierdzenie protokół. TCP również dynamicznie kontroluje szybkość, z jaką dane mogą być wypompowywane z bufora hosta wysyłającego. Może ocenić wydajność trasy, monitorując postęp uzgadniania, a następnie dostosować przepływ danych, aby przesunąć go z maksymalną możliwą prędkością bez przeciążenia.

.

W świadomości wielu eCommerce i Internet są nierozłączne. Chociaż jest to zbyt prosty pogląd, nie ma wątpliwości, że technologie, aplikacje i standardy związane z Internetem dominują we wdrażaniu aplikacji e-biznesowych i prawie we wszystkich przypadkach przynajmniej jedna część łańcucha procesów będzie prowadzona przez sieci działające na protokołach internetowych. Ale najpierw powinniśmy uznać, że nie ma czegoś takiego jak Internet. Prawdziwym terminem jest „internet”, działalność, a nie jednostka, aktywność łączenia ze sobą kilku sieci i części zestawu, w celu zapewnienia pewnych możliwości transmisji typu end-to-end. Pragnienie, aby to zrobić, pierwotnie pojawiło się w wyniku zbieżności dwóch wyraźnie różnych nurtów myśli dotyczących sieci komputerowych. Jedną z nich była inicjatywa Departamentu Obrony USA, której celem było opracowanie rozwiązań, które zapewniłyby przetrwanie łączności w czasie ataku nuklearnego. Drugim był rynek komercyjny, który szukał opłacalnych rozwiązań dla szerokopasmowego połączenia między sieciami lokalnymi o bardzo niejednorodnym charakterze. Internet zawdzięcza swoje pozytywne i negatywne cechy tym bliźniaczym pragnieniom. W odniesieniu do kwestii przeżywalności: wojsko USA obawiało się, że konwencjonalne sieci telefoniczne, które obejmowały połączenia hierarchiczne za pośrednictwem scentralizowanych central telefonicznych, są podatne na ataki. Zaproponowano zatem, aby przesyłane dane były dzielone na małe pakiety (lub datagramy), każdy pakiet był oznaczony swoim numerem seryjnym, źródłem i miejscem docelowym, a pakiety były niezależnie odpalane w sieci. Tak więc, gdyby jedna część sieci miała zostać zniszczona, można by określić, które pakiety zostały utracone i szybko znaleźć nową trasę, którą można by je ponownie wysłać. Protokół służący do osiągnięcia tego celu, protokół internetowy (IP), zajmuje się dostarczaniem pakietów „z najlepszymi staraniami”. W zależności od zaistniałych warunków może nie dostarczyć, może dostarczyć więcej niż jedną kopię pakietu, może dostarczać pakiety w dowolnej kolejności i mogą one zawierać błędy. Aby spełnić to wymaganie do przetrwania w przedstawionych powyżej realiach komercyjnych, IP dzieli dane na datagramy o zmiennej długości do 64 KB (chociaż w praktyce mają one zwykle około 1000-2000 bajtów). Te pakiety danych są często dalej dzielone przez interweniujące sieci na mniejsze „fragmenty”, aby dopasować je do lokalnych ograniczeń dotyczących maksymalnego rozmiaru. Te fragmenty nie są ponownie łączone, dopóki nie dotrą do miejsca przeznaczenia, a jednym ze złożonych zadań protokołów internetowych jest dodanie do tych fragmentów dodatkowych informacji o adresowaniu i porządkowaniu, aby można je było pomyślnie dostarczyć i ponownie uporządkować. Każdy host („komputer”) i każdy router w Internecie ma unikalny adres, zwany jego adresem IP. Jest to 32-bitowy adres, który jest dołączany do datagramów w celu wskazania źródła i miejsca docelowego pakietu

Adres składa się z dwóch części: jedna część identyfikuje sieć, do której należy host, a druga część to unikalny numer w tej sieci. Sieci różnią się wielkością i złożonością, niektóre są „prywatne”, np. sieć kampusów uniwersyteckich, inne są zapewniane przez władze regionalne lub krajowe. Wszystkie sieci uzyskują swój adres IP od scentralizowanego organu, Network Information Centre. Sieci i adresy sieciowe można również podzielić na „podsieci”, co pomaga w administrowaniu systemem i umożliwia rozszerzenie zakresu numerów, a nie w taki sposób, że numery telefonów zawierają kod lokalny, regionalny i krajowy. Kody są zwykle wyrażane w oktetach, aby były łatwiejsze do odczytania. Routery przechowują tablice zawierające informacje o niektórych (ale nie wszystkich) innych sieciach w Internecie, a także o niektórych adresach do podsieci i hostów we własnej sieci. Istnieje kilka sposobów tworzenia tych tabel. W przypadku małych sieci możliwe jest ręczne ustawienie tych informacji. W przypadku większych sieci istnieje wiele zautomatyzowanych metod, dzięki którym routery uzyskują te informacje stopniowo, obserwując przechodzące przez nie dane. Mogą również okresowo wysyłać prośby do swoich sąsiadów, prosząc ich o zwrócenie informacji, z kim są połączeni. Załóżmy teraz, że pakiet dociera do routera 

Router porównuje adres docelowy pakietu z tabelą i może być w stanie wysłać go bezpośrednio do lokalnej sieci LAN, w której znajduje się host docelowy. Jeśli pakiet jest przeznaczony dla sieci zdalnej, router wyśle ​​go do następnego routera zalecanego w tabeli. Zauważ, że router niekoniecznie wysyła pakiet najbardziej bezpośrednią trasą; może po prostu wysłać go do domyślnego routera, który ma większy zestaw tabel. W pokazanym przykładzie adres docelowy pakietu 7.7.7.1 nie będzie pasował do następnej ścieżki oznaczonej jako 7.7.7.99, ale pasuje do ścieżki oznaczonej jako 7.7.7.0, czyli ścieżki 2. Jeśli ścieżka 2 nie istnieje i nie ma kompletne dopasowanie, wtedy zostałaby wybrana domyślna ścieżka 0.0.0.0. Ze względu na wymóg odporności na atak zdecydowano, że w każdym węźle w sieci (np. gdy router łączy poszczególne podsieci różnych organizacji), trasowanie w celu przekazania każdego pakietu dalej do następnego węzła będzie obliczane lokalnie , na podstawie wiedzy o tym, co działo się w pobliżu węzła (na przykład, która trasa z niego była najmniej zajęta i nie została zniszczona). Pakiety w końcu dotarłyby do zamierzonego miejsca przeznaczenia, pod warunkiem, że w ogóle istniała trasa, chociaż mogły dotrzeć w dowolnej kolejności i doświadczyć znacznego opóźnienia. Ważne jest, aby zdać sobie sprawę, że nie było intencją utrzymywania rejestru „najlepszego sposobu” od końca do końca w całej sieci. Pomysł na jakikolwiek półtrwały najlepszy sposób był sprzeczny z tym, co się stanie, gdy bomby zaczną spadać. Żadna trasa nie byłaby gwarantowana, aby przetrwać, a pakiety musiałyby znaleźć drogę przez sieć, której węzły ciągle się zapadały i były odbudowywane. Oprócz wojskowego imperatywu stworzenia sieci zdolnych do przetrwania, istniało szereg realiów komercyjnych: sieci komputerowe rozwijały się w duchu lokalnego świadczenia usług i na szybko zmieniającym się, konkurencyjnym, niestandardowym rynku. W konsekwencji nieuniknione było występowanie różnych protokołów komunikacyjnych i mało prób zapewnienia gwarantowanej jakości usług poza domeną lokalną. Również struktura danych nie jest zgodna z identycznymi układami. Istnieje wiele sposobów, w jakie sieci mogą się różnić, w tym sposób ich adresowania, maksymalny rozmiar pakietu, sposób obsługi błędów, sposób radzenia sobie z przeciążeniem węzłów i tak dalej. To, że możliwe jest osiągnięcie transmisji typu end-to-end w tego rodzaju złożoności (i spadających bomb!), jest dużym osiągnięciem, ale Internet to robi, chociaż nie bez nabywania mniej pożądanych właściwości. Pakiety mogą na przykład zniknąć w ślepym zaułku routerów, na stałe lub z dużym opóźnieniem. Pakiety mogą być dzielone na fragmenty przez heterogeniczne systemy o różnych długościach buforów przetwarzania; W niektórych przypadkach mogą być nawet generowane zduplikowane pakiety. W przypadku wielu wymagań nie jest to zadowalające, wymagamy jedynie protokołu, aby poinformować nas, na czym stoimy i kiedy poprosić o powtórzenie informacji.

Działa to dobrze na krótkich dystansach i sieciach, które nie są zbyt obciążone – zauważ, że nawet w obrębie jednej sieci LAN nadal istnieje możliwość przedłużonego opóźnienia z powodu konieczności powtarzania serii danych po wystąpieniu kolizji. Ale sytuacja znacznie się pogarsza, gdy sieci są ze sobą połączone. Maksymalna szybkość transmisji danych, jaką może obsłużyć kabel, jest funkcją jego długości. Im dłuższy kabel, tym niższa stawka. W związku z tym nie możemy łatwo przekazywać szybkich serii danych przez łącza na duże odległości. Warunek ten jest pogarszany przez dalszy warunek, o którym wspomnieliśmy wcześniej, w naszej dyskusji o sieciach telekomunikacyjnych: maksymalna szybkość transmisji danych dozwolona w kablach telekomunikacyjnych jest ściśle kontrolowana i wyceniana. Tak więc, jeśli chcesz wprowadzić do sieci telekomunikacyjnej nawet bardzo okazjonalną porcję szybkich danych, musisz zapłacić za szybki obwód, niezależnie od tego, czy używasz go cały czas, czy nie. To może być bardzo drogie. Alternatywą jest ścisła kontrola szybkości, z jaką dane są wstrzykiwane do szerokiego obszaru sieć z sieci LAN. Odbywa się to poprzez zapewnienie pewnego rodzaju bramy między obszarami lokalnymi i rozległymi. Sieci komputerowe muszą ograniczać się do rozległego obszaru

W przypadku łączy klient-serwer detaliczny widzieliśmy, że przynajmniej klienci krajowi zazwyczaj musieli nawiązywać połączenia za pośrednictwem modemów i sieci telefonicznej. Charakterystyki tej sieci przez wiele lat były optymalizowane pod kątem obsługi głosu i niekoniecznie są tak dobre dla danych. Nawiązywane jest „połączenie telefoniczne” od końca do końca przez wszystkie centrale pośrednie na czas trwania rozmowy, praktycznie bez opóźnień od końca do końca, a ścieżka jest gwarantowana, ponieważ zaangażowane firmy telekomunikacyjne centralnie zaplanowały swoje trasy i wcześniej wspólnie uzgodnili łączność. Jedną z konsekwencji takiego podejścia i bardzo mocną stroną telekomunikacyjnych usług głosowych jest jakość usług. Połączenia, które są podłączone są mniej więcej gwarantowane, że będą działać bez wad lub pogorszenia. Jeśli sieć jest przeciążona, nowe połączenia są blokowane przed wejściem do sieci, zamiast kradzieży zasobów z istniejących połączeń. Co więcej, w naturze połączeń wybieranych kryje się koncepcja sesji: zaczyna się ona, gdy osoba wywoływana podnosi słuchawkę i kończy się, gdy słuchawka jest odkładana. Jednak podstawowy kanał głosowy charakteryzuje się raczej niską szybkością transmisji danych, zazwyczaj rzędu 64 kbit/s, a za jeden z nich pobierana jest opłata czasowa, niezależnie od tego, czy jakiekolwiek informacje są przesyłane, czy nie. Obwody również miały tendencję do bycia jednym, a nie jeden-do-wielu lub wiele-do-wielu. Przez wiele lat połączenia komputer-komputer wykorzystywały zmodyfikowane kanały głosowe lub kupowano prywatne obwody, które były przewodowe w całym kraju, aby bezpośrednio łączyć ich witryny. Wszystkie decyzje dotyczące trasowania ruchu podejmowała firma telekomunikacyjna, a sprzęt klientów był pod tym względem postrzegany jako „głupi”. Pojawienie się sieci lokalnych (LAN) o wielkości kampusu w latach 70. dało początek pierwszej architekturze, którą można określić jako „komputerową” (w przeciwieństwie do „opartej na telefonii”). Tym, co bardzo różni architekturę LAN od telefonii, są stosunkowo krótkie odległości: kilometr długości kabla jest duży w kategoriach LAN. Teraz zdolność kabla do przenoszenia szybkich sygnałów danych jest funkcją jego podstawowej konstrukcji i długości. Ponieważ sieci LAN są krótkie, mogą obsługiwać dziesiątki megabitów danych na sekundę na stosunkowo prostym (a tym samym tanim) kablu miedzianym. Pozwala to na bardzo prostą i „głupią” sieć

Terminale A, B i C są podłączone do tego samego kabla. Kiedy tylko chcą się komunikować, po prostu wysyłają pakiety danych z nazwą terminala nadawczego, nazwą terminala odbiorczego, niektórymi danymi kontrolnymi i samymi danymi. Każdy terminal „słyszy” każdy pakiet, a sygnały są zaprojektowane tak, aby każde uszkodzenie danych spowodowane przez dwa terminale jednocześnie transmitujące mogło zostać rozpoznane, a transmisja powtórzona po krótkim, losowym opóźnieniu. Zauważ, że to terminal, a nie sieć, posiada inteligencję. Centralnej centrali telefonicznej nie ma nic, a także nie ma potrzeby ograniczania szybkości transmisji danych (w ramach podstawowej przepustowości kabla). (Powinniśmy wspomnieć, że istnieją inne, bardziej ustrukturyzowane i mniej „statystycznebiznesowe” protokoły LAN, które nie opierają się na rzadkich kolizjach losowych – Token ring IBM jest godnym uwagi przykładem – ale powyższa metoda współdzielenia kabla tak, jakby był to otwarty “eter” radiowy, jest dominująca, pod odpowiednią nazwą Ethernet.) Jedną z konsekwencji tego podejścia jest brak rozróżnienia między transmisją informacji sterujących (routingu, wykonanego połączenia itp.) a danymi wiadomości, w przeciwieństwie do przypadku telefonii, w którym informacje sterujące mogą nawet obrać inną ścieżkę w sieci niż „ładunek” danych. W przeciwieństwie do mowy telefonicznej i danych faksowych, które są generowane w dość stałym tempie, dane komputerowe są zazwyczaj bardzo „przerywane” .

To z powodu tej zmienności możemy umieścić kilka urządzeń w tej samej sieci LAN bez zbytniego kolidowania ich danych. Jak powiedzieliśmy, krótki zasięg oznacza, że ​​kabel może obsługiwać bardzo dużą szybkość transmisji danych, a im wyższa szybkość transmisji, tym mniejsze ryzyko kolizji.

Rzadko zdarza się, nawet w jednym, zunifikowanym biznesie, aby wszystkie procesy przyjmowania zamówień, katalogowania, zarządzania łańcuchem dostaw itp. odbywały się na jednym sprzęcie, w jednym pomieszczeniu. W naszym modelu wielopoziomowym niemal niejawne jest założenie, że w grę wchodzi pewna liczba komputerów. Muszą one być połączone (w sieci) razem. Jeśli wszystkie znajdują się w tym samym pomieszczeniu, być może nie musimy zbytnio zastanawiać się nad optymalizacją szybkości i kosztów. Ale jeśli są rozdzieleni na terenie kampusu, kraju lub na całym świecie, staje się to poważnym problemem. Zwykle tak będzie. Wiele firm istnieje w wielu lokalizacjach, a zatem tworzenie prawdziwie zintegrowanych, rozbudowanych przedsiębiorstw oznacza, że ​​usługi transmisji danych i głosu muszą działać na duże odległości. Prawie każda firma korzystająca z usług ISP będzie musiała zainstalować połączenie między usługodawcą internetowym a własnymi komputerami. Sposób, w jaki te połączenia sieciowe można osiągnąć skutecznie i niskim kosztem, był i nadal jest obszarem szybkiego rozwoju. Najłatwiej to zrozumieć, śledząc rozwój historyczny.

Rysunek, z którym po raz pierwszy spotkaliśmy się wcześniej, przypomina nam podstawowy widok eCommerce. Jest to model skoncentrowany na transakcjach klientów detalicznych.

 Korzysta z internetowego połączenia obsługiwane przez serwer WWW. Dostarcza to klientowi użytkownika uwodzicielskich i/lub informacyjnych usług opartych na stronach internetowych, prawie na pewno w HTML lub XML, być może zawierających małe programy (np. w Javie), które działają na kliencie. Strony mogą mieć całkowicie ustalony format (statyczny), ale jest bardziej prawdopodobne, że będą tworzone dynamicznie i wypełnione dostosowanymi danymi wydobytymi z katalogu. Za pomocą innych dynamicznych skryptów żądania klientów i dane osobowe mogą być również przekazywane do bazy danych w celu przyjęcia zamówienia. Obie czynności wspierane są przez pakiet oprogramowania zwany usługami aplikacyjnymi. Ta bardzo prosta trójwarstwowa architektura, która rozdziela prezentację, aplikację (biznesową) i bazę danych, jest przydatna do pozycjonowania tego, co następuje, co opiera się na znacznym rozszerzeniu usług aplikacji i interakcji z bazami danych na architekturę wielowarstwową. Zacznijmy od otwarcia usług na model warstwowy (rysunek 1.4). Ten schemat architektoniczny różni się raczej od poprzedniego rysunku 1.3, ponieważ na tym poziomie nie oddziela sprzedaży front-office (HTTP do klienta) od zarządzania danymi back office (np. przez ODBC do katalogu). Zamiast tego traktuje je jednakowo, rozkładając ich funkcjonalność w pionie na wiele warstw. W kolejnych częściach przyjrzymy się kolejno tym warstwom. Zauważ również, że pokazujemy ciąg zarządzania systemem biegnący pionowo przez Rysunek

Jest to być może kontrowersyjne: modele architektoniczne, takie jak IBM Application Framework for eBusiness, mają tendencję do umieszczania zarządzania systemem w dolnej warstwie swoich modeli. Ponieważ jednym bardzo dużym i ważnym aspektem zarządzania systemem jest bezpieczeństwo i mając na uwadze to, co mówimy w części 3, Bezpieczeństwo, o zagrożeniach bezpieczeństwa pojawiających się na wszystkich poziomach, wolimy wyraźnie zaznaczyć, że te kwestie muszą być traktowane na wszystkich poziomach

W większości dyskusji, które nastąpią, skoncentrujemy się na aspektach integracji e-biznesu po stronie serwera. Jest to być może logiczne, ponieważ większość mocy obliczeniowej jest wymagana do obsługi operacji wewnątrz firmy. Ale jest jeszcze jeden powód, który może nie jest tak oczywisty. Rzeczywiście, wydaje się, że klient klienta rośnie w siłę i staje się bardziej zintegrowany z procesami wewnętrznymi. W ciągu ostatnich kilku lat przetwarzanie internetowe przeszło od prostego ściągania statycznych stron internetowych do architektury, w której przeglądarki obsługujące kod mobilny na komputerze klienta pobierają aplety Java lub kod Active-X z serwera. Te fragmenty kodu wykonywalnego mogą następnie wchodzić w interakcje z serwerem sieci Web, który teraz zachowuje się jak brama do e-biznesu, wywołując procesy w maszynach aplikacji biznesowych (trzecia warstwa). Aplety mogą zatem wymagać różnych trybów dostępu do różnych platform aplikacji biznesowych. Na tym polega problem. Systemy, które muszą sobie radzić z takim podejściem, są skomplikowane w projektowaniu, a tym samym potencjalnie niebezpieczne dla bezpieczeństwa działania. Doprowadziło to wielu komentatorów do postulowania, że ​​może nastąpić powrót do uproszczonych interakcji klient/serwer sieciowy oraz interakcji serwera sieci Web z warstwami aplikacji za pośrednictwem brokera żądań obiektów (patrz dalej), który może wywoływać dłuższe, bardziej złożone i pewniejsze aplikacje. Zasadniczo klient jest osłabiony lub osłabiony, a serwer sieciowy dopasowany, ale połączony z innymi serwerami za pomocą dobrze przygotowanego interfejsu. To kładzie jeszcze większy nacisk na to, co dzieje się po drugiej stronie serwera WWW, w ramach e-biznesu.

Pierwotnie obliczenia biznesowe były wykonywane jako zadanie punktowe, bez rzeczywistej koncepcji działania w sieci. Istnieją dwa bardzo proste podejścia architektoniczne do tego: komputer mainframe i głupi terminal lub izolowana osobista stacja robocza. Chociaż te pierwsze mogły być preferowanym sposobem pracy dla dużych firm, a drugie wyborem dla małych firm, pod wieloma względami są one równoważne. Ich wspólną cechą jest to, że wszystkie procesy biznesowe są uruchamiane na jednej platformie lub jednej warstwie

Obecnie wiele systemów ewoluowało w kierunku podejścia klient-serwer (dwuwarstwowego),  w którym większość procesów biznesowych działa na serwerze, a klient zajmuje się głównie prezentacją i przechowuje tylko ograniczoną ilość danych specyficznych dla użytkownika. Następnym etapem jest architektura trójwarstwowa, w której większość procesu (w praktyce prosta procedura zakupów w sieci Web) działa na jednym serwerze i pobiera dane z serwera bazy danych, trzeciego poziomu. Potem sprawy stają się bardziej skomplikowane, a dodatkowe aplikacje działają na różnych warstwach. W artykułach na ten temat często nie wyjaśniono, że poziomy są logiczne, a nie fizyczne. Nie ma jednej warstwy na serwer/komputer ani jednego komputera/serwera na warstwę. Na jednej maszynie można uruchomić kilka warstw biznesowych, a warstwy mogą być rozmieszczone na kilku komputerach. Jest to znane i uznawane przez architektów systemów jako powód zamieszania. Jednak terminy te są szeroko stosowane i należy być przynajmniej świadomym ich istnienia.

Powinniśmy również zauważyć, że architektury wielopoziomowe powstały niekoniecznie dlatego, że temu wyborowi architektury poświęcono wiele uwagi; w rzeczywistości są one bardziej wynikiem prób jak najlepszego wykorzystania tego, co tam było. Jednym z powodów, dla których projektowanie e-biznesu jest tak złożone, jest to, że potrzebujemy kilku komputerów do wspólnej pracy w wielu geograficznie odseparowanych lokalizacjach, pomimo w wielu przypadkach innego sprzętu i oprogramowania. Mogą pochodzić od różnych dostawców i mogą mieć ponad dwadzieścia lat. Dzisiaj, gdybyśmy mogli projektować od zera, moglibyśmy preferować projekty sprzętowe oparte na klastrach stosunkowo małych, kompatybilnych komputerów i pisać programy przy użyciu orientacji obiektowej i przenośnego kodu. Jednak wiele systemów biznesowych, które nadal działają, opiera się na scentralizowanych big boxach, aby uruchamiać wszystkie swoje procesy lokalnie i wdrażać relacyjne lub nawet płaskie bazy danych oraz kodowanie COBAL lub zastrzeżone. Mogą przechowywać dane, które trudno zintegrować z warstwowymi modelami danych bardziej nowoczesnych struktur baz danych. W zamian mogą cieszyć się bardzo wysokim poziomem bezpieczeństwa i integralności transakcyjnej. Ewolucja przetwarzania warstwowego w wielu przypadkach będzie po prostu niemożliwa do wyrzucenia starych i wprowadzenia nowych bez narażania firmy na ryzyko. Z tego powodu rozwiązania do budowy rozbudowanego przedsiębiorstwa elektronicznego musiały być pragmatyczne. Nikt poważnie nie zasugerował, że powinien istnieć system operacyjny e-biznesu, który zastąpiłby dotychczasowe. Nie byłoby również możliwe przepisanie całego zastrzeżonego oprogramowania biznesowego. Zamiast tego podejście, jak zobaczymy, opiera się na budowaniu rozproszonego oprogramowania pośredniczącego, które może pośredniczyć między różnymi lub rozproszonymi systemami. W szczególności na tym polu konkurują i współpracują obecnie Microsoft DCOM, otwarta architektura CORBA oraz rozwiązania Enterprise Java. Ze względu na złożoność procesów i różnorodność maszyn, te rozwiązania oprogramowania pośredniego mogą powodować poważne wąskie gardła, jeśli nie zostaną uwzględnione w projekcie.

Pod względem technologicznym, co odróżnia „e-biznes” od „zwykłego”? W innym miejscu wspomnieliśmy o modelach komercyjnych, które kładą nacisk na globalizację, handel online i przedsiębiorstwo rozproszone. Ale kiedy przyjrzymy się podstawowym technologiom, widzimy, że wiele dzisiejszych organizacji, które, z wyjątkiem być może dla celów reklamowych, nie uważałyby się za e-biznesy, w rzeczywistości posiadają wysoce rozwiniętą i złożoną infrastrukturę elektroniczną, która wspiera te aspekty. Zautomatyzowane procesy biznesowe działają od ponad 30 lat. Jednak procesy te, choć być może zaprojektowane przez jeden wewnętrzny dział IS, często były opracowywane w celu zaspokojenia potrzeb konkretnych jednostek funkcjonalnych. Nie było między nimi koordynacji i mało zastanawiano się, jak mogą współpracować. Często między działami istniała nawet zupełna przepaść kulturowa. Chociaż technologia może niewiele zrobić na krótką metę, aby zmienić kulturę, z pewnością może ją rzucić wyzwanie. Dlatego odpowiadając na nasze pytanie, gdybyśmy mieli znaleźć jeden termin opisujący architekturę prawdziwie eBiznesu, byłaby to integracja. Rozważmy nieco dalej tło historyczne. Jeśli spojrzy się na przyjęcie automatyzacji komputerowej w organizacji, często jest jasne, że operacje obliczeniowe zachowały całkowity podział między kontrolą procesów przemysłowych i przetwarzaniem danych handlowych. Często nawet ich pracownicy byli umieszczani w różnych strukturach kariery – „inżynierskiej” i „administracyjnej” lub „handlowej”. Ich komputery również były inne: maszyny inżynieryjne działały w czasie rzeczywistym i były sterowane przerwaniami, podczas gdy systemy komercyjne były zorientowane na dane i wykonywały duże zadania przetwarzania wsadowego. W wielu firmach niemożliwe było kierowanie produkcją lub dostawą w odpowiedzi na warunki handlowe. Na przykład firmy telekomunikacyjne, gazowe i energetyczne nie miały możliwości zwiększenia lub zmniejszenia dostaw do klientów biznesowych w oparciu o nowe umowy taryfowe, ponieważ systemy handlowe i inżynieryjne nie współpracowały ze sobą. Teraz można to naprawić. Nawet w hierarchii inżynierskiej odnajdujemy podziały technologiczne. Wystarczy wziąć pod uwagę głęboką przepaść między „telekomunikacją” a „technologią informacyjną”, z których pierwsza pierwotnie zaspokajała potrzebę komunikacji, a druga przetwarzania informacji. W przeszłości uważano za słuszne traktowanie ich jako dwóch bardzo oddzielnych działań, przy czym ich obowiązki w wielu organizacjach były oddzielnie przekazywane kierownikowi IT i kierownikowi ds. komunikacji, którzy mogli nigdy ze sobą nie rozmawiać. Dziś rozróżnienie to bardzo się zatarło, wraz z pojawieniem się poczty elektronicznej i rosnącą potrzebą obsługi komputerów w ramach sieci danych. Sytuację dodatkowo komplikuje rosnące zainteresowanie usługami głosowymi w sieciach danych (w szczególności głos przenoszony przez Internet Protocol), przy czym ważnym przykładem jest projektowanie call-center. Podstawowym wymogiem dla aplikacji e-biznesu jest tania, wysokiej jakości reakcja na dane wejściowe z wielu różnych, tymczasowych kanałów. Integracja poczty elektronicznej, formularzy internetowych i połączeń głosowych, umowa nabywca-dostawca na duże odległości i heterogeniczne platformy, negocjacje między ludźmi oddzielonymi odległością: te i ich integracja są głównymi wyzwaniami w tworzeniu e-biznesu.

Projektowanie systemów musi koncentrować się na strategiach i rozwiązaniach, które umożliwiają to zadanie integracyjne w sposób niezawodny, bezpieczny i w sposób, który może być budowany przez innych bez kosztownego ponownego wymyślania. Wymagane są komponenty wielokrotnego użytku, które są niezależne od platformy i kodu (lub przynajmniej tolerancyjne), przy czym orientacja obiektowa w dużej mierze zastępuje inne metody zdalnego wywoływania procedur. Wszystko to musi odbywać się w obecności wielu starszych systemów, niektórych zorientowanych na komputery mainframe, chociaż dominującą architekturą platformy będzie wielowarstwowa architektura klient-serwer. Zaproponowano szereg rozwiązań, a debata na temat ich meritum jest nadal bardzo aktywna. W tym rozdziale staramy się przedstawić przegląd głównych zaangażowanych działań oraz pewien wgląd w kwestie, które wciąż są dyskutowane.