This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Smalltalk and XML on the Web
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
XML On the web - where it's going. He's talking about his company, Wizard Information Services. Located in Canberra, Australia, started with VisualAge Smalltalk - has been doing so for 7 years. They were sold on Smalltalk originally by IBM, but all the IBM people now push Java. What did they start with?
WizDom
Core Framework
Object Oriented
Pattern Oriented
"Naked" Business Objects
Mavis
Merged Audio/Visual Information System. Major customers:
Library of Congress
AMPAS (Oscars)
Bundesarchiv
National Library of Norway
Screensound Australia
MetaWizDom
Content mgmt and bsuiness transaction system
Running over 35 websites for Australian govt entities
MetaGrants
Govt grants mgmt system
2 customers - Brisbane City council, ACT government
All Communities Online
online communities - like Ezboard, but govt/community oriented
Make simple pages online
publish events
Categorized
Used by ACT government - over 1000 community groups
Goals
Web Enable all applications
X-enable every application
Interfaces to and from external systems
Expose "naked" business objects using trusted APIs
General Goals
CRUD apps (plus search)
Achieve "browser based" UIs as well as traditional GUIs
Reuse "web" technology
Open
Architecure
Here we have a picture - client tier - WithStyle. Middle Tier - VW and VA apps. Why HTTP and XML? Well understood, everyone has it, XML can be dealt with regardless of implementation language used by others. Easy to read and debug by a developer. XSLT? Lots of knowledge in house (Wizard). Well supported by Cocoon and WithStyle. SOAP? industry buzzword. Works better than XML-RPC, well supported by VW and VA. Most developers at Wizard prefer HTTP and a "REST" interface. Apache Cocoon? It's the web publishing framework they use. Based around XML. Supports HTTP, XSLT, and SOAP. Something well done in Java. WithStyle - written in Smalltalk (VW). Can talk XML to the server rather than HTTP. Richly supports HTTP, XSLT, SOAP, REST, and Smalltalk. Great UI experience.
Database to Objects? Using Toplink (VA). Moving to GLORP. Almost enough information in their descriptors (business level) to generate an XML Schema. Downside - XML Schema does not map well to Smalltalk OO designs. Very large and cumbersome. Is barely machine usable - don't want any actual people looking at it :) SOAP doesn't equire it - industry wants it. They generate it, since it's such a PITA. They use the descriptors from their db layer to do so. Basically, use the "meta" information for one transform (object to db) for another (object to xml). Good thing - VW and VA both have SOAP frameworks. They have business objects already - they translate SOAP into Smalltalk using XSLT. Quote:
It's not as disgusting as it sounds
ST Server - take request, translate into a SOAP request. Turn SOAP into Smalltalk. Execute the Smalltalk. Cocoon deals with the ST server for back end services. Validates user id and passwd via the ST server. All requests to the ST server ae done with the session ID and the user ID. HTML Forms? Template XSLT for making forms, ST Server transforms the HTML form value pairs into a SOAP request, which then goes through the normal execution path.
Ahh, a demo. He's got Cocoon running in the background, a VW server, and a VA server. Going to the Smalltalk server directly yields an XML doc. Going via Cocoon round trips to the ST server, uses Cocoon to apply XSLT to it and display a web form. Some nifty stuff in the demos, again.
Previous Topic
