PHP и ESB (с Mule) (ESB: служебная Шина предприятия)
где, когда и почему вы использовали ESB в PHP-проекте?
где, когда и почему вы считаете, что имеет смысл использовать ESB в PHP-проекте?
предоставляет ли ESB (и ESB-фасилитаторы, такие как Mule) какие-либо возможности PHP и собственные технологии LAMP?
редактировать
моя мотивация для этого вопроса вытекает из моего предположения, что вам на самом деле никогда не нужен мул. Мул облегчит общение с внешними службами, с которыми вы могли бы справиться без мула. В конце дня также мул создаст издержки и накладные расходы. Поэтому мой вопрос заключается в том, чтобы кто-то рассказал мне о сценариях, где вы действительно пользуетесь ESB и инструментами, такими как мул, или поддерживаете мою догадку с твердым знанием.
Изменить 2
о Houcem ответ на мой комментарий на его пост ... что будет родной лампой-ответ ESB / Mule?
изменить 3
кажется смокинг может быть более PHP-родной альтернативой Mule / ESB. У кого-то есть опыт использования этого инструмента?
4 ответов
ESB можно использовать по-разному:
обеспечение асинхронной обработки : пример : если у вас есть веб-сайт, который делает большое украшение .. и отправка электронной почты занимает много времени, которое может заблокировать выполнение вашей страницы : вы можете использовать ESB для отправки данных электронной почты Мулу и направить его на исходящий канал электронной почты, таким образом, вы можете сказать, что вы внедрили очередь почтовых сообщений. Другая форма асинхронной обработки: использование mule для выполнения php скрипты (с использованием командной строки) не блокирующим способом.
интеграция с java-приложениями : вы можете отправлять сообщения mule с помощью php и реализовать некоторый бизнес java с помощью API mule в java, сообщения php будут получены вашими бизнес-компонентами java. Это используется в больших веб-сайтов, который делает много сложной обработки и нужен гибкий и мощный язык, как java.
Что вам нужно знать : ESB должен использоваться как автобус, который означает сбор данных из гетерогенных сред в стандартной форме (сообщения Мула).. выполните бизнес-логику, а затем выведите данные (после маршрутизации) в другую среду
в мире PHP нет собственной интеграции php с Mule. Для этого вы должны использовать веб-службы (SOAP)
ESB-это общее решение проблемы масштабируемости; проблема управления накладными расходами, стоимостью и сложностью большого количества интерфейсов приложений. Я написал короткую статью о обосновании решений ESB / EAI вhttp://psicom.com.au/solutions/eai
по общему признанию, большинство PHP-сайтов являются маломасштабными и обычно трудно оправдать административные и технологические накладные расходы ESB. Но теперь вполне возможно встретить все бизнес-приложение нуждается в продуктах OSS PHP, а также растет давление на затраты на организации, поэтому я ожидаю, что будет увеличиваться количество магазинов PHP, которые начнут ощущать виды растущих болей, о которых я писал. Это может заставить их пересмотреть свои вопросы интеграции приложений, и ESB, является хорошим решением этой проблемы.
насколько я знаю, в PHP нет продуктов ESB, и я не ожидаю увидеть это в ближайшем будущем. Но чистки рядов, многие продукты ESB предоставляют привязки для PHP и других платформ OSS, поэтому платформа, на которой работает ESB, не имеет решающее значение.
ESB (служебная Шина предприятия) является своего рода основой для интеграции нескольких гетерогенных приложений предприятия, которые могут исходить от разных поставщиков, технологий и даже быть избыточными.
тот факт, что он кажется более связанным с миром Java, чем PHP или любой другой язык, это обычно информационные системы крупных компаний состоят из:
- смешайте развития OpenSource и инструменты редакторов программ (включая ССП). Разработка часто производится с использованием Java EE, чтобы полагаться на стеки Java EE (и его поставщиков IBM, Oracle, ...)
- полная Microsoft (нет необходимости ESB, Microsoft предоставляет EAI/ESB, как инструменты)
PHP больше всего используется для веб-приложений (даже для крупных компаний, но веб-ориентированных).
ESB-это большая стоимость и полезна/необходима только тогда, когда количество взаимосвязанных приложений увеличивается. Когда у вас есть только несколько соединений (между Java, PHP или что), вы можете обрабатывать его на сетевом уровне, используя DNS, и на уровне приложения, используя конфигурационные ключи и выполняя обмен протоколами и интеграцию малого бизнеса для каждого соединения точка-точка.
потенциальным случаем использования PHP-приложения будет интернет-сайт туристического агентства, запрашивающего несколько компаний рейса/поезда / отелей. И даже в таком случае не будет безумием разрабатывать полную систему перекрестного опроса, поскольку это ядро бизнеса для такого сайт / компания.
Я бы рекомендовал Windows Azure Service Bus, которая предоставляет PHP SDK здесь https://github.com/WindowsAzure/azure-sdk-for-php
служебная шина отличная, но поддержание одного нет. Служебная Шина Windows Azure решила все накладные расходы на обслуживание для вас, и она совместима с PHP. Вы даже можете легко общаться с приложениями, написанными на Java, C#, VS C++ из PHP.