Главная  Новые телекоммуникационные услуги 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [ 146 ] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

Следует отметить, что в отличие от миграции, которая может начаться очень скоро, взаимодействие понадобится только тогда, когда будут реализованы первые сети TINA. Сегодня трудно предсказать, через какой интерфейс будет осуществляться это взаимодействие, ибо это будет зависеть также от дальнейшего развития IN. Таким образом, выбор конкретных сценариев, имеющих хороший шанс воплотиться на практике, вряд ли можно считать сделанным. Именно поэтому в данном параграфе названы два сценария взаимодействия: один на уровне INAP, а другой на уровне ISUP.

5.6.6 Интеграция ОКС-7 и CORBA

На рисунке 5.6.12 представлена общая схема взаимодействия систем IN и TINA. Структура и функционирование блоков адаптации AU и сопряжения IWU в обеих системах будет сильно зависеть от конкретных реализаций IN и TINA в соответствующих сетях. Однако общее для всех блоков адаптации и сопряжения состоит в необходимости преобразования операций INAP ОКС-7 в вызовы объектов, размещённых в DPE. В TINA среда DPE базируется на архитектуре CORBA. Следовательно, нужен «шлюз», способный конвертировать INAP ОКС-7 в CORBA и обратно.



Функции шлюза:

• Позволяетустанавливатьсвязь между объектами IN и серверами CORBA

• Ддаптируетоперации INAP ОКС-7 к запросам шины ORB

Беспроводный доступ

/традиционнаяЧ lonu i ШирокополосньиЧ

>ч телефония j \ """" доступ j


Рис. 5.6.12 Схема взаимодействия IN и TINA



Существенными при этом являются несколько важных требований, которые должны быть выполнены до того, как продукты CORBA можно будет использовать в сетях связи. Таковы, например, фундаментальное требование обеспечить режим реального времени, атакже требования высокой надежности и отказоустойчивости. Именно на решение этих проблем нацелен документ IN/CORBA White Paper, разрабатываемый в настоящее время в рамках Рабочей группы по управлению объектами (OMG) в области электросвязи, а также упоминавшийся выше проект EURESCOM Р508, в котором даны два прикладных сценария интеграции ОКС-7 и CORBA.

Принцип связывания операций в TINA сильно зависит от принципов процедурных вызовов, определенных OMG. На момент написания книги существовала всего одна (также определенная OMG) спецификация общего протокола связи между узлами DPE (GlOP), а именно - протокол МОР (Internet inter ORB protocol) взаимодействия между ORB-компонентами в архитектуре CORBA, версия 2.0.

Как известно, по ряду причин сеть Internet не может обеспечить гарантированное качество обслуживания ни в части потерь пакетов данных, ни в части их задержки. Поэтому до момента введения новых протоколов (некоторые из них находятся в стадии апробации, например IPv6 и RSVP) во все узлы сети Internet протокол МОР целесообразно использовать лишь внутри одного или нескольких доменов, в которых оператор IP-сети может гарантировать качество обслуживания, требуемое для поддержки услуг в сетях общего пользования. С другой стороны, при введении объектов CORBA в инфраструктуру телефонных сетей возникает естественное желание использовать возможности сетей ОКС-7 в качестве транспортной среды для распределенной шины ORB.

Сети, построенные с применением системы сигнализации ОКС-7, широко распространены и обеспечивают необходимое качество обслуживания, в связи с чем производители телекоммуникационного оборудования ведут работы по использованию ОКС-7 как ESIOP для переноса сообщений протокола GlOP. Для сопряжения ТСАР ОКС-7 и CORBA требуется преобразование протокола ROSE, который используется подсистемой ТСАР, в язык определения интерфейсов IDL группы OMG и наоборот. Структура шлюза, осуществляющего такое преобразование протоколов, представлена на рисунке 5.6.13.

Одно из решений может заключаться в том, что первоначальные запросы от любого объекта CORBA направляются к объекту-посреднику с интерфейсом IDL в брокере объектных запросов (ORB) клиента. Этот объект имеет открытые прикладные программные интерфейсы API и отвечает за преобразование запроса в форму, понятную серверу ORB. Такая стратегия не очень эффективна, поскольку



запросы должны сперва передаваться к объекту-посреднику, и только потом - к другой стороне соединения. Вместе с тем, её легко реализовать, причем не требуется участие поставщиков ORB. Поэтому данную стратегию имеет смысл применять во всех случаях, когда производительность не является главным критерием. Соответствующие функциональные возможности реализуются в приложении нижнего (распределённого) уровня, в котором на одной стороне (на стороне сети сигнализации) обеспечивается интерфейс ОКС-7, а на другой (на стороне CORBA) - интерфейс IDLAPI с приложениями.

Реализация SSP на основе ТСАР

Межсетевой шлюз

Реализация SCP на основе CORBA

Объекты ROSE

Блоки данных 1МАРДСАР


СетьОКС-7

Функции сопряжения

ТСАР

SCCP

Объекты

CORBA

о о

Операции ODL/IDL

Сеть IP

Рис. 5.6.13 Структура межсетевого шлюза OKC-7/CORBA

В связи с отсутствием достойной альтернативы ОКС-7 можеттак-же использоваться и для соединения узлов CORBA DPE внутри TINA-сети. Имеется возможность реализовать на прикладном уровне ОКС-7 общий протокол GIOP или, если необходимо, разработать новый протокол, ориентированный на конкретную среду (ESIOP - Environment specific inter ORB protocol).

В качестве ESIOP можно использовать стек MTP/SCCP (GIOP «поверх» SCCP) или стек МТР/ЗССРДСАР (GIOP «поверх» ТСАР). В первом случае реализация GIOP более проста, но привязана ктранспорт-ной услуге SCCP, вследствие чего потребует изменений при введении в стек ОКС-7 нового транспортного протокола. Во втором случае реализация GIOP несколько сложнее, так как требует преобразования используемых ТСАР форматов данных ASN.1 в формат ODL CORBA, однако она обеспечивает простоту добавления новых прикладных протоколов, что может понадобиться в будущем.

Достоинством данного решения является то, что эффективно используются капиталовложения в сеть ОКС-7, которая служит очень надёжным и высокопроизводительным средством связи между узлами. К недостаткам следует отнести то, что такая стратегия, разумеется, требует участия поставщиков ORB. Кроме того,



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [ 146 ] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

0.0013