class Pipe
{
    void Suspend(string reason) // явное связывание, чисто бизнеслогика
    {
      Check(IsReasonValid(reason));  
      ...
    }
}

 var operation = GetOperationResource<Operations.Suspend>({reason = "Maintenance", pipe = pipe });

 context.Operations.Add(operation);
 context.Submit()

 switch(resource)
 {
  ...
   case Resource.Operation:
     var params = ExtractParamsFrom(resource);

     ProcessOperation(params); // неявное связывание взамен вагона кода
     break;
  ...
 }

class SuspendProcessor : IProcessor // неявное связывание взамен вагона кода
{
    void Run(int pipe, string reason)
    {
      Check(IsPipeValid(pipe));
      Check(IsReasonValid(reason));  
      ...
   }
}

H>Ага. Только тот пример, что ты показал, рестом не является Это некий гибридный вариант реста и рпц. Операции реста ограничены методами хттп, а у тебя операция есть ресурс. Это от попытки натянуть идеологию на задачу.

var s = echo("Hello JSON-RPC"); // вот для того нужна инфраструктура

string echo(string value) // вот для того нужна инфраструктура
{
    return value;
}
а результат имеем вот такой:
[code]
--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- { "result": "Hello JSON-RPC", "error": null, "id": 1}
[/code]

class Book
{
 public string Title;
 public string Annotation;
 public string ISBN;
 public string Author;
 public string Excerpt;
}

T> H>При невозможности использовать инфраструктуру. Почему нет? У клиента в такой ситуации вообще выбора нет

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

После твоего рест-примера.

T> H>Так кто же спорит Руками придется дофига писать, как и в случае рест. Только при этом не нужно будет думать, как бы от идеологии не отступить.

Example 3-2. A sample error response from S3
404 Not Found
Content-Type: application/xml
Date: Fri, 10 Nov 2006 20:04:45 GMT
Server: AmazonS3
Transfer-Encoding: chunked
X-amz-id-2: /sBIPQxHJCsyRXJwGWNzxuL5P+K96/Wvx4FhvVACbjRfNbhbDyBH5RC511sIz0w0
X-amz-request-id: ED2168503ABB7BF4
<?xml version="1.0" encoding="UTF-8"?>
<Error>
 <Code>NoSuchKey</Code>
 <Message>The specified key does not exist.</Message>
 <Key>nonexistent/object</Key>
 <RequestId>ED2168503ABB7BF4</RequestId>
 <HostId>/sBIPQxHJCsyRXJwGWNzxuL5P+K96/Wvx4FhvVACbjRfNbhbDyBH5RC511sIz0w0</HostId>
</Error>

Очевидно, в равных условиях, при отсутствии поддержки SOA инфраструктурой придется убить немеряно времени на реализацию и забить на многие аспекты вроде перформанса

T> H>И давно рест сузился до wcf data services? Что-то тебя потянуло обсуждать существующий фреймвок, хотя разговор начался с обсуждения подходов

После твоего рест-примера.

There are many instances when SOAP messages are designed for uses which are purely for information retrieval, such as when the state of some resource (or object, in programming terms) is requested, as opposed to uses that perform resource manipulation. In such instances, the use of a SOAP body to carry the request for the state, with an element of the body representing the object in question, is seen as counter to the spirit of the Web because the resource is not identified by the Request-URI of the HTTP GET. (In some SOAP/RPC implementations, the HTTP Request-URI is often not the identifier of the resource itself but some intermediate entity which has to evaluate the SOAP message to identify the resource.)

IB> H>Ну а вообще, конечно, SOAP был сделан гигантами для того, чтоб небыло ни одной человеческой реализации, дабы породить vendor lock-in

Хотя SOAP является стандартом, некоторые программы часто генерируют сообщения в несовместимом формате. Например, запрос, сгенерированный AXIS-клиентом, не будет понят сервером WebLogic.

IB> H>Вот-вот. Stateful в полный рост

but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.

One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and flexibility of XML

IB> H>Еще как существует

A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
Distributed garbage collection
Boxcarring or batching of messages
Objects-by-reference (which requires distributed garbage collection)
Activation (which requires objects-by-reference)

IB> Спецификация только об обмене сообщениями и говорит.

IB> H>Вполне конкретные прикладные задачи на отлично решаются и другими, более специализированными, средствами

IB> H> Зачем нужно связываться с монстром с многотонной спецификацией...

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
  <SOAP-ENV:Body>
    <ns1:doSpellingSuggestion xmlns:ns1="urn:GoogleSearch"
        SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <key xsi:type="xsd:string">00000000000000000000000000000000</key>
      <phrase xsi:type="xsd:string">britney speers</phrase>
    </ns1:doSpellingSuggestion>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value>00000000000000000000000000000000</value>
    </param>
    <param>
      <value>britney speers</value>
    </param>
  </params>
</methodCall>

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>key</name>
            <value>00000000000000000000000000000000</value>
          </member>
          <member>
            <name>phrase</name>
            <value>britney speers</value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodCall>

S> H>У меня есть опыт разработки веб-сервера с нуля, т.е. с уровня сокетов и пула потоков. Прокси для XML-RPC делается на его основе элементарно

S> H>У нас такие приложения, что кэширование практически неприменимо Но это не отрицает возможности его реализации в RPC.

S> H>Вот так всегда, как только речь заходит о конкретике, сторонники REST вспоминают о каком-то одном, конкретном, REST-фреймвоке А что делать юзерам проповедующим другой конкретный REST-фреймвок для повзаимодействовать с вашим сервисом? Правильно, выкинуть свой конкретный REST-фреймвок и принять ваше вИдение. Нужно ли говорить о том, что в протоколах решающих эту задачу на уровне именно протокола, таких проблем нет и двое человек говорящих об обработке ошибок или формате сериализации понимают, что говорят об одном и том же. И таки да, их никто не обязывает юзать фреймвок, можно так же тупо ручками.

Браузеры имеют ограничения по длине URL, что определяет максимальный размер данных. Например, URI в Опере имели предел 4 КБ, а в Internet Explorer около 2 КБ.

H><?xml version='1.0' encoding='UTF-8'?>
H><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
H>  <SOAP-ENV:Body>
H>    <ns1:doSpellingSuggestion xmlns:ns1="urn:GoogleSearch"
H>        SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
H>      <key xsi:type="xsd:string">00000000000000000000000000000000</key>
H>      <phrase xsi:type="xsd:string">britney speers</phrase>
H>    </ns1:doSpellingSuggestion>
H>  </SOAP-ENV:Body>
H></SOAP-ENV:Envelope>
H>

H><?xml version="1.0" encoding="utf-8"?>
H><methodCall>
H>  <methodName>google.doSpellingSuggestion</methodName>
H>  <params>
H>    <param>
H>      <value>00000000000000000000000000000000</value>
H>    </param>
H>    <param>
H>      <value>britney speers</value>
H>    </param>
H>  </params>
H></methodCall>
H>

H>Что-то избыточности, по сравнению с SOAP, да еще и четырехкратной, не видно даже в микроскоп

<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value><string>00000000000000000000000000000000</string></value>
    </param>
    <param>
      <value><string>britney speers</string></value>
    </param>
  </params>
</methodCall>

H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

S> <methodCall>
S>   <methodName>google.doSpellingSuggestion</methodName>
S>   <params>
S>     <param>
S>       <value><string>00000000000000000000000000000000</string></value>
S>     </param>
S>     <param>
S>       <value><string>britney speers</string></value>
S>     </param>
S>   </params>
S> </methodCall>
S>

S> H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

S> H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

Отфонарный скриншот моего десктопа ужатый до 320x200x24, в формате BMP

S> Опять мы говорим про отказ от industry-proven и straightforward решений в пользу жутких костылей лишь на том основании, что "потенциально это можно написать".

H>Оно мало где применимо вообще В многопользовательской системе ориентированной не на одну лишь перлюстрацию данных этот тип кэширования будет просто не востребован.

H>Обычно, тело запросов на получение данных не является большим, так что экономии там чуть

H>Если учесть, что мы используем сжатие, то в gzip этот запрос будет весить всего 149 байт (запрос сериализован одной строкой + отсутствует ненужная декларация кодировки). Итого: 149/69, всего в два раза. Да и что вообще такое дополнительные 80 байт

<?xml version="1.0"?>
 <methodResponse>
  <params>
   <param>
    <value>
     <struct>
      <member>
       <name>Result</name>
        <value>
         <array>
          <data>
           <value>
            <array>
             <data>
              <!--Placed order ID -->
              <value><i4>22</i4></value>
            </data>
           </array>
          </value>
         </data>
        </array>
       </value>
      </member>
     </struct>
    </value>
   </param>
  </params>
 </methodResponse>

H>Огрести проблемы можно не только с проксями, некоторые фаеры режут незнакомые/запрещенные/подозрительные для них заголовки HTTP (легко гуглится). Так что, и там тоже драконы живут. У-у-у-у

H>Вот я и не понимаю, нафига страдать с тонкими (браузерными) клиентами, когда можно взять, что потолще У нас таких клиентов нет, кроме админки на флексе, но там, насколько мне известно (не моя тема), с локальным стореджем проблем нет.

S>> H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

S>> H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

H>Я знал, что ты это попросишь Остался у меня и тот скриншот и весь тестовый проектик В общем, дело обстоит так. Тот самый скриншот:

H>

Отфонарный скриншот моего десктопа ужатый до 320x200x24, в формате BMP

пожатый в png (безо всякой дополнительной меты, с максимальным сжатием) занимает 49443 байта, респонзовый пакет XML-RPC с этим же png и пожатый gzip'ом занимает 49878. Итого, разница аж в 435 байтов. Как видим, вывод, по ссылке, актуальности не потерял