Re: Tool support goal

Tools are pretty important, more important than you might expect if you 
were (I assume you are) an expert programmer.

On Thursday, June 27, 2002, at 06:36  PM, Champion, Mike wrote:

>
>
>
>> -----Original Message-----
>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>> Sent: Tuesday, June 25, 2002 8:33 PM
>> To: www-ws-arch@w3.org
>> Subject: Tool support goal
>>
>
>> D-AG010 The Web Services Architecture shall, where possible, enable
>> semi-automatic tools to support the construction of web services.
>
> I'm skeptical of this as a goal.  For one thing, I think it's 
> backwards --
> if we meet the other requirements -- modularity, simplicity, etc. -- and
> specs follow the architecture, then tool developers will be able to 
> automate
> the WSA with little difficulty.   Second, I think it's more important to
> ensure that web services can be built WITHOUT tools than with them.  
> This is
> a common issue in the debates between advocates of W3C Schema and 
> advocates
> of RELAX NG.  On one hand tools to minimize the labor needed to build 
> W3C
> Schemas are readily available; on the other hand, all but the most
> specialzed experts NEED tools to build non-trivial W3C schemas.  I hope 
> that
> at least simple web services remain hand-codeable and human-debuggable.
>
>

The problem here is the `double PhD' problem -- sure, anyone with a 
sufficiently deep understanding of the protocols, architectures, support 
etc etc. can build a web service by hand. But, in practice, the number 
of sufficiently experienced professional programmers who haven't been 
kicked up into management is always going to be low.

The real goal here is to keep an eye on the folks who will have to write 
web services for a living, and who will need all the help that they can 
get. By making it easier for tool vendors to support the average 
J.Hacker, we will make it safer for the rest of the world. Besides, as 
you pointed out, a lot of it is simply sound software engineering 
principles.

(BTW, as far as human readability is concerned, we all start with one 
hand tied behind our backs with a rope called XML.)

It is my opinion that if you do the software engineering right you will 
be able to build a web service by hand; but the converse is not true.



>
>> D-AC027.1 It is important to prohibit or discourage the use
>> of ANY type in descriptions of services and choreographies.
>
> I'm not sure what this is getting at, what it has to do with tools, 
> etc.  I
> fear that it is saying "let's promote tight coupling driven by schemas 
> to
> make the world safe for automation."  That tends to make it unsafe for
> humans, in my experience anyway :~)

This LOOKS like a highly bizarre and specialized kind of CSF, but there 
is a fair amount of thinking behind it.

If you use the ANY type then you also give up any support from tools. 
That is because semi-automatic tools need meta-level information (such 
as types) to gain traction. Again, if an architecture REQUIRES that data 
is made available as ANY then you give up most hope of automating the 
process. However, it is definitely the case that being upfront about 
types adds to the programmer's burden and can also act as a kind of 
straightjacket. This is especially the case when using simple-minded 
type systems (such as XML-schema?)

A parallel case here is in the filed of knowledge representation. 
Because humans have, to date, been the knowledge generators and because 
of the untyped history in AI languages, 99% of KR are untyped; worse 
they are `aggressively untyped'. This had a number of consequences -- it 
was (is) very hard to integrate a LISP program (say) with a Java program 
(say) because of the impedance mismatch in the type systems.

Similarly with web services. Eventually, all those interfaces must 
result in ordinary code (OK extra-ordinary code if you are a wizard) 
being executed. Given that that ordinary code is written in Java then 
the types of the program either have to be exposed to the user (e.g. 
SOAP client) or someone has to go to a lot of trouble mapping the 
untyped data into the typed data. (This is independent of early vs late 
binding)

The ANY type is an untyped structure, and therefore hard for a Java 
program to deal with. (I am aware of the DOM, and that doesn't really 
help: that gives the data's meta-structure in Java terms, but the Java 
server needs to get to the object data that is encoded)

>
>> D-AC027.2 The WSA shall permit automatic validation of web services
>> D-AC027.3 The WSA that allow for the automatic testing of web
>> services
>> and choreographies.
>> D-AC027.3.1 Permit construction of test coverage suites
>> D-AC027.3.2 Permit construction of client validation and server
>> validation test suites
>> D-AC027.3.3 permit document verification and automatic document
>> generation (a la Javadoc)
>
> These seem like worthwhile objectives, but I'm not at all sure what the 
> WSA
> could say or not say to affect them.  They're more general requirements 
> on
> specifications derived from WSA, no?

What these amount to is a series of gotchas -- like the ANY type -- that 
we have be aware of. I don't know them all, but, like security, 
validation is better designed in than tacked on afterwards.

>
>>
>> D-AC028 ensures that best practice modeling of web services is
>> supported; and that best practice tools can help automate the
>> construction of web services
>
> Is "best practice" REALLY well-established here?

We do our best ;-)

>>
>> D-AC028.1 Permit and encourage the use of standard modeling
>> language, in  particular UML, to model services, orchestrations and
> service
>> compositions. This may require extensions to UML.
>
> I think this was discussed in reference to another proposed 
> requirement, and
> got a lot of pushback.  I'm not a UML user and have no strong opinions, 
> but
> I get the sense that this is a "best practice" that works a lot better 
> in
> theory than practice.  And I would VIOLENTLY oppose taking on the task 
> of
> extending UML to make it web-services friendly; that's clearly a job 
> for the
> maintainers of UML.
>
>

It is pretty unlikely that we would need to modify UML in any 
significant way. That phraseology is there to protect us and to avoid 
setting up a hostage to fortune.

Received on Friday, 28 June 2002 16:05:23 UTC