Yes, we will look at SOAP and other solutions, not
for any marketing reasons, but...
At 10:09 PM 6/27/2001 -0700, Roy T. Fielding wrote:
On Wed, Jun 27, 2001 at 06:09:31PM -0700, Mark Nottingham wrote:
> On Wed, Jun 27, 2001 at 04:27:13PM -0700, Roy T. Fielding wrote:
> >
> > Excuse me, Lee, but I am getting tired of the marketing bull
> > associated with SOAP.
>
> So don't listen. Or do you characterize people bringing up SOAP as a
> possible solution for OPES as 'marketing bull'? I know it's Not
> Invented Here, but not everyting good in the world was brought to us
> by the kind benevolence of the IETF.
How can I not listen when there are so many people that are being paid
to market the concept to all of the protocol and standards forums in which
I actually try to get work done? I get five of these messages a day from
folks who have never even attempted to build an Internet service.
SOAP is certainly a possible solution, as I said in my message, but it
isn't a good solution. I have no problem with people implementing it and
*then* evaluating it as a solution for OPES. I have a problem with
the pot calling the kettle black for marketing reasons within a forum
that is supposed to be a potential IETF standards-track working group.
I would have the same problem if iCAP forum folks used SOAP's heritage
to denigrate SOAP as a solution.
Ok, provide the group with some evaluation criteria so we can
apply it to the problem space.
> > The fact of the matter is that SOAP was defined by a far smaller
> > group of people with no open industry involvement and then moved to
> > a pay-per-view pseudo-standards body for ratification.
>
> IME, technology that is initially defined externally, and then
> refined by the IETF process is most likely to succeed.
As was the case for HTTP. I don't advocate designing a protocol within
an IETF working group, but the IETF is the best way to find discrepancies
between a specification of a protocol and the implementations of it, as
well as pointing out design flaws in what has been designed. It is therefore
the only forum which I respect for Internet protocol standardization.
If you want to see an excellent example of how a new protocol should
progress through the IETF, look at the BEEP working group. I don't agree
with all of the design decisions behind BXXP and BEEP, but the way in which
input from the Internet community was welcomed and accepted was flawless.
> Besides which,
> SOAP was brought to the IETF, and deemed too scary-application-layer
> to touch.
No it wasn't. It was plopped into the ID pile, evaluated and determined
that it sucked, and since then it has been reworked to suck considerably
less than it did before due to a lot of private work between IBM and
Microsoft. Nevertheless, it is still the least efficient RPC syntax
ever invented.
> The W3C is indeed membership-based. So what? BTW, the W3C does not
> characterize itself as being a standards organisation.
What it means is that the product of W3C working groups are never evaluated
by the people who implement the products of W3C working groups. They are
evaluated by standards weenies appointed to represent each company in that
forum, and technology decisions are made according to what features have
already been pre-marketed to the public rather than what has actually
been shown to work in implementations.
> > It is not and never has been implemented in real Web services, in
> > spite of the marketing splash of "Web Services".
>
> What exactly are 'real Web services'?
Services that are accessible via the Web. Actual working systems that are
being used for more than demo technology and which are subject to the
wider Internet. That is the only kind of system for which we need
interoperable standards developed within an IETF forum.
> > This doesn't mean it is better or worse than iCAP, but it is
> > completely foolish to disparage iCAP for being developed outside
> > the normal IETF process when SOAP didn't even come close to that.
>
> I've participated in both iCAP and SOAP development, and would
> certainly not characterize iCAP as more openly developed than SOAP.
So have I, and my opinion differs. I wouldn't categorize either one as an
open specification (where the contents were determined by rough consensus).
> > There is no reason why people can't implement an iCAP-like RPC
> > mechanism in the form of SOAP over BEEP (or whatever), but until
> > someone does it and actually deploys it for a real application, any
> > claims about its suitability for this purpose are just marketing
> > bull.
>
> I resent your characterization of anything to do with SOAP as
> 'marketing bull'; this group is trying to explore what the best thing
> to do is. Ruling out options based on prejudice doesn't seem very
> open, now, does it?
I didn't characterize "anything to do" with SOAP as marketing bull. I said
that the message that Lee posted was marketing bull. Marketing bull has
its place, but here is not one of them. And if you read what I said, you
can see that I expressly did not rule it out as an option.
> > Just to be clear, I don't like iCAP as a protocol (I have
> > implemented an earlier version) and I don't like SOAP as a protocol
> > (even though the only real implementation of SOAP is now an Apache
> > project)
>
> Are you purposefully ignoring the 50+ other implementations? Or is
> something only 'real' when it's associated with Apache?
No, I am unaware of any 50+ other implementations. I can show you 75 or
so pre-announcements of tools that will one day implement Web Services,
but I know of only one implementation of SOAP as specified that will
actually run. It was the IBM one that is now in the Apache SOAP project.
There are a lot of other implementations that reuse that code, but I don't
consider those to be separate. The last Microsoft one doesn't implement
SOAP as specified, though I expect the recent Windows XP beta has fixed
that by now [I haven't seen it]. None of those have attempted the type
of large-grain message exchange that is typical of the OPES space, though
Henrik's latest additions to SOAP in the form of attachments are certainly
a step in that direction.
There may be hundreds of other SOAP implementations that I don't know
about, but since they haven't been used to build real services yet, it
is hard for me to evaluate them. In any case, what matters right now are
the requirements of the OPES working group as expressed by the charter.
....Roy
The existence of a multiple implementations is a good thing but it
is the only criteria specified. That is not a very good one to evaluate
a protocol. How about coming to the meeting (assuming things happen
in London) and lead a discussion on what good criteria for measuring these
protocols would be? Mark has already signed up for one item...
Michael W. Condry
Director, Network Edge Technology