It’s just data

Make it so

Patrick Logan: Shouldn't the WS-xxx folks be working with OMG on that stuff? Why isn't "Enterprise Web Services" simply the next CORBA 4.0 release with SOAP optionally (but efficiently) slipped into the stack?

Shouldn't the OMG folks be working with the WS-xxx folks on that stuff?  Why isn't the next CORBA 4.0 release simply "Enterprise Web Services" with SOAP optionally (but efficiently) slipped into the stacK?

Forget conspiracy theories.  Make it happen.


(1) With Microsoft being a major player in the WS arena, how likely is it that they would ever support this idea?
(2) Why should concepts from CORBA, which is (mostly) a tightly coupled, synchronous, RPC-oriented framework, be a good match for a document-centric, loosely-coupled, asynchronous WS-style solution?
BTW, the spell-checker just rocks.

Posted by Stefan Tilkov at

Stefan: whereas Patrick seems to only be able to think of one reason, you immediately are able to think of two.  I suspect that if you were to think about it a bit more, you could come up with plenty more.

My style is not to address such criticisms head on.  If people think that such things are so easy, I simply suggest that they Name That Tune.

Meanwhile, there are people like the developers of WSIF who are doing exactly that.

Posted by Sam Ruby at

Sam,

I can usually think of several reasons for things. I usually write one startling one, because those tend to start conversations and those conversations get me to think in ways I may not otherwise. I have no end of criticism of CORBA and many are in common with WS-xxx.

As for naming the tune, I have no interest. I have participated in "standards" definitions before. They are unsatisfying for me as an activity, but I still have opinions about the process and results. Still it is more than fair to challenge me to this.

None of which means I don't appreciate all that you do, or others in your cadre. I don't have to point out to anyone that you are clear thinking and productive in the most practical sense. Would that this were the norm.

Posted by Patrick Logan at

CORBA... is (mostly) a tightly coupled, synchronous, RPC-oriented framework

CORBA has taken significant steps away from this original position over the last 5+ years, esp. with CORBA 3.0.

The benefit of WS-xxx folks working with CORBA folks (and I don't know that they aren't the same folks already), is not so much in wholesale adoption of CORBA 3.0. Instead it is the incorporation of ideas and lessons learned, from both parties, into a CORBA 4.0 better than either 3.0 or WS-xxx.

Posted by Patrick Logan at

If people think that such things are so easy...

Never said that.

WSIF

Nice.

Posted by Patrick Logan at

FYI:



Posted by Sam Ruby at

Sam,

OK --- after a few similar feeling exchanges and an hour or so after writing "I have no interest" in such things, I'm going to plug in more directly (not sure what form, open to suggestions) into some of the WS-xxx efforts that concern me.

No more shooting from the hip in this topic. I obviously have an interest in such things.

Posted by Patrick Logan at

Patrick: excellent!

If you want suggestions, what I most would like to explore is what is next.  After Web Services.

I occasionally hear talk of an Internet Operating System.  And as a group we obsess on what is the optimal design of an individual neuron.

Something nagging in me tells me that these are the wrong metaphors and that we are are the wrong meta-level.  There is no brain operating system.  The emergent behavior of a brain can't completely be understood by looking at how individual neurons operate.

The future is multi-cellular.  The cell walls aren't necessarily distance, but represent trust boundaries.  It will never be the case that all data will be directly addressible.  We wouldn't want it to be.

Posted by Sam Ruby at

What is next...

Maybe some people want to talk about this in Portland in July.

Posted by Patrick Logan at

Here's what's next; the Web.  Again.

Posted by Mark Baker at

Mark: It will never be the case that all data will be directly addressable.  We wouldn't want it to be.

Posted by Sam Ruby at

Patrick: I would be very interested in such a discussion.  I'll be in Portland in July, bouncing between OSCON and the DevCon.

Posted by Sam Ruby at

The Web doesn't force you to identify all data, it just makes it sub-optimal.  That's a feature.

Posted by Mark Baker at

Mark: Is Linda the web?

Posted by Sam Ruby at

It's not the Web, but it can be integrated into it. rd->GET, out->POST, etc.. just like all other inferior systems. 8-)

Posted by Mark Baker at

Mark, the key point of Linda that when I "out", I don't know who the recipient is, or even how many recipients there may be.

Treat it as an inverted web.

My RSS feed achieves a similar result despite being built upon an inferior system like HTTP, even though architecturally that seems pretty dumb.

Posted by Sam Ruby at

Sam, that's exactly the same as POST.

Posted by Mark Baker at

POST w/o the URI.  In other words, it is a POST to noplace in particular.

Or are you suggesting layering the Linda verbs on top of the HTTP protocol?  HTTP is an application layer protocol after all...

Posted by Sam Ruby at

I'm interested in a What's next discussion at OSCON.

Sam, my autoping to you blog is broken.  It thinks that your pingback url is

http://intertwingly.net.new.cr.sabren.com/blog/pingback

Posted by Ted Leung at

OSCON for sure

I've completed my registration for the O'Reilly Open Source Convention. I'll be in Portland from Tuesday July 8, through Friday July 11. If there's anyone who wants to get together during OSCON, please leave a comment on this entry. I know that Sam ...

Pingback from Ted Leung on the air

at

Pingback seems to be working now.

Posted by Sam Ruby at

I'll keep track of the interested folks. I've had some email from my blog too. As the week gets closer and each of our agendas are more clear, I'll start a search for the best time slot.

Posted by Patrick Logan at

Wiki page created for names of interested participants...

http://www.c2.com/cgi/wiki?WhatsNext

Posted by Patrick Logan at

No, picking a URI for POST is the same as locating a tuple space on which to invoke out().

I wouldn't layer tuple spaces on top of HTTP, because HTTP already provides me a tuple-space-like network abstraction.  I may extend HTTP to provide more tuple-space-like actions, like oh say, notify()/NOTIFY/MONITOR (ala KnowNow).

Posted by Mark Baker at

Hmm.  Directing all posts to a single URI.  Implementing new verbs which are not uniformly available.  Sounds familiar.

Posted by Sam Ruby at

Hmm, nope.  I think you're missing something, though I can't tell what.  Here's my model;

tuple space <-> resource
tuple <-> representation
tuple space identifier <-> URI
tuple space server <-> Web server

Posted by Mark Baker at

Mark:  Let's see if a concrete example gets to the bottom of this: Weblogs.com has an XML-RPC interface. One 'pings' it with a tuple (weblogname, weblogurl).  The resource is http://rpc.weblogs.com:80/RPC2.  The weblogs.com identifier is clearly a URI.  And the weblogs.com server is clearly a web server.

Given that these two things are apparently isomorphic, I am having a hard time understanding why you have a visceral reaction to XML-RPC, and yet appear fairly comfortable with Linda.

Posted by Sam Ruby at

Well, in that example, the application semantic is "ping" and the tuple is, as you say, (weblogname, weblogurl).  In a truly tuple space based or RESTful solution, the application semantic would be out()/POST, and the tuple/representation would be the same.

So you'd have a URI and you'd out() or POST the (weblogname, weblogurl) tuple too it.  The "ping" semantic would not be present on the network interface; it would be a side effect of the out()/POST action to that URI.

Posted by Mark Baker at

In a Linda space, an "out" would not equal a ping.  There would need to be another application which "in'ed" the data.  There would be an out of band agreeement between the source and the destination as to what tuples would represent a ping (as opposed to any other data inserted into the tupl-space).  This information would, by necessity, be contained within the tuple.

Posted by Sam Ruby at

Agreed completely, but there are two different ways in which that information can be included within the tuples; via nouns or verbs.  The Weblog ping example uses verbs, while the Web uses nouns.  The advantage of the latter is that visibility is improved.

Posted by Mark Baker at

In the case of a weblog ping, there is only one documented service for that URI, so any other encoding of this information in the datastream is redundant.

In the case of a Linda tuple, if there is any other use of the this tuplespace, then there must be some other indicator in the tuple that conveys the information that "this is a ping".

Bottom line, from purely a REST perspective, XML-RPC is not inherently evil.  Nor is Linda a reinvention of the web.  There are profiles of each which conform to REST.  And there are usages of each, as there is with HTTP, in which knowledges of application state is implicit in client to server interactions.

Posted by Sam Ruby at

Add your comment