max404.NET

Ориентация на сервисы и её роль в Стратегии распределенных систем

Эта статья представляет видение корпорацией Microsoft сервисной ориентации и архитектуры ориентированной на сервисы (service-oriented architecture, SOA) в вычислительной обработке данных в масштабе предприятия.

Бизнес-контекст сервисной ориентации

Сервисная ориентация - средство для формирования распределенных систем. Наиболее абстрактно, сервисная ориентация рассматривает всё - от основных приложений, от принтера, до клерка из дока отгрузки, до компании ночной доставки - как поставщика услуг. Поставщики услуг предоставляют возможности через интерфейсы. SOA отображает эти возможности и интерфейсы так, что они могут гармонично сочетаться в процессы. Сервисная модель "рекурсивна"(fractal): вновь сформированный процесс - непосредственно сервис, выставляет новую, объединенную возможность.

Фундаментом для сервисной модели является разделение на интерфейс и реализацию. Тот, кто вызывает(invoke) и использует сервис должен знать только его интерфейс; реализация сервиса может развиваться в течение долгого времени, не тревожа клиентов. Интересно, что один интерфейс может быть представлен несколькими реализациями; ключевые выгоды сервисной ориентации основаны на абстракции возможности от того, как эта возможность предоставляется.

OK, именно это является сервисной ориентацией. Для чего же она нужна?

Получив яйцо, фермер мог бы представить цыпленка; повар - омлет; а ребенок ярко раскрашенное Пасхальное яйцо. Сервисная ориентация - это яйцо.

Для разработчиков и архитекторов решений, сервисная ориентация - средство для создания динамических взаимодействующих приложений. Поддерживая выбор поставщиков услуг в реальном масштабе времени, сервисная ориентация позволяет приложениям быть чувствительными к содержанию и контексту определенного бизнес-процесса, и изящно включать новых поставщиков услуг в течение долгого времени.

Для IT-менеджера сервисная ориентация - средство эффективной интеграции разнообразных систем, типичных для современных центров данных предприятий. Предусматривая модель для агрегирования информации и бизнес-логики множества систем в одном интерфейсе, сервисная ориентация позволяет разнообразным и избыточным системам быть адресуемыми через общий, последовательный набор интерфейсов.

Для главного представителя по связям с общественностью сервисная ориентация - средство для защиты существующих IT-инвестиций, не запрещающее развертывание новых возможностей. Выделяя в самостоятельный элемент бизнес-приложение позади мандатных(capability-based) интерфейсов, сервисная модель даёт контролируемый доступ к приложениям для решения критически важных, ответственных задач, и создает возможность непрерывного усовершенствования реализации позади данного интерфейса. Сервисная ориентация защищает инвестиции от водоворотов перемен.

Для бизнес-аналитика сервисная ориентация - средство обеспечения инвестиций в информационные технологии в большем соответствии с деловой стратегией. Отображая служащих, внешних поставщиков услуг, и системы автоматизации в единой модели, аналитик может лучше понять стоимость компромисного решения, связанного с инвестициями в людей, системы, и привлечением сторонних ресурсов.

Для корпорации Microsoft, сервисная ориентация - критически важная предпосылка к созданию распределенных систем. Распределенные системы - приложения, которые усиливают сеть, связывая акторов и системы, управляющие бизнес-процессами. Вы строите распределенные системы на прикладной модели, которая переступает пределы любого устройства, вежливо пересекает границы, и отклоняет ограничения синхронности. Распределенные системы объединяют в совокупность сервисы и устройства, более эффективно отвечая потребностям вашего бизнеса, чем автономные приложения прошлого.

Потребность в большем понимании видов бизнес-деятельности заставляет IT-отделы предприятий искать соответствующие эффективные средства, чтобы интегрировать их в прикладные портфели. Цели - прозрачность и последовательность:
- Имеем ли мы непротиворечивое представление наших клиентов и деловых отношений, что позволяет нам лучше обслуживать их потребности и лучше представлять наши предложения?
- Все ли наши бизнес-процессы выполняют организационные постановления и правительственные инструкции?
- Наши системы достаточно эффективны в решении наших бизнес-задач?
- Делают ли наши технологические инвестиции нас максимально производительными, автоматизируя повседневные задачи и гармонично организовывая работу наших служащих, чтобы отвечать сложным вызовам?

Чтобы достигнуть прозрачности и последовательности, организации должны устанавливать связи. Они должны объединять системы, создавая непротиворечивое управление информацией; объединять человеческие и технические возможности, создавая непротиворечивые бизнес-процессы. Они должны объединять работников, создавая совместные группы, подключая организации, чтобы создать эффективные связи (бизнес-цепочки).

Сервисная ориентация, с ее акцентом на обобщенной модели вызова возможностей - ядро эффективной стратегии распределенных систем.

Сервисы и распределенные системы

В контексте моделей компьютерных компонентов, сервис это программа, которая взаимодействует, обмениваясь сообщениями. Говоря иначе, сервис - модуль прикладной логики, интерфейс которого определен просто в соответствии с сообщениями, которые он примет и отправит.

С развитием стандартов передачи сообщений, основанных на Расширяемом Языке Разметки (XML), сервисная ориентация быстро становится господствующим подходом построения распределенных систем.

Неотъемлемый вызов в соединении разнообразных систем - трансляция платформно-зависимой информации и процедурных моделей. В идеальном мире мы имели бы:
- Стандартный синтаксис, в котором информация из всех систем могла быть выражена однозначно.
- Стандартные семантические модели, основываясь на которых, организации могли бы выразить практику их деловых отношений на непротиворечивом языке.
- Стандартные протоколы, основываясь на которых, информацию можно было бы передать невзирая на границы между средами и между организациями.
- Стандарт, связывающий поведение и деловые документы.

В идеальном мире, все наши системы говорили бы на чем-то вроде "Эсперанто" (в дополнение к их родному языку), так, чтобы они могли общаться вне их родной среды.

XML, XSD, WSDL, UDDI и WS-* спецификации, типа WS-Security и WS-Policy, являются первыми конструкциями этого растущего общего языка.

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

Жизненно важный, но часто упускаемый элемент распределенных систем - клиент. Сервис интересен только тогда, когда кто-нибудь его вызывает. Различные требования взаимодействия требуют поддерживать разнообразие клиентских образцов. Клиентами веб-службы могут быть:

• "Умные" приложения с богатыми пользовательскими возможностями - решения, которые взаимодействуют с одним или многим сервисами, разумно кэширующие информацию, которую они получают, дающие и большую интерактивность, и поддержку автономной обработки информации.


• "Умные" устройства - решения от киосков самообслуживания, до инвентарного трэкинга на карманных устройствах, или управления контактами в смартфонах.


• Веб-интерфейс(UI) - портальные решения предприятия, которые объединяют и координируют взаимодействия типа "группа-группа" и "бизнес-служащий".


• Системы автоматизации - клиенты, которые не представляют никакого UI не должны вызывать исключение.


• Сервисы сочетания процессов - вызывают другие сервисы, чтобы предложить объединенные возможности.

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

Даже горячие защитники сервисной ориентации не могут договориться о границах модели сервисной ориентации. Что является для неё фундаментальным, а что может меняться с реализациями? ("Что Вы хотите сделать с теми яйцами?") Позвольте нам исследовать несколько связанных с сервисами понятий, которые проскальзывают в этих дебатах:

• Архитектура предприятия - систематическое моделирование целей организации, приоритетов, ресурсов, и процессов, в стремлении достигнуть понимания того, что необходимо для направленного усовершенствования.


• Интеграция информационных ресурсов предприятия - создание ряда организационных стандартов для бизнес-объектов(entities) - комплексных "типов", таких как "Клиент", "Служащий", "Заказ на поставку" - которыми управляет ваш прикладной портфель.


• Процессная ориентация - установка фокуса дизайна для вашей архитектуры предприятия и портфеля информационной технологии на бизнес-процессе.


• Гармоничное сочетание бизнес-процессов - модели, которые поддерживают проворные(agile) бизнес-процессы, делая последовательность шагов в процессе настолько легкой и адаптивной, насколько возможно.


• Управляемая событиями архитектурa - модель в которой бизнес-события, например прибытие запчастей в судовой док или счета на оплату, вызывают сообщение, которое будет послано подписанным сервисам, чтобы позволить им предпринять соответствующие действия.


• Виртуальные предприятия - рассмотрение бизнес-процессов как бизнес-цепочек (цепочка бизнес-сотрудничества), которые протягиваются между организациями, позволяя каждой сосредоточиться на ее основных возможностях и привлекать третьих лиц для выполнения работ по неосновным возможностям внешними поставщиками услуг (outsource).


• Аспектная ориентация - обеспечение средств для непротиворечивой обработки перекрестных отношений(cross-cutting concerns), например мониторинг деловой активности, управление доступом к сервисам и надежности доставки сообщения.


• Человеческое управление технологическим процессом - гармоничное сочетание информационных работников и их взаимодействий с бизнес-процессами, для достижения эффективности и живого отклика на потребности клиента.


• Отказ от посредничества в общении - автоматизация обмена неисключительной информацией поперек деловых границ, устраняющая потребность в информационных работниках(операторах), выполняющих стандартные задачи типа ввода данных из письменных источников (факс, почта, электронная почта) или устного информационного обмена.


• Проворство - системы разработанные быть чуткими к определенному контексту и содержанию бизнес-запроса, так же как к более широким изменениям требований бизнеса и деловых стратегий.


• Разработка, управляемая моделью - управляет процессом развития решений на высокоуровневом, в основном графическом языке, более близко связанным (допустим, по сравнению с Visual C#) с автоматизируемыми бизнес-процессами.

Microsoft рассматривает проворство и аспектную ориентацию, как жизненно важные свойства для делового и технического успеха сервисной ориентации; эти темы будут ещё неоднократно подняты в этой статье. Отказ от посредничества - это обычная цель сервис-ориентированных решений, что может рассматриваться как неявная выгода архитектуры. Каждое из других понятий дополнительно к сервисной ориентации, и может быть, или не быть критическим для вашей стратегии распределенных систем.

Ваша стратегия построения распределенных систем должна быть взвешенным подходом к возможностям и рискам, чтобы обеспечить лучшее возвращение ваших IT-вложений. Перестановки использования сервисов и поддерживающих моделей безграничны, и эволюционный пример должен попробовать пролить на это свет.

Первая итерация: Crawl

Тайфун (Typhoon Taylor) был информационным концентратором для Rum Island Industries(RII). Каждый заказ и отчет отгрузки проходили через его стол, и он удостоверялся, что данные вошли в систему майнфрейма. Однако, после того, как RII был приобретен Worldwide Spirits(WWS), Тайфуну стало необходимо вводить одну и ту же информацию и в операционные системы RII, и в систему планирования корпоративных ресурсов (enterprise resource planning, ERP) WWS; различные информационные модели были причиной постоянных ошибок ввода данных, приводя к непоследовательности данных между этими двумя системами.

Тайфун обсудил эту проблему с его приятельницей по IT - Дайкири (Daiquiri Jones). Дайкири не хотела расставаться с приложением майнфрейма - и не имела никакой возможности изменить ERP систему WWS, поэтому она предложила поместить перед обеими системами сервисный уровень.

Работая с Тайфуном, Дайкири определила документ PurchaseOrder, который включал всю информацию, требовавшуюся и операционной системе и системе ERP, отображая общие элементы, которые были необходимы обоим. Потом Дайкири показала этот черновик Урагану (Hurricane Harris) в бухгалтерии, и Соленому (Salty Robinson) в подразделении обслуживания клиентов. Опираясь на их отзывы, она добавила к схеме PurchaseOrder элементы для поддержки их потребностей.

Продолжая работать с Тайфуном, Дайкири определила два сервиса:

• NewOrder, который принимает документ заказа на поставку и обновляет обе конечные системы.


• ProcessShipment, который принимает документ Shipment, связывает его с заказом, и обновляет конечные системы.

Дайкири реализовала эти сервисы в BizTalk Server 2004, используя существующие адаптеры и к базе данных DB2, и к ERP системе WWS, и сделала на скорую руку UI для Тайфуна в ASP.NET.

Тайфун был счастлив. Он должен был ввести данные только один раз, и проблема непоследовательности информации была устранена.

Вторая итерация: Walk

Однако теперь Соленый и Ураган начали испытывать неудобства.

Соленый должен был обработать жалобы клиентов, когда из-за умеренных волнений моря в пути разбивалось несколько бутылок. С разнообразием систем, Соленый не был даже уверен в том, где именно нужно изменить данные клиента, и, когда клиент нуждался в замене поврежденного, он должен был вести переговоры с Тайфуном по переадресовыванию случаев повреждения тары рома.

Дайкири было довольно просто дать Соленому доступ к интерфейсу GetPurchaseOrder, который Тайфун использовал для проверки завершения заказа, но Тайфун настаивал, что Соленый не имеет права модифицировать заказы без его одобрения. В результате Дайкири определила ряд ролей для бизнес-сервиса PurchaseOrder, и установила Соленому роль "Читателя".

Дайкири также предложила новый документ CustomerCredit, который Соленый мог использовать, чтобы уладить жалобы о повреждениях, но когда Ураган увидел это, он стал ballistic. Предложение не обращалось за согласием Sarbanes-Oxley вообще. "Наши дни того, чтобы быть быстрой-и-свободной частной компанией закончены", - говорил он раздраженно. Дайкири повторно рефакторила документ CustomerCredit, чтобы включить элементы RegulatoryCompliance, используя схемы, которые уже были приняты бухгалтерским отделом в Worldwide Spirits.

Разбирательство в переустановлении приоритетов клиентов в судоходном процессе было сложнее, но была возможность решить проблему, которая долго перекладывалась на производителя и отдел по работе с клиентами в Rum Island.

Работая с Тайфуном, Соленым, и Моджито (Mojito Moore) в подразделении отгрузки, Дайкири переделывала схему Shipment, чтобы включить связывания в обоих Customers и PurchaseOrders. Она осуществила приоритетную очередь для документов Shipment, так что Моджито будет знать, куда должен пойти следующий груз. (Моджито получил роль "Писатель" для интерфейсов очереди, так что он мог оптимизировать очередь судов, покидающих порт).

Дайкири определила технологический процесс(workflow), который будет подвергаться обработке, когда Соленый вызвает интерфейс ReprioritizeShipmentQueue, который направит запрос к Тайфуну для одобрения.

Прежде ручной процесс, создающий неточную коммуникацию между Тайфуном, Моджито, и Соленым теперь протекал гладко. Конечно, Соленый все еще затевал конфликт, когда Тайфун отклонял один из его запросов.

Третья итерация: Run

Когда бюджет Дайкири был урезан снова, она знала, что придется быть креативной для нахождения денег. Она платила состояние за выделенный канал к WWS, который нес только несколько сотен килобайт безбумажной технологии (electronic data interchange, EDI) трафика в день. Что, если ...

Мартини (Martini Wilson) в штабе WSS уже создал схемы XML для трафика электронного обмена данными; он нуждался в них, чтобы связать входящие сообщения электронного обмена данными с пакетом согласования акта USA PATRIOT. Он согласился, что большинство филиалов WSS могло извлечь выгоду при использовании зашифрованных запросов Веб-служб вместо того, чтобы использовать специализированные строки электронного обмена данными, так что он создал межсетевой сервис, который отображал запросы в обрабатывающий конвейер электронного обмена данными.

Усиливая её новую инфраструктуру и практический опыт, Дайкири предложила ряд сервисных интерфейсов для поставщиков сахарной свеклы Rum Island's. Бродяга (Beachcomber Perry) в отделе снабжения был взволнован; он устал от траты целого дня из-за общения по телефону с владельцами плантаций и капитанами судов. Конечно Моджито подключился к проблеме. С улучшенной информацией, он был в состоянии устроить те же самые суда, которые привезли сахар для вывоза рома. Управление инвентаризацией в Rum Island никогда не было лучше.

Некоторые из производителей и моряков сопротивлялись изменениям, но это означало, что они видели всё меньше и меньше бизнеса с Rum Island в течение долгого времени.

Технология сервисной ориентации

Фиксация сервисной ориентации корпорацией Microsoft

В сентябре 1999, тогдашний президент (теперь CEO) Microsoft, Стив Балмер(Steve Ballmer), начал публично исследовать вызовы "программного обеспечения как сервиса" и ввёл понятие Веб-службы. С созреванием Интернета, было ясно, что новая программная модель была на горизонте; модель, в которой программные компоненты были бы вызываемы между глобальных сетей, между платформ, и меж организационных границ. Что требуется, чтобы сделать эту программную модель заслуживающей доверия платформой для бизнес-приложений?

В июне 2000, стратегия на стадии становления получила имя: "Microsoft .NET"

Период настройки, группы, разделяющие взгляды Microsoft выровняли себя, чтобы встретить новые вызовы, изложенные платформой .NET. Ориентация вокруг Веб-служб XML появилась как непротиворечивая стратегия подключения изделий Microsoft, и друг к другу, и ко всем другим активам в вашем организационном портфеле технологий.

Microsoft поняла, что для технологии, чтобы взять следующий шаг в релевантности к бизнес-процессу - для технологии, чтобы продолжить управлять прибылью в производительности работника - границы должны быть пересечены. Одна из тех границ была просто изготовлением технологов: граница между платформами выполнения. Microsoft стала работать с продавцами других платформ, чтобы сломать барьеры.

Работая с BEA Systems Inc., IBM Corp., TIBCO Software Inc., VeriSign Inc., и другими поставщиками технологий, Microsoft сформировала процесс расширения межплатформенных возможностей передачи сообщений SOAP, и рационализации конкурирующих спецификаций. Эти спецификации были выпущены в разработку стандартов на безгонорарном основании. Через это действующее обязательство, эти конкуренты сотрудничали, чтобы поставить их клиентам функциональную совместимость, критически важную для воплощения в жизнь универсальной передачи сообщений.

Признание, что спецификации не достаточно - причина того, что более ранние стандарты были не в состоянии достигать функциональной совместимости в реализации - Microsoft, IBM, и другие, спонсировали создание Web Services Interoperability Organization (WS-I). WS-I обеспечивает форум для общей интерпретации стандартов Веб-служб, так что потребители технологии могут быть уверены, что две реализации WS-Security действительно будет взаимодействовать. Основанная в феврале 2002года, WS-I теперь имеет приблизительно 150 членов, от системных продавцов, системных интеграторов до провайдеров решений, провайдеров здравоохранения, правительственных агентств. America Online Inc., BEA, Fujitsu, HP, NEC Corp., Oracle Corp., SAP AG, Siebel Systems Inc., Sun Microsystems Inc., и TIBCO - все члены WS-I.

Используя этот фонд, Microsoft встраивает функциональную совместимость на основе стандартов в свою линию продуктов вычислительной обработки данных масштаба предприятия.

Сервисная ориентация сегодня

Платформа Microsoft поддерживает построение сервисов и решений, совместимых с WS-I Basic Profile 1.0, и обеспечивает раннюю поддержку расширенной спецификации Веб-служб WS-*.

Основной подход к формированию Веб-служб на платформе Microsoft состоит в том, чтобы использовать поддержку Веб-служб в ASP.NET, разговорно называемой ".asmx" или ASMX из-за расширения файла используемым Visual Studio для этих выполнимых программ.

BizTalk Server 2004 позволяет сочетаниям(orchestrations) быть выставленными как Веб-службы, значительно ускоряя процесс разработки шлюзов Веб-службы к бизнес-приложениям, которые испытывают недостаток в родной поддержке Веб-служб.

Ранняя реализация расширенных возможностей Веб-служб, типа комплексной маршрутизации сообщений, используя спецификацию WS-Addressing и возможностей защиты уровня сообщения спецификации WS-Security, является доступным в Web Services Enhancements for Microsoft .NET (WSE). WSE - программа предварительного ознакомления с технологией(technology-preview) для клиентов, желающих экспериментировать с технологией, основанной на предложенных стандартах.

Microsoft предлагает расширенную поддержку вызова Web-сервисов из своих операционных систем (Windows XP, Windows Server 2003 and Windows CE) и Microsoft Office System.

Microsoft Office InfoPath 2003 является новым продуктом в системе Microsoft Office, которая поддерживает использование схематизированных форм как модель взаимодействия с конечным сервисом. InfoPath доказал себя особенно полезным в структурных сценариях сотрудничества, от регистрации ресурса оператором, до заключения контрактов.

Другой новый компонент Office, который обеспечивает доступ к информации через Веб-службы, - Microsoft Office Information Bridge Framework (IBF). IBF - плагин к Visual Studio.NET, который дает возможность разработчикам сформировать решения, основанные на Веб-службах, обращающихся к бизнес-данным предприятия, например количества продаж, инвентарных данных, информации о клиентах, и других. Эта информация может отображаться непосредственно в 2003 версиях Word, Excel, и Outlook. Решения IBF расширяют производительность информационного работника, давая возможность получать и воздействовать на информацию, не покидая знакомые приложения Office.

Visual Studio продолжает традицию обеспечения лучшей среды разработки для line-of-business приложений предприятия. Поддержка Веб-служб в Visual Studio.NET включает следующее:

• Разработка сервисов


• Систему для работы с XSD (authoring)


• Автоматическая генерация WSDL


• Регистрация UDDI


• Пакеты развертывания Datacenter


• Обнаружение сервиса на стороне клиента посредством UDDI


• Связывание с сервисом на стороне клиента


• Автоматическая генерация прокси-сервиса

Microsoft также фокусируется на поставке руководства, необходимого для хорошего(правильного) построения. Расширяя традиционно сильное руководство для разработчиков, доступное в MSDN, Microsoft предлагает архитектурное руководство в форме книг, статей, примеров типовых приложений, и библиотеки образцов. Портал Microsoft "Образцы и практики" (patterns and practices, http://www.microsoft.com/practices/) - точка доступа для руководства по архитектурным вопросам, от информационного дизайна до архитектуры решения, моделирования решений, развертывания в центр обработки данных предприятия.

Сервисная ориентация с SQL Server 2005 и Visual Studio.NET 2005

Две ключевых технологии выпускаются в 2005году - это Microsoft SQL Server 2005 (кодовое имя "Yukon") и Visual Studio.NET 2005 (кодовое имя "Whidbey").

Visual Studio.NET введет новую канву моделирования для архитекторов, сосредоточенных на вызове проектирования распределенных систем с использованием Веб-служб. В Visual Studio.NET присутствуют два средства проектирования, использующих эту канву:
- Логический прикладной проектировщик, для моделирования компонентов сервис-ориентированных решений и их взаимодействий.
- Логический проектировщик центра обработки данных, для моделирования процессоров, на которых будет развернуты сервисы, и зоны безопасности, в которые эти процессоры окружены брандмауэрами.

Важность этих инструментальных средств моделирования - в поддержке ранней связи между архитекторами решения и системными архитекторами, позволяющей удостовериться, что операционные требования решения полностью рассматриваются в фазе дизайна. Microsoft вняла многократным отзывам клиентов о том, что множество проектов отсрочены или превысили бюджет из-за проблем с развертыванием, которые, возможно, были бы предотвращены лучшим моделированием в начале.

Оба проектировщика работают с System Definition Model (SDM), схемой XML для описания программных компонентов, компьютерных аппаратных средств, сетей, и моделей взаимодействия. Как язык моделирования для описания и анализа подключенных систем, SDM - технический краеугольный камень Dynamic Systems Initiative (см. ниже).

Среди многих изменений в SQL Server 2005 улучшена поддержка XML и Веб-сервисов. SQL Server предложит следующее:

• Естественное хранение документов XML.


• Поддержка XQuery для поиска этих документов.


• Возвращение результирующих наборов в XML.


• Выставление хранимых процедур как Веб-сервисов.

Несколько архитектурных элементов в SQL Server будут поддерживать сценарии решений в сервис-ориентированном центре обработки данных:

• Сервисы уведомления могут использоваться, чтобы публиковать и подписаться на информационные каналы(feeds).


• Сервисы отчетов могут выполнить запланированные запросы, и произвести уведомления XML о результатах анализа.


• SQL Service Broker может использоваться, чтобы поддержать сервисы, спроектированные для распределенной модели данных, включая суперскалярные информационные архивы.

Сервисная ориентация с "Indigo" и Windows "Longhorn"

"Indigo" будет кульминацией инвестиций Microsoft во взаимодействии обменом сообщениями:

• Это будет реализация Microsoft расширенных Веб-служб (WS-* спецификации).


• Это будет унифицированный стек Microsoft для передачи сообщений распределенного вычисления, от взаимодействий процессов до меж-организационных вызовов Веб-служб.


• Это будет модель и фреймворк Microsoft для разработки сервис-ориентированых бизнес-приложений.

"Indigo" представит модель программирования и реализацию передачи сообщений, основанную на сервис-ориентированых понятиях контрактов, сообщений, каналов, и сервисов. "Indigo" поддержит более безопасный, надежный, транзакционный информационный обмен и вызов возможностей, совместимый с заявленными политиками обмена организаций-участников.

Технологии "Indigo" будут включены в выпуск клиента "Longhorn", и будут доступны для Windows Server 2003, Windows XP.

Следующее поколение Windows клиента, под кодовым названием "Longhorn", введет новшества, которые расширяют возможности настольного компьютера по участию в сервис-ориентированом бизнес-сотрудничестве.

"Longhorn" введет XAML, новый, основанный на XML, язык разметки для "умных" приложений Windows. Как и HTML, XAML использует декларативный синтаксис для описания элементов UI, которые могут быть сгенерированы и разобраны с точки зрения программы намного проще, чем процедурные объявления. Это новшество позволит пользовательским интерфейсам быть более рефлексивными относительно информации, которую они представляют, потому что UI может быть сгенерирован программно, на основе состояния взаимодействия.

WinFX завершает переход к управляемому коду в Windows, который начался со введения Visual Studio.NET в 2002году. WinFX - интерфейс системного программирования следующего поколения. В терминах сервисной ориентации, WinFX объединяет модели Microsoft multiple messaging, поддерживает защиту доступа кода (code access security, CAS), основанную на информации, возвращенной Веб-службами, и предоставляет прикладным разработчикам возможности "Indigo" для стека передачи сообщений.

Посредством Dynamic Systems Initiative(DSI), Microsoft стремится значительно увеличить IT-производительность и уменьшить стоимость проектирования, развертывания, и взаимодействия распределенных, сервис-ориентированых систем. Ядро технологии, как часть этой инициативы, System Definition Model (SDM) позволяет осуществить приложение принципов сервисной ориентации к управлению системами, определяя общую семантику для приложений, систем и взаимодействий. Используя этот общий проблемный язык, приложения могут выразить их технические требования, типа частоты центрального процессора, емкости памяти и жесткого диска, а системы смогут описать их ресурсы. Эта новая технология моделирования даст возможность предпринимателям быстрее "выкатить" сервис-ориентированные приложения, которые более просты для развертывания и дешевле в управлении. DSI - значительное усилие и Microsoft и отрасли, которое будет воздействовать на инструментальные средства разработки программного обеспечения и приложения, операционные системы, решения управления, и аппаратные платформы. Подробная информация о DSI доступна на сайте http://www.microsoft.com/dsi/.

Формирование сервис-ориентированых решений

Не все Веб-службы созданы одинаковыми. Яйцо может стать восхитительным суфле; шероховатой, горькой попыткой приготовления голландского соуса; или слизистой массой, когда уронено на пол. Можно сделать что-нибудь с сервисом: хорошее, плохое, или уродливое.

Планируя сервисный портфель предприятия, Вы решаете три фундаментальных вызова:

• Сервис-ориентированый анализ - какие сервисы Вы должны сформировать, чтобы поддержать деловые приоритеты организации?


• Сервисный дизайн - как должен быть сформирован каждый сервис?


• Сервисное управление - какая инфраструктура сервисов должна быть развернута, чтобы поддержать бизнес-сервисы, и какая поддержка необходима, чтобы понимать и обрабатывать исключения?

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

Сервис-ориентированный анализ

Сервис-ориентированая архитектура - искусство моделирования бизнес-процессов организации, как хорошо факторизованный портфель бизнес-компонентов, доступных в сети.

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

Целесообразность - мощная сила. Используйте её, но держите руку на пульсе. Способствуйте экспериментированию и запустите crawl; способствуйте коммуникации и учитесь walk; способствуйте сотрудничеству и получите running.

Насколько целесообразно Вы определяете сервисный портфель? Вот несколько принципов.

Design Services to Last, Design Systems to Change

В архитектуре сервисов предприятия, сервисы возможностей - компоненты, из которых составлены бизнес-процессы и бизнес-системы. Лучшие ключевые методы должны служить моделью ваших сервисных интерфейсов, чтобы сохранять близость с моделью бизнес-возможностей. Например, большинство изготовителей имеет определенные бизнес-требования, чтобы принять запросы закупки; определение информационного набора, который описывает запрос закупки и конечный пункт, который принимает образцы этого информационного набора - пример хорошо-выровненного обслуживания.

Бизнес-процессы намного больше непостоянны, чем информация, которой они манипулируют. Процессы подчинены суждению и прихотям людей в процессе, так же как и бесчисленным бизнес-исключениям, которые могли бы будоражить экземпляр процесса. Каждый экземпляр бизнес-процесса может поместить в диаграмму уникальный путь через ваш сервисный портфель.

Поэтому системы должны быть проворны. Гармоничное сочетание процессов должно быть легко-модифицируемо, или даже полностью динамическим. Заданные жестко последовательности бизнес-процессов в откомпилированных выполнимых программах - антиобразец для успешных деловых систем.

Понятие управляемой событиями архитектуры может быть поучительно, как то, что составляет эффективный дизайн процесса. Процессы должны знать о бизнес-событиях, которые продвигают их, или уводят от нормального пути. Когда исключительный случай уводит процесс в подпрограмму, фокус должен быть на перенормализации процесса и возвращения его на основной курс; ручное управление процесса к завершению будет увеличивать стоимость процесса для организации.

Think Globally, Act Locally

Большинство организаций имеет немного (возможно не более 10) ключевых сущностей, которыми они управляют в процессах основного бизнеса. Обычно это Customer, Employee, BusinessTransaction (также обычно называемый PurchaseOrder). Инвестируйте в определение нескольких из этих ключевых объектов, чтобы создать организационный образец для стиля объекта, и разработайте экспертизу в моделировании объекта. Взгляните на формальные и фактические стандарты для руководства и многократного использования (если стандарт существует в вашей вертикальной промышленности, и удовлетворяет ваши потребности, просто используйте его).

Сформировав экспертизу и общность понимания, дополнительно обратитесь к бизнес-возможностям и рискам:

• Идентифицируйте ключевую возможность усовершенствования.


• Моделируйте непосредственный деловой сценарий с оглядкой на существующие стандарты.


• Сделайте обзор этой модели с тремя - четырьмя знающими лидерами от связных бизнес-дисциплин.


• Расширьте и пересмотрите модель согласно их отзывам.


• Разработайте бизнес-сервис.


• Повторяйте эти пункты снова.

Результаты не будут совершенны. Позже будут обнаружены бизнес-случаи, требующие дополнительной информации. Нужно будет добавить шаги к модели бизнес-процесса. Однако, благодаря следующему принципу, Вы будете готовы к изменениям.

Дизайн для расширяемости

Никогда не было достаточного понимания требований, чтобы выдержать испытание временем. К future-proof ваших сервисов и решений, Вы должны проектировать расширяемо. Есть две ключевых области расширяемости: расширяемость объекта и поведенческая расширяемость.

Основной подход к расширению информации, смоделированной в объекте - это позволить последовательность элементов Extension, которые могут иметь любое содержание. Обычно они идентифицируют себя названием, и ссылкой на их собственную схему. Включая эту поддержку в определении объекта, Вы создаете полиморфные объекты. Расширенный объект Employee все еще может обрабатываться всеми сервисами, которые понимают базовый объект, но могут также поддержать расширенную обработку сервисами, которые понимают, скажем, расширение названное TravelProfile.

Различные географии требуют различной информации. Налоговый идентификатор, например, может быть по-разному структурирован в различных странах. Не делайте Social Security Number элементом верхнего уровня в вашем объекте Employee; лучше иметь элемент TaxID, который может идентифицировать свой подтип как "US-SSN".

В отличие от объектной ориентации, сервисная ориентация использует позднее связывание(late binds) поведения - "поведение" объекта прикрепляется к нему, когда он направлен сервису, который знает, как воздействовать на информацию, содержащуюся в объекте.

Поведенческая расширяемость достигается в первую очередь выставляя сервисы, которые могут добавить значение, управляя объектом. Есть множество эффективных образцов для связи нового поведения с объектами, но их обзор вне рамок этой статьи. Поучительный пример - сервис, который действует как "фасад" для другого сервиса, являясь способным к управлению элементом большего объекта. VerifyEmployeeAddress мог бы принять объект Employee, извлечь элемент Address, и передать его более универсальному сервису VerifyAddress, предлагаемому соответствующим национальным почтовым сервисом.

Ключевая часть руководства, следовательно, в составлении объектов из стандартизированных элементов, максимизируя и возможность многократного использования сервисов, и последовательность обработки общих информационных элементов.

Отделить функциональные и операционные отношения

Думайте и о вашем бизнес-сервисе и о сервисах инфраструктуры, как поставляющих возможности. Сервисы инфраструктуры поставляют горизонтальные возможности, также называемые перекрестные отношения(cross-cutting concerns) или, несколько загадочно, аспекты.

При выполнении сервис-ориентированного анализа, ваш вызов - идентифицировать эти перекрестные отношения и факторизировать их из ваших деловых объектов. Вы захотите, насколько это возможно, иметь единственную реализацию каждого сервиса инфраструктуры, что даёт возможность конвейеризации, превращая полные операционные требования в обмен индивидуальными сообщениями.

Ваш портфель инфраструктуры сервисов вероятно будет смешением и покупных продуктов и созданных внутри компании, с большим предпочтением покупке, если соответствующая реализация будет доступна на рынке. Эта тема развита более подробно в теме "Управление сервисом" ниже.

Помнить клиентов

Упражнения в пользователь-центрированном дизайне - важная часть сервис-ориентированного анализа. Каковы варианты использования этих сервисов? Кто вызовет их и зачем? Пользователи каких ролей обратятся к сервисам? Кто должен иметь возможность вызвать сервис и кто не должен? Какие устройства и требования должны быть поддержаны? Мы должны разработать сервисных агентов, чтобы упростить доступ к сервисам от любого из этих устройств?

Размышления при моделировании информации для клиентской манипуляции включают следующее:

• Использовать только типы XSD (и сложные типы, составленные из типов XSD); не привязываться к операционной системе, кодируя данные определенным для неё способом.


• Схемы должны выражать ограничения на значения данных, чтобы позволить клиентам проверять правильность запросов обновления перед отправкой; клиентская проверка правильности может очень уменьшить издержки и неудовлетворенность сервисом, отклоняющим запросы из-за некорректных значений. (Конечно, сервис тоже должен проверять правильность значений, несмотря на то, что публикует ограничения)


• Ссылочная информация должна быть с временными метками или как-либо иначе версионизирована, чтобы поддержать кэширование, дельта-обновления, и условные запросы обновления.

Когда сервис станет доступен, умные люди в вашей организации найдут способы использовать его. Не делайте предположений, что клиенты, на которых Вы ориентируетесь во время разработки, являются единственными клиентами, которые будут когда-либо вызывать сервис. Не помещайте в клиента ожидания чего-либо, не указанного в сервисном контракте, и не доверяйте клиенту, он может посылать сервису не только правильные запросы.

Сервисный дизайн

Сервисная ориентация - эволюционное развитие лучших методов формирования распределенных систем. Также, она извлекает образцы из успешных аспектов распределенных объектных технологий и ориентированных на сообщения решений связующего ПО (ПО, обеспечивающее прозрачную работу программ в неоднородной сетевой среде, middleware), и определяет антиобразцы из менее успешных аспектов той же самой архитектуры. Дон Бокс из группы "Indigo" выделяет четыре принципа, которые следует иметь в виду, рассматривая сервисную ориентацию:

• Принцип 1: Границы явны. Сервис взаимодействует явной передачей сообщений через границы. Мы не делаем никаких предположений о пространстве позади сервисных границ. Пересечение сервисных границ может быть дорогостоящим (например, Вы, возможно, должны охватить разные страны, трастовые границы, или среды выполнения). Мы явно указываем это в вызове сервиса, формально передавая определенные сообщения между сервисами. Явные границы позволяют нам формально выражать реализацию независимого взаимодействия - мы можем быть агностичными к выбору платформы, промежуточному ПО, или языку программирования, используемому для реализации других сервисов.


• Принцип 2: Сервисы автономны. Сервис ведет себя разумно, как независимый объект. Мы не делаем никаких предположений о пространстве между сервисными границами. В сервис-ориентированной среде нет никакого начальства. Сервис независимо развернут, версионизирован и управляется. Топология, в которой выполняется сервис, может и будет развиться. Сервис должен ожидать, что одноранговые сервисы могут и будут ломаться, и что он может и будет получать уродливые(поврежденные) или злонамеренные сообщения. Сервис должен быть построен, чтобы не "падать", используя (например) избыточность и отказоустойчивые методики.


• Принцип 3: Сервис публикует Схему и Контракт, а не класс. Сервисы взаимодействуют исключительно на их описании структур, используя схему, и поведения, используя контракт. Контракт сервиса описывает структуру сообщений и ограничения на получение сообщений. Формальность выражения позволяет машине проверять входящие сообщения, и позволяет нам защищать целостность сервиса. Контракты и схема должны остаться устойчивыми во времени, поэтому формируйте их гибко (например, через использование xsd:any в схеме) и это важно.


• Принцип 4: Сервисная совместимость основана на политике. И поставщики услуг и сервисные потребители будут иметь политики - операционные требования - для взаимодействий между границ. Простой пример провайдерской политики - то, что сервис может требовать, чтобы вызывающий имел правильную учетную запись у поставщика услуг. Со стороны потребителя, организация может требовать, чтобы вызовы сервиса через Интернет были зашифрованы, так что будет использовать только сервис, которое предлагает возможность обеспеченного двунаправленной защитой обмена данными. Сервисы выражают их возможности и требования в терминах машинно-читаемого выражения политик. Утверждения политик идентифицированы устойчивым, глобально-уникальным названием.
  Индивидуальные утверждения политики непрозрачны к системе в целом; сервис просто должен быть в состоянии удовлетворить требования других политик.

Взаимодействия в пределах вашего сервиса должны придерживаться вышеупомянутых принципов. Эти принципы требуют формального выражения схемы, контракта, и политик между сервисами участвующими в сервис-ориентированной среде. В то время как механизмы, созданные для определенного случая на скорую руку могут быть разработаны для выражения границы сервиса, такие механизмы ограничены областью влияния изобретателя. Например, если Вы разрабатываете систему, которая выражает схему и контракт способом, который является распознаваемым только в вашем отделе, Вы обрекаете ваш сервис на непригодность его использования вне вашего отдела.

Чтобы полностью понимать выгоды сервисной ориентации, ваше выражение сервисной границы должно быть так широко принятым и способным к взаимодействию, насколько возможно. Индустрия ясно выбрала WS-* протоколы передачи через среду в сообщениях SOAP, как стандарт функциональной совместимости для сервисов. Сервисная ориентация, на практике, требует Веб-служб, сообщений SOAP, и использования WS-* протоколов.

Выбор технологии передачи сообщений, которая поддерживает сервисную ориентацию, означает выбор среди технологий передачи сообщений, которые поддерживают SOAP и WS-* протоколы. В текущей поставке технологий Microsoft, это означает .asmx в ASP.NET. Если Вы нуждаетесь в поддержке расширенных протоколов WS, используйте .asmx с WSE. В текущих технологиях передачи сообщений Microsoft, .asmx оказывает лучшему поддержку для выставления схемы, контракта и политики, независимую от реализации и способа взаимодействия.

Ключевая часть уважения сервисных границ в том, что в пределах границы может использоваться любая реализация. Как только Вы формально определили ваши сервисные границы с ASMX и/или WSE, Вы можете использовать любую технологию или стек передачи сообщений, чтобы осуществить обработку и обмен данными в пределах этих границ. Для простоты и последовательности, мы рекомендуем оставаться с сервисной моделью и использованием ASMX даже с сервисной границей. Нужно ли это для поддержки специфических возможностей или поддержки использования существующего развертывания, в любом случае, MSMQ, Remoting, или Enterprise Services - разумный выбор в границах сервиса. Они - не подходящие технологии, чтобы осуществить граничные интерфейсы вашего сервиса.

Управление сервисом

Тонкая красота спецификации SOAP состоит в том, что она предусматривает ясное разделение функциональных требований сервиса - деловой информации, которой сервис будет манипулировать - из операционных требований сервиса это, например, команды, касающиеся маршрутизации сообщений, и получения доступа к сервису. Функциональные требования удовлетворены Body сообщения SOAP; операционные требования удовлетворены элементами в Header сообщения SOAP.

Keep it that way. Если Вы поместите поддержку регистрации сообщения в ваш объект Employee, то Вы будете должны сформировать реализацию регистрации сообщения, которая может анализировать(ся) Employee. Гораздо лучше иметь универсальную реализацию регистрацию сообщения, который может определить местонахождение соответствующего элемента в заголовке SOAP независимо от того, что содержится в его теле.

Разработка и обслуживание взаимодействующей сервисной инфраструктуры могут быть дорогостоящим делом. Построение заслуживающей доверия реализации сервиса, основанного на WS-* спецификации и последующих тестов реализации, используемой всеми партнерами вашей организациями - вне возможностей большинства IT-бюджетов. Системные продавцы могут увеличить стоимость такой разработки поперек намного более широкого пользовательского ядра, и проверить функциональную совместимость с дополнительными технологиями других продавцов. Организации должны тщательно взвесить все аспекты перед формированием таких сервисов, а не отдавать их на откуп системного продавца.

Что же должен сделать IT-отдел, чтобы ответить сегодняшним операционным требованиям, когда реализации WS-* спецификаций все еще находятся на рассмотрении системными продавцами?

Компромис. Используя существующие технологии, которые наиболее эффективно соответствуют вашим потребностям, с намерениями мигрировать на сервисные технологии, когда они станут доступны и полностью поддержаны вашими системными продавцами. Если Вы должны защищать передачу, используйте HTTPS; если Вы нуждаетесь в надежной(гарантированной) передаче сообщений, используете MSMQ.

Некоторые операционные требования выйдут за рамки вашего организационного сервисного портфеля, но не будут хорошо-поддержаны продавцами систем. Примеры могут исходить из требований вертикальной промышленности, типа потребности проследить происхождение частей в автомобильной промышленности, в то время как другие могут быть чисто организационными, как, например, ориентированная на результат последовательная программа подтверждения равных возможностей/шансов при найме и продвижении по службе.

Когда Вы должны спроектировать и сформировать такой сервис, следуйте за образцами, появляющимися от реализаций продавцов WS-* протоколов:

• Работайте с консорциумом заинтересованных сторон, чтобы эффективно собрать требования; для требований вертикальной промышленности, работайте с торговыми партнерами и даже конкурентами.


• Определите схему для заголовка SOAP, который может быть присоединен к любому сообщению, чтобы нести операционную информацию.


• Продумайте иерархию отношений и факторов для эффективного многократного использования. Например, сообщению, содержащему информацию здравоохранения, вероятно, придется нести множество утверждений секретности с подобными структурами.


• Составьте ваши схемы, заново используя работу, которая соотносится с действительно горизонтальными отношениями, например описание физического адреса.


• Стройте итерационно; вложите капитал в формирование вашей инфраструктуры передачи сообщений, с допущением бюджета и времени.

Образцы сервис-ориентированных решений

Что Вы должны делать, чтобы сформировать распределенные системы сегодня? Вы должны погрузиться в полную переразработку вашего прикладного портфеля вокруг сервис-ориентированной модели? Вы должны только ждать и смотреть?

Опыт Microsoft, непосредственно подкрепленный опытом наших клиентов и партнеров предлагает более умеренный подход. Есть много бизнес и технических образцов, для которых сервисная ориентация даёт ясную выгоду уже сегодня.

Самый распространенный образец - информационная интеграция, изображенная в сценарии Rum Island crawl. Поскольку архитектура технологии развилась за прошедшие 30 лет, организации пришли к управлению или источнику обширного количества распределенных и избыточных данных. Законченное описание клиента, например, могло бы быть распространено поперек дюжины деловых приложений и баз данных. Эта информация редко полностью актуальна, и объединение этой информации для взаимодействия оптимального клиента (или партнера, или служащего) плохо поддержано. Сервисы информационной интеграции - эффективное средство и для представления вашего прикладного портфеля с унифицированным представлением этих ключевых объектов, и чтобы гарантировать последовательность информации поперек всех ваших конечных систем. Внутренний проект корпорации Microsoft - Алхимия(Alchemy) успешно обращается точно к такому же вызову, как и у наших собственных корпоративных хранилищ информации. Проекты информационной интеграции могут идти от тактических соображений, типа примера Rum Island, или от более широких стратегических - с дополнительным реинжинирингом информационного доступа и управления поперек предприятия.

Образец унаследованной интеграции изображает тактическое использование сервисов, чтобы сохранить существующие инвестиции в бизнес-приложениях, расширяя поставляемые функциональные возможности. Сервис мог бы добавить поддержку выполнения новых инструкций, например, перед существующим ERP package. Приложения проектировались бы, чтобы обмениваться сообщения с сервисом, который извлечет compliance-relevant данные и затем направит запрос к ERP package.

Предыдущий пример предлагает более широкий образец для сервисной ориентации: управление процессом. В этом образце, элементы "заголовка" используются, чтобы взаимодействовать ключевыми деловыми метаданными - с оборотного времени на клиенте запрос к объекту (тот, кто подтверждает) для определенных деловых решений. Это метаданные captured сервисом инфраструктуры, для объединенного анализа и/или в реальном масштабе времени. "Сервис-родные" процессы, включили бы эту информацию в заголовки SOAP, в то время как неродные приложения придется проектировать заново, чтобы передать метаданные, как сообщение на сервер governance .

Немного другой (или возможно только простая производная) образец - непротиворечивый доступ - использует сервисный уровень, чтобы гарантировать непротиворечивое принуждение разнообразия операционных требований, когда разнообразный набор приложений должен подключиться к критическому конечному ресурсу. Передавая под мандат, что весь доступ будет направлен через фасад сервиса, организация могла бы предписать непротиворечивое авторизованный доступ, управление распределения и загрузки.

Много сервисов поставляют некоторую форму ресурса virtualization. Вот - некоторые примеры:

• Контекстно-зависимая и чувствительная к содержанию маршрутизация запросов, типа посылки real-estate inquiry агенту по указанной географии, который специализируется в свойствах фермы.


• Маршрутизация запросов к разделенным банкам сообщений (без необходимости понимать схему разделения запрашивающему).


• Балансировка загрузки запросов поперек доступных средств - от клиента сервиса представителей в каналах потокового видео.

Наконец, организации весьма успешно использовали сервисы для externalization процесса. Веб-службы используются, чтобы помочь надежно договариваются об обработке платежной ведомости, компенсации расхода служащего, и logistical поддержке. Поставщики услуг сотового телефона и Интернет-порталы используют Веб-службы, чтобы объединить содержание. Стоящие перед клиентом организации используют Веб-службы, чтобы сформировать составные предложения, типа пакетов, включая рентные автомобили и стоимость авиабилетов. Ключ к успешному воплощению процесса на сегодняшнем стеке технологии это управлять вашим собственными ожиданиями - компромиссом ваших требований к пределам существующих технологий так, чтобы Вы не потеряли прибыль или сохранения на построении инфраструктуры сервисов, которое Вы замените через несколько лет.

---

Об авторе

Майк Бернер - архитектор решений в Microsoft Developer and Platform Evangelism Group. Майк в настоящее время сосредотачивается на исследовании лучших методов проектирования, построения, и управления сервис-ориентированными решениями.

В течение прошедших семнадцати лет, Майк формировал крупномасштабные распределенные системы, от сетей университетского городка до интерактивных телевизионных систем управления контентом и Веб-служб масштаба Интернета. За его шесть лет в Microsoft, Майк сосредоточился на техниках построения для XML-управляемого сотрудничества, включая и решения B2B и возможностей конечного пользователя. До присоединения к Microsoft в 1998, Майк был Vice President of Engineering в Alexa Internet, где он управлял разработкой Веб-метаданных Alexa, и сервисов "recommender", одной из первых суперскалярных веб-служб XML.