RPC проти веб-сервісу
Для створення веб-служб за допомогою протоколу SOAP потрібно використовувати будь-яку з двох альтернатив. Можна або слідувати протоколу SOAP для документа або протоколу обміну повідомленнями RPC SOAP. RPC посилається на віддалений виклик процедури, і це протокол, який може використовуватися даною програмою для запиту на певну послугу в іншій програмі, яка знаходиться в іншому віддаленому комп'ютері. Під час використання RPC не потрібно знати мережеві деталі програми. Даний виклик процедури називається підпрограмним викликом або навіть викликом функції.
Використовуючи використання RPC, широко використовується модель клієнт / сервер. Програма, яка вимагає виконати послугу, знаходиться на стороні клієнта, а комп'ютер, що забезпечує виконання певної програми, вважається на кінці сервера. Дія RPC може бути названа синхронною, оскільки вона вимагає, щоб програма, яка вимагає дії, припинила вказану дію до тих пір, коли результати віддаленої процедури не будуть надані.
Щоб пристрій не зайняло занадто багато часу, коли очікуються різні дії, RPC дозволяє обробляти декілька потоків, які поділяють певну адресу, і, таким чином, відповіді можна наводити як вони надходять, а не послідовно, коли одна дія повинна виконуватись буде завершено до наступного, що розпочнеться.
Таким чином, веб-служба, створена за допомогою керування SOAP, може слідувати стилю обміну повідомленнями RPC або Document. Отже, стиль документа може вказувати конкретний .xml документ, який може бути перевірений відповідно до заданої схеми XML. Оскільки Java RPC використовується в комунікації таких платформ, як EJB, подібні додатки працюють на Java. Веб-сервіс, з іншого боку, в основному використовується, коли використовується додаток, який не працює на Java і прагне з'єднатися з веб-службою.
Продуктивність між RPC та веб-сервісами досить чітка, при цьому величезна різниця між веб-сервісами та RPC є досить різною. У деяких випадках варіація може бути зовсім невеликою, враховуючи стійкість, що вступає в дію. RPC постає перед проблемою наявності перевантаженого серверного середовища, що ускладнює роботу з кількома клієнтами.
З іншого боку, Веб-сервіс дозволяє здійснювати багаторазове розгортання сервісу, єдиною необхідністю є те, що Веб-служба викликається через HTTP. Це дозволяє використовувати звичайні методи обприскування та маршрутизації мережі, що застосовуються на великих площах. Важливо також зазначити, що веб-сервісу не потрібно спеціального кодування для роботи з сервером або навіть клієнтом.
Стійкість як RPC, так і веб-сервісу можна порівняти однаково, хоча важливо зазначити, що RPC вимагає, щоб посередники використання функціонували так, як очікувалося. Саме тут вступають у дію EE EJB та рамки типу Spring. Для найкращого обслуговування, бажано спочатку попрацювати з Java EE EJB, перш ніж привести в середовище RPC. Опромінення веб-сервісу до цього середовища та RPC також значно спрощує налаштування.
Підсумок
RPC посилається на віддалений виклик процедури.
Використовувати RPC рекомендується, коли клієнт / серверна модель широко використовується.
RPC дозволяє обробляти декілька потоків, які поділяють задану адресу.
RPC використовується на платформі, яка використовує EJB.
Веб-сервіс, що використовується в платформах, що не є Java, коли програма хоче отримати доступ.
Веб-сервіс також використовується для синхронізації асинхронного зв'язку.