Гранулярность веб-сервисов с проектом SAP? - PullRequest
3 голосов
/ 07 октября 2009

В проекте, который идет как третье приложение поверх SAP, чтобы расширить его функциональность через веб-сервисы SOAP, мне интересно, как следует определять сами веб-сервисы; должны ли мы реализовать дюжину веб-сервисов, которые выполняют простые и элементарные действия, или очень мало веб-сервисов, которые принимают множество параметров и выполняют все эти функции.

Меня интересуют отзывы и предложения с учетом:
- рабочая нагрузка на слое Netweaver SAP (количество одновременных веб-сервисов)
- обслуживание третьего приложения
- Обслуживание веб-сервисов SAP
- нагрузка на сеть (с учетом SOAP-конвертов и http-запросов)
- любое другое соображение, о котором я, возможно, и не подумал

Спасибо

OB.

Ответы [ 3 ]

2 голосов
/ 07 октября 2009

Если исходить из SAP, то при определении интерфейса веб-службы моей первой мыслью было то, что грубые службы имеют тенденцию быть более подходящими, чем занятые подробные службы.

Во-первых, это связано с тем, что накладные расходы на каждый вызов сравнительно велики, поэтому предпочтительным является меньшее количество обратных вызовов. (Например, GetName, GetAddress, GetPhoneNumber и GetPersonInfo)

Во-вторых, если есть логика, мы хотим, чтобы служба принадлежала ей. Мы не хотим, чтобы каждому клиенту нужно было знать, в каком порядке вызывать детализированные методы. В противном случае мы получим дублирующую логику в каждом клиенте.

У меня есть статья здесь , в которой подробно рассматриваются такие вопросы, как эта.

1 голос
/ 20 октября 2009

Я бы просто пошел по пути, который проложил SAP: начиная с создания CRUD, как мелкозернистые сервисы. Просматривая SAP Enterprise Services Wiki , вы обнаружите, что большинство услуг, предоставляемых SAP, являются мелкозернистыми.

Предполагая, что вы в настоящее время находитесь на первой итерации своего сервисного API, вы наверняка не получите корректный высокоуровневый API с первой попытки, а вместо этого должны будете расширить его для более и более особенных в любом случае в будущем. Так почему бы не начать с мелкозернистого API и предоставить более высокоуровневый API, основанный на реальном опыте, позже - опять же, как это сделала SAP с сервисами композиции.

Конечно, производительность учитывается, но, как написано выше: инфраструктура корпоративных сервисов - это оболочка для проверенного временем механизма ABAP, и это быстро.

0 голосов
/ 07 октября 2009

Что касается рабочей нагрузки на уровне Netweaver SAP. Так не должно быть. Сервер приложений sap abap является настолько зрелой платформой, насколько вы встретите. Он прекрасно масштабируется и может принимать любую нагрузку, если в процессоре есть что-то (что он использует эффективно).

Таким образом, вопрос заключается в дополнительных затратах и ​​обслуживании сети. Как и я, я считаю, что грубый путь - это путь. Но ничего особенного в этом нет.

...