Как происходит разработка приложений с помощью corba
CORBA (Common Object Request Broker Architecture, Common Object Request Broker Architecture) - это стандартная объектно-ориентированная спецификация прикладной системы, сформулированная организацией OMG. Другими словами, архитектура CORBA - это решение, предложенное OMG для решения проблемы взаимосвязи аппаратных и программных систем в среде распределенной обработки (DCE).
OMG: Object Management Group, организация управления объектами. Это международная некоммерческая ассоциация по стандартам в области компьютерной индустрии с открытым членством, созданная в 1989 году. Ее обязанность заключается в предоставлении общедоступной основы для разработки приложений, формулировании отраслевых руководящих принципов и спецификаций управления объектами и ускорении разработки объектных технологий. , , Любая организация может присоединиться к OMG и принять участие в процессе установления стандартов. OMG разработала унифицированный язык моделирования Unified Modeling Language ™ (UML®), модель управляемой архитектуры Model Driven Architecture® (MDA®) и другие стандарты моделирования. Сделайте возможным визуальное проектирование, выполнение и обслуживание программного обеспечения и других процессов. Кроме того, OMG разработала хорошо известный стандарт промежуточного программного обеспечения Common Object Request Broker Architecture (CORBA®).
CORBA (Common Object Request Broker Architecture) - это решение, определенное OMG для реализации взаимодействия между большим количеством аппаратного и программного обеспечения.CORBA также является важным шагом на пути к объектно-ориентированной стандартизации и функциональной совместимости.
Проще говоря, CORBA позволяет приложениям взаимодействовать друг с другом независимо от того, где они существуют и кто их разработал, то есть кросс-платформенный и кросс-языковой. CORBA1.1 был выпущен OMG в 1991 году, в котором был определен язык определения интерфейса (IDL) и интерфейс прикладного программирования (API) в посреднике объектных запросов (ORB) для реализации взаимодействия между объектами клиента и объектами сервера. CORBA2.0 был выпущен в 1994 году и предусматривал правила связи ORB между различными поставщиками.
Стандарт CORBA в основном разделен на три части: Язык определения интерфейса (IDL), посредник объектных запросов (ORB) и протокол взаимодействия IIOP между ORB.
IDL - это язык, определенный в CORBA. CORBA также определяет отображение IDL на различные языки. Стандартными являются Ada, C, C ++, Smalltalk, Java и Python. Благодаря этим сопоставлениям IDL может быть переведен на разные языки, что позволяет достичь межъязыкового языка. Язык IDL является языком определения интерфейса. Язык IDL отличается от всех существующих языков программирования, это описательный язык, то есть описываемый им интерфейс не может быть напрямую скомпилирован и выполнен. Язык OMG IDL использует набор символов ISOLatin-1 (8859.1). Набор символов можно разделить на буквы, цифры, графические символы, пробелы и символы формата. Буквы включают 26 заглавных букв на английском языке, а цифры включают 10 арабских цифр 0-9.
ORB является ядром CORBA, Является промежуточным программным обеспечением, которое устанавливает отношения клиент / сервер между объектами. Используя ORB, клиент может прозрачно вызывать метод для объекта службы, который может быть локальным или на других компьютерах, подключенных через сеть. ORB перехватывает этот вызов и отвечает за поиск объекта, реализующего сервис, передачу ему параметров и вызов метода для возврата окончательного результата. Клиент не знает, где находится объект службы, каковы его язык программирования и операционная система, и он не знает других частей системы, которые не являются частью интерфейса объекта. Таким образом, ORB обеспечивает совместимость приложений на разных машинах в гетерогенной среде распространения и легко интегрирует несколько объектных систем.
Основная структура CORBAСледующим образом:
При вызове кода на стороне сервера со стороны клиента ORB невидим для стороны клиента.Клиент чувствует, что вызывается метод его собственного объекта, но процесс передачи по сети инкапсулирован в ORB.
Небольшие примеры, разработанные с использованием CORBA
Если вы хотите разработать CORBA Helloworld, в основном есть следующие шаги:
1. Используйте язык idl для разработки файла idl, этот файл описывает определение интерфейса
модуль: соответствует пакету в Java
interface: соответствует интерфейсу в Java, HelloWorld - имя интерфейса
sayHello: Соответствует методу объявления интерфейса в Java
строка: соответствует возвращаемому значению метода в Java
2. Используйте команду idlj в Java, чтобы перевести язык idl на язык Java и сгенерировать код Java.
Скопируйте файл idl в% JAVA_HOME% \ bin, а затем переключитесь в каталог bin в командной строке, чтобы выполнить:
idlj: собственный инструмент Java
-fall: генерировать код сервера и клиента или генерировать сервер или клиент отдельно
helloworld.idl: файл idl, созданный ранее
В это время папка helloworld будет создана в каталоге bin, в ней будет 6 файлов, скопируйте эти 6 обратно в проект eclipse. Примечание. Имя пакета в файле - это helloworld of life в idl. Как показано ниже:
В настоящее время _HelloWorldStub.java, HelloWorld.java, HelloWorldHelper.java, HelloWorldHolder.java, HelloWorldOperations.java - это код, требуемый клиентом; HelloWorld.java, HelloWorldOperations.java, HelloWorldPOA.java - это код, требуемый сервером.
Кратко рассмотрим эти автоматически сгенерированные файлы:
HelloWorld.java, точно такое же, как имя интерфейса в idl, но на самом деле это просто интерфейс идентификации без какой-либо реализации
HelloWorldOperations.java , Интерфейс объявлен в idl _HelloWorldStub.java , HelloWorldHelper.java, HelloWorldHolder.java - это класс свай и инструментов клиента; HelloWorldPOA.java - это класс сервера, который реализует интерфейс (возможно, это означает, что я его не понимаю). Глядя на головокружение, я не буду его публиковать.
3. Разработайте серверный код
Теперь, когда определение интерфейса было разработано и переведено в код Java, реализация интерфейса должна быть написана. Реализация на стороне сервера и должна быть унаследована от HelloWorldPOA
Код запуска сервера, основная функция этого кода - зарегистрировать реализацию интерфейса в ORB и запустить мониторинг, ожидая вызова клиента. 4. Разработка клиентского кода
Внедрение сервера и мониторинг сервиса завершены. Теперь нам нужно написать клиент для вызова метода сервера
Мы можем видеть, что экземпляр ORB был создан на сервере и клиенте. В настоящее время, поскольку и сервер, и клиент должны иметь поддержку связи (см. Базовую структурную диаграмму CORBA выше).
5. Запустите сервис orbd
Одного создания кода сервера и клиента недостаточно для запуска HelloWorld, вам также нужно запустить службу orbd, эта служба находится в папке% JAVA_HOME% \ jre \ bin. orbd содержит службы автоматического запуска, службы прозрачного именования, службы постоянного именования и фоновую обработку для менеджеров имен. Должно быть так, что вышеупомянутый HelloWorld использует nameService, поэтому этот сервис необходим. Разве нет необходимости использовать другие методы для получения экземпляра сервера, или все CORBA должны взаимодействовать с этим сервисом, не понимаете?
Введите orbd для запуска в командной строке:
6. Запустите службу сервера
7. Запустите клиент
Вы можете увидеть вывод:
Сейчас CORBA используется редко, в основном только некоторые крупные телекоммуникационные проекты все еще используются, и теперь WebService более популярен среди аналогичных решений.
CORBA (Common Object Request Broker Architecture – общая архитектура брокера объектных запросов) – это технологический стандарт написания распределённых приложений, продвигаемый консорциумом OMG (Object Management Group – группа управления объектами) и соответствующая ему информационная технология.
Технология CORBA является механизмом для интеграции изолированных информационных систем, который даёт возможность программам, написанным на разных языках программирования и работающим на разных узлах сети, взаимодействовать друг с другом, так как если бы они находились в адресном пространстве одного процесса.
1 Ключевые понятия технологии CORBA
1.1 Объекты по значению
Помимо удалённых объектов в CORBA 3.0 определено понятие объект по значению. Код методов таких объектов по умолчанию выполняется локально. Если объект по значению был получен с удалённой стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base – список URL, откуда может быть загружен код.
У объекта по значению могут также быть и удалённые методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь также могут быть такими объектами, формируя таким образом списки, деревья или произвольные графы. Объекты по значению могут иметь иерархию классов, включая абстрактные и множественное наследование.
1.2 Компонентная модель CORBA (CCM)
Компонентная модель CORBA (CCM) — дополнение к семейству определений CORBA.
CCM была введена, начиная с CORBA 3.0, и описывает стандартный каркас приложения для компонент CORBA. CCM построена под сильным влиянием Enterprise JavaBeans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы порты.
Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности (способности объекта существовать дольше процесса, создавшего его) и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.
1.3 Общий протокол межброкерного взаимодействия (GIOP)
GIOP – абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность (способность к взаимодействию) брокеров. Стандарты, связанные с протоколом выпускает Object Management Group (OMG). Архитектура GIOP включает несколько конкретных протоколов:
1.4 Ссылка на объект (Corba Location)
1.5 Список брокеров (CORBA ORBs)
- Borland Enterprise Server, VisiBroker Ed — CORBA 2.6-совместимый коммерческий ORB от Borland, поддерживает Java и C++.
- MICO — свободный (LGPL – GNU Lesser General Public License – Стандартная общественная лицензия ограниченного применения GNU) ORB с поддержкой C++.
- omniORB — свободный (LGPL) ORB для C++ и Python.
- ORBit2 — свободный (LGPL) ORB для C, C++ и Python.
- JacORB — свободный (LGPL) ORB, написан на Java.
- TAO — The ACE (англ. Adaptive Communication Enviroment – адаптивная коммуникационная среда) ORB, открытый ORB для C++.
- Orbacus — коммерческий ORB для C++, Java от IONA Technologies.
- Orbix — коммерческий ORB от IONA Technologies.
- PolyORB — ORB от AdaCore для языка программирования Ada. Есть как свободная, так и коммерческая версии.
2 Создание распределённого приложения на базе CORBA
Процесс разработки распределенного приложения на языке Java с использованием технологии CORBA включает в себя следующие шаги:
3 Пример простого приложения клиент-сервер
Ниже приведена последовательность действий по разработке клиент-серверного приложения, в котором сервер предоставляет возможность клиенту вывести на экран текстовую строку «Hello, World!» и завершить работу ORB.
3.1 Создание интерфейса на языке IDL
IDL – декларативный язык для формального описания интерфейсов взаимодействия клиентов и серверов в распределенных приложениях. IDL не привязан к какому-либо языку программирования, но для большинства современных языков программирования существуют спецификации, определяющие правила трансляции конструкций IDL в конструкции этих языков.
Ниже приведен пример описания интерфейса для приложения Hello (в файле Hello.idl каталога приложения).
Конструкция interface определяет программный интерфейс, с помощью которого объекты общаются друг с другом. В этом интерфейсы языков IDL и Java аналогичны.
В теле конструкции interface объявляются операции, которые должен быть способен выполнять сервер по запросу клиента. Операции языка IDL соответствуют методам языка Java.
В результате компиляции будет создан пакет с именем HelloApp (имя из конструкции module) в каталоге Hello , содержащий 6 файлов: Hello.java, HelloPOA.java, _HelloStub.java, HelloOperations.java, HelloHelper.java, HelloHolder.java .
3.2 Создание серверной части приложения
Серверная часть приложения состоит из двух классов: собственно сервера и серванта ( servant ). Сервант (назовем его HelloImpl ) реализует IDL-интерфейс Hello , при этом каждая сущность IDL-интерфейса Hello реализуется сущностью класса HelloImpl. Сервант является подклассом класса HelloPOA , описание которого сгенерировано компилятором idlj .
Ниже представлен пример кода (в файле HelloServer.java каталога Hello ) серверной части приложения.
Далее следуют пояснения отдельных строк кода.
ORB orb = ORB.init(par, null);
Любому серверу CORBA необходим локальный объект ORB. Каждый сервер создает экземпляр ORB и регистрирует в нем свои объекты-серванты, дабы ORB мог найти объекты при получении соответствующих запросов.
org.omg.CORBA.Object objRef = rb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
3.3 Создание клиентской части приложения
Клиент объекта имеет доступ к объектной ссылке и вызывает операции объекта. Клиент знает только логическую структуру объекта в соответствии с его интерфейсом и может наблюдать за поведением объекта через вызовы методов.
Ниже представлен пример кода (в файле HelloClient.java каталога Hell o) клиентской части приложения.
Прежде чем запустить на выполнение сервер, и затем клиент распределённого приложения, необходимо запустить сервис именования командой orbd из набора jdk 7 (в нашем случае был использован jdk1.7.0_09) с параметрами порта и хоста.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
- Сочетаемость приложений, ориентированных на пользователей.
- Многократное использование бизнес-сервисов.
- Независимость от набора технологий.
- Автономность (независимые эволюция, масштабируемость и развёртываемость).
SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
Общая архитектура брокера объектных запросов (CORBA)
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
- Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
- Транзакции (в том числе удалённые!).
- Безопасность.
- События.
- Независимость от выбора языка программирования.
- Независимость от выбора ОС.
- Независимость от выбора оборудования.
- Независимость от особенностей передачи данных/связи.
- Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Принцип работы
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
Достоинства
- Независимость от выбранных технологий (не считая реализации ORB).
- Независимость от особенностей передачи данных/связи.
Недостатки
Веб-сервисы
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
— Microsoft 2004, Understanding Service-Oriented Architecture
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
— Microsoft 2004, Understanding Service-Oriented Architecture
Достоинства
Недостатки
Запрос/Ответ
Все эти паттерны можно отнести к либо к pull- (polling), либо к push-подходу:
Достоинства
Недостатки
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.
Достоинства
Недостатки
- Ниже скорость связи, особенно между уже совместимыми сервисами.
- Централизованная логика:
- Единая точка отказа, способная обрушить системы связи всей компании.
- Большая сложность конфигурирования и поддержки.
- Со временем можно прийти к хранению в ESB бизнес-правил.
- Шина так сложна, что для её управления вам потребуется целая команда.
- Высокая зависимость сервисов от ESB.
Микросервисы
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений, чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат», и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту — уменьшению потребности в интеграции.
[Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
— Sam Newman 2015, Principles Of MicroservicesГлавным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры. Это:
- Проектирование сервисов вокруг бизнес-доменов
Это может дать нам стабильные интерфейсы, высокосвязные и мало зависящие друг от друга модули кода, а также чётко определённые разграниченные контексты. - Культура автоматизации
Это даст нам гораздо больше свободы, мы сможем развернуть больше модулей. - Скрытие подробностей реализации
Это позволяет сервисам развиваться независимо друг от друга. - Полная децентрализация
Децентрализуйте принятие решений и архитектурные концепции, предоставьте командам автономность, чтобы компания сама превратилась в сложную адаптивную систему, способную быстро приспосабливаться к переменам. - Независимое развёртывание
Можно развёртывать новую версию сервиса, не меняя ничего другого. - Сначала потребитель
Сервис должен быть простым в использовании, в том числе другими сервисами. - Изолирование сбоев
Если один сервис падает, другие продолжают работать, это делает всю систему устойчивой к сбоям. - Удобство мониторинга
В системе много компонентов, поэтому трудно уследить за всем, что в ней происходит. Нам нужны сложные инструменты мониторинга, позволяющие заглянуть в каждый уголок системы и отследить любую цепочку событий.
![]()
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
— Martin Fowler 2014, MicroservicesДостоинства
Недостатки
- Высокая сложность эксплуатации:
- Нужно много вложить в сильную DevOps-культуру.
- Использование многочисленных технологий и библиотек может выйти из-под контроля.
- Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
- Использование «согласованности в конечном счёте» (eventual consistency) может привести к серьёзным последствиям, которые нужно учитывать при разработке приложения, от бэкенда до UX.
- Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.
Антипаттерн: архитектура равиоли (Ravioli Architecture)
![]()
Архитектурой равиоли обычно называют антипаттерн микросервисной архитектуры. Равиоли получаются, если микросервисов слишком много, они слишком мелкие и не отражают доменных концепций.
Заключение
В последние десятилетия SOA сильно эволюционировала. Благодаря неэффективности прежних решений и развитию технологий сегодня мы пришли к микросервисной архитектуре.
Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.
Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развёртывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.
![]()
Повторюсь, что всё дело в слабой взаимозависимости и высокой связности, причём размер компонентов должен быть больше прежнего. Необходимо прагматично оценить свои потребности: используйте SOA, лишь когда это необходимо, поскольку она сильно увеличивает сложность. И если на самом деле вы можете обойтись без SOA, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.
Создание CORBA-приложений
Cоздадим ни много ни мало. систему сотовой связи! Не нужно вздрагивать, конечно же, это будут отдельные весьма упрощенные фрагменты системы с небольшой степенью детализации. Более того, не имея представления о том, как в действительности работает сотовая связь, очень надеемся, что специалисты в области телекоммуникаций не будут судить нас строго — это всего лишь пример. Просто разработаем свой стандарт, особенностью которого будет то, что все в системе, включая мобильные телефоны и радиостанции-»соты», работает на основе CORBA, т. е. «прошитое» программное обеспечение этих устройств превращает заурядные приемопередатчики в незаурядные объекты CORBA. Само собой разумеется, обмен данными между всей аппаратурой происходит по принятому в CORBA протоколу IIOP с использованием радиоканала. Оно и удобно, ведь по сути своей «хозяйство» провайдера услуг сотовой связи — это огромная компьютерная сеть, в которой есть центральный сервер (административная консоль и хранилище различных данных), маршрутизаторы («соты») и клиентские терминалы (телефоны).
Функционирует система следующим образом (рис. 11). Администратор запускает приложение системной консоли, производящее внутреннюю инициализацию и устанавливающее параметры сотовых станций. Система настраивает имена «сот», с которыми работает администратор, и разрешает им начать обслуживание клиентов. С этого момента система позволяет абонентам звонить, получать счета и проводить удаленную оплату, а администратор получает в свое распоряжение консоль, с помощью которой он управляет работой всего оборудования. На рис. 12 показана совокупность функций, которые администратор выполняет с помощью консольного интерфейса.
Сотовые станции проделывают в нашем проекте много полезной работы. Они включаются независимо от системы, но начинают выполнять свои функции только после того, как придет соответствующая команда. До этого же момента они находятся в ждущем режиме. Множество функций сотовой станции изображено на рис. 13.
Сотовые телефоны в нашей системе — не самые интеллектуальные устройства. Их задача сводится, по сути дела, к непрерывному излучению радиосигналов: сигналов с передаваемыми и принимаемыми данными либо тестового сигнала, которым телефон проверяет канал связи: вышел ли он из зоны приема. Ну и конечно же, телефон служит пультом для ввода телефонных номеров других абонентов. Полный набор функций вы можете увидеть на рис. 14.
Следует отметить, что и сотовая станция и телефон имеют уникальные 64-битовые целочисленные идентификаторы, представленные IDL-типом unsigned long long. Будем считать, что это номер, жестко «прошиваемый» производителем оборудования.
Осталось описать еще две подсистемы: финансовую и получения счетов. Первую используют для учета платежей за предоставляемые услуги, и она довольно тривиальна — система ищет объект для удаленного платежа, предоставляемый банком, и отдает через него команду на пересылку денег. Вторая подсистема опять-таки работает на пользователя. По его запросу формируется большой сводный счет, который либо пересылается на факс пользователя, либо распечатывается и отсылается письмом по обычной почте.
Сотовая станция
При включении сотовой станции (имеется в виду аппаратное включение питания) происходит внутреннее тестирование компьютерного микроконтроллера, который управляет работой «соты», затем инициализируется брокер объектных запросов и запускается сервер CORBA, создающий объект «соты» типа Cell. С этого момента объект начинает отслеживать общедоступный канал (в простейшем случае это может быть сетевой сокет с определенным номером), пытаясь обнаружить подключающиеся телефоны, посылающие тестовые сигналы. Но даже если абоненты и будут найдены до получения разрешающего сигнала от центральной системы, сотовая станция сыграет роль лишь пассивного наблюдателя. Более того, в любой момент «сота» может быть перезапущена.
Телефоны
Система
После включения центрального сервера системы и его тестирования главный объект CellularSystem последовательно выбирает из базы данных, управляемой объектом DataStorage, уникальные имена сотовых станций и находит по ним ссылки на объекты «сот». Найденные ссылки привязываются к именам. На завершающем этапе всем станциям рассылается разрешение на обслуживание абонентов. После этого станции периодически посылают системе сигнал, показывая, что они работают нормально.
Функционирование системы
Возможно, принцип функционирования системы уже ясен. Кратко опишем его, приводя в скобках предполагаемые имена операций и атрибутов на языке IDL.
Голосовой звонок одного абонента другому — самый сложный случай. Пользователь набирает номер (Phone::dialNumber), и если это не телефон сервисной службы, то он передается «соте» (Cell::callNumber), которая спрашивает у центральной системы ссылку на «соту», где в текущий момент находится вызываемый телефон (CellularSystem::findClient). Центральная система определяет ссылку, исходя из данных в хранилище (DataStorage:: recallClientPlace). Дальнейшее служит предметом более детального рассмотрения, и мы займемся этим на следующем занятии.
В листинге, приведенном на сервере, вы найдете черновик IDL-описаний частей системы. Не следует воспринимать его слишком серьезно — впоследствии все описания претерпят массу изменений.
Читайте также:
