This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Procor Experience Report 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. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Procor Experience Report, Val Balovnev, Procor

(The beginning of this clashed with the end of a competing talk so I missed a few minutes.) Procor is a rail company. (Special offer: come to Val's talk and you'll get a free ride. When you get to the talk you learn it's on a tanker car as that is their business :-)). Procor is based in Oakville, Ontario. It has Canada's largest private rail car rental fleet.

In 1996 they moved from Enfin Smalltalk to VAST. Every fortnight they have a problems and answers session for all Smalltalk developers. They also have a 30 minute tips meeting every week. They push design patterns and Smalltalk books on all developers. They have standards for web app appearance, etc. They have four teams of 3-4 each and a couple of experts.

They have 40 VA apps, of which 26 are web-based (intranet), one on internet. All apps are specific to a line of business. Some are also used by their U.S. affiliate (Union Tank Car company). Why 26 web-apps, not fewer? There are advantages (independent simultaneous development, Line-of-Business specificity) and disadvantages (duplication of business logic, integration difficulties).

Their repair shops, etc., are widely scattered so web apps were attractive (needs no client installation, etc.; the limitations of web connection was also a plus, not a minus in their environment). They use iPlanet web server, DB2 and VAST, and have some in-house frameworks for security, cascading web menus, etc.

As their web app suite grew, the need to share business logic became more important. They have left server workbench and web services for future exploitation, concentrating on the last of the following possible reuse approaches:

• put business and mapping objects in every app: this raises versioning problems
• pass user to relevant app whenever reuse needed, passing login ID, etc., in URL: this would need encryption and pushes the limits of what can be passed in the URL
• Use apps as servers: App 1 requests info from App 2, gets back info, display in App 1 UI. This is useful for integrating legacy apps but is still a URL-based request, so needs complex URL data formatter
• share objects using XML and MQ: this is the route they have chosen and are developing. Each app talks via an MQ queue to an XML app sitting between the web apps' queues.

The user can pull data by logging in and navigating. They also push data: user defines requirements on login and they email the use with this data daily, or provide it whenever they login, fax it, whatever. The key business value of this is that it reminds the customer they exist.)

They use HTML, XML, JavaScript and CSS on their front-ends and use their imagination to exploit Smalltalk's power on the server.

Q. Web browser conflicts. Most customers are intranet, so can be told what web browser version to use. External web app is simple on client, complex on server. They have many problems with the back button therefore much data put in session data. (He will be going to Avi Bryant's Seaside tutorial.)