В предыдущем сообщении 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.
>> Вернемся к OSS/J. В основе этих стандартов лежит вполне здравая идея отделения уровня данных (inventory) от уровня бизнес-процессов: обработки заявок на подключение (order management), обнаружения и устранения неисправностей (fault management), технической поддержки (trouble ticketing).
Ну это не достижение OSS/J — они наследуют такое разделение от TAM (eTOM) и SID.
Не очевидно. У TMForum есть разделение на структуры данных/приложения/бизнес-процессы и акцентированное разделение на ресурсы/сервисы/ продукты, т.е. resource inventory — это отображение сети, product inventory — это продуктовый каталог, а service inventory — это…. хм, сервисный каталог. Место сервисного каталога среди двух других каталогов тема не особо прозрачная.
В OSS/J границы между модулями более четкие. Инвентори — это компонент(в смысле UML), предоставляющий интерфейс для ордеринга, фолта и траблтикетинга. Доступны через этот интерфейс сущности, связанные друг с другом отношениями и обладающие спецификациями. Честно говоря, если бы спецификация была бы чуть менее абстрактной и оперировала бы понятиями устройства, порты и линки, то пользы от неё было бы существенно больше