On 30/06/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > [SJ] I'd disagree with those two paragraphs as as a consumer or a producer > the real world effect is the same and while there are some different elements > I'm not seeing how it isn't just a remote procedure call. > > > [SC] Here's a (admittedly clumsy) attempt... > > In any standard RPC -- DCE, DCOM, CORBA, etc., how does one reference an RPC > invocation ? > > i.e. if I want to tell someone (a human, or piece of software) "To begin > this business process, and get a status ticket, please call this RPC on this > server", how can I encode this in a universally interoperable way, that's > both machine-understood and human-understood, and independent of any > particular hardware or programming language -- and potentially any network > protocol ?
[SJ] "Here is my Interface load it into your IDE" works for CORBA and SOAP/WSDL and more. Or to be more trendy "Here is my service definition load it into your service development environment" [/SJ] > > I haven't seen this in any RPC-based system. I've seen it in HTTP (URIs), > and to some degree, in SMTP (email addresses). This is one of the missing > keys in traditional RPC -- a split between the thing (a web page, a process, > an email acocunt) and a reference to the thing. [SJ] Those don't describe service interfaces but data exchanges [/SJ] > > IORs and GUIDs don't go all the way, and fail the human-readable requirement. > WS-Addressing EPR's come close to a transfer-protocol independent way of > doing this at the expense of complexity. http://mail.gogle.com/mail/?auth=DQAAAHDFcBO0r4YnuwawkfrLsdan_LqEGtV41eieKvPdiI7-HGhTjxrKcSrzPtlFJ0H9CGzoIyd-r8qy3N07uFb3EfYtjRunq2Xmkv8Wn3RKQHedL3ejDC8UZrc-3-EE_BvSi2ImxnvQHyAQax9pYrHQR9t8Yz20tcOZN8hVcNMe_xP0A&zx=5sn5x2nn4p8j&shva=1 Is the slightly edited URI from my gmail account... not sure that is human readable. XML certainly isn't human readable. What I like is grabbing an interface spec (be it Java, C# or WSDL) and lobbing it into a visual tool so I can see a picture of the interface. > > [SJ] I might be missing something but that describes > REST/SOAP/IIOP/RMI/rsh/etc and in my simple world is what RPC is all about. > > [SC] At a base level, yes, if all you're trying to do is communicate between > systems. > > But, with ideal SOA, we want to do this in a way that's cheap, exhibits > network effects (due to compatibility), tolerates latency & failure, and is > decentralized. > > So, let's add a few constraints to that: > a. You, the application developer, are used to making your own interfaces > with RPC systems, based on whatever you feel like for your particular system. > Loose coupling suggests "stop doing that". The more general the audience, > the more general your interface needs to be. [SJ] Ummm this makes an assumption that application developers should be designing interfaces, interfaces are just the technical realisation of the service definition their format and function should already have been thought about. This is why (for me) this argument is pointless. And I'd definately disagree (and it has nothing to do with REST v WSDL) that the more general the audience the more general the interface. [/SJ] > > b. Split the thing (RPC/RMI/resource) from the reference to the thing (WS-A > EPR or HTTP-URI) so I can tell others precisely and simply what to call and > what the expected semantics are. [SJ] RPC isn't the thing, the SERVICE and its CAPABILITIES are the things. You are talking about the technologies. [/SJ] > > c. Assume stateless interactions to ensure any interaction can potentially > tolerate latency & failures. AAAAAAAAAARRRRRRRRRRGGGGGGGGGHHHHHHHHHHHHHH The biggest myth of SOA is that services should be stateless (Made me write this http://service-architecture.blogspot.com/2006/06/shooting-myths-of-soa.html) > > d. Ensure your interface and wire protocol is future proof: it should be > extensible, meaning it can add new operations in the future, and allow expose > customized/extensible metadata at runtime. It also should be support new > data types in the future, data volumes of arbitrary size, versioning & > evolution of those data types, and not break when arguments need to be > re-ordered or re-named. Again this is about technical implementation of the execution context. > > If you had modest requirements, I'd suggest HTTP and URIs are a good > solution to the above, and most existing RPC systems, by default, do not > handle the above constraints easily. But they don't define either the service or the capabilities, so how does any consumer know what it is? > > If you have sophisticated requirements, then absolutely another messaging > mechanism & protocol would be appropriate. > > Cheers > Stu > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/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/
