{"id":91,"date":"2003-02-09T18:22:00","date_gmt":"2003-02-09T22:22:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=222"},"modified":"2003-02-09T18:22:00","modified_gmt":"2003-02-09T22:22:00","slug":"capeclear-presentation-about-architectural-styles","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2003\/02\/capeclear-presentation-about-architectural-styles\/","title":{"rendered":"Capeclear presentation about architectural styles"},"content":{"rendered":"

Jorgen<\/a> points to a\npresentation<\/a> he’s giving at an\nOMG Workshop<\/a>\ncomparing Service Oriented, Resource Oriented, and Object Oriented architectural styles.\nThis is somewhat similar to my REST Compared<\/a>\npresentation, though mine was done at a lower level.<\/p>\n\n

I’ll jot down some comments here as I read it.<\/p>\n\n

Slide 10, “In other words, architecture styles are design patterns for the\nstructure and interconnection within and between software systems.”. Sort of.\nArchitectural styles are pattern *languages*, not just patterns.<\/p>\n\n

Slide 12, “Two main types of distributed software systems”. This distinction\nseems quite arbitrary to me, and a superficial distinction at best.<\/p>\n\n

Slide 13, Request\/Response systems. Here, an association is asserted between\nrequest\/response and RPC. I consider those entirely orthogonal issues. I know RPC systems\nwhich aren’t request\/response (e.g. Orbix+Isis), and I know of request\/response system\nwhich aren’t RPC (HTTP). Perhaps it’s just a terminology issue, not sure.<\/p>\n\n

Slide 16, Object Oriented 1. “Communications are implicitly stateful”; I don’t\nthink that’s the case. Some are, like EJB\/CORBA, but some aren’t, like MTS\/COM (or\nwhatever it’s called now; Biztalk?)<\/p>\n\n

Slide 19, Resource Oriented 1. I wouldn’t include SQL here, since it’s not\nresource centric. If you wanted to create a “data oriented” super category,\nthen you might include it and resource-oriented, and file-oriented (FTP), etc..\nin there. It also says that resources have state and identity, as if to suggest\nthat they don’t have behaviour like objects. That’s not the case, they do have\nbehaviour.<\/p>\n\n

Slide 21, Resource Oriented 3. POST isn’t for “partial updates”, it’s for\ntriggering the “behaviour” part of identity\/state\/behaviour.<\/p>\n\n

Slide 22, Resource Oriented 4. “Resource Oriented” is not an architectural\nstyle. REST is the only resource oriented architectural style I know about,\nthough any REST extension would also be so. I suspect that any resource\noriented architectural style will be either REST, or a REST extension like\nthe Semantic Web, or ALIN<\/a>.\nSee also slide 24.<\/p>\n\n

Slide 23, Service Oriented 1. “Communications are implicitly stateless (all\nrequests are sent to the same service endpoint)”. That reason doesn’t have\nanything to do with stateful\/statelessness, AFAIK. If it was meant that the\nmessage is sent to the same in-memory object, then that would be implicitly\n*stateful*, as knowing what “the same” is requires a memory between invocations\non the server, and that memory is state. From the discussions I’ve had with\nWeb services proponents,\nthey say<\/a>\nthat service oriented architectures are state neutral; they can be stateful or stateless.<\/p>\n\n

Slide 28, Web Services vs. REST 1. “There is no real conflict between the\ngeneral idea of Web services and the REST approach”; excuse me?! 8-O There is\na fundamental and inescapable conflict between the two. They cannot peacefully\nco-exist. That Web service definition you quoted is completely\nincompatible with the REST architectural style. End of story.<\/p>\n\n

Slide 29, Web Services vs.REST 2. “The total set of Web services specifications\nprovide a superset of the REST approach”. Absolutely true. Yet by doing this –\ncreating a superset – most of REST’s important architectural constraints are\nobliterated. A superset (in this sense of the word) of REST is not REST. Architectural\nstyles combine via constraint intersection, not union.<\/p>\n\n

Slide 32, “Choosing Between Architectural Styles”. Resource oriented styles\ndon’t revolve around cacheability. That’s a small part of the advantages of the\nstyle. There is nothing that is read-only\/mostly\/idempotent specific about its\nstyle. It’s simply optimized for coarse grained data transfer, like document based\nservice oriented styles, only more loosely coupled via late binding. Anyhow, even\nif you disagree, you should at the very least try to defend that position; there’s\nnothing in there that does that.<\/p>\n\n

Slide 33, “Combining Architectural Styles”. See slide 29 comment above.\nYou cannot combine styles in this way, and hope to preserve the constraints\nthat are giving you your desired properties … which brings me to a general\npoint about this presentation; despite the very a propos snippets up front\nfrom the likes of Fowler, Shaw, Kazman, etc.., very little of that experience\nappeared to be reused in the rest of the presentation. For example, I would\nhave expected the presentation to talk about the architectural properties\nof each of the styles presented, and extract from that the domain of applicability.<\/p>\n\n

Slide 34, “How to avoid the Choice of Style”. Yikes. As Neil Peart wrote,\n“If you choose not to decide,\nyou still have made a choice”<\/a>. This is a recipe for failure. Even SCOUT2\nassumes an architectural style, though a mostly constraint-less one (which is\na bug, not a feature).<\/p>\n\n

In general, I had high hopes for this, but with all due respect to Jorgen,\nit needs a lot more work. Not only does it misrepresent the value of the\napproaches represented without backing up its claims, but it evaluates them\nin a context very different from the one accurately(!) described in the first\nfew pages by the gurus of the field of software architecture.<\/p>","protected":false},"excerpt":{"rendered":"Jorgen points to a presentation he’s giving at an OMG Workshop comparing Service Oriented, Resource Oriented, and Object Oriented architectural styles. This is somewhat similar to my REST Compared presentation, though mine was done at a lower level. I’ll jot down some comments here as I read it. Slide 10, “In other words, architecture styles […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-91","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/91","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=91"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/91\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=91"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=91"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}