Re: Minority objection to requiring unique GEDs or required feature to distinguish operations

On Fri, 13 Aug 2004 11:55:41 -0400
Mark Baker <distobj@acm.org> wrote:

> On Fri, Aug 13, 2004 at 10:53:39AM -0400, Amelia A Lewis wrote:
> > We have clients who will *not* be able to use a standard URL
> > describing a dispatch mechanism, because they aren't using one.
> 
> Of course they're using a dispatch mechanism!  Without one, the message
> can't get to the application.

They're certainly dispatching.  That doesn't mean that they use a single
mechanism (as opposed to several).

> Could you describe in detail what these customers of yours are trying to
> do please?

Sorry, no.  One of them I can't describe, because I don't understand how
it works.  The other two I've described approximately.  I'll try, without
breaching confidentiality, to describe a little more.

It's interesting that there are two of them, actually.  One of them uses a
pretty easy-to-describe algorithm; there's a field (pretend it's called
"command") in each message that identifies it.  Always the same xpath
(this is rpc in wsdl 1.1, so better to say always the same xpath apart
from the root element, taking the first child of the body as the root
element).

It wouldn't be too hard to generate a URL that describes this.

Now, the other uses multiple fields, and the second (and greater than)
fields depend upon the content of the first field.  That is, one
particular operation may be identified by the value "1" in field "root/x"
plus the value "7" in field "/root/a/b/c", whereas another operation is
selected by the value "2" in field "root/x" and the value "4" in field
"root/l/m".  Actually, it's more complex than that, but that's the general
idea.

Question: should there be one URL that says "operation identifier
contained in message"?  Or does every XPath need a different URL?  Or is
there some middle ground, such as a URL per algorithm to determine the
location of the operation indicator?  Note that, in no case are any of
these "operation names" in the WSDL sense; it is possible to build a table
that maps these indicators (singular or plural per message) to an
operation.  Big table, in two cases (one I haven't described; I assume
it's table-driven).

Now, the fact is that nobody is going to connect to these systems (these
are legacy systems, mind, not new design; the goal is to describe them,
then modify and modernize them over time) without knowing stuff, and
putting this sort of complex stuff into the WSDL is just pointless.  I can
pretty much guarantee that these folks are all just going to use a
facility (which *we* will certainly offer them, since we wanna keep their
business) to either turn off conformance with Stupid Requirement, or to
specify an Alkahest URL that dissolves requirements.  If other vendors
don't do the same, fine, we have a nice value-add to keep them locked up. 
But this is *exactly* the kind of thing that leads to incompletely
implemented specifications, because the requirement for this is *STUPID*. 
I'm rather surprised that more people aren't bothered by it; maybe there
aren't that many folks helping build out integration or facades for legacy
systems?  I wish *I* could write all new software whenever I wanted. 
*sigh*

So ... there are folks who won't bother creating a specific URL for their
specific case, because it already requires special work to connect to the
service, and the point of the WSDL isn't to allow random strangers to
connect, it's to document the system as it's modernizing, with the goal of
*eventually* allowing random strangers who use toolkits created by purists
(who can't be bothered to permit customers to deal with problems
pragmatically) to connect.  Eventually.  Eventually, probably, they'll
adopt the best practice, revising the messages and making sure that things
are done in a well-known, easily understandable way.  But they're not
rewriting their bloody systems 'cause a bunch of spec-writers decided to
create a Stupid Requirement.  They'll work around that one.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 13 August 2004 16:22:18 UTC