Zrób Sobie Firmę

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.

Jak mówimy w kilku innych miejscach, gwałtownie rośnie zainteresowanie mobilnymi aplikacjami e-biznesu. Pod wieloma względami istnieje bardzo niewielka różnica w kategoriach serwera, między statycznymi i mobilnymi protokołami dostępu oraz aspektami usług, ale istnieją pewne istotne warianty. Wiele aplikacji mobilnych sprowadza się po prostu do korzystania z urządzenia komputera osobistego w postaci laptopa. Można go podłączyć do gniazdka przewodowego lub działać przez łącze radiowe, na przykład za pomocą modemu podłączonego do telefonu komórkowego. Nie ma żadnej różnicy między tym a połączeniem telefonicznym ze stacjonarnego punktu do konwencjonalnego dostawcy usług internetowych. Być może istnieje prawdopodobieństwo wolniejszego i mniej niezawodnego połączenia oraz chęci korzystania z bezpiecznych środków komunikacji, aby uniknąć oszustw itp., ale nic się zasadniczo nie zmieni. Z drugiej strony, niektóre terminale mobilne, w szczególności te, które wyewoluowały z technologii telefonii komórkowej, mogą nie mieć bezpośredniego dostępu do standardowego serwera WWW. W części 1, Terminale detaliczne, omawiamy terminale oparte na protokole Wireless ——Application Protocol (WAP), co jest przykładem: język komunikacji klient-serwer, język skryptowy interfejsu użytkownika i różne funkcje bezpieczeństwa różnią się od są głównymi podmiotami internetowymi i muszą być hostowane na klientach i serwerach specjalnie zaprojektowanych do obsługi WAP. Zwykle istnieje serwer bramy, który działa bezpośrednio między klientem a serwerem sieci Web, aby pośredniczyć między ich protokołami.

Większość pomiarów wydajności usług sieci Web koncentrowała się na ograniczeniach szybkości różnych połączeń między klientem a serwerem i do niedawna niewiele uwagi poświęcano krytycznej analizie wydajności serwera i jej wpływowi na wrażenia użytkownika. W rzeczywistości nie można traktować szybkości sieci i wydajności serwera jako niezależnych komponentów, które mają wpływ na ogólną wydajność: są one wzajemnie powiązane, a nie tylko addytywne. Na przykład nadmierne kolejkowanie na wejściu do serwera powoduje konieczność powtarzania poleceń w sieci w celu utrzymania działającej sesji. Proste pomiary wydajności serwera, mierzone na serwerze, niekoniecznie wskazują na widok widziany przez klienta: w badaniu jednego z największych dostawców usług internetowych w USA zespół badawczy z Hewlett-Packard Research Labs zgłosił szereg takich zagadnienia . Przeprowadzili pomiary wydajności serwerów w stosunku do zapotrzebowania na dane wejściowe.

Wraz ze wzrostem popytu zdolność serwera do przetwarzania wszystkich żądań http stopniowo się wyrównywała, co pokazuje pełna krzywa. Patrząc na to w ten sposób, pogorszenie wydajności wygląda „z wdziękiem”, bez dramatycznego spadku wydajności. Jeśli jednak serwer nie zwróci potwierdzenia odebrania wiadomości http z powodu przeciążenia, wówczas żądanie „przekracza limit czasu”. Prowadzi to do wygenerowania powtórnego żądania, które stawia dalsze żądania na serwerze. Wraz ze wzrostem popytu coraz większy odsetek tego popytu to w rzeczywistości powtarzające się żądania. Efekt netto, jak widzą klienci (którzy w końcu są jedynymi, którzy naprawdę mogą ocenić usługę), polega na załamaniu liczby udanych sesji, reprezentowanych przez krzywą kropkowaną. Usługa faktycznie uległa „katastrofalnej” degradacji. Nie jest łatwo uniknąć tego typu problemów: należy zorganizować monitorowanie przynajmniej niektórych żądań http w celu wykrycia powtarzających się żądań, a może być konieczne włączenie oprogramowania diagnostycznego do wyszukiwania przypadków patologicznego zachowania. Warto również zwrócić uwagę na ataki typu „odmowa usługi”, w szczególności na duże partie bardzo szybkich „poleceń odświeżania” pochodzących od poszczególnych klientów, co może wskazywać na ataki zautomatyzowane. Istnieje złożona kwestia dotycząca tego, kto jest odpowiedzialny za zyski ze strat, w tych warunkach dostawca usług internetowych lub właściciel witryny internetowej klienta

Model klient/serwer zastosowany w powyższych sekcjach jest oczywiście znacznie uproszczonym schematem rzeczywistej instalacji wymaganej do spełnienia działającej sytuacji e-commerce. Nie każda organizacja może sobie pozwolić na uruchomienie serwera WWW, nie mówiąc już o czasie i wysiłku na zbudowanie własnego eSklepu od podstaw. Jak małe i średnie przedsiębiorstwa mogą konkurować on-line z dużymi firmami, nie posiadając własnych serwerów, personelu do ich obsługi i kreatywnych projektantów stron internetowych? Aby sprostać tej potrzebie, na rynku pojawia się szereg produktów, które zapewniają szereg udogodnień, które mają umożliwić mniejszym firmom zaistnienie w sieci. Firmy takie jak HipHip i WebToolPro.com oferują miejsce na serwerach i narzędzia do tworzenia eShopów. Zapewnią rejestrację nazwy domeny (http://www.myshop.co.uk, myshop.com itp.), a także umożliwią przekazywanie wiadomości e-mail w przypadku zapytań klientów. Narzędzia te zazwyczaj pozwalają również osobom nie przeszkolonym w HTML na łatwe dostosowywanie serii stron internetowych, z różnych stylów stron, do których można wyciąć logo firmy i ilustracje. Firma może stworzyć katalog i dowolnie go modyfikować, m.in. aby pokazać dostępność zapasów i ceny. Użytkownicy mogą przeglądać katalog i umieszczać wybrane pozycje w koszyku. Formularze zamówień pozwalają klientom na wprowadzenie niezbędnych danych, a bezpieczeństwo jest zazwyczaj zapewniane przez warstwę bezpiecznych gniazd (SSL). Oczywiście jest to tylko front eShop, z minimalną integracją z pozostałymi procesami pracy firmy, ale pozwala małej firmie na niemal natychmiastowe przejście do Internetu za roczną sumę około 500 funtów. Wydaje się to być bardzo rozsądnym podejściem dla małej firmy o ograniczonej zmienności zapasów i produktu, który jest „niszowy”, ale potencjalnie z szerokim rynkiem geograficznym, który mógłby zostać zaspokojony, np. pocztą. Wiele większych organizacji woli również przekazać zarządzanie serwerem firmie zewnętrznej, albo dostawcy usług internetowych, albo wyspecjalizowanej firmie outsourcingowej. Niektórzy wolą to robić we własnym zakresie. Niezależnie od wybranej trasy, instalacje na ogół przebiegają według podobnego schematu. Rysunek przedstawia dużą instalację, jaką zapewniałaby firma oferująca połączenie z Internetem oraz możliwość obsługi aplikacji eCommerce, ale jest odpowiednia dla tych o dowolnej wielkości.

Jedną z głównych niewiadomych związanych z witryną internetową jest wiedza, jakiego natężenia ruchu można się spodziewać. Dlatego dostawcy zazwyczaj wybierają skalowalne rozwiązanie, które można łatwo zwiększyć wraz ze wzrostem ruchu, po prostu dodając dodatkowe serwery oraz dodatkową pojemność transmisji i routingu. Same serwery WWW znajdują się po lewej stronie rysunku . Mogą to być maszyny UNIX (LINIX), które mogą obsłużyć kilka instalacji eShop, lub mniejsze maszyny z systemem Windows, działające w systemie Microsoft NT, w którym to przypadku zwykle przypada jedna na sklep. Tabela 4. 2 podaje specyfikację na przykład tego ostatniego.

Specyfikacja serwera WWW

Typowa specyfikacja serwera internetowego z systemem Windows (np. Dell „PowerEdge”)

Procesor: podwójny P3 533 MHz, aktywny i zapewniający równoważenie obciążenia

RAM: 256 MB

Dysk twardy: 9 GB

Konstrukcja: „solidna”, a nie „odporna”. Wyposażony w „zasilacze bezprzerwowe”

Orientacyjny koszt: 3–4 tys . funtów

Większość użytkowników eShopping (po prawej stronie rysunku) łączy się z usługą zakupów za pośrednictwem modemu wdzwanianego do lokalnego punktu obecności (POP) dostawcy usług internetowych. POPS są połączone przez sieć usługodawcy z serwerami WWW (po lewej stronie rysunku). W wielu przypadkach firma zawarłaby umowę z dostawcą usług aplikacji do handlu elektronicznego w Internecie, aby ten ostatni dostarczał usługi aplikacji, takie jak katalog, weryfikacja kredytów, przyjmowanie płatności, oprócz podstawowego serwera sieci Web. Te serwery aplikacji byłyby również udostępniane w sieci korporacyjnej usługodawcy, która może być rozległa. Alternatywnie, jeśli eSprzedawca chciałby obsłużyć większość z nich samodzielnie, dostawca usług byłby połączony ze sprzedawcą za pośrednictwem połączenia intranetowego lub ekstranetowego. Zostało to omówione dalej w części 2, Architektura systemów e-biznesu. W pewnym miejscu pomiędzy publiczną „twarzą”, którą serwer WWW prezentuje światu zewnętrznemu, a wewnętrznymi, korporacyjnymi bazami danych i serwerami płatności, będzie również znajdować się jedna lub więcej zapory ogniowej, zapewniającej ochronę przed przypadkowymi lub celowymi działaniami, które mogą uszkodzić krytyczne procesy.