Donnerstag, 25. Juli 2002

Stupid XSLT Tricks Doug Tidwell. The room is packed. I'm sitting on the floor. XSLT basics. Hello World example. Small templates help reuse. You don't have to transform to a markup language. Small demonstration shows how to generate XML into different output versions. Asks briefly if anyone uses Cocoon. Demonstration also generates Java source code. SVG example. Creating multiple output files using xslt: Use extensions (supported e.g. by xalan - redirect extension). This works by first defining a namespace and then using the namespace inside the xsl stylesheet. Exslt is working on providing extensions in a community process. Next example uses document() function. Question from the floor: "Is it easy to write extensions?" Answer: "If you read my book it is" :-). Next shows recursion and iteration. Recursion is done using named templates. Using document() and sort() together. Document(' ') with an empty string and you can use it to lookup stuff in a lookup table. This means you can put the data into the stylesheet itself. The lookup table must have a different namespace. Use document() function for grouping. Toot-o-matic: Automated tutorial generation using XSLT to generate complete tutorial documentation (HTML, PDF etc.) for IBM DeveloperWorks.

Lunch: Lunch with Doc Searls and we introduced him to geekchalking and of course we geekchalked him. Jeremie Miller dropped by and we played around connecting up the various mac laptops to each other. John "Maddog" Hall dropped by to chat with Doc and introduced himself.

Web Service Discovery techniques. Doug Tidwell. Al Gore said in 1984 that "applications will be based on compositions of services discovered ... dynamically". Web Service example: MagicEightBall. Advantage of Web Services is that you can take existing stuff and put it out on the web. Use Apache Axis and deploy class as Web service. In order to use the service, the client needs to know:: the address of the machine, the id of the service, the name of the methods, the parameters to a method, the contents of the SOAPAction field. SOAP toolkits do most of the work for you. But how do you discover what you need? WSDL, WSIL, UDDI. WSDL: W3C, supported by Axis, WSDL2Java, Java2WSDL, "?WSDL" to generate WSDL from the service. But we still need to discover the WSDL file. WSIL and UDDI: Web Services Inspection Language and Universal Description, Discovery and Integration protocol. With WSIL - I know the host I want to work with. I go to the host and get a list of services (inspection.wsil). Like index.html. With UDDI I do not know the host and therefore it is more difficult. A UDDI server is a SOAP server in itself. Metadata about services can be stored in the registry. The UDDI spec calls this concept: "technical models" or "tModels". Question from the floor: What about contracts and SLAs? Why do I then need UDDI? Answer: These things are being worked on. But because of this most UDDI is inside a firewall. Right way to discover a service: Search in a trusted registry for a service, choose the provider based on criteria, invoke the service. But not feasable outside an institution..

Keynote: Evolution in Action. Jim Kent. Talks about how evolution can be compared to programming.

Keynote:Hacking the Genome: Open Source in Bioinformatics. Ewan Birney. Ewan starts with a crash course in bioinformatics.

Good morning from San Diego: Breakfast with Sam and Erik. Talked with Sam about his views on REST vs. SOAP. Erik's book sounds very interesting as does Ant which can do a whole lot more than what we have been using it for up to now.

Cocoon XML Portal article is up on on XML.com. It is also linked here

Web Services Architectures: Paul Prescod. And I'm sitting next to Dr. Roy Fielding. SOAP 1.0/1.1. RPC style. Static endpoints. Dynamic things do not have URIs (like purchase orders). Shows example in C# and example submit request for a purchase order. SOAP 1.2: is extremely flexible. Choose your own message exchange pattern, choose your own protocol, choose your own methods. SOAP is becoming too complicated and too "open for everyone" (meaning exisiting protocols from other vendors). Solution: Standardize SOAP subset - use URIs for addressing; use SOAP over HTTP. Nouns cannot be standardized because dependent on industry etc. But verbs can be standardized (insert, update, delete). Moves over to introducing REST. REST goals: scalability of component interactions, generality of interfaces, independent deployment of components. REST says: Interactions are stateless (no dependency on previous messages, better scalability, persistant data via URIs). Resources are identified through URIs (any information that can be named is a resource, all logical constructs in a system should be given URIs). Manipulation through representations (resources are not transmitted over the Web - only representations, many representations have URIs to other representations and are therefore "hypermedia resources"). Self descriptive messages (messages should be explicit and clear, no message history, semantics are predefined and globally known). Hypermedia as the Engine of Application state (servers are stateless and messages can be interpreted without examining history, there is no such thing as a service, there are just resources, clients migrate through a series of steps towards a goal follwing hypertext links).

Why SOAP sucks, why SOAP rocks: Matt Sergeant. Why does SOAP suck: Hard to implement fully. Most implementations only implement a subset.Too many technologies (SOAP, UDDI, WSDL). Any SOAP implementors here? Yes. Sam Ruby is here :-). No built in Logging. No security model (yet). SOAP bypasses firewall security measures. No session definition. Garbage collection required on the server to maintain consistancy in objects. SOAP does not scale well. POST vs. GET discussion. SOAP uses POST over HTTP. POST bypasses HTTP caching. HTTP offers other verbs that we should be using - we are GETting a stock quote and not POSTing it. (Now Matt is moving towards REST). SOAP is not human readable. (SOAP)Methods are not enough. Developers need APIs. Google created the WebSevice and then developed APIs (as well). If you are going to implement everything then why SOAP. REST description. Defines the Web as we know it. Writing applications using HTTP. Use the verbs available. Stock quote example using REST. Google example (they already had REST interface - but now only paying customers can use that). Only SOAP interface is free. Benefits: Works with HTTPD (including logging), standard authorisation works - even on a method basis (using different resources). Cache works (such as squid). Persistant sessions are supported. Why SOAP rocks: SOAP::Lite is simplest module for SOAP in any language (Perl). Matt shows SOAP server in 2 lines of PERL. Wow. SOAP client is 5 lines. Other implementations available in different languages. WSDL file makes it a lot easier if you use strongly typed languages. No need to understand HTTP to build SOAP services. Interoperability works unless you have complex needs. SOAP is a W3C standard and easily accessible. Future development is certain. REST disadvantages: No standard. Every application is different. REST works well for borwsers but is harder to adapt for computers. No REST tools beyond HTTPD and server languages. Conclusions: The application will dictate the method. Or customers - or pointy haired bosses. Basically SOAP sucks - but SOAP implementations rock. REST is better if you can use it.

RMS and Miguel: Straight Talking: Caught the last part of this discussion. RMS is basically making his points clear as to where the difference is between Free software and open source. Seems to me to be slightly over the top - but perhaps I need to read his book first. But I'm in the same room as Eric Raymond, Richard Stallmann and Miguel de Icaza - which is pretty cool.

MySQL: From lunchtime-talks it seems as though the database MySQL is being used a lot - especially when it comes to serving data out to the Web from a data-storage system.