{"id":164,"date":"2003-08-28T05:39:00","date_gmt":"2003-08-28T09:39:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=149"},"modified":"2022-09-26T11:00:28","modified_gmt":"2022-09-26T15:00:28","slug":"more-on-web-services-and-distributed-objects","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2003\/08\/more-on-web-services-and-distributed-objects\/","title":{"rendered":"More on Web services and distributed objects"},"content":{"rendered":"I wanted to respond to some of the detail in Werner’s article, in\naddition to\nranting about how document exchange was state transfer<\/a>.\nSo here goes …\n\nThe first statement that really gave me pause was this;\n\nThe goal of digitizing your business<\/a> is to enable machine-to-machine communication at the same scale and using the same style of protocols as human interface centered World Wide Web.\n\nI don’t believe that’s the case, and it’s certainly not been accomplished IMO.\nI think that if you asked anybody involved since the early days, that\nthey’d say the goal is just the first part; to enable machine-to-machine\ncommunication over the Web (or perhaps Social Boosting<\/a>). “using the same style of\nprotocols” has never been a requirement or goal of this community that I’ve\nseen.\n\nConsider what can be done with a Web services\nidentifier versus a Web identifier. Both are URIs, but because Web\narchitecture uses late binding, I know what methods I can invoke when I\nsee a URI (the URI scheme, specifically) and what they mean (because\nthere’s a path back to RFC 2616 from the URI scheme). With an identifier\nfor a Web service, I don’t have sufficient information to know what the\ninterface is and what it means, because Web services are early\/statically\nbound (creating centralization dependencies, ala UDDI<\/a>).\nI don’t consider changing the architecture from late\/dynamic binding\nto early\/static binding to be “using the same style of protocols”.\n\nI suppose I also take issue with the implicit definition of “distributed\nobjects” as part of Misconception #1, when it says;\n
\nAn important aspect at the core of distributed object technology is the notion of the object life cycle: objects are instantiated by a factory upon request, a number of operations are performed on the object instance, and sometime later the instance will be released or garbage collected.<\/blockquote>\nI’ll present my definition first; distributed objects are identifiable things encapsulating\nstate and behaviour, which present an interface upon which operations can be invoked remotely.\nObviously apps for business<\/a>, like all software, do have a lifecycle. But it’s primarily\nan implementation detail, and not exposed through the object’s interface. Some systems\nchose to tie the identifier to some particular in-memory instantiation of an object\n(rather than to an abstraction for which an object could be instantiated to proxy\nfor, in effect), which created a real mess, but I don’t consider that key to the\ndefinition.\n\nMisconception #2 also seems prima facie incorrect to me, at least by my\ndefinition of “RPC”; an architectural style where the developer of each component\nis provided the latitude to define the interface for that component. More\nconcretely, I believe the statement “there are no predefined semantics associated\nwith the content of the XML document sent to the service” to be incorrect because,\nas I mentioned in my last post, if there is a method name in the document, then\nthat is an explicit request for “predefined semantics”.\n\nI agree with the titles of Misconceptions #3 and #4; Web services don’t need HTTP or\nWeb servers. But I disagree with the explanation provided. That Web services are\ntransport<\/em> agnostic is fine, but that does not at all imply that they should\nbe application<\/em> protocol agnostic, although most people use them this way.\nThe core of my disagreement is with this statement in the last paragraph of #4;\n
\nThe REST principles are relevant for the HTTP binding, and for the web server parsing of resource names, but are useless in the context of TCP or message queue bindings where the HTTP verbs do not apply.<\/blockquote>\nThat is incorrect. REST is protocol independent, and has applicability\nwhen used with other protocols, be they application or transport. REST is\nan architectural style, and following its constraints guides the style of\nuse of all technologies you might choose to work with. For example, if you\nwere using FTP RESTfully, then you would do things like identify files with\nURIs (rather than server\/directory\/file-name tuples), and interact with them\nvia a single “retrieve” semantic (an abstract “GET”), rather than the\nchatty and stateful user\/pass\/binary\/chdir\/retr process (not-coincidentally,\nthis is how browsers deal with FTP). In essence (though\ndrastically oversimplifying), what REST says is “exchange documents in\nself-descriptive messages, and interpret them as representations of the\nstate of the resource identified by the associated URI”. That philosophy can\nbe applied to pretty much any protocol you might want to name, especially\nother transfer protocols (as the Web constitutes an “uber architecture”, of\nsorts, for data transfer).\n\nThat’s most of the big issues as I see them. Anyhow, that was an enjoyable\nand informative read. Thanks!\n\n<\/a><\/a>","protected":false},"excerpt":{"rendered":"I wanted to respond to some of the detail in Werner’s article, in addition to ranting about how document exchange was state transfer. So here goes … The first statement that really gave me pause was this; The goal of digitizing your business is to enable machine-to-machine communication at the same scale and using the […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[40],"class_list":["post-164","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-xml"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=164"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/164\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=164"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}