JMS по сравнению с веб-сервисами
db.collection.find({"createdDate":{$gte:new ISODate("2017-04-14T23:59:59Z"),$lte:new ISODate("2017-04-15T23:59:59Z")}}).count();
Замените collection именем коллекции, которую хотите выполнить запрос
7 ответов
EDITED after correction from erickson:
JMS requires that you have a JMS provider, a Java class that implements the MessageListener interface for processing messages, and a client that knows how to connect to the JMS queue. JMS means asynchronous processing - the client sends the message and doesn't necessarily wait for a response. JMS can be used in a point-to-point queue fashion or publish/subscribe.
"Service" is a fluid term. I think of a service as a component that lives out on a network and advertises a contract: "If you send me X I'll perform this task for you and return Y."
Distributed components have been around for a long time. Each one communicated using a different protocol (e.g., COM, Corba, RMI, etc.) and exposed their contract in different ways.
Web services are the latest trend in distributed services. They use HTTP as their protocol and can interoperate with any client that can connect via TCP/IP and make an HTTP request.
You can use SOAP or RPC-XML or REST or "contract first" styles, but the underlying idea of a distributed component using HTTP as its protocol remains.
If you accept all this, web services are usually synchronous calls. They need not be bloated, but you can write bad components in any style or language.
You can start designing any distributed component by designing the request and responses first. Given those, you choose JMS or web services based on what kind of clients you want to have and whether or not the communication is synchronous or asynchronous.
Системы, основанные на сообщениях, в том числе JMS, обеспечивают возможность «хронологической развязки» с другого конца. Сообщение может быть отправлено без доступа к другому концу.
Все другие распространенные подходы A2A требуют, чтобы партнер был в состоянии реагировать немедленно, требуя, чтобы они были в состоянии справиться с пиковыми нагрузками, с небольшой способностью распределять обработку.
Позвольте мне рассказать о реализации веб-сервисов по протоколу SOAP ... что лучше, чем JMS против веб-сервисов ... JMS предоставляет транспортный протокол, и он является основным провайдером обмена сообщениями, который показывает, насколько хорош или плох ваш провайдер JMS, например. MQ - это мощный надежный JMS-провайдер, в котором протокол SOAP можно рассматривать как протокол прикладного уровня, а также можно рассматривать как транспортный протокол (в смысле SOAP / HTTP) ... в основе SOAP лежит поддержка стандарта на основе XML. ... как протокол уровня приложения, мы рассматриваем SOAP как сообщение, передаваемое из одной системы в другую по любому транспортному протоколу, где в качестве транспортного протокола SOAP можно рассматривать как контейнер для передачи полезной нагрузки (данных сообщения) ... SOAP / HTTP также можно рассматривать как провайдера мессенджера JMS ... но в последней форме HTTP имеет проблему надежности, так как он включает ошибки, связанные с сетью, соединениями сокетов, пропускной способностью и т. Д. ... поэтому, говоря коротко, JMS с надежный поставщик сообщений делает его хорошим стандартом для взаимодействия с хорошим транспортным протоколом, где webservice как протокол уровня приложения заставляет разнородное приложение взаимодействовать с использованием протокола XML-like-SOAP ... надеюсь, это проясняет ...
Добавил бы это в качестве комментария к посту Dyffymo, но пока не имеет представителя.
Цитата из вашего ответа:
«Веб-сервисы являются последним трендом в распределенных сервисах. Они используют HTTP в качестве протокола и могут взаимодействовать с любым клиентом, который может подключиться через TCP / IP и сделать запрос HTTP.
Вы можете использовать стили SOAP, RPC-XML, REST или «контракт в первую очередь», но основная идея распределенного компонента, использующего HTTP в качестве протокола, остается. "
I ' Предполагая, что под веб-сервисами вы подразумеваете набор протоколов WS- *, WSDL и SOAP. Если это так, то ни один из них не требует использования HTTP в качестве «транспортного» протокола. Набор протоколов SOA был спроектирован так, чтобы не зависеть от используемых протоколов передачи, поэтому вы можете использовать HTTP, NamedPipes, необработанный TCP и даже JMS в качестве средства для передачи сообщений в и из веб-службы.
Так что в случае прямого использования JMS и использования «веб-сервисов» я думаю, что это в основном сводится к инструментам, уровню комфорта и необходимости действительно прямого доступа к какой-то специфической функции JMS (которая использует WS- * прятался бы от тебя). На этом этапе я бы подумал, что только довольно специализированным приложениям потребуется необработанный доступ к JMS.
Все зависит от ваших требований, какие платформы вы будете использовать, а также от среды и поведения ваших приложений. Если вы можете дать обзор об этом, то вы можете получить жесткий ответ.
Теперь это похоже на сравнение грузовика с автомобилем-седаном. Вы должны знать, для чего вы будете его использовать и на какой дороге можно решить, какой из них лучше.
Я бы сказал, что самое большое отличие состоит в том, что JMS ориентирована на сообщения, а не на RPC. По умолчанию большинство поставщиков JMS поддерживают протоколы высокого уровня, которые выполняют повторные попытки, предотвращают дублирование и поддерживают транзакции.
Во многих приложениях эти возможности не нужны. Но там, где они необходимы, создавать их самостоятельно на основе механизма RPC сложно, дорого и подвержено ошибкам.
Вот отличия, которые я нашел: JMS - я привязан к поставщику JMS, но у меня есть выбор типа реализации (pub / sub, точка-точка) Веб-сервис - проще в обращении / проектировании, но это скорее прямая связь между устройствами. Множество инструментов для разработки - и чистый интерфейс (WSDL), так что разработчик и вызывающий могут быть независимыми.
Какой из них использовать? Зависит от того, в чем проблема.