ProActive

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Поиск источников:  "ProActive"  -  новости  · газеты  · книги  · ученый  · JSTOR ( ноябрь 2010 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

ProActive Parallel Suite основан на платформе Java на основе « активных объектов » для оптимизации распределения задач и обеспечения отказоустойчивости.

Ключевые особенности ProActive Parallel Suite [ править ]

• Рабочие процессы упрощают распараллеливание задач (Java, сценарии или собственные исполняемые файлы), выполняя их на ресурсах, соответствующих различным ограничениям (например, ускорению графического процессора, библиотеке или расположению данных).
• Веб-интерфейсы предоставляются для разработки и выполнения рабочих процессов и управления вычислительными ресурсами. RESTful API обеспечивает взаимодействие с корпоративными приложениями.
• Вычислительные ресурсы могут быть объединены (облако, кластеры, виртуализированные инфраструктуры, настольные компьютеры) в единую виртуальную инфраструктуру. Он обеспечивает автоматическое масштабирование и упрощает стратегии управления ресурсами.
• Совместимость обеспечивается разнородными рабочими процессами, в которых задачи могут выполняться на различных платформах, включая Windows, Mac и Linux.

Структура ProActive Java и модель программирования [ править ]

Модель создана Денисом Каромелем, профессором Университета Ниццы София Антиполис . ^[1] Несколько расширений модели были сделаны позже членами команды OASIS в INRIA . ^[2] Книга «Теория распределенных объектов» представляет исчисление ASP, которое формализует функции ProActive и обеспечивает формальную семантику исчислению вместе со свойствами выполнения программы ProActive. ^[3]

Активные объекты [ править ]

Активные объекты - это основные единицы активности и распространения, используемые для создания параллельных приложений с помощью ProActive. Активный объект работает со своим собственным потоком . Этот поток выполняет только методы, вызванные для этого активного объекта другими активными объектами, а также методы пассивных объектов подсистемы, принадлежащей этому активному объекту. В ProActive программисту не нужно явно манипулировать объектами Thread, в отличие от стандартной Java.

Активные объекты могут быть созданы на любом из хостов, участвующих в вычислениях. После создания активного объекта его активность (тот факт, что он работает с собственным потоком) и его местоположение (локальное или удаленное) становятся совершенно прозрачными. Любым активным объектом можно управлять, как если бы он был пассивным экземпляром того же класса.

Активный объект состоит из двух объектов: в теле , и стандартного объекта Java. Тело не видно снаружи активного объекта.

Тело отвечает за прием вызовов (или запросов ) к активному объекту и сохранение их в очереди ожидающих вызовов. Он выполняет эти вызовы в порядке, заданном политикой синхронизации. Если политика синхронизации не указана, вызовы управляются по принципу « первым пришел - первым ушел » (FIFO).

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

На стороне подсистемы, которая отправляет вызов активному объекту, активный объект представлен прокси . Прокси-сервер генерирует будущие объекты для представления будущих значений, преобразует вызовы в объекты Request (с точки зрения метаобъекта, это повторение ) и выполняет глубокие копии пассивных объектов, переданных в качестве параметров.

Основа активного объекта [ править ]

ProActive - это библиотека, предназначенная для разработки приложений в модели, представленной Eiffel //, параллельным расширением языка программирования Eiffel .

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

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

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

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

Асинхронные коллы и фьючерсы [ править ]

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

Будущий объект действует как заполнитель для результата еще не выполненного вызова метода. Как следствие, вызывающий поток может продолжить выполнение своего кода до тех пор, пока ему не нужно вызывать методы для возвращаемого объекта. Если возникает необходимость, вызывающий поток автоматически блокируется, если результат вызова метода еще не доступен. Хотя будущий объект имеет структуру, аналогичную структуре активного объекта, будущий объект не активен. У него есть только заглушка и прокси.

Пример кода [ править ]

В приведенном ниже фрагменте кода подчеркивается понятие будущих объектов. Предположим, пользователь вызывает метод fooи метод barиз активного объекта a; fooметод возвращает недействительным и barметод возвращает объект класса V:

// односторонняя асинхронная связь с (удаленным) AO a // запрос отправляется на a . foo  ( параметр );// типизированная асинхронная связь с результатом. // v - это сначала ожидаемое будущее, которое будет прозрачно заполнено после // обслуживания запроса и ответа V  v  =  a . бар  ( параметр ); ... // использование результата асинхронного вызова. // если v все еще ожидаемое будущее, запускается автоматическое // ожидание: ожидание по необходимости v . гы  ( парам );

Когда fooвызывается для активного объекта a, он немедленно возвращается (поскольку текущий поток не может выполнять методы в другой подсистеме). Точно так же, когда barвызывается a, он немедленно возвращается, но результат еще vне может быть вычислен. Возвращается будущий объект, который является заполнителем для результата вызова метода. С точки зрения подсистемы вызывающей стороны, нет никакой разницы между будущим объектом и объектом, который был бы возвращен, если бы тот же вызов был отправлен на пассивный объект.

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

См. Также [ править ]

• Список программного обеспечения для планировщика заданий

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Ranaldo, N .; Tretola, G .; Зимео, Э. (14–18 апреля 2008 г.). Планирование действий ProActive с помощью механизма рабочего процесса на основе XPDL . Параллельная и распределенная обработка . Майами: IEEE . С. 1–8. DOI : 10.1109 / IPDPS.2008.4536336 . ISBN 978-1-4244-1693-6. ISSN  1530-2075 .
• Солнце, Хайлун; Чжу, Яньминь; Ху, Чуньмин; Хуай, Цзиньпэн; Лю, Юньхао; Ли, Цзяньсинь (2005). «Ранний опыт удаленного и горячего развертывания сервисов с надежностью в CROWN Grid». В Цао Цзяньнун; Нейдль, Вольфганг; Сюй, Мин (ред.). Передовые технологии параллельной обработки . Конспект лекций по информатике. 3756 . Берлин: Springer. С. 301–312. DOI : 10.1007 / 11573937_33 . ISBN 978-3-540-29639-3.
• Кема, Вивьен; Балтер, Роланд; Беллиссар, Люк; Фелиот, Дэвид; Фрейсине, Андре; Лакурт, Серж (2004). «Асинхронное, иерархическое и масштабируемое развертывание компонентных приложений». В Эммерихе Вольфганг; Вольф, Александр Л. (ред.). Компонентное развертывание . Конспект лекций по информатике. 3083 . Берлин: Springer. С. 50–64. DOI : 10.1007 / 978-3-540-24848-4_4 . ISBN 978-3-540-22059-6.
• ProActive-CLIF-Fractal получает награду OW2 2012
• Программное обеспечение, раскрывающее возможности сети (результаты ИКТ)
• ActiveEon et MetaQuant renforcent leur partenariat sur le Cloud ProActive (на французском языке)

Внешние ссылки [ править ]

• Официальный веб-сайт
• Спецификация модели компонентов сети