Zrób Sobie Firmę

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.

Wracając do interakcji między klientem a serwerem dostawcy, omówimy teraz jeden aspekt, który nie zawsze jest rozumiany: to przeglądarka, czyli oprogramowanie w kliencie, pamięta to, co było wcześniej odwiedzane, podczas gdy serwer nie. Jeśli chodzi o serwer WWW, każde kliknięcie to nowe żądanie, a poprzednie zostają zapomniane. Interakcja między serwerem WWW a klientem WWW jest procesem bez pamięci lub bezstanowym. Była to świadoma decyzja podjęta podczas projektowania protokołów internetowych: usuwa wszelkie problemy związane z blokowaniem itp., które mogą wystąpić z powodu raczej zawodnego charakteru komunikacji przez Internet lub przeciążenia serwera. Zmniejsza również obciążenie serwera ponieważ ta ostatnia nie jest zaangażowana w półtrwałą transakcję ze swoimi klientami i dlatego nie musi przechowywać informacji o statusie tego, co się działo wcześniej. Ale ma to niefortunne konsekwencje dla handlu elektronicznego: każde działanie klienta jest postrzegane przez serwer osobno, a działania nie mogą być połączone w kompletny proces. Weźmy prosty przykład (który również jest wymogiem DAVIC): często robimy zakupy, kupujemy kilka sztuk, ale oczywiście wolimy rozliczyć się tylko jedną płatnością. W najprostszej formie nie jest to coś, co możemy zrobić w sieci Web: bez przyjęcia bardziej wyrafinowanego podejścia każdy wybór wymagałby wypełnienia indywidualnego formularza zakupu. To, co wolelibyśmy, to odpowiednik koszyka, który mógłby przechowywać informacje o liście wybranych przez nas produktów, a nawet pozwalał nam usuwać przedmioty po namyśle, a następnie ostatecznie rozliczyć się, gdy będziemy gotowi. Najprostszym sposobem, aby to zrobić, jest skorzystanie z funkcji cookies dostępnej we wszystkich obecnych przeglądarkach. Plik cookie to po prostu fragment danych przekazywany do przeglądarki przez serwer, który może być następnie pobrany przez serwer. W celu stworzenia koszyka zakupowego serwer tworzy przestrzeń w bazie danych i przypisuje jej unikalny kod referencyjny, który posłuży do identyfikacji klienta. Następnie wysyła ten numer na terminal klienta, gdzie jest przechowywany w przeglądarce jako plik cookie. Za każdym razem, gdy klient wypełnia wpis w formularzu zamówienia, plik cookie jest przesyłany z powrotem na serwer, gdzie umożliwia aktualizację wpisu specyficznego dla klienta w bazie danych.

Chociaż korzystanie z plików cookie jest bardzo wygodne, nie zawsze jest możliwe: niektórzy użytkownicy nie ufają im (prawdopodobnie bez ważnych powodów) jako mechanizmowi wysysania informacji z ich maszyn bez ich kontroli. W związku z tym przeglądarki posiadają możliwość wyłączenia mechanizmu cookies i niektórzy użytkownicy z niego korzystają. Alternatywą, w przypadku dość nowoczesnych przeglądarek, jest wykorzystanie apletów JAVA, które w rzeczywistości są bardziej inwazyjne niż pliki cookie, są fragmentami kodu wykonawczego, a nie tylko danymi, ale które są bardziej akceptowane przez użytkowników. Możliwe jest nawet stworzenie koszyka zakupów, który działa na kliencie, a nie na serwerze, przekazując zamówienie do tego drugiego dopiero po podjęciu przez klienta decyzji. W przypadku tradycyjnych komputerów, które są połączone za pomocą niezawodnej sieci przewodowej, nie jest to prawdopodobnie dobry pomysł, ponieważ problemy w połowie zakupów częściej występują na kliencie niż na serwerze, ale może to być dobry pomysł na środowisko mobilne.

Możemy krótko przeanalizować jedno popularne rozwiązanie bazodanowe (pozostawiając szczegółowe omówienie w Części 2, Architektura systemów e-biznesowych). Jeszcze zanim serwery WWW były widoczne, systemy baz danych często działały jako serwery dla klientów aplikacji. Początkowo odbywało się to przy użyciu zastrzeżonych interfejsów, co oczywiście prowadzi do przywiązania do konkretnego dostawcy. Aby ułatwić korzystanie z aplikacji na komputery PC, firma Microsoft stworzyła oprogramowanie pośredniczące, które może działać jako usługa aplikacji i oferuje otwarty interfejs. To oprogramowanie, Open Database Connectivity (ODBC) umożliwia aplikacjom komputerowym komunikację z różnymi relacyjnymi bazami danych za pomocą standardowych zapytań SQL. ODBC umożliwia również odwoływanie się do plików w DBMS poprzez nazwę, a nie ich dokładną lokalizację w bazie danych. Chociaż pierwotnie został zaprojektowany dla systemu operacyjnego Windows, ODBC został uznany za standard przez SQL Access Group i został przeniesiony na wiele komputerów mainframe, a także na środowiska Macintosh i UNIX, a także dalej rozwijany w celu obsługi nierelacyjnych bazy danych. Należy pamiętać, że połączenie bazy danych z serwerem WWW jest jednym z oczywistych wymagań aplikacji, ale są też inne: w szczególności możliwość zrealizowania zamówienia klienta poprzez wyodrębnienie danych karty kredytowej i wykonanie polecenia przelewu to kolejny często spotykany wymagany. Wykorzystanie tych innych aplikacji jest częścią konstrukcji kompleksowej n-warstwowej architektury biznesowej, która zazwyczaj wymaga rozwiązania opartego na komponentach. Zostanie to omówione dalej, kiedy przyjrzymy się procesom, które są mniej bezpośrednio widoczne dla klienta końcowego

Możliwe jest utworzenie witryny sieci Web dla operacji sprzedaży detalicznej, pisząc zestaw stron HTML, które zawierają każdy przedmiot do sprzedaży, wszystkie jego odmiany i cenę, w obrębie samych stron

Jeżeli katalog nie jest duży i nie ma większych szans na zmiany w czasie, to można to zrobić w ten sposób, zmieniając strony za każdym razem, gdy chcesz dodać/usunąć/zmienić produkt, jego dostępność lub cenę. Aby upewnić się, że nie ma kłopotliwych różnic między zapasami, harmonogramami dostaw lub utrzymywaniem zapasów, a tymi stronami internetowymi, należy zadbać o to, aby regularnie aktualizować strony, przy jednoczesnym zachowaniu bezpiecznego poziomu zapasów. Ewentualnie trzeba jasno powiedzieć, że klienci będą musieli sprawdzić dostępność, na przykład przez telefon lub e-mail. To może być raczej zniechęcenie. Lepszą alternatywą jest połączenie usługi sieciowej z bazą danych o zapasach.

Na rysunku wprowadziliśmy dwa nowe elementy, usługi aplikacji oraz giełdową bazę danych lub katalog. Niektórzy uważają, że wprowadzenie katalogu on-line zasadniczo zmieni model biznesowy prowadzenia działalności detalicznej. Postrzegają to jako interaktywny proces oparty na kliencie, który odwraca poprzedni model biznesowy oparty na uwzględnieniu poziomu zapasów. Jednak z technicznego punktu widzenia ta funkcja katalogowania może być nadal zapewniana przez tradycyjne, starsze systemy zarządzania bazami danych (DBMS), które istnieją od dłuższego czasu. Mogą to być małe systemy hostowane na komputerach zgodnych z IBM do użytku przez osoby fizyczne lub małe organizacje bez większych umiejętności programowania: Microsoft Access jest jednym z takich przykładów, mogą to być systemy średniej wielkości do użytku przez wykwalifikowanych programistów i do użytku na większych komputerach, w których w przypadku, gdy są one zwykle zaprojektowane w oparciu o język zapytań SQL i działają na ORACLE, Microsoft SQL Server lub IBM DB2, lub mogą być bardzo dużymi, niestandardowymi systemami, być może z oprogramowaniem krytycznym dla firmy, w którym to przypadku mogą być dość stare, stare systemy. Niezależnie od tego, jakie są, zazwyczaj można je zintegrować ze środowiskiem WWW, za pośrednictwem usług aplikacji. Obejmują one samodzielne części oprogramowania, często nazywane „oprogramowaniem pośredniczącym”, które mogą działać na tym samym komputerze fizycznym, co serwer sieci Web, lub na innym komputerze. Muszą być zaprojektowane tak, aby łączyć się między bardzo różnymi środowiskami serwera WWW sterowanego zdarzeniami i integralnością transakcyjną bazy danych. Zostało to szerzej omówione w części 2, Architektura systemów e-biznesu. Jak sama nazwa wskazuje, różne serwery aplikacji mogą obsługiwać inne aplikacje niż bazy danych, ale wymagania dotyczące bazy danych są coraz większe.

Jak dotąd opisaliśmy najprostsze z dostępnych w sieci możliwości pobierania informacji z serwera. Podstawowa instrukcja http://www.myshop.co.uk powoduje załadowanie do klienta strony internetowej HTML zapisanej pod tym adresem na serwerze w postaci statycznego pliku danych. Gdy klient wysyła żądanie http do serwera, serwer obsługuje żądanie za pośrednictwem „demona http”, fragmentu kodu generowanego do obsługi każdego indywidualnego żądania. Demon jest wezwany do uruchomienia tylko jednego rodzaju procesu: zdalnego przesyłania plików, nic więcej. Strony są wyodrębniane z dysku, dodawanych jest kilka wierzchołków i końcówek, a dane są kodowane do transmisji za pomocą protokołu HTTP

Czasami może to nie być najlepszy lub wystarczający sposób robienia rzeczy. Przychodzą mi na myśl dwie szczególnie częste operacje: selektywne pobieranie dalszych szczegółów informacji podsumowanych na aktualnie przeglądanej stronie internetowej oraz zwracanie informacji od klienta na serwer, na przykład adresu pocztowego, w celu sfinalizowania transakcji . Oczywistym sposobem na zrobienie tego jest uwzględnienie dodatkowych informacji w ciągu http od klienta, który może uruchomić proces na serwerze i dostarczyć mu informacje związane z tym konkretnym zdarzeniem

Żądanie klienta do serwera WWW wywołuje „demona” HTTP w w normalny sposób, ale dodatkowo przekazuje resztę ciągu http do głównego systemu operacyjnego serwera, w sposób umożliwiający systemowi operacyjnemu uruchomienie procesu o nazwie w ciągu i dostarczenie mu danych zawartych również w ciąg. Specyfikacja przesyłania tych informacji i rozpoczynania wtórnego procesu została ujednolicona kilka lat temu w zestawie protokołów znanych pod wspólną nazwą Common Gateway Interface (CGI). Proces która została uruchomiona, nazywana jest metodą, a przekazywane do niej parametry, które są specyficzne dla bieżącej aktywności, są zmiennymi akcji. Protokół CGI definiuje, w jaki sposób te zmienne mają być reprezentowane w systemie i jak mogą być pobrane przez wywołaną metodę, niezależnie od języka kodu źródłowego (zwykle C, C11, Perl) tego ostatniego. Początkowo skrypty CGI były wykorzystywane do prostych metod zbierania informacji z formularzy wypełnianych przez użytkowników oraz do wstawiania prostych odpowiedzi bazy danych w obrębie tabel tworzonych przez serwer, jednak wzrosło zapotrzebowanie na bardziej elastyczne rozwiązania. Rozważmy na przykład strony pokazane na rysunkach

Klient wybrał towar z katalogu on-line poprzez przesłanie formularza na serwer, który zwrócił pozytywne potwierdzenie.

Ale załóżmy, że skoczka nie ma w magazynie? Wtedy oczekiwana odpowiedź byłaby podobna do poniższej. Przychodzące żądanie spowodowało zapytanie do bazy danych iw wyniku zapytania należy wykonać dwie możliwe akcje: co zrobić, gdy zapasy są/nie są dostępne. To tutaj możliwość uruchamiania procesów oparte na skryptach. Skrypt nie tylko zapewnia możliwość zwrócenia klientowi strony „towary dostępne” lub „niedostępne”, ale może też „spersonalizować” ją do konkretnego żądania („sweter nie ma młodości…”). Mogliśmy stworzyć zestaw stron statycznych dla każdej możliwej odpowiedzi, nawet dla każdego możliwego produktu, i przechowywać je w magazynie stron statycznych. Oczywiście byłoby to bardzo czasochłonne i stanowiłoby poważny problem z konserwacją. Zamiast tego chcemy tworzyć dynamiczne strony, które można dostosować do każdego zdarzenia. Zamiast mieć opisy stron HTML w statycznej bazie danych, po jednym dla każdego typu żądania klienta, strony są generowane dynamicznie, zgodnie z algorytmem zakodowanym w skrypcie. Można to zrobić za pomocą skryptów CGI, które wywołują wymaganą metodę, która działa jako osobny proces w systemie serwera (ale poza samym serwerem WWW). Jednak bardziej nowoczesny.

Coraz bardziej preferowana jest metoda taka jak Active Server Pages firmy Microsoft. W tym podejściu wewnątrz samego serwera WWW istnieje maszyna wirtualna (zdefiniowana w zestawie procesów), która ładuje odpowiedni plik z dysku do pamięci głównej . Ten plik lub skrypt zawiera zarówno podstawowe dane strony, jak i kod programu dla metody. Możemy myśleć o tym działaniu jako o trzymaniu opisu pustej strony szablonu oraz metodzie dokończenia strony zgodnie z bieżącą wartością dowolnych zmiennych akcji dostarczonych przez klienta. Metoda jest tłumaczona przez oprogramowanie na maszynie wirtualnej na serwerze, zwykle jest to interpreter (chociaż może to być kompletna operacja kompilacji i uruchamiania) i wykonywana, po dostarczeniu niezbędnych zmiennych metody i akcji, w żądaniu http. Skrypty można pisać w dowolnym z wielu języków, ale prawdopodobnie najczęściej używane są Perl i JAVAscript. Oprócz dostarczania zaawansowanych funkcji programistycznych wykraczających poza proste skrypty CGI, podejście aktywnych stron ma również przewagę wydajnościową. Jak pokazano , oryginalny model CGI obejmuje uruchomienie procesu znajdującego się poza serwerem WWW. Zabiera to dodatkowe koszty przetwarzania i może, w obciążonym systemie, powodować opóźnienia. Może to nawet prowadzić do błędu pamięci poza zakresem, jeśli projekt nie jest odpowiednio określony. Przy aktywnych stronach maszyna wirtualna obsługująca proces jest częścią serwera WWW, dzięki czemu jest szybsza i bardziej niezawodnie zintegrowana.