Если просто, то APS это все в одном флаконе: бизнес-логика, UI и возможность выполнять скрипты на конечном сервисе. А программная часть, которая непосредственно управляет Lync (активация и управление) может быть написана на чем угодно — в частности на PowerShell. Я не помню, пакет Lync'а разрабатывала другая команда, но помоему у них как раз PS используется для управления Lync'ом. Ну и вторая (а может быть первая) причина — APS стратегическое направление Parallels, сейчас вся поддержка новых сервисов делается на нем.
Сейчас новые провайдеры не разрабатываются, поскольку все новые сервисы создаются с помощью APS. С помощью этой технологии значительно легче выпускать новые сервисы для PA. Также важно что APS-пакеты отвязаны от релизов основного продукта PA, т.е. можно делать свои релиз-циклы для пакетов, добавлять новые фичи, не дожидаясь пока будет очередной релиз PA.
Что касается MS Lync 2010-2013 они реализованы как APS -пакеты как раз. :)
Строго говоря WPE это уже legacy — он поддерживается, но новые вещи туда не добавляются. Теоретически, прикрутив какой-нибудь frontend UI, WPE можно было бы выдвинуть на уровень большого enterprise, который настолько богат, что может позволить себе собственные инсталяции Exchange, Sharepoint и прочего. Но пока планов нет.
Не уверен, что понял ваш вопрос. WPE изначально задумывался как замена MPS, ибо Microsoft сделала ему EOL. И примерно в тоже время появился Exchange 2010 (насколько я помню), который хорошо провизился через PowerShell. Была идея: сделать MPS-like движок, который бы понимал клиентские MPS -запросы (там довольно сложный язык на базе xml), мог бы запускать на стороне сервера старые MPS-провайдеры (кроме native) и работать с новыми провайдерами написанными на PowerShell. Т.е. первая версия WPE сразу умела запускать провайдеры написанные на PowerShell. Но это не совсем: «работать через командлеты PowerShell».
С отладкой дела обстоят так:
1. Есть PowerShell ISE, но с помощью него можно отлаживать только локальные скрипты по факту, т.е. подцепиться к скриптам которые выполняются через .NET (System.Management.Automation) не получится
2. Можно породить свой PowerShell Host и туда попытаться прикрутить отладчик
Но самый простой вариант через логи. У нас логика достаточно простая в модулях, там особо отлаживать нечего интерактивно. :)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Что касается MS Lync 2010-2013 они реализованы как APS -пакеты как раз. :)
Строго говоря WPE это уже legacy — он поддерживается, но новые вещи туда не добавляются. Теоретически, прикрутив какой-нибудь frontend UI, WPE можно было бы выдвинуть на уровень большого enterprise, который настолько богат, что может позволить себе собственные инсталяции Exchange, Sharepoint и прочего. Но пока планов нет.
1. Есть PowerShell ISE, но с помощью него можно отлаживать только локальные скрипты по факту, т.е. подцепиться к скриптам которые выполняются через .NET (System.Management.Automation) не получится
2. Можно породить свой PowerShell Host и туда попытаться прикрутить отладчик
Но самый простой вариант через логи. У нас логика достаточно простая в модулях, там особо отлаживать нечего интерактивно. :)