OSS/J, MTOSI и другие

В предыдущем сообщении Forrester: SOA жив и здоров я посетовал на отсутствие отраслевых стандартов и как следствие конкретных сервисов SOA. Было бы неверным умолчать о ситуации с отраслевыми стандартами в телекоме. В телекоммуникациях отраслевые стандарты есть. Более того, стандартов таких слишком много и они порой противоречат друг другу.

Начнем с OSS through Java Initiative (OSS/J). Эта инициатива стартовала в 2000г. в рамках Java community с целью разработки интерфейсов для взаимодействия систем поддержки операций телекоммуникационной компании. OSS/J изначально ориентировалась на работы TMForum, с его shared information/data model(SID), развесистыми картами бизнес-процессов и приложений оператора связи, что предопределило её достаточно абстрактный характер. Естественно OSS/J платформо-зависимая спецификация. Изначально в ней присутствовали два типа взаимодействия приложений: RMI и обмен XML сообщениями через очереди посредством JMS. В 2006 году OSS/J присоединилась к TMForum. Сейчас кроме java интерфейсов OSS/J поддерживает для ряда API и SOAP веб-сервисы.

Multi-Technology Operations System Interface (MTOSI) это базирующийся на XML интерфейс, выросший из задачи управления сложными гетерогенными сетями. По мнению TMForum стандарты дополняют друг друга, тем не менее, задачи, решаемые OSS/J и MTOSI, довольно сильно перекрываются. Насколько я понимаю, в TMForum-е неустанно работают комитеты, гармонизирующие эти стандарты.

Вернемся к OSS/J. В основе этих стандартов лежит вполне здравая идея отделения уровня данных (inventory) от уровня бизнес-процессов: обработки заявок на подключение (order management), обнаружения и устранения неисправностей (fault management), технической поддержки (trouble ticketing). На текущий момент системы поддержки операций таким разделением не обладают. Т.е. в одной и той же системе сосредоточены планы строительства, заявки на проведение работ, отображение результата (построенной сети). Так как сети разные, то таких систем много и в каждой зашита специфика конкретной сети. Естественно, доступ к данной информации возможен только через пользовательский интерфейс конкретного приложения, а задача объединения inventory в телекоме признана нерешаемой.  В какой-то момент это превращается в настоящий кошмар для служб эксплуатации и развития.

И потому рано или поздно приходится задумываться о SOA.