Когда впервые появилась SID, потенциальные пользователи думали, что для обеспечения соответствия SID им придется менять свои внутренние структуры баз данных. Однако вскоре они убедились: достаточно один раз воспользоваться SID, чтобы превратить ее в структурную основу для интег­рации приложений. При таком использовании SID внутренняя структура базы данных представлялась в рамках SID как XML-схєма с расширениями для конкретных приложений (как описано в главе «Внедрение SID» в этой книге).

MetaSolv начала использовать SID таким образом несколько лет назад, еще до разработки XML-схем SID. В качестве структур для интеграции ис­пользовались разработанные к тому времени на базе SID схемы OSS/J Основ­ных бизнес-сущностей (Core Business Entity, СВЕ). Примеры таких схем пред­ставлены на двух приведенных ниже рисунках.

На рис. 4.11 представлен фрагмент СВЕ домена Услуга, содержащий SID-подобную сущность Услуга. Как и при использовании схем SID, каждый домен, например Продукт, Услуга или Ресурсы, находится в пределах собст­венной схемы. Обратите внимание на то, что в этом примере сущность Ус­луга обладает всеми атрибутами SID. Если данное приложение использует не все атрибуты и/или связи SID, то можно разработать другой набор схем, который представлял бы ограничительную базу сущностей SID. О базе огра­ничений речь шла в предыдущей главе, в разделе «SID как часть структуры интеграции приложений».

Эти схемы используются для определения другого набора схем, которые содержат расширения SID для конкретных приложений. На следующем ри­сунке представлено расширение для конкретного приложения к сущности Услуга (при этом сущность Услуга используется как база расширений — см. рис. 4.12).

Таким образом, расширения для конкретного приложения используются, чтобы построить схемы доменов, содержащие информационный контент для операций (подобно контрактам NGOSS). Рисунок для пояснения здесь не приводится, поскольку эти схемы весьма сходны со схемами, приведенными в главе «Внедрение NGOSS».

<complexType і "ServiceValue">

<o. cnnplc;xCor. tGnT.>

<extensior; :-="obecore : Ent і tyVal ue"> <sequence>

«і 1emenr • ="mandatory" гyi •

="C"/>

rot "cbeservice:startMode" mir. Ccrur.-- "0"/> л • ="serviceKey" ' . -="cbeservice:ServiceKey"

:■ r "cbeservice:serviceState" rinOccirs "0"/>

; subsc г i. be г I d" ype="s t г і ng " bib е="true"

</sequence>

</extension>

</complexContent>

</complexType>

<element na:-ie="baseStartMode" ype="string"/>

<element name "startMode" iype "cbeservice:StartMode" subs t і lutionGrour - "cbeservice: bascS tar r. Mode " / >

<simpieType..,r1H="startMode">

<restriction oast "string">

«^enumeration им I ="UNKNOWN"/>

<enumeratibn val ..e="AUTO_BY_ENV"/>

<enumeration vaIсо-"AUTO_BY_DEVICE"/> enumeration • 1 •="MANUAL_BY_PROVIDER"/>

<enumeration і..e="MANUAL BY CUSTOMER"/>

■^enumeration value’ "ANY"/>

</rest r. ction>

</simpieType>

Рис. 4.1 1. Фрагмент XML-схемы СВЕ домена Услуга.

ccomplexType "MetaSoivServiceValue">

<complexContent>

<extensіon I ="cbeservice:Serv:ceValue">

<seauence>

<element .. і: "serviceKey" ty - "metasolv-service:

MetaSolvServiceKey" н i ■■ . ;="0"/>

<element і -!!i-.="paxentSpecKey" yj r="metasolv-service :MeLaSol vServiceSpecilicationKey" rmOrci rs1 "C"/>

<element hi. ="doscr ibingSpocificat ionKoy" у ="netasoiv - service:MetaSolvServiceSpecificationKey" аЫ ="true" ="0"/>

<eiemer. t name "parer. tServiceKey" t:T - "metasolv-service: MetaSolvServiceKey" rr. і r. Occjrs-"0"/>

<eiement . і ="exterr. a'Serv ceKey" ■ yp ="st r і r. g"

it : i:0c ■ . ■ ; "C">

Рис. 4.12. Фрагмент XML-схемы расширения для конкретного приложения