name="quantity" type="float"/>
name="CurrentQuantity">
name="quantity" type="float"/>
name="getCurrentInput">
name="body" element="sqsxsd: CurrentQuantity"/>
name="getCurrentOutput">
name="body" element="sqsxsd: CurrentQuantity"/>
name="StockInventoryServicePortType">
name="getCurrent">
message="sqs: getCurrentInput"/>
message="sqs: getCurrentOutput"/>
name="StockInventoryServiceSoapBinding"
type="sqs: StockInventoryServicePortType">
style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
name="getCurrent">
soapAction="http://mycompany.com/getCurrent"/>
use="literal"/>
use="literal"/>
name="StockInventoryService">
name="StockInventoryServicePort"
binding="sqs: StockInventoryServiceBinding">
location="http://mycompany.com/StockInventoryService"/>
Третьим «усовершенствованием» стал отказ от автоматической подгрузки связанных объектов[84] в пользу исключительно ручного управления процессом.
В CORBA объекты функционируют на сервере, тогда как на клиенте находится только соответствующая заглушка (stub). То есть вы в программе вызываете какой-то метод, а на самом деле происходит обращение к серверу, вызов соответствующего метода у серверного объекта и возврат результата на клиента с возможным обновлением состояния локальных полей заглушки. Аналогично со свойствами объектного типа: связанный объект подгружается по мере необходимости. Всё это происходит прозрачно для программиста, которому не нужно вмешиваться в процесс взаимодействия, но желательно знать, что стоит за манипуляциями с заглушкой на клиенте. Соответственно, существует соблазн вместо реализации на сервере новой функции службы написать код непосредственно на клиенте, благо сделать это легко. Тогда, например, обработка достаточно большой коллекции объектов в цикле может вызвать интенсивный обмен сообщениями с сервером и возникновение узкого места в системе. Аналогичная проблема плохой реализации имеется и при работе приложения напрямую с СУБД.
