Autor: admin

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.

Zarządzanie wiedzą to konwersja surowych danych w znaczące zbiory informacji w kontekście modelu biznesowego, a zatem potencjalnie może wspierać planowanie i podejmowanie decyzji. Jednym z głównych problemów jest stworzenie wspólnego rozumienia struktury informacji i semantyki między organizacjami. Wcześniejsze inicjatywy EDI poszły w pewnym stopniu do osiągnięcia tego celu, szczególnie w niektórych sektorach wertykalnych, ale zadanie pozostaje trudne. Rozwój Internetu, taki jak rozszerzalny język znaczników (XML), zapewnia mechanizm przekształcania opisów semantycznych na format przetwarzalny maszynowo. To toruje drogę do tworzenia korporacyjnych portali wiedzy, które otwierają części korporacyjnych repozytoriów wiedzy dla klientów i dostawców, pracując w ten sposób na rzecz wspólnego zrozumienia i celu. Informacje korporacyjne nie powinny znajdować się w organizacji jako wyizolowane zbiory danych. Zamiast tego celem powinno być stworzenie jednolitej hurtowni danych, spójnej i konsekwentnie utrzymywanej, dostępnej w dostosowanych widokach do jednostek funkcjonalnych. Aby być skalowalnym, zautomatyzowane czyszczenie danych musi odbywać się na różnych poziomach w hurtowni przy użyciu poziomu sztucznej inteligencji. Zwiększona moc przetwarzania i możliwości przechowywania pozwalają teraz na analityczne przetwarzanie danych online, aby pomóc w planowaniu strategicznym i rynkowym. Omówiono prezentację w kostkach danych i wizualnie oraz przedstawiono przegląd i krytyczną analizę inteligentnej eksploracji i ekstrakcji danych.

Architektura systemów e-biznesu

Wychodząc poza tworzenie prostego sklepu internetowego, wymagana jest kulturowa zmiana od rozwiązania punktowego do kompleksowej integracji. Ta integracja jest złożona i działa w ramach heterogenicznej gamy sprzętowych i programowych platform przetwarzania rozproszonego i komunikacji. Musimy również zastanowić się, jak zintegrować aplikacje on-line, które obejmują zautomatyzowane procesy, interakcję człowiek-maszyna oraz wspomaganą komputerowo współpracę między ludźmi. Coraz częściej standardowe usługi komunikacyjne są świadczone przez protokoły internetowe TCP/IP, uzupełnione o procesy bezpieczeństwa, które pozwalają na budowę wirtualnych sieci prywatnych, intranetów i ekstranetów. Dominującą architekturą komputerową jest n-warstwowa klient-serwer, z komponentami zorientowanymi obiektowo, czego przykładem są CORBA, DCOM i JavaRMI, które pozwalają nam wywoływać procesy bez konieczności dokładnej wiedzy, w którym miejscu rozproszonego środowiska będą one działać. Operacje na danych o krytycznym znaczeniu działają w rozproszonym modelu przetwarzania transakcji. Ludzie, jako część rozproszonych zespołów, osiągają pewien poziom empatii za pomocą multimedialnych narzędzi konferencyjnych, choć dziś odnoszą one tylko częściowy sukces. Działania w przedsiębiorstwach są wspierane przez zarządzaną dokumentację, która zawiera heterogeniczną zawartość, kontrolowaną wersję i synchronizowaną na wielu platformach. Coraz częściej również na tę architekturę wpływa rozwój Internetu, szczególnie w odniesieniu do tego, ile należy przechowywać, a ile po prostu „wskazywać”. Zautomatyzowane procesy przepływu pracy, które usuwają wiele ręcznych ponownego wprowadzania kluczy i planowanie zadań, są opisane. Podkreślono centralną rolę katalogów rozległych.

Skoncentrowaliśmy się na opisie głównych elementów wirtualnego okna zakupów, koszyka zakupów i półek, pomijając funkcje back-office, takie jak obsługa zamówień, realizacja i obsługa klienta, które łącznie uzupełniają cały e-biznes, a nie e-handel. , domena. Zostały one omówione w innych rozdziałach. Potrzebne są jednak jeszcze dwie czynności, niemal najważniejsze, które zamieniają igraszki zakupowe w poważne zobowiązanie: przyjęcie zamówienia i pobranie płatności. Być może moglibyśmy uznać, że są one po prostu dodatkiem do przeglądania sklepu i ładowania koszyka, ale jest jeden bardzo dobry powód, dla którego byłoby to nierozsądne: bezpieczeństwo. Zamiast tego, obsługę zamówienia i płatność należy traktować jako dwa wyraźnie różne procesy, które zachodzą jednocześnie w fazie następującej po wstępnych zakupach .

Chociaż pożądane jest zapewnienie niezawodnej, wydajnej i atrakcyjnej obsługi funkcji pokazanych w stanie numer jeden na rysunku, żadna z nich nie jest, ściśle rzecz biorąc, śmiertelnie uszkodzona w wyniku awarii lub uszkodzenia. Jest to znacznie mniej prawdopodobne niż w przypadku działań przedstawionych w stanie drugim. Nieprawidłowe działanie obsługi zamówień towarów często prowadzi do bardzo znacznych kosztów awarii i zadowolenia klienta; problemy z przyjmowaniem płatności mogą być jeszcze poważniejsze. Architektonicznie i w rzeczywistości projektanci przyjmują osobny sposób radzenia sobie z nimi. Część , Architektura systemów e-biznesu, obejmuje przetwarzanie wniosków, w tym przyjmowanie zamówień towarów i ich późniejsze przetwarzanie. Obsługa płatności może być krótko omówiona tutaj, ze szczegółami bezpieczeństwa, o których mowa w Części, Bezpieczeństwo. Głównym przesłaniem obsługi płatności jest to, że dwustanowy model przedstawiony na rysunku jest odzwierciedlony w architekturze – dla każdego z nich używany jest fizycznie i logicznie odseparowany zestaw serwerów. Gdy klient zobowiąże się do zakupu artykułów, powinien przejść do wysoce niezawodnego, transakcyjnego zestawu procesów, które pobierają płatność i dodają zamówienie do kolejki. Zazwyczaj serwer płatności oferuje klientowi możliwość otwarcia bezpiecznego (tj. zaszyfrowanego) kanału przekazywania wiadomości między nim a nim, w którym gromadzone są informacje o karcie kredytowej lub inne informacje dotyczące płatności.

Ten proces może nawet przebiegać w witrynie innego dostawcy, być może w agencji płatniczej. Szczegóły dotyczące wymagań koszyka na zakupy są przekazywane z serwera WWW do serwera płatności (być może tylko całkowity koszt) w bezpieczny sposób, który nie pozwala na włamanie się do tego ostatniego. Przynajmniej taka powinna być intencja, jak wyjaśniamy w naszych dyskusjach na temat bezpieczeństwa.