Раздел developerWorks XML содержит множество статей, советов и учебных пособий, чтобы помочь вам оптимальным образом использовать Web-сервисы и строить приложения на их базе. Однако для тех, кто пытается освоится с новой для него темой, весь объем информации может быть избыточен. Для тех читателей, кто хочет подробней изучить Web-сервисы, но не знает с чего начать, эта страница дает общее представление о теме. Она содержит информацию об основах технологии Web-сервисов в разрезе тематик и связывает их с соотвествующими статьями на developerWorks, учебными пособиями, советами, образовательными сервисами IBM, практикумами и продуктами IBM для дальнейшего изучения
Сервис-ориентированная архитектура (Service-Oriented Architecture или SOA) - это компонентная модель, которая связывает различные функциональные модули приложений, называемые сервисами (или службами), посредством четко определенных интерфейсов и соглашений между этими сервисами. Интерфейсы определяются независимым способом, и не дложны зависеть от аппаратной платформы, операционной системы или языка программирования, на котором реализован сервис. Такой подход позоволяет создавать сервисы на различных системах, которые взаимодействуют друг с другом единообразным и стандартным образом.
Наличие независимого определения интерфейса, которое не связано жестко с конкретной реализацией, известно как слабая связь (loose coupling) между сервисами. Достоинством слабосвязных систем является быстрота и возможность выдерживать эволюционные изменения в структуре и реализации каждого отдельно взятого сервиса, которые составляют приложение в целом. С другой стороны, жесткая свзяь (tight coupling) подразумевает, что интерфейсы различных компонент приложения сильно взаимосвязаны по функциональности и взаимодействию, что делает их достаточно уязвимыми, когда меняется одна из частей приожения.
Необходимость слабосвязанных систем произрастает от потребности быстрой адаптации бизнес-приложений в соотвествии с меняющимися требованиями окружения, такими как изменение политик, объем бизнеса, акценты бизнеса, партнерство, репутация в индустрии и другими бизнес-факторами, которые влияют на природу бизнеса. О бизнесе, который способен быстро реагировать на изменяющиеся требования окружающей его среды говорят, как о "бизнесе по требованию", когда изменения делаются в соотвествии с задачами бизнеса, или когда необходимо выполнить определенную работу.
Сервис-ориентированная архитектура является не новой, а альтернативной моделью более традиционным сильно-связным объетно-ориентированным моделям, которые развивались в последние десятилетия. Несмотря на то, что SOA-системы не исключают объектной реализации конкретных сервисов, в общем и целом дизайн системы остается сервис-ориентироваанным. Поскольку такой подход позволяет оспользовать объекты в системе, SOA является объектной (object-based), но не объектно-ориентированной системой(object-oriented). Различие заключено в самих интерфейсах. Классический пример ранней SOA системы, который был в свое время достаточно популярным, это Общая архитектура брокера объектных запросов (Common Object Request Broker Architecture -- CORBA), которая определяет концепции, схожие с SOA.
Однако современная SOA отличается тем, что полагается на последние достижения в области eXtensible Markup Language (XML). За счет описания интерфейсов Web-сервисов с использованием языка на основе XML, называемого Web Services Definition Language (WSDL), система описания интерфейсов стала более динамичной и гибкой, по-сравнению с языком описания интерфейсов (Interface Definition Language -- IDL), специфицированного в рамках стандарта CORBA.
Web-сервисы - это не единственный способ реализации SOA. Например CORBA, как уже было сказано ранее, является одним из вариантов реализации, то же самое можно сказать и о системах на базе Message-Oriented Middleware, таких как IBM WebSphere MQ (MQ Series). Но для создания архитектурной модели вам необходимо несколько больше, чем просто описание сервиса. Вы должны определить, как приложение в целом осуществляет координацию действий между сервисами. Далее, вы должны найти точки трансформации между бизнес-операциями в сравнении с операциями программного обеспечения, используемого для автоматизации. Таким образом, SOA должна иметь возможность соотнести коммерческие бизнес-процессы с их техническими обеспечивающими процессами и соотнести последовательность операций (workflow) между ними. Например оплата поставщику является бизнес-процессом, в то время как изменение вашей базы данных с добавлением поставленных деталей является техничеким процессом. Таким образом, последовательность операций (workflow) играет значительную роль при проектировании SOA.
Кроме того, последовательность операций может включать не только операциии между подразделениями, но и взаимодействие с внешними партнерами, которые вам неподконтрольны. Следовательно, для большей эффективности вам необходимо определить политики и как будет осуществляться взаимодействие между сервисами, что часто делается в виде соглашений об уровне сервиса (service level agreements) и политик осуществления операций.
И наконец, все это должно работать в надежной и доверительно среде, чтобы процессы выполнялись так, как ожидается, в соотвествии с согласованными условиями. Таким образом, безопасность, доверительность и надежный обмен сообщениями должны играть значительную роль в любой сервис-ориентированной архитектуре.
IBM vision of Service-Oriented Architecture -- изучите как SOA может помочь Вам решить бизнес задачи и удовлетворить требованиям IT-инфраструктуры, являющимся неотъемлемой частью современного меняющегося рынка.
Web-сервисы для новичков -- это руководство, которое ответит на множество вопросов, которые помогут вам разобраться в теме, если вы не знакомы с технологией Web-сервисов.
An Executive's Guide to Web services. Если вы архитектор или далеки от технологий, но хотите разобраться с Web-сервисами, в указанной статье вы найдете множество полезных идей реального применения Web-сервисов.
Потребность в SOA произрастает из необходимости быстрой адаптации IT систем к изменениям в бизнесе. Возможность строгого определения взаимоотношений наряду с гибкостью конкретной реализации позволяет использовать функционал существующих систем, и одновременно быть готовым к будущим изменениям в их взаимодействии.
Приведем пример, организации, занимающейся продажей одежды и имеющей сеть из 500 магазинов по всему миру, нужно изменить дизайн с учетом требований моды. Это может означать не только изменения в стилях и цветах, но и изменение используемых материалов, производства и процедур доставки. Переход от одного поставщика к другому, с точки зрения программного обеспечения, может стать очень сложным процессом, если системы поставщика и заказчика несовместимы. Гибкость WSDL-интерфейса позволит каждой компании поддерживать свою существующую систему без изменений. Вместо изменения своих систем они могут привести в соответствие WSDL-интерфейсы и установить новые соглашения на сервисном уровне. Это называется горизонтальными изменениями в бизенсе, то есть в то время, как партнеры или поставщики меняются, бизнес-процессы остаются практически без изменений. Бизнес-интерфейсы могут претерпевать минимальные изменения, а внутренние процедуры вообще не будет затронуты, потому что бизнес-интерфейсы являются верхним уровнем взаимодействия.
Другой формой являются внутренние изменения, то есть организация продавец решает передать часть своих активов по продажам в другие организации, то есть переходит к модели магазин-в-магазине. Большинство бизнес-операций останется без изменения, но потребуется новое внутреннее программное обеспечение, для поддержки нового способа деятельности. Поэтому внутреннее программное обеспечение должно быть перестроено, он без серьезного влияния на взаимодействие с существующими системами поставщиков. SOA-система в данной ситуации останется незатронутой. В модель SOA могут быть добавлены новые аспекты, отражающие изменения, в то время как управление продажами и взаимодествие с поставщиками останутся без изменений.
В качестве продолжения идеи внутренних изменений можно рассмотреть следующее: IT-менеджер может решить, что новая конфигурация программного обеспечения может быть использована несколько иным образом, например, для учета использования свободного места под рекламу. Здесь снова может быть применена SOA. Это новая возможность модели SOA, которая не была доступна ранее.
Вертикальные изменения также возможны, когда организации потребуется полностью перейти от продажи собственной одежды к сдаче в аренду своих магазинов (магазин-в-магазине). Такие масштабные изменения потребуют значительной перестройки модели SOA c добавлением новых систем, программного обеспечения, процессов и взаимодействий. Преимущество модели SOA в данном случае заключается в том, что она ориентирована на будущий рост процедур и бизнес-процессов, а не программ и приложений, позволяя руководству четко понимать, что следует добавить, изменить или удалить, руководствуясь бизнес-процессами. Системы программного обеспечения могут быть структурированы для адаптации к бизнес-процессам, что гораздо легче, чем другой путь, используемый в большинстве программных платформ.
Как видно, изменения и возможности SOA-системы адаптироваться к ним - это самое важное. Для разработчиков такие изменения могут произойти в области их работы или вне ее, что зависит от того, нужны ли изменения в самих интерфейсах или в их взаимодействиях. Болше, чем разработчики в эти изменения будут вовлечены архитекторы, внедряющие их в модель SOA. Это разделение труда, когда разработчик фокусируется на разработке функциональных модулей (сервисов), а архитектор сосредотачивается на взаимодействии сервисов, существует около десятилетия и представлено универсальным языком моделирования UML и описано Архитектуре, управляемой моделями (MDA).
Узнайте об этом больше:
IBM SOA Web site -- Книги, статьи, вебкасты и другие материалы по SOA.
Преимущества SOA -- Узнайте больше о том, как SOA может улучшить Вашу IT-инфраструктуру и возможность быстро реагировать на бизнес-требования.
Когда дело доходит до создания XML приложений, вы сталкиваетесь с несклькими применимыми моделями. Эти модели позволяют создавать программные интерфейсы, которые вы можете использовать в ваших приложениях для анализа и манипулирования XML-структурами. Модели могут быть как объектно-ориентированными, такие как Document Object Model
(DOM) или JDOM (Java Document Object Model), так и событийно-ориентированными, например такие как Simple API
for XML (SAX).Помимо этого Java API for XML Parsing (JAXP) предоставляет общие интерфейсы для обработки XML документов с использованием DOM, SAX и
XSLT
Наиболее популярным, из перечисленных выше программных интерфейсов, является DOM, в котором каждая часть документа описывается как узел определенного типа. Эти узлы расположены как пары родитель-потомок. Отображение DOM API существует для различных языков, таких как Java, C++, Perl или Python.
SAX является следующим по популярности интерфейсом. В отличие от объектной модели DOM, SAX является событийным интерфейсом, который преобразовывает документ в набор callback-вызовов, например таких как startElement().
Поскульку по своей сути XML является простым текстом, программный интерфейс для работы с ним может быть создан кем угодно. На самом деле SAX был создан не организацией, а участниками списка рассылки XML-DEV. Другим таким объектным API, является JDOM, который был создан плохо сформированной организацией. JDOM похож на DOM, но первый более тесно связан с языком Java.
Узнайте об этом подробнее :
Учебные пособия "Understanding
DOM " и "Understanding
SAX" описывают в детялях создание Java приложений для чтения и манипулирования XML документами, но рассмотренные в них концепции применимы также и к другим языкам.
Образовательные сервисы IBM предлагают учебный курс, продолжительностью 2 с половиной дня "Programming XML and Related Technologies for Java", который затрагивает использование DOM и SAX, а также выполнение XSL преобразований программным образом.
Одной из сильный сторон XML является его способность быть понятым в различных средах...
Появилось множество различных XML словарей, позволяющих людям мгновенно понимать друг-друга. Три наиболее широкоиспользуемых это: Extensible HyperText Markup Language (XHTML), Resource
Definition Framework (RDF) и Scalable Vector Graphics (SVG).
XHTML это HTML переформулированный в терминах XML. XHTML документ это просто HTML документ, который следует правилам XML. Между тем множество XML словарей было создано для бизнес-задач и отображения информации. Например, RDF предоставляет средства добавления информации в XML документ, SVG дает возможность описывать графические элементы с использованием XML (поскольку SVG является простым текстовым XML документом, SVG может использоваться не долько для динамического создания графики, но и для анимирования и написания сценариев); Voice Extensible Markup Language (VoiceXML) используется для описания меню в телефонах и других голосовых системах.
Как только вы поймете XML в целом, все что будет необходимо сделать для использования конкретного словаря -- это понять его различные элементы и атрибуты, и какую информацию они представляют.
Для более подробной информации об XHTML посетите раздел developerWorks Web
architecture.
Учебное пособие "Modularization of XHTML" объясняет как с помощью ммодулей можно создавать и использовать различные подмножеста и варианты XHTML.
Учебное пособие "Introduction
to Scalable Vector Graphics" рассказывает о том, как с использованием SVG можно описывать графические изображения на Web-странице.
В учебном пособии "Interactive, dynamic SVG" вы найдете более продвинутый взгляд на технологию, где демонстрируется использование JavaScript для динамического управления содержанием страницы, где отображается поэтапный план, визуализируемый при помощи SVG.
Статья "An
introduction to RDF" дает обзор подходов к использованию RDF, начиная от схем (schemes) и заканчивая сценариями использования.
Имеет ли смысл заморачиваться со всеми этими XML стандартами? В серии из четырех статей, подготовленной ведущим колоки Уче Огбуджи, он предлагает свое собственное руководство по спецификациям, на которые имеет смысл обратить внимание в первую очередь:
XML яввляется прекрасным фундаментом для создания Web сервисов, поскольку он помогает в создании сообщений, которые могут быть легко стандартизируемы и воспринимаемы. Для того чтобы подробнее ознакомиться с Web службами и множеством ресуров, которые им посвящены, посетите раздел SOA и Web-сервисы сайта developerWorks. В частности, страница SOA и Web-сервисы для новичков поможет вам быстрее соориентироваться в этой сложной теме.
Как только вы усвоите основные принципы работы с XML, то обнаружите, что поле деятельности для различных улучшений является достаточно обширным, и постепенно появляются лучшие опыты использования.
Посетите раздел учебных пособий по XML (на английском) на сайте developerWorks, где вы сможете найти последние разработки в области XML и связанных с ним технологий.
Программы сертификации по XML
В такой большой области, как XML, достаточно полезно иметь некоторый стандарт, который позволяет судить об уровне выших навыков. Программы сертификации предоставляют некоторую контрольную точку проверки знаний, как для вас, так и для ваших текущих и потенциальных работодателей.
