11.1. Корпоративні Web-портали та Web-сервіси у КІC
11.2. Програмні продукти ефективного управління бізнесом CPM та ВPM
11.3. IР-телефонія та відеоконференції у КІС
Резюме
Терміни і поняття
Запитання для перевірки знань
Завдання для індивідуальної роботи
— сутність і порядок використання корпоративних Web-порталів і Web-сервісів у КІС;
— класифікацію порталів за функціональним призначенням;
— призначення корпоративного інформаційного порталу;
— структуру корпоративного порталу;
— сервісно-орієнтовану архітектуру (Service Oriented Architechture, SOA);
— використання програмних продуктів ефективного управління бізнесом CPM та ВPM;
— використання корпоративної ІР-телефонії у КІС а також УМІТИ:
— використовувати корпоративні Web-портали та Web-сервіси в програмних продуктах корпоративного рівня;
— використовувати стандартний протокол SOAP (Simple Object Access Protocol) для відсилання запитів та отримання повідомлень мережею Internet;
— використовувати ІР-телефонію в практичній діяльності.
11.1. КОРПОРАТИВНІ WEB-ПОРТАЛИ ТА WEB-СЕРВІСИ В КІС
У наш час відбувається активний процес інтеграції інформаційних систем корпоративного рівня із додатками, що забезпечують взаємодію підприємств із клієнтами і партнерами, а також з Web-додатками, призначеними для відвідувачів Web-сайтів. Число пов’язаних з цим Internet-проектів стрімко зростає рік у рік. Іншими словами, багато компаній зараз активно створюють інфраструктуру, що дозволяє використовувати Internet не тільки як засіб комунікацій, а й як один із основних інструментів ведення бізнесу. Створення такої інфраструктури означає упровадження Internet-додатків, що дозволяють корпорації надавати своїм клієнтам і співробітникам актуальну інформацію, а часто — і прямий доступ до корпоративних інформаційних систем та інших бізнес-додатків і своєчасно обробляти відомості, що надійшли від них (наприклад, замовлення на товар чи пропозиції на обслуговування).
Великого значення у таких інфраструктурах надають так званим корпоративним Web-порталам і Web-сервісам.
За своєю сутністю портал — це Web-сайт, призначений для певної аудиторії (наприклад, клієнтів і співробітників), який здійснює оброблення, аналіз і доставку інформації до замовника, і надає при цьому доступ до різних сервісів шляхом персоналізації користувачів за допомогою будь-якого пристрою, підключеного мережі Internet. З іншого боку, портал можна розмістити як групу Web-сторінок, що належать конкретній особі чи організації і підтримуються ними. Практично, це Web-вузол, що надає початкову сторінку, яка персоналізу-
Вивчивши матеріал цього розділу, ви будете ЗНАТИ:
В архітектурі (не комп’ютерній, а звичайній) порталом називають головний, парадний вхід у будівлю; найчастіше так говорять про вхід у готичний храм. Відомий як архітектурна класика портал кафедрального собору у Фрайбурзі (Німеччина).
Останнім часом корпорації наввипередки почали створювати власні інформаційні портали. Менеджери ІТ покладають на цю технологію великі надії, і поки вона не дає їм приводів для розчарування.
Класифікувати портали можна за різними ознаками, але найчастіше вдаються до класифікації за призначенням. У даний час за цією ознакою розрізняють три основні типи порталів:
1. Загальнодоступні, або горизонтальні, портали (іноді їх називають мегапорталами), такі як Meta, Yahoo, Lycos, Excite, Rambler та інші. Ці портали призначені для найширшої аудиторії, характеризуються акумуляцією інформації загального характеру і наданням відповідних послуг (наприклад, новини про політичні події й культурне життя), відправлення (отримання) інформації, електронна пошта, розсилання тощо). Сфера діяльності таких порталів перетинається зі сферою діяльності засобів масової інформації, тому останнім часом спостерігаються процеси злиття загальнодоступних порталів і засобів масової інформації в рамках однієї компанії.
2. Вертикальні портали призначені для специфічних видів ринку й обслуговують аудиторію, яка користується послугами цього ринку або працює на ньому. Прикладами таких порталів можуть слугувати додатки В2С (Business-to-consumer), наприклад туристичні агентства, що надають послуги з бронювання місць у готелях, замовлення і доставку квитків, доступу до карт і відомостей про автомобільні маршрути тощо, або портали на кшталт В2В (business-to-business) що дозволяють своїм клієнтам реалізовувати сумісні бізнес-операції (обирати постачальників і здійснювати закупівлю товарів, проводити аукціони). Кількість таких порталів останнім часом швидко зростає, оскільки нові ринки товарів і послуг переміщаються в Internet.
3. Корпоративні портали призначені для співробітників, клієнтів і партнерів одного підприємства (іноді їх називають В2Е-портали Business-to-employees). Користувачі такого порталу дістають доступ до призначених ним сервісів і додатків залежно від їх ролі і персонального профілю, і це найцікавіша категорія порталів у плані реалізації корпоративної інфраструктури й інтеграції додатків. Призначенням корпоративного порталу є надання зовнішнім і внутрішнім користувачам можливості персоніфікованого доступу до всіх корпоративних даних і додатків включно з: неструктурованими й різнорідними даними, об’єднанням ізольованих моделей бізнесу, інтеграцією різних корпоративних додатків (зокрема додатків бізнес-партнерів), забезпечення повноцінного цілодобового доступу всіх користувачів (включно з мобільними приладами) до ресурсів компанії незалежно від місця їх перебування.
У літературних джерелах пропонується і більш детальна класифікація порталів. Їх підрозділяють на портали, що містять результати аналізу даних (Busi-
ється. Як відомо, тривалий час єдиними точками входу в Інтернет були добре відомі пошукові машини, проте для більшості користувачів цього виявилося недостатньо, тому виникла ідея Інтернет-порталу. Власне це претензійно названа спроба створити якщо не головний, то принаймні зручніший вхід у «Павутину».
Крім цього, порталами іноді називають інші типи Web-додатків, що надають своїм користувачам ті чи інші послуги через Internet, наприклад голосові портали, що дають право доступу до деяких послуг з телефонної лінії за допомогою голосових команд або команд, що надходять з клавіатури телефону, або так звані персональні портали, що надають послуги персональних інформаційних менеджерів й електронної пошти.
Словосполучення «корпоративний інформаційний портал», яке останнім часом стало вельми поширеним, означає програмний продукт, що забезпечує доступ за допомогою браузера до широкого спектра джерел даних — електронної пошти, СУБД, систем аналізу інформації, Internet, реєстраційних журналів систем виписки рахунків й автоматизації роботи відділів збуту тощо.
Зазвичай корпоративні портали привертають симпатії фахівців інформаційних технологій тим, що дозволяють «зробити нове обличчя» корпоративної інтрамережі, що із часом виявлялася захаращеною і сегментованою. Фахівці підрозділів інформаційних технологій можуть налаштовувати корпоративні портали для доступу до змінних у реальному масштабі часу даних, до ключових показників діяльності компанії і джерел новин, а також доповнювати їх засобами пошуку та оброблення запитів.
Портал прагне стати місцем, яке можна бачити, коли запускається Internet-оглядач. Для цієї мети він пропонує такі безкоштовні послуги, як підібрані за особистим смаком теми новин чи обліковий запис електронної пошти. Такий сайт є точкою входу користувачів у Web і привертає величезніший загал. Тому мати його виявляється вкрай вигідним, адже приплив реклами чималий з огляду на високу відвідуваність вузла.
Можливість пошуку за систематичним каталом — це додатковий сервіс, який надає бібліотека, і його рівень перебуває в прямій залежності від кваліфікації укладачів. Зазвичай користувач починає розробку теми з вивчення каталогу, а потім уже накопичує необхідний набір бібліографічних посилань. Отже, ідея зовсім не нова, проте у додатку до Мережі вона виявилася напрочуд плідною.
Як правило, портали володіють відкритою архітектурою, що дає змогу розширювати їхню функціональність додаванням сторонніх додатків або додаткових компонентів. Найчастіше такими компонентами виявляються засоби управління інформаційним наповненням, тому зазвичай їх виробляють розробники порталів або ж вони просто входять до складу останніх. ????????? ?????????????? ???????
Функціональну архітектуру порталу можна подати так, як це зроблено на рис. 11.1. Портал забезпечує доступ до інформаційних джерел різного роду, індексує їх і накопичує свою власну базу метаданих.
ness intelligence portals), внутрішньокорпоративні Internet-портали (Business area portals), портали для організації групової роботи (Enterprise Collaborative Portals), портали, призначені для управління знаннями (Enterprise Knowledge Portals), так звані рольові портали (Role portals), що підтримують три бізнесмоделі B2E, B2C, і B2B; корпоративні експертні портали (Enterprise Expertise Portals), для підключення користувачів до експертної системи, щоб отримувати додаткову інформацію, корпоративні прикладні портали (Enterprise Application Portals).
Джерела інформації
Рис. 11.1. Функціональна структура порталу
Функціональна архітектура підтримується логічною, яка може включати такий набір компонентів:
1. Клієнт. Це звичайний навігатор, що забезпечує користувачеві доступ до сторінок у форматі, наприклад HTML. Принциповим є те, що домашня сторінка може бути адаптована до потреб певного користувача, тобто налаштована на отримання того типу звітів, документів й інших даних, які становлять для нього інтерес і на отримання яких він авторизований, Крім заданої систематики сторінка може включати механізм пошуку за ключовими словами та інші традиційні інструменти навігатора.
2. Забезпечення безпеки доступу через Інтернет. Ця частина має звичайні для захисних екранів засоби кодування, аутентифікації та управління сесіями.
3. Репозиторій. Одна з найважливіших частин корпоративного порталу, в якому зберігаються метадані про інформаційні об’єкти, користувачів, робочі групи й інформаційні канали. Метадані, що стосуються об’єкта, вказують його тип, розділ, до якого він належить, формат зберігання, розташування.
4. Підсистема публікації та передплати. Ця частина порталу дає користувачам можливість публікувати власні документи і здійснювати підписку на існуючі джерела.
5. Механізм фільтрації даних. Цей механізм за заданими правилами фільтрує і сортує об’єкти, що надходять в репозиторій, за типом формату чи іншими ознаками. Він може направляти користувачеві інформацію про нові об’єкти і про зміни, що вже є, і водночас актуалізувати доступні йому джерела.
6. Механізм аналізу бізнес-процесів. Ця частина порталу забезпечує підтримку аналізу даних засобами реляційних і багатовимірних OLAP та інших аналогічних систем.
7. Драйвери даних. Зв’язок із реляційними і багатовимірними СУБД, різного роду бібліотеками й іншими можливими джерелами інформації здійснюється набором драйверів.
Типова архітектура Web-порталу, зазвичай має такі основні компоненти:
— публічні Web-сервери, які забезпечують доступ користувачів мережі Інтернет до інформаційних ресурсів порталу;
— кеш-сервери, що забезпечують тимчасове зберігання копії ресурсів, до яких діставали доступ Інтернет-користувачі. При зверненні до ресурсів Web-
— DNS-сервери, що забезпечують можливість перетворення символьних імен серверів Web-порталу на відповідні їм ІР-адреси;
— сервери додатків, на яких встановлено спеціалізоване програмне забезпечення, призначене для управління інформаційним вмістом Web-порталу;
— сервери баз даних, які забезпечують централізоване зберігання інформаційних ресурсів Web-порталу;
— комунікаційне устаткування, що забезпечує взаємодію між різними серверами Web-порталу.
Як правило, сервери Web-порталів розміщуються на території Інтернет-провайдерів, які можуть забезпечити необхідну смугу пропускання каналів, якими сервери порталу підключаються до мережі Інтернет.
Управління Web-порталом у цьому випадку здійснюється видалено через Інтернет з автоматизованих робочих місць (АРМ) адміністраторів. Ураховуючи той факт, що ресурси публічного Web-порталу за визначенням відкриті будьякому користувачеві мережі Інтернет, вони стають потенційною мішенню для атак порушників. Необхідно наголосити, що в останні кілька років спостерігається значне почастішання інформаційних атак, переважна частина яких спрямована саме на загальнодоступні ресурси, до яких належать і Web-портали. Атаки порушників можуть мати на меті порушення конфіденційності, цілісності чи доступності інформаційних ресурсів, що зберігаються на серверах Web-порталу.
Для захисту Web-порталу найдоцільніше застосовувати комплексний підхід, що поєднує організаційні і технічні засоби захисту. Організаційні засоби захисту пов’язані з розробленням і впровадженням нормативно-правових документів, таких як політика і концепція забезпечення інформаційної безпеки Web-порталу, посадові інструкції з роботи персоналу з автоматизованою системою порталу тощо. Технічні засоби захисту реалізуються за допомогою відповідних програмних, апаратних або програмно-апаратних засобів, які забезпечують виконання цілей і завдань, визначених у відповідних нормативно-правових документах. Використання комплексного підходу передбачає об’єднання технічних засобів захисту Web-порталу в інтегрований комплекс, що охоплює підсистеми антивірусного захисту, контролю цілісності, розмежування доступу, виявлення вторгнень, аналізу захищеності, криптографічного захисту інформації, а також підсистему управління захистом.
Концепція Web-сервісу. Концепція веб-сервісів винипкла після кількох не зовсім удалих спроб груп аналітиків, архітекторів і розробників у всьому світі створити середовище і механізм взаємодії того багатоманіття інформаційних систем, які вони ж, ці групи аналітиків, архітекторів і розробників, створили. Сучасне комерційне підприємство важко уявити без інформаційних систем різного призначення: бухгалтерських, фінансово-аналітичних, виробничих, складських тощо. Велике підприємство використовує великі багатофункціональні інформаційні системи (можна згадати абревіатури ERP, CRM, SCM та ін), часто
порталу спочатку здійснюється спроба витягування ресурсу з пам’яті кешсерверів, і лише якщо ресурс там відсутній, тоді запит передається публічним Web-серверам. Використання кеш-серверів дає змогу зменшити навантаження на основні публічні сервери, а також скоротити час доступу користувачів до кешованих ресурсів;
Проте еволюція WWW не зупинилася на Web-додатках. Взаємна інтеграція бізнесів різних компаній, що відбувається зараз у всьому світі, неминуче тягне за собою появу технологій і стандартів для інтеграції додатків, що їх обслуговують і корпоративних інформаційних систем. З’явився сервіс-орієнтований Web, в основу якого накладено дві відносно нові технології — SOAP та XML. Згідно з цим сценарієм Web складається з набору серверів додатків, які обмінюються інформацією у форматі XML за протоколом SOAP.
Підгрунтям сервіс-орієнтованого Web є Web-сервіс — набір логічно пов’язаних функцій, які можна програмно викликати через Internet. Інформація про те, які функції надає цей Web-сервіс, міститься в документі WSDL, а для пошуку наявних Web-сервісів передбачається використання спеціальних реєстрів, сумісних зі специфікацією UDDI.
Назвемо сервісом (service) ресурс, який реалізує бізнес-функцію з такими властивостями:
— є повторно використовуваним;
— має один чи кілька явних технологічно незалежних інтерфейсів;
— може бути викликаний за допомогою комунікаційних протоколів, що забезпечують можливість взаємодії ресурсів між собою.
Таким чином, з функціональної точки зору бізнес-додаток зрештою розпадається на сукупність сервісів, що взаємодіють між собою. Цю сукупність сервісів, що згідно з деякими загальними правилами мають певні інтерфейси і механізми взаємодії, називають сервісно-орієнтованою архітектурою (Service Orien-ted Architechture, SOA). Будь-який програмний додаток з функціональної точки зору може бути поданий сукупністю функцій, а ресурс, який реалізує функцію, це сервіс. Таким чином, для подання та реалізації будь-якої програми в рамках SOA потрібна певна декомпозиція її до рівня окремих функцій.
Сервіси функціонують незалежно від інших інформаційних систем і є функціонально самостійними об’єктами. Вони являють собою «чорні скриньки» для будь-яких зовнішніх додатків: зовнішні програми не знають, як сервіс формує з вхідних даних вихідні. Усе, що їм відомо, — це те, що необхідно подати на вхід сервісу і чого слід очікувати на його виході.
одразу кілька. А є ще постачальники, клієнти, партнери, в яких свої, не менш складні й специфічні інформаційні системи, і з цими інформаційними системами підприємству необхідно взаємодіяти. Як організувати цю взаємодію, щоб створити продуктивні, надійні та безпечні автоматизовані корпоративні ланцюжки саме тих бізнес-процесів, інтеграція яких необхідна підприємству для здійснення своїх бізнес-функцій? Саме у сфері інтеграції корпоративних додатків (англ. Enterprise Application Integration, EAI) лежить переважна маса IT-проблем сучасних підприємств, саме на досягнення взаємодії різнорідних інформаційних систем ладні кинути свої основні ресурси СЕО і СІО, і саме тут найефективнішим інструментом будуть веб-сервіси. Упродовж останніх кількох років World Wide Web зазнає якісних змін. Якщо зовсім нещодавно «всесвітня павутина» являла собою головним чином сукупність серверів, що містять статичні документи з посиланнями один на одного, то сучасний Web практично неможливо уявити без інтерактивних Web-додатків, що обробляють різні запити і поміщають результат обробки цих запитів як у бази даних, так і на динамічно згенеровані Інтернет-сторінки.
Власне Web-сервіси —це новий різновид веб-додатків для створення рівня бізнес-логіки й зв’язку різнорідних додатків шляхом використання загальних стандартів. Завдяки Web-сервісам функції будь-якої прикладної програми стають доступними через Інтернет. Web-сервіси реалізуються на загальних принципах:
— розробник конкретного Web-сервісу визначає формат запитів до нього і формат відповідей на ці запити;
— з будь-якого комп’ютера в Інтернеті можна зробити запит до обраного Web-сервісу;
— Web-сервіс виконує задану послідовність дій і відправляє назад результат.
Таким чином, усі Web-сервіси базуються на застосуванні відкритих, ухвалюваних консорціумом ІТ-спільноти стандартів і протоколів, ключовими з яких є такі:
• SOAP (Simple Object Access Protocol) — протокол доступу до простих об’єктів тобто механізм передання інформації між об’єктами на базі протоколу HTTP і деяких інших Internet-протоколів;
• WSDL (Web Services Description Language) — мова опису Web-сервісів;
• UDDI (Universal Description, Discovery and Integration)
— універсальний опис, виявлення й інтеграція, спрощено — протокол пошуку ресурсів в Інтернеті.
Схему взаємодії стандартів унаочнено на рис. 11.2.
Рис. 11.2. Схема взаємодії відкритих стандартів
Сервери додатків є сховищами Web-сервісів і роблять їх доступними через протоколи HTTP GET, HTTP POST і HTTP SOAP.
Наявні Web-сервіси описуються в WSDL-документах, які розташовані або на сервері додатків, або у спеціальних XML-сховищах. WSDL-документ можна надсилати на інші WSDL-документи та документи XSD (XML Schema), в яких описані типи даних, використовувані Web-сервісами. XML-сховища використовують для управління WSDL-документами. Усередині WSDL-документа є адреса (URL) Web-сервісу. Web-сервіси описані та проіндексовані в бізнес-реєстрі, що містить адреси (URL) WSDL-документів.
Розглянемо детальніше три основні Web-стандарти, на яких базуються Web-сервіси SOAP, WSDL і UDDI.
Рис. 11.3. Схема SOAP-запиту
Рис. 11.4. Схема SOAP- відповіді
Специфікація SOAP визначає формат кодування, який, своєю чергою, задає спосіб подання даних у XML-форматі.
SOAP — Simple Object Access Protocol SOAP — це стандарт для відсилання й отримання повідомлень по Internet. Цей протокол був запропонований фірмою Microsoft як засіб для віддаленого виклику процедур (RPC, Remote Procedure Call) за протоколом HTTP, а специфікація SOAP 1.0 (Userland, Microsoft, Developmentor) була тісно пов’язана з Component Object Model. Фірма IBM та низка інших компаній, у тому числі Lotus, зробили певний внесок у розвиток цього протоколу, і його стандарт був переданий на розгляд комітетом W3C. Специфікація SОАP визначає XML-«конвepт» для передавання повідомлень, метод для кодування програмних структур даних у форматі XML, а також засоби зв’язку за протоколом HTTP. SOAP-повідомлення бувають двох типів: запит (Request) і відповідь (Responsе). Запит викликає метод віддаленого об’єкта, відповідь повертає результат виконання цього методу. Далі наведено приклади запиту і відповіді у форматі SOAP, (рис. 11.3 і 11.4).
Однією з перших реалізацій протоколу SOAP була Java-версія, створена фірмою Developmentor. Компанія IBM випустила власну Java-версію, відому під назвою IBM SOAP4J, доступну на Web-сайті alphaWorks. Згодом ця версія була інтегрована в проект Apache XML. Нині вона має назву Apache SOAP 2.0 і працює під управлінням Apache Tomcat, IBM WebSphere Application Server та інших серверів, що підтримують сервлети. Версія Microsoft, відома під назвою SOAP Toolkit, дозволяє використовувати Visual Basic. Повніший список відомих реалізацій протоколу SOAP можна знайти на Web-сайті SOAP WebServices Resource Center, а список доступних SOAP Web-сервісів — на Web-сайті SOAP Web Services. WSDL — Web Services Description Language
Щоб програми могли використовувати Web-сервіси, програмні інтерфейси останніх мають бути детально описані; в цьому аспекті мова WSDL відіграє ту саму роль, що й мова Interface Definition Language (IDL) у розподілених обчисленнях. Опис може включати таку інформацію, як протокол, адреса сервера, номер використовуваного порту, список доступних операцій, формат запиту та відповіді тощо.
Для опису цієї інформації було запропоновано кілька мов. Однією з них була мова Service Description Language (SDL), розроблена Microsoft, що входила у першу версію Microsoft SOAP Toolkit. Компанія IBM переробила специфікацію і, використавши специфікацію Network Accessible Service Specification Language (NASSL), випустила NASSL Toolkit як частину SOAP4J. Ідеї, реалізовані в NASSL, вплинули на специфікацію мови SOAP Contract Language (SCL), запропоновану Microsoft. Нині обидві специфікації (NASSL і SDL / SCL), а також пропозиції інших фірм враховані в специфікації мови WSDL (рис. 11.5). Для опису бізнес-логіки IBM і Microsoft працюють над специфікацією мови Web Services Flow Language (WSFL).
Рис. 11.5. Приклад опису сервісів мовою WSDL
Отже, опис сервісів являє собою XML-документ, що складається з кількох елементів, у тому числі з опису простору імен (namespace), опису типів і елементів, повідомлень, порту, а також можливих операцій — запитів і відповідей. Файл, що містить опис сервісів, є вельми комплексним документом, тому для його створення за можливістю слід користуватися автоматичними генераторами, включеними до складу засобів розробки.
Опис мови WSDL можна знайти на Web-сайті компанії Microsoft за адресою [38]. UDDI — Universal Description, Discovery and Integration
Завдання UDDI — надати механізм для виявлення Web-сервісів. UDDI задає бізнес-реєстр, в якому провайдери Web-сервісів можуть реєструвати сервіси, а розробники — шукати необхідні їм сервіси. Компанії IBM, Microsoft і Ariba створили власні UDDI- реєстри (невдовзі ці реєстри будуть об’єднані у Web-реєстр), в одному з яких розробники можуть зареєструвати свої Web-сервіси, після чого дані будуть автоматично реплікувати в інші реєстри (рис. 11.6).
Рис. 11.6. Схема UDDI-бізнес реєстра UDDI базується на елементах чотирьох типів: Business Entity, Business Service, Binding Template і Technology Model, Елемент Business Entity описує індустрію, яка надає даний Web-сервіс. Цей елемент може включати описи категорій для даної індустрії, що полегшують більш детальний пошук сервісів. Business Service — це клас сервісів у рамках певної галузі промисловості або послуг. Кожна галузь належить певному елементу Business Entity.
Разом Binding Template і Technology Model визначають Web-сервіс. Technology Model містить абстрактний опис, a Binding Template — конкретну специфікацію сервісу. Кожен елемент Binding Template належить певному елементу Business Service, але кілька елементів Binding Template можуть посилатися на один елемент Technology Model. Бізнес-реєстр UDDI сам є SOAP Web-сервісом. Він підтримує операції створення, модифікації, видалення та пошуку елементів усіх чотирьох розглянутих вище типів.
Повний опис UDDI можна знайти на Web-сайті за адресою [39].
Треба визнати, що ці речі реально показують простоту реалізації двох варіантів додатків типу Web.Services. За допомогою механізмів WebClass і DHTML у тому ж Visual Basic 6.0 подібні завдання вирішувалися довше і складніше. Але потрібно наголосити, що це не пов’язано із застосуванням нових протоколів —
Рис. 11.7. Код функції, використовуваної при створенні Web.Services
Створіть додаток за допомогою команди Build.Все! Тепер можна звертатися до створеної нами функції зі звичайного браузера, передаючи різні вихідні дані (у нашому випадку ticket — команду про необхідність покупки чи продажу акцій) і одержувати відповідну відповідь.
