Miesiąc: marzec 2022

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.

Pomimo tych teoretycznych dyskusji, dzisiejsza rzeczywistość jest taka, że ​​handel elektroniczny online jest zdominowany przez przeglądarkę internetową i protokoły internetowe. Sieć została po raz pierwszy opracowana jako narzędzie wspierające badania naukowe, zapewniając pracownikom naukowym, rozproszonym po całym świecie i połączonym z różnymi systemami komputerowymi, dostęp do dokumentów oraz komunikowanie się ze sobą niezawodnie i wydajnie, przy użyciu protokołów transmisji TCP /IP, jak wyjaśniono w części 2, Architektura systemów e-biznesu. Sieć to aplikacja (lub przynajmniej zestaw aplikacji), która działa w Internecie. Nie jest absolutnie konieczne uruchamianie aplikacji internetowych w Internecie i nie jest nieuniknione, że handel elektroniczny działa na jednym lub obu, chociaż oba stanowią, pojedynczo i razem, bardzo dobry przypadek. Rzeczywiście, dzisiaj jest to niezmiennie wybrana konfiguracja. Większość czytelników jest dobrze zaznajomiona z korzystaniem z Internetu w celu uzyskania dostępu do zdalnych serwerów w Internecie. Usługi sieciowe są świadczone za pośrednictwem standardowej architektury klient – serwer opisanej wcześniej: komputer użytkownika, stacja robocza lub ewentualnie cyfrowy dekoder jest wyposażony w oprogramowanie, przeglądarkę, która komunikuje się ze zdalnym serwerem sieciowym za pomocą jeden z zestawu protokołów aplikacji, z których najpopularniejsze to http dla ‘stron WWW’, smtp dla poczty elektronicznej, ftp dla dostępu do zdalnych plików. Zwróć uwagę, że  Serwer WWW to oprogramowanie, a nie sprzęt (choć oczywiście może być hostowany na zarezerwowanym do tego celu komputerze). Największym zainteresowaniem w aplikacjach eShopping jest http, ponieważ jest to protokół używany do uzyskiwania dostępu do stron WWW na zdalnym serwerze, które wspólnie próbują stworzyć katalog wystawowy dla oferowanych towarów. Użytkownicy uzyskują dostęp do eShopu, wysyłając żądanie przeglądarki w postaci polecenia http. Polecenie: http://www.myshop.co.uk rozpoczyna się od zlokalizowania adresu IP odpowiadającego serwerowi WWW dla WWW.myshop.co.uk. W tym celu uzyskuje dostęp do serwera nazw domen (DNS), który został przypisany przez administrację systemu do (pod-)sieci, w której znajduje się komputer kliencki). Przykład tego, jak to działa, w przypadku kupującego w domu podłączonego do dostawcy usług internetowych .

DNS utrzymuje tablicę przeglądową, która ustala korespondencję między (zwykle) niezapomnianą nazwą („www.myshop.co.uk”) a „prawdziwym” adresem internetowym („adres IP”) serwera zakupów. Jeśli sam nie zawiera tych danych, może przekazać żądanie do usługi DNS wyższego poziomu. Gdy nazwa zostanie powiązana z rzeczywistym adresem, klient może wysłać żądanie do serwera WWW. W tym przypadku, ponieważ nie wysłał żadnych dodatkowych poleceń w wiadomości http, w rzeczywistości prosi serwer o przesłanie swojej standardowej strony wejściowej. Jeśli żądanie się powiedzie, dokładnie to zrobi serwer: wyśle ​​wiadomość zwrotną do przeglądarki, która z kolei wyświetli go na ekranie użytkownika. Wysłana wiadomość to strona internetowa, która dziś prawie we wszystkich przypadkach została skomponowana za pomocą hipertekstowego języka znaczników (HTML). Ogólnie rzecz biorąc, strona internetowa jest dokumentem, zwykle napisanym w języku HTML, przechowywanym w pliku, z którego można uzyskać dostęp przez Internet.

HTML jest znacznie uproszczoną wersją Standard Generalized Markup Language (SGML) [27], dość złożonego języka publikacji elektronicznych. To nie tylko określa układ dokumentów, ale pozwala na opisanie ich szczegółowej struktury, a nawet kontekstu w organizacji w sposób jednoznaczny i możliwy do przetworzenia przez maszyny. SMGL mógł kiedyś być potencjalnym kandydatem na język programowania używany do opisywania złożonych transakcji międzybranżowych, które omówimy w części 2. Jednak prawdopodobnie przegrał z raczej prostszym kandydatem, Extensible Markup Language, XML, który omówimy bardziej szczegółowo w Części 2, Zarządzanie wiedzą e-biznesową. Podobnie jak większość oprogramowania DTP, HTML otacza tekst, który ma być oglądany przez użytkownika, dodatkowymi metainformacjami, które dają dalsze instrukcje przeglądarce, która go wyświetla. Jeśli nie znasz tej koncepcji, dobrym pomysłem jest przyjrzenie się kilku konkretnym przykładom. Przykładem strony HTML jest sam domyślny ekran przeglądarki. Uruchom przeglądarkę. Następnie, aby wyświetlić kod źródłowy tego, co jest dla Ciebie widoczne, wybierz „źródło” z opcji „widok” na pasku narzędzi przeglądarki. Na przykład zrobienie tego podczas przeglądania strony wprowadzającej Internet Explorera spowoduje wyświetlenie następującego tekstu:

< h2 style = ‘‘font:8pt/11pt verdana; color:black” id =”ietext”>Internet Explorer< /h2 >

Ta linia odpowiada za wyświetlanie tekstu „Internet Explorer” jako „nagłówek typu 2” w kolorze czarnym. Zwróć uwagę, jak to się robi, włączając w to znaczniki rozdzielające ,h2…/h2, pomiędzy którymi operacja na tekście ma się zaczynać i kończyć. Początkowo HTML był używany głównie w Internecie jako medium do projektowania atrakcyjnych układów dokumentów tekstowych i nadal jest to jedna z jego głównych ról. Zapewnia udogodnienia dla różnych mocnych pozycji nagłówków, list numerowanych i nienumerowanych, tabel danych i tak dalej. Jednak być może najbardziej interesującą funkcją HTML jest możliwość dołączenia odnośnika http do innej strony internetowej – na przykład strona opisująca produkt może zawierać stwierdzenie takie jak „szczegóły”. Ta podkreślona nazwa to łącze, którego kliknięcie powoduje wysłanie żądania http do serwera kontrolującego ten plik w celu zwrócenia odpowiedniej strony. (Zgodność między słowem „szczegóły” a faktycznym adresem strony została wstawiona przez programistę i można ją ponownie zobaczyć, sprawdzając kod źródłowy.) Pierwotnie linki były rzeczywiście reprezentowane na stronie internetowej głównie jako element tekstu – wielu nadal tak jest – ale środowiska tworzenia stron internetowych pozwalają teraz średnio niewykwalifikowanym programistom na umieszczanie przycisku lub obrazu w celu reprezentowania łącza do przeglądarki. Rozwój przeglądarek obsługujących ramki był wczesnym rozszerzeniem możliwości wyświetlania pojedynczej strony HTML. Tutaj ekran może zostać podzielony na wiele obszarów, z których każdy może pomieścić osobny plik, którego rozmiar i położenie jest zgodne z główną stroną zestawu ramek, która rzeczywiście działa jak ramka, do której wstawiane są poszczególne strony. Zapewnia to, na przykład, bardzo wygodny sposób na ciągłe utrzymywanie paska narzędzi kontrolnych na ekranie, jednocześnie umożliwiając użytkownikowi przeglądanie wyników wyszukiwania katalogu produktów w pozostałej części ekranu

Jak wyjaśniono w częściach dotyczących sprzedaży detalicznej, istnieje szereg technik transmisji służących do dostarczania eSklepu i jeszcze większej liczby terminali klienckich, na których można go odbierać. Jednak technologia wykorzystywana przez dostawcę do obsługi klientów jest znacznie mniej zróżnicowana. We wszystkich obecnych modelach zakupów elektronicznych wspólnym czynnikiem jest mały i średni komputer działający jako serwer w dość prostej, klasycznej konfiguracji klient-serwer, jak pokazano na rysunku

Istnieje więcej różnic w sprzęcie klienta, jak wskazano w części 1, Terminale detaliczne, ale ogólne zasady są bardzo podobne we wszystkich przypadkach: klient (komputer PC, dekoder telewizyjny, kiosk itp.) zawiera dane lokalne i ogólne system operacyjny oraz sprzęt i oprogramowanie komunikacyjne. W przypadku komputera PC może to być na przykład system operacyjny Microsoft Windows, oprogramowanie do połączenia z Internetem punkt-punkt i sprzętowa karta komunikacyjna. Dostępna jest również warstwa prezentacyjna, która umożliwia użytkownikowi przeglądanie scenariusza zakupów i interakcję z nim. Ponownie, w przypadku komputera PC, jest to zawarte w przeglądarce internetowej. Wiadomości między serwerem a klientem i na odwrót są zwykle przekazywane za pośrednictwem niezależnego dostawcy usług internetowych (ISP) (który odpowiada za pośredniczenie między protokołem internetowym typu punkt-punkt rezydującym w kliencie a pełnym protokołem TCP). /protokół IP) . Czasami dostawca może zapewnić samą funkcję ISP, ale to tylko szczegóły. Faktyczny proces zakupowy jest określony w modelu handlowym serwera, który określa wygląd ekranów, które klient może przeglądać, formularze, które może wypełnić, proces ładowania koszyka, weryfikację i podstawowe aspekty bezpieczeństwa, i tak dalej. Serwer zawiera również dane katalogowe lub ma bezpośredni dostęp do wydzielonej bazy danych zawierającej informacje o sprzedawanych produktach i usługach. Jak powiedzieliśmy, wydaje się, że jest to obecnie powszechnie akceptowany model, prawdopodobnie z wielu rozsądnych powodów. Maszyna klienta jest odizolowana od zmian w modelu komercyjnym, a użytkownicy nie muszą ładować nowego oprogramowania za każdym razem, gdy sprzedawca zdecyduje się zmienić projekt lub złożoność zakupów. Gdyby było inaczej, mogłyby wystąpić problemy z kompatybilnością i konfiguracją z klientem, być może niewystarczająca pamięć lub dziwactwa w funkcjonalności. Praca z opisanym modelem pozwala na stworzenie rynku, na którym większość kosztów i niedogodności związanych z zapewnieniem wydajności i aktualizacją będzie dotyczyć stosunkowo niewielu serwerów w witrynach dostawców. W ten sposób zmniejsza się uciążliwość dla klienta, a bariery w dostępie do oferty konkretnego dostawcy są skutecznie usuwane.

Chociaż są to prawie powszechnie przyjęty projekt, istnieją warianty i alternatywy, które wymagają wzmianki. Na przykład powyższy przykład użycie komputera PC oznacza, że ​​klient jest stosunkowo „gruby” – zawiera znaczną ilość oprogramowania, w tym pełny system operacyjny. Mimo to w przeszłości elastyczność klienta była ograniczona: przeglądarka była tak naprawdę tylko usługą lokalizacji i pobierania dokumentów, wzbogaconą o możliwość wysyłania danych do procesów, które działały na serwerze. W ciągu ostatnich kilku lat nastąpił wzrost elastyczności tego klienta dzięki wykorzystaniu JAVA i ActiveX oraz innych metod pobierania oprogramowania z serwera i uruchamiania go na komputerze klienta. W pewnym sensie to „tuczy” klienta – w końcu jest w nim więcej oprogramowania, ale daje też możliwość odchudzania: w wielu przypadkach klient nie wymaga przynajmniej dużego, ogólnego systemu operacyjnego będąc używanym jako terminal handlowy. Dlaczego więc nie pobrać prostego „systemu zakupów”, który łączy funkcjonalność aplikacji i niezbędnych narzędzi systemu operacyjnego, ale ze znacznie zmniejszonymi wymaganiami dotyczącymi pamięci? Mogłoby to potencjalnie obniżyć koszt terminala klienckiego, aw przypadku terminali mobilnych, zminimalizować wagę i zużycie energii. Równie radykalną alternatywą byłoby rozważenie terminalu klienta, który był właściwie tylko ekranem, z całą elastycznością prezentacji zachowaną na serwerze. Ta koncepcja nie jest tak fantazyjna, jak mogłoby się wydawać: telewizja jest dziś ucieleśnieniem właśnie tej zasady. Dzięki wielu kanałom cyfrowym dostępnym w trybie transmisji schodkowej lub wideo na żądanie, istnieje możliwość zapewnienia obsługi bardzo cienkiego klienta do robienia zakupów w domu – a tym samym korzystania z niezwykle taniego terminala, być może tylko z prostym kanałem telefonicznym do przyjmowanie zamówień na ustalonych formularzach. Trzeba powiedzieć, że ta koncepcja cienkiego klienta jest kontrowersyjna, a główni gracze w branży opowiadają się po stronie, która ma tendencję do popierania własnych linii produktów. Microsoft, na przykład, postrzegałby system operacyjny PC jako obszar wzrostu, a nie obszar, który prawdopodobnie się skurczy; Z drugiej strony firma ORACLE poświęciła znaczną ilość czasu na promowanie modelu zorientowanego na klienta cienkiego, zorientowanego na bazę danych. Omówimy tę kwestię dalej, gdy przyjrzymy się urządzeniom końcowym.

Pod wieloma względami najważniejszym elementem doświadczenia zakupowego jest platforma sprzedawcy, na której zamontowana jest większość oprogramowania eCommerce. Jak pokazuje rysunek,

platforma ta wygląda na dwa sposoby, w kierunku klienta i w biznesie. Platforma eCommerce jest raczej koncepcyjna niż rzeczywista. Jak zobaczymy, składa się on z części wielopoziomowej architektury komputerowej, zamontowanej na wielu platformach sprzętowych i programowych. Rzeczywiście, części modelu eCommerce będą czasami hostowane na terminalu klienta użytkownika, a nie tylko na serwerze dostawcy. Ale koncepcja platformy eCommerce jest jednak przydatna, ponieważ pozwala nam pomyśleć o niezbędnych elementach, które są potrzebne do obsługi eCommerce. W naszej dyskusji na temat zasad handlu elektronicznego wspomnieliśmy o zestawie wymagań DAVIC. DAVIC zmapował to również na podstawowy zestaw funkcji wykonywanych przez użytkownika końcowego, dostawcę usług, dostawcę treści i dostawcę sieci . Ich lista życzeń, pokazana w tabeli, zapewnia najwyższą specyfikację doświadczeń zakupowych i wyznacza dość wymagające cele dla programistów eCommerce, korzystających z istniejącej technologii.

Podstawowy zestaw funkcji DAVIC

Użytkownik końcowy

U1 Poruszaj się po środowisku zakupów

U2 Wybierz interesujące Cię pozycje

U3 Odbieranie (i) zdjęć przedmiotów, (ii) tekstu, (iii) dźwięku, (iv) ruchomego wideo, (v) nieruchomej i animowanej grafiki opisującej przedmioty

U4 Porozmawiaj z prawdziwym sprzedawcą (tylko audio lub audio wideo), który zna kontekst aplikacji (do rozważenia w przyszłości)

U5 Kontroluj klipy multimedialne, w tym powtórz, wstrzymaj i przerwij

U6 Autoryzuj płatność/zakup towarów

U7 Zapytanie i zmiana poprzedniego zakupu (zamówień), w tym żądanie autoryzacji wymiany/zwrotu

U8 Umiejętność wykonania kopii papierowej

U9 Rezerwuj produkty/usługi

U10 Wybierz metodę płatności

Dostawca usługi

S1 Zapewnij środowisko zakupów!

S2 Poproś o przesłanie klipów multimedialnych do użytkownika

S3 Wyślij klipy multimedialne do użytkownika

S4 Przetwarzaj pozycje zamówienia użytkownika

S5 Prowadź pośrednią listę nabytych

Dostawca treści

C1 Zapewnij klipy multimedialne do produktów

C2 Podaj informacje o cenie, dostępności, czasie dostawy, specjalnych warunkach

C3 Kategoryzacja materiałów do selekcji elektronicznej

C4 Określ układ sklepu wirtualnego

C5 Przypisz produkty do wirtualnych działów

Dostawca internetu

N1 Przesyła różne formaty danych do użytkownika, w tym: filmy, zdjęcia, dźwięk, tekst i grafikę

N2 Przesyłaj informacje od dostawców treści lub usługodawców na serwer w celu uzyskania szybkich aktualizacji informacji o produktach

N3 Zezwalaj na dynamiczne dodawanie/usuwanie połączeń między użytkownikiem końcowym a dodatkowymi serwerami (tj. jeśli użytkownik „kliknie” element, który ma klip wideo, wówczas musi być skonfigurowany „potok” wideo dla użytkownika)

Jak również powiedzieliśmy wcześniej, prawdziwe przykłady zakupów w Internecie zostały oparte na tym, co jest możliwe, być może stosunkowo łatwe do wdrożenia, a nie na liście DAVIC, która może, ale nie musi, zostać zrealizowana, gdy cyfrowa telewizja interaktywna stanie się usługą masową. Niemniej jednak warto zachować trochę pamięci na liście, aby porównać z tym, co faktycznie zostało osiągnięte.