- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Fri, 28 Jun 2002 13:05:18 -0700
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: www-ws-arch@w3.org
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