XMLHTTP и SOAP:
XML — это основная базоваятехнология веб-сервисов и ключ к реализации SOAP. XMLHTTP разработан на основе XML; С точки зрения реализации: XMLHTTP основан на браузере. Если у вас есть IE, вы можете передавать строки XML на сервер, что очень универсально. Однако браузер не используется для просмотра XMLHTTP. Если XML можно использовать для выполнения различных операций, это неизбежно повлияет на пользователей. Например, браузер, соответствующий предыдущей версии msxml, может получать доступ к клиентским XML-документам (изначально разработанным для XMLHTTP), а это означает, что доступ к локальной файловой системе можно получить с помощью технологии XMLHTTP. Позже Microsoft определила это как уязвимость, но сейчас это уже невозможно. Конечно, вы также можете писать клиентские программы, но они ограничены программами серии Visual. Они могут вызывать API в msxml. Но сервером может быть asp, jsp/servlet, каждый из которых преобразует строки xml вобъекты документов xml.
SOAP — это протокол связи в формате XML, включающий: конверт SOAP определяет соглашение для описания содержимого сообщения, подразумевая, что метод привязки протокола обеспечивает набор общих механизмов для передачи конвертов SOAP через протоколы нижнего уровня, которые необходимо объединить; различные Соглашение о сопоставлении типов данных приложения спредставлением XML на основе тегов. Механизм RPC обеспечивает способ представления удаленных вызовов процедур и их возвращаемых значений. Между ним и другими соглашениями нет четкой связи. Его областью является соглашение. Его можно привязать к http.stmp, tcp и другим протоколам. Сообщения SOAP представляют собой документы XML и могут также иметь вложения. Они могут генерировать сообщения SOAP на основе API, определенного W3C. Конечно, платформа Microsoft .net также поддерживает SOAP. SOAP+HTTP похож на XMLHTTP в том, что он обеспечивает лучшие и более мощные возможности реализации, масштабируемость и универсальность в распределенных совместных коммуникациях. Что еще более важно, он стал ключевой технологией для веб-сервисов и линейной связи.
SOAP и RMI, CORBA, COM
RMI и COM являются реализациями распределенных приложений и определяют связь между компонентами. Поскольку это всего лишь соглашения о взаимодействии между программами в системе (например, серией программ, написанных на Java ), а связь требует специальной поддержки платформы, за исключением того, что связь внутри этой системы эффективна, ее нельзя использовать с другими системами.
Чтобы решить эту проблему связи, CORBA разработала модель запроса прокси (с использованием языка IDL), чтобы они могли общаться друг с другом. Однако это похоже на исправление, которое не может решить фундаментальную проблему. Система становится все более и более сложной. , а использование CORBA эффективно только для восстановления ценности старых систем. Ни один из них не может пройти через брандмауэр. SOAP+HTTP — это протокол, дружественный к брандмауэру, который может проходить через брандмауэр.
SOAP — это протокол, не имеющий ничего общего с конкретной реализацией. Он основан на формате XML и передает данные в формате XML, что делает систему свободной. Таким образом, читаемость XML используется в приложении для анализа XML-документа для реализации приложения, что значительно улучшает совместимость системы (связь с различными системами). Более того, бизнес-логика каждого модуля системы понятна, что делает ее легко переносимой и многоразовой.
UDDI и JNDI
UDDI — это протокол управления регистрацией служб. Центр регистрации UDDI используется для регистрации служб через WSDL. Клиенты получают документы WSDL, выполнив поиск служб в центре регистрации UDDI, и получают доступ на основе WSDL. документы. Методы службы для связи со службой с использованием SOAP. Его можно реализовать через базу данных или выразить с помощьюоткрытого или корпоративного ( IBM и т. д.) XML. Когда пользователи запрашивают, их данные могут быть возвращены в виде информации в формате XML. Процедура доступа представляет собой не что иное, как иерархический процесс поиска. Регистрируемые им службы являются универсальными и независимыми от платформы, а метод регистрации осуществляется в универсальном формате XML. Он может быть ориентирован на Интернет или Интернет для предоставления различных услуг различным пользователям.
JNDI — это каталог именования служб Java. Он записывает каталог доступа к EJB и источнику данных в виде дерева. Программы могут находить службы через JDNI и RMI. В частности, через свои файлы развертывания при запуске сервера он автоматически устанавливает JNDI на основе файлов развертывания и поддерживает запросы RMI и службы именования (реализуемые самим сервером). Затем RNI сможет получить доступ к этим компонентам. Его идея в основном аналогична UDDI, но он привязан к конкретной системной платформе и полностью привязан к сервисам (относящимся к программам, строго называемым не сервисами, а компонентами), а его реализация проста. Таким образом, UDDI более динамичен и прост в использовании, чем JNDI.
Файлы конфигурации WSDD и EJB
аналогичны объектам CMP. WSDD имеет сходство с файлами конфигурации, но описывает сопоставление между данными и базой данных и не использует методы. .Существует серверная система.Основные методы реализации доступа. WSDD определяет интерфейс доступа к сервису, а базовая система, поддерживающая веб-сервисы, идентифицирует интерфейс, передает данные и т. д.