On Fri, Sep 16, 2005 at 11:47:30AM -0600, David Forslund wrote:
> I enjoyed reading your article, but I think it fails to justify its
> conclusion. The "placeOrder" may be implicit in your second (simpler)
> example, but the second
> example has a very different semantic meaning that the one with the
> "placeOrder". One uses a verb and the other doesn't. There is no way
> of knowing what is intended
> to be "done" with the purchase Order in the second example without an
> "out-of-band" communication which would tell the person to send this
> message if they want to place an order.
Great observation, David! I had considered this, but the reason I
knew what Anne intended in the document oriented case, was because it
was presented as an alternative to the RPC example where that intention
was explicitly declared. Check my response to Dims in the comments for
a more detailed explanation.
But you'd have been bang-on if that document oriented example were
presented alone; it's just data, as you accurately describe.
>What if they want to know if
> they the user knows anything about the purchase order? This is a
> separate agreement. Thus I think you have set up a "straw man" argument
> in comparing two different meanings or intentions of sending a
> message. It may illustrate your point you want to make but verbs are
> important in determining what to do with "nouns". If we only spoke with
> nouns, and no verbs we wouldn't be able to communicate. I think the
> same thing applies to communicating on the Internet.
Agreed.
>But RPC's do work
> on the Internet. It is what happens with DNS, LDAP and other services
> that work very well and are the ubiquitous backbone of the Internet.
I am sympathetic with that view of RPC. I've used it myself in the
past, to try and make a point. Why I don't use it anymore can best
be explained by example ...
Even if DNS and LDAP used the exact same, perfectly interoperable, RPC
layer, could they interoperate? Could a DNS client get data from an
LDAP server? Could an LDAP client get data from a DNS server? Of
course not. Therefore, even though it is true that these systems use
RPC in the sense that "remote operations are invoked", describing
systems in those terms doesn't help to understand their affinity for
each other. It's an insufficient descriptor.
> The semantics of a request must be accomplished regardless of the
> protocol to send the information. The protocol isn't that essential,
> but the semantics of the request is.
I see that I didn't make my point. 8-(
Application protocols define application semantics. They are not
"protocols" in the same sense of the word used in systems like CORBA,
DCOM, RMI, Jini, etc.. IMO, that's the root cause of the
misunderstanding. If these things had been called "locotorps", this
confusion wouldn't exist; "protocol independence" would be a good
idea, since protocols just move bits around. But "locotorp
independence" would be silly, because everybody knows that locotorps
define the application semantics, and how can an applications be
independent of application semantics?! 8-)
Consider these two (short-cut) example HTTP messages, both reusing
the document from Anne's document-oriented example;
POST some-uri HTTP/1.1
Content-Type: application/soap+xml
<env:Body>
<m:purchaseOrder xmlns:m="someURI">
...
</m:purchaseOrder>
</env:Body>
vs.
PUT some-uri HTTP/1.1
Content-Type: application/soap+xml
<env:Body>
<m:purchaseOrder xmlns:m="someURI">
...
</m:purchaseOrder>
</env:Body>
Those two messages have different application semantics. The former
means "process this SOAP envelope", the second means "store this SOAP
envelope".
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
