Miesiąc: marzec 2022

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.

Tak długo, jak ADSL jest używany tylko jako sposób zapewnienia szybkiego dostępu do Internetu, serwery, do których mają dostęp klienci, będą musiały po prostu przetwarzać pliki HTML z większą szybkością. Jeśli jednak, co jest prawdopodobne, zapotrzebowanie na naprawdę ruchome wideo wzrośnie, albo z powodu wzrostu popytu na telewizję/filmy, albo witryn e-commerce chcą katalogów ruchomych obrazów, dynamika serwerów musi się znacząco zmienić. Każda usługa VOD musi umożliwiać indywidualnym użytkownikom traktowanie systemu raczej jak odtwarzacza kaset wideo o wysokiej wydajności: ciągły przepływ programów musi być dostępny w dowolnym momencie, rozpoczynając się w dowolnym miejscu programu, z pauzą, przewijaniem do przodu, przewijaniem do tyłu i skanowaniem udogodnienia. Zapewnienie tego przy użyciu standardowej technologii komputerowej jest dość wymagające: serwer musi być w stanie obsłużyć dużą liczbę jednoczesnych przerwań od klientów i być w stanie obsłużyć ciągłe przesyłanie strumieniowe o dużej szybkości danych. Od prawie dekady naukowcy badają opcje adaptacji standardowych architektur komputerowych, opartych na obsłudze bloków danych, do systemów obsługujących ciągłe przesyłanie strumieniowe. Istnieją dwa główne problemy: opóźnienie i niezawodność, z których oba są krytycznie zależne od optymalizacji wydajności dysków i ich interakcji z urządzeniami buforującymi na serwerze. Zaproponowano dużą liczbę alternatywnych odmian . Jak pokazano na rysunku  należy podjąć decyzję, czy zarządzanie pobieraniem danych z dysków ma odbywać się przy użyciu procesora serwera, czy za pomocą specjalnego sprzętu do tego celu, taki jak pompa  wideo .

Wcześniejsze próby VOD skłaniały się do faworyzowania rozwiązania specjalnego przeznaczenia, ale ostatnio systemy oparte na konwencjonalnych serwerach stały się możliwe dzięki poprawie szybkości, która jest obecnie dostępna na stosunkowo niedrogich maszynach. Oba podejścia mają swoich zwolenników: oczywiście robienie wszystkiego za pomocą oprogramowania na serwerze zmniejszy koszty, ale zwiększy obciążenie serwera; odwrotna sytuacja będzie miała miejsce w przypadku wdrożenia sprzętu. Sprzęt zapewnia również ogólnie wyższy poziom niezawodności. Innym sposobem na obniżenie kosztów streamerów wideo (i innych wysokowydajnych serwerów plików) jest użycie konwencjonalnych dysków magnetycznych. Aby to zrobić, potrzebny jest zestaw technik, które zapewniają niezwykły poziom niezawodności i wydajności. Podejście to nazywa się redundantną macierzą niedrogich dysków (RAID). (Czasami słowo „niezależny” zastępuje „niedrogi”.) Istnieje wiele wariacji na temat RAID i próba dostarczenia oficjalnej taksonomii na 10 poziomach została wyprowadzona przez Radę Doradczą RAID. Poziomy te są definiowane pod kątem ich kodów korekcji błędów oraz sposobu zapisu danych (rozkładania) w sektorach dysku, w tym możliwości zapisania ich na więcej niż jednym dysku, w celu zoptymalizowania niektórych aspektów wydajności i niezawodności. W przypadku VOD zoptymalizowanie szybkości pisania nie jest generalnie problemem, ponieważ można to zrobić w trybie offline, ale osiągnięcie stale wysokiej szybkości czytania jest trudne, w tym w scenariuszu, w którym dwie lub więcej osób chce uzyskać dostęp do tego samego wideo plik. W tym ostatnim przypadku, jeśli plik (zazwyczaj film) jest przechowywany tylko na jednym dysku, istnieje poważne ograniczenie prędkości pobierania. Jednym ze sposobów jest zsynchronizowanie wielu dysków i rozłożenie danych na nich sektor po sektorze.

Macierz wielodyskowa może być traktowana jako zestaw logicznych sektorów dyskowych, z których każdy jest n razy większy niż pojedynczy dysk (gdzie n to liczba zaangażowanych dysków). W ten sposób szybkość transferu wzrasta również n razy. Tam, gdzie na przykład muszą być przechowywane długie pliki filmów i istnieje prawdopodobieństwo, że dostęp do nich będzie możliwy w niezależnych losowych momentach, powyższa metoda ma problemy z buforowaniem. W tym scenariuszu lepszym rozwiązaniem może być przeplatanie kolejnych bloków każdego filmu w kolejnych sektorach na różnych dyskach

Ten układ pozwala na wiele alternatyw dla wyszukiwania danych, które mogą być zaprojektowane do optymalizacji obciążenia

Przykładem działania bardzo cienkiego klienta może być przypadek telewizji emisyjnej – telewizor wyświetla jedynie obraz dokładnie zgodnie z emitowanym sygnałem. Oczywiście mamy też bardzo cienką konfigurację serwera: serwer po prostu wysyła pojedynczy sygnał do wszystkich odbiorników. Oznacza to, że nadawanie jest z natury usługą nieelastyczną. Mimo powierzchownego podobieństwa nie ma to miejsca w przypadku prawdziwego wideo na żądanie (VOD), które stawia przed serwerem spore wymagania. Dzieje się tak, ponieważ VOD zapewnia relację jeden-do-jednego między każdym aktywnym klientem a serwerem oraz ponieważ wiąże się z przechowywaniem i dystrybucją dużych ilości danych wideo. W części 1, Retailing Network Technologies, wyjaśniamy zasady transmisji dla VOD i podobnych usług związanych z eShopping. Podsumowując: sygnały szerokopasmowe, rzędu Mbit/s lub nawet więcej, zdolne do dostarczania wysokiej jakości ruchomych obrazów, mogą być dostarczane do pomieszczeń klientów za pomocą modemów kablowych pracujących na koncentrycznych zasilaczach telewizji kablowej do pomieszczeń lub za pośrednictwem konwencjonalnych dwużyłowe kable telefoniczne wykorzystujące technologię cyfrowej pętli abonenckiej (DSL). Jedną z opcji jest wykorzystanie tych systemów do dostarczania danych klientom korzystającym z usługi opartej na protokole IP. W przypadku dostaw telekomunikacyjnych przy użyciu DSL możemy zobaczyć architektury typu przedstawionego na rysunku

Każdy klient posiada na terenie obiektu modem zdolny do transmisji sygnału o dużej szybkości. Sygnały te są multipleksowane (łączone w jedną ścieżkę transmisyjną) na zasadzie „ulica po ulicy” lub lokalnej centrali telefonicznej, w zależności od zapotrzebowania i gęstości zaludnienia. Multipleksowanie może wiązać się z niskim poziomem koncentracji, co oznacza, że ​​istnieje możliwość, że niektóre sygnały zostaną wyciszone w okresach dużego natężenia ruchu (podobnie jak w sieci Ethernet LAN). W węźle usługowym połączenie serwerów zapewnia kontrolę i dostęp do szeregu usług świadczonych przez ADSL: dostawcę usług sieciowych. Należą do nich szerokopasmowe serwery wideo, które mogą dostarczać wiele zasadniczo nieprzerwanych, indywidualnych strumieni wideo do wielu klientów jednocześnie, urządzenia do zarządzania usługami w celu rejestracji, wyrejestrowania, ładowania itp. zarządzanie strumieniami IP i zarządzanie nazwami domen aby zezwolić na sesje między klientem a dowolnymi zdalnymi serwerami w sieci Web, kontrolę bezpieczeństwa i tak dalej. Węzeł serwisowy łączy się następnie z Internetem za pośrednictwem usługi sieciowej, sieć szkieletowa dostawcy. Do i chyba dostawcy sieci zapewniają bardzo tanie, szerokopasmowe połączenia przez sam Internet, połączenie między węzłem usługowym a Internetem będzie doświadczać typowych problemów z dużą rywalizacją, znanych dzisiaj, w przeciwieństwie do łącza koncentratora do węzła usługowego, które zapewnia znacznie wyższe prędkości. Właśnie dlatego architektura pokazana na rysunku 4.15 jest tym, czym jest: dane (na przykład strumienie wideo), które wymagają szybkiej transmisji, muszą być przechowywane lokalnie u klienta. Tak więc w scenariuszu zakupów obejmującym katalog on-line z ruchomymi klipami wideo sprzedawca kupiłby miejsce na serwerze wideo w węźle usługowym. Film w ruchu byłby tutaj przechowywany w standardowym formacie wideo. Sprzedawca tworzyłby następnie na własnym serwerze zestaw stron internetowych, które określały katalog zakupów, pozostawiając „dziury” (w postaci ramek lub kotwic obrazu) na wideo. Użytkownicy sklepu nadal będą mieli dostęp do witryny detalicznej pod adresem http://www.myshop.-co.uk, a nie do witryny usługodawcy, zachowując w ten sposób markę sprzedawcy i codzienną kontrolę zmian, ale za każdym razem do katalogu po obejrzeniu sekcji, odpowiedni klip wideo mógł zostać wywołany (automatycznie lub przez wywołanie innej przeglądarki internetowej). Architektura zaczyna być wielowarstwowa, o zwiększonej złożoności, ale także elastyczności: klienci negocjują z więcej niż jednym serwerem, z możliwością dość złożonej kontroli sesji. Kolejny element elastyczności pokazano również na Rysunku 4.15: chociaż dostawcy usług telekomunikacyjnych mają nadzieję, że będą w stanie sami zapewnić wszystkie urządzenia węzłowe, są na ogół zmuszani przez organy regulacyjne telekomunikacyjne do zapewniania dostępu stronom trzecim do ich sieci lub usług, takich jak DSL, który na nich działa. Gdy usługi dojrzeją, w zasadzie nie powinno być problemu z detalistą łączącym się bezpośrednio z łączem DSL na równych zasadach z innymi dostawcami. W ten sposób detaliści mogliby umieszczać własne węzły usługowe tam, gdzie chcieli i z wybraną funkcjonalnością, będąc zmuszeni jedynie do łączenia się z urządzeniami zarządzania IP używanymi przez dostawcę usług telekomunikacyjnych na łączu między koncentratorem a węzłem usług telekomunikacyjnych. Jedną z kwestii jest kontrola dostępu (przy użyciu technik uwierzytelniania, takich jak RADIUS), aby umożliwić klientowi szerokopasmowy dostęp do serwera. Być może bardziej prawdopodobnym scenariuszem jest to, że opcję łączenia na tym poziomie podejmą konkurujący operatorzy telekomunikacyjni, którzy będą próbować oferować detalistom zróżnicowane usługi (cena, jakość usług, niska rywalizacja itp.), tak jak robią to dziś dostawcy usług internetowych za ich usługi. Jeszcze inną opcją jest skonfigurowanie przez dostawców usług internetowych własnego sprzętu w ramach istniejących central telefonicznych. To właśnie zaczęło się dziać w Wielkiej Brytanii. Jedną z kwestii, która wciąż znajduje się na wczesnym etapie badań, jest najlepszy wybór lokalizacji serwerów wideo w sieci krajowej lub globalnej. Lepiej mieć kilka dużych serwerów lub sieć mniejszych i jak podzielić dane (klipy wideo) między nie? Rzeczywiście, jeśli technologia sieciowych serwerów wideo jest w powijakach, trudno powiedzieć, że specyfikacje usług zostały stworzone!

Wraz z rozwojem technik transmisji, które umożliwiają dostarczanie ułamkowych Mbit/s lub nawet wyższych prędkości do lokali domowych, rośnie zainteresowanie zapewnianiem szybkich usług internetowych i/lub telewizji cyfrowej innymi sposobami niż zwykła transmisja. Chociaż do tej pory zakładaliśmy, że platforma kliencka będzie urządzeniem podobnym do komputera osobistego lub mobilnego, wyraźnie nie ma powodu, dla którego Internet i technologie internetowe nie mogłyby być również wykorzystywane do świadczenia usług handlu elektronicznego w kanałach telewizji cyfrowej na rzecz konwencjonalnych telewizorów, czy to poprzez transmisja cyfrowa lub wideo na żądanie. Jak wyjaśniono w tym rozdziale, telewizja cyfrowa wykorzystuje przystawkę STB, która w zasadzie jest prostym komputerem PC z minimalnym systemem operacyjnym i oddzielnym obrazem („obraz telewizyjny”) i płaszczyznami pamięci graficznej. Jako przykład prostej aplikacji eCommerce możemy wyobrazić sobie ukryty „komentarz bieżący” płynący synchronicznie z programowaniem wideo, który może być widoczny na żądanie (za pomocą pilota użytkownika) w celu dodania napisów do programu. Na przykład program podróży może zawierać komentarz reklamowy. Alternatywnie możemy sobie wyobrazić, że usługodawca emituje karuzelę recyklingu wstępnie wybranych stron internetowych, na przykład kanał zakupów internetowych. Użytkownicy wybierają je ze strony menu, a następnie czekają, aż ekran się odświeży w sposób podobny do tego, który jest używany przez obecne serwisy wideotekstowe. Jednak w żadnym przypadku nie ma rzeczywistej interakcji między tym klientem a serwerem transmisji: ten ostatni po prostu przekazuje wszystkie informacje dodatkowe do głównego dźwięku i obrazu w dodatkowym kanale, w którym użytkownicy wybierają po prostu czekając na przybycie informacji. Usługa jest całkowicie wypychana przez serwer, a nie pobierana przez klienta. (Oczywiście musi istnieć pewna interakcja między klientami a zdalnym sklepem, ale można to zrobić za pomocą dekodera nawiązującego połączenie z serwerami zakupów [dane karty kredytowej itp.]), a nie za pośrednictwem serwera WWW odpowiedzialnego za transmisję

Część transmisji internetowej do dekodera musi być unikalnym kluczem, który jednoznacznie identyfikuje wszystkie strony, które można przeglądać (i wszystkie dyskretne elementy danych na nich), aby można go było użyć w wiadomości między dekoderem Box i serwery zakupów. Należy zauważyć, że emisja może w zasadzie obejmować aktywne strony z kodem, który można wykonać na kliencie dekodera (na przykład aplety Java i ActiveX). Dzięki temu formularze zamówień mogą być prezentowane użytkownikowi i sprawdzane automatycznie, przed automatycznym wywołaniem połączenia telefonicznego i wysłaniem zamówienia danych.

Zapotrzebowanie na uwodzicielskie treści przesunęło Internet z samego tekstu, przez statyczne obrazy, do ruchomych obrazów i dźwięku. Ze względu na bardzo ograniczone przepływności, które są ogólnie dostępne dla krajowych klientów, musimy przestrzec przed nierealistycznymi oczekiwaniami co do jakości, ale warto wspomnieć o obecnie dostępnych mechanizmach dostarczania. Równie dobrze mogłoby to zostać uwzględnione w rozdziale dotyczącym terminali detalicznych, ponieważ wszystkie rozwiązania obejmują zarówno klienta, jak i serwer. W przypadku klienta zwykle będzie potrzeba jakiejś wtyczki lub przynajmniej posiadania aktualnej przeglądarki. Należy zauważyć, że istnieje bardzo realna różnica między technologią stosowaną do aplikacji, które dostarczają multimedia tylko w jednym kierunku (na przykład uwodzicielskie obrazy w katalogu zakupów lub filmy na żądanie), a tymi, które wymagają dwukierunkowego interakcji, takich jak telefonia wideo. W tym drugim przypadku zakładamy, że wszelkie przetwarzanie i kodowanie obrazu musi być przeprowadzone równo na obu końcach, model symetryczny. Jednak w przypadku jednokierunkowego wyszukiwania zapisanych obrazów możemy złagodzić ten wymóg. Ponadto w takich przypadkach odbiorników takich sygnałów będzie zwykle więcej niż producentów (np. znacznie więcej odbiorników telewizyjnych niż nadajników). Te fakty oznaczają, że kodowanie może być asymetryczne, a kodery mogą być drogie, choć nie w czasie rzeczywistym, podczas gdy dekodery powinny być tanie i działające w czasie rzeczywistym. To w dużym stopniu wyjaśnia różnice w filozofii projektowania koderów między telefonią/współpracującą społecznością roboczą a osobami zaangażowanymi w rozrywkę i tworzenie katalogów. Innym aspektem do rozważenia jest rozróżnienie między rozwiązaniami multimedialnymi, które pozwalają tylko na pobranie do klienta kompletnego pliku, który jest następnie odtwarzany „off-line”, a metodami, które umożliwiają odtwarzanie „w czasie rzeczywistym”, gdzie serwer strumieniuje zawartość do klienta, który odtwarza go mniej więcej zaraz po dostarczeniu. (Zwykle będzie krótkie opóźnienie przetwarzania). Oczywiście, w przypadku ciągłego tła doświadczeń zakupowych, preferowane jest rozwiązanie strumieniowe, chociaż techniki off-line mogą być wykorzystywane do efektów specjalnych o krótkim czasie trwania. Gdy weźmie się pod uwagę, że na przykład sygnały cyfrowe z kompaktowych dysków audio są stale przesyłane strumieniowo z prędkością 56 kbit/s £ 20 ¼ 560 £ 2 ¼ 1 Mbit/s, zaczyna się zdawać sobie sprawę, że wszystkie standardy kodowania audio i wideo muszą działać, aby osiągnąć całkiem znaczące zmniejszenie szybkości transmisji danych w celu przesyłania sygnałów dobrej jakości przez wolne łącza on-line. Konieczne jest również oddzielenie „produktu” multimedialnego od podstawowej technologii: oferowanych narzędzi i elementów sterujących, w przeciwieństwie do sposobu kodowania sygnału. Wiele produktów osiągnęło znaczący udział w rynku, w tym RealSystem, Shockwave, Quicktime, Microsoft Windows Media. Niektóre z nich są raczej zastrzeżone pod względem platformy, na której działają, a każdy ma swoje zalety i wady. Niektóre są lepsze dla audio niż wideo lub odwrotnie. Jeśli chodzi o sposób kodowania sygnału, znów pojawia się szereg autorskich rozwiązań. Jedna dobra, najwyraźniej bezstronna analiza jest obecnie dostępna online. Zastrzeżone rozwiązania mogą być dostępne już od jakiegoś czasu dla aplikacji strumieniowych, ale jedno standardowe podejście zaczyna dominować w przypadku dźwięku off-line i gdzie połączenie między klientem a serwerem może obsługiwać dość duże prędkości. Jest to standard MPEG Layer 3 (MP3), opracowany jako część serii standardów przez Moving Pictures Expert Group, która, jak sama nazwa wskazuje, zajmuje się również standardami wideo. Jednym z powodów popularności standardu MP3 jest fakt, że nie zapewnia on zbyt wiele ochrony praw autorskich! W przypadku szerszego pasma ruchomego obrazu wideo stale przyjmuje się standard multimedialny MPEG 2, który obejmuje zakres dopuszczalnych szybkości transmisji z jakością telewizji nadawanej na poziomie około 2 Mbit/s.