Соображения относительно высоко-совместимой реализации SOA с Java? - PullRequest
Новая
       15

Соображения относительно высоко-совместимой реализации SOA с Java?

1 голос
/ 26 июня 2011

Прошло уже более двух лет с тех пор, как кто-то спросил: " Какую библиотеку сериализации объектов SOAP XML для Java вы бы порекомендовали? " и, предполагая, что с тех пор многое изменилось, я полагаю, что для этого достаточно веской причины. обновить тему.

Таким образом, вместо внедрения SOA в Java, это будет максимально совместимо с .NET Framework (или любой другой корпоративной платформой в этом отношении), в первом анализе, который я собираюсь использовать с Apache Тоскана но мне было интересно, есть ли причина, по которой я не должен? Любые отзывы обязательно будут оценены.

Ответы [ 2 ]

2 голосов
/ 26 июня 2011

Мы используем инфраструктуру метро , и до сих пор она доказала свою высокую совместимость с WCF, включая комплексную защиту на уровне сообщений с использованием взаимной аутентификации сертификата и токена имени пользователя. В нашем случае WCF - это сервер, а Java - это клиент.

2 голосов
/ 26 июня 2011

Собственно, первое, что я хотел бы сделать, это "действительно ли мне нужен SOAP / XMl?".

В частности:

  • WSDL не является почти кроссплатформенным, как это предлагается; очень легко получить случаи, которые не работают должным образом (ранее на этой неделе был один из них, посвященный PayPal)
  • XML читается человеком ... Но в результате он относительно медленный и раздутый

Существуют и другие способы совместного использования определения - например, мы все отлично справляемся с с помощью документа API, в котором говорится, что «этот API возвращает JSON в этой форме {...}». WSDL в основном , кажется, помогает разработчикам перетаскивания; из которых я не один.

Поэтому я предлагаю взглянуть на более простые (думаю, YAGNI) протоколы. Что касается полезной нагрузки, я большой поклонник protobuf, который намеренно является более простой схемой и, следовательно, допускает гораздо меньшую неопределенность в отношении того, что может / не может быть обработано различными реализациями, и в то же время охватывает все разумные варианты использования. Это также очень эффективный или оба CPU / пропускная способность. Очень переносимый и имеет язык определения схемы (.proto) для определения данных, но MUCH проще, чем WSDL. Шок ужас! Он не читается человеком ... Ну, для этого есть инструменты :) зачем навязывать нам недельные недочеты и медленные модули на основе плоти в наших API?

...