New Home for SOFEA, Thin Server Architecture

Peter Svensson has set up a website where like-minded people can discuss the brave new world of applications whose common characteristic is that no aspect of presentation logic resides on the server side. I admit that's an overly broad-brush generalisation, and it will be necessary to read what the various authors of this camp have to say.

In addition to the SOFEA paper that Rajat Taneja, Vikrant Todankar and I co-wrote last year, the site has Peter's articles on The End of Web Frameworks I and II and Mario Valente's four articles 1, 2, 3 and 4.

The site is admittedly a bit rough round the edges at the moment, but we will be polishing it as the days go by, and we would welcome community feedback. For the moment, since the site itself has no comment facility, you may comment here, or send me a mail (g dot c dot prasad at gmail dot com).

Context Diagrams as a Tool for SOA

Pursuing the theme of reverting to a form of procedural thinking to implement SOA, I remember how we used to draw Context Diagrams and Data Flow Diagrams (DFDs) as part of system design in the eighties. Context Diagrams were also called DFD Level 0. We used to draw the system being designed as a single bubble, and show all interactions (dataflows) with external parties (drawn as rectangles) as a set of arrows going back and forth between these external parties and the system.

To draw the Level 1 and Level 2 DFDs, we used to "explode" the single bubble into "modules". The dataflows shown in the Context Diagram would still need to be shown, but this time, (1) the arrows would terminate at one of the smaller bubbles representing a particular module of the system, (2) the external parties themselves would no longer be shown and (3) there would be new arrows showing dataflows between modules of the system and not involving external parties.

I now think the Context Diagram is the modelling tool for SOA. The dataflows going back and forth between the system and external parties that deal with it form the "service contract". We can express this in SOAP or REST terms. That really doesn't matter.

When we begin to "explode" the single bubble representing the system as a whole into smaller "modules", we are entering the world of domain design. This is no longer SOA. In the old days, the inter-module dataflows were also procedural. Today, they're method calls on objects.

I wrote earlier that when a student embarks on the study of Zen, the mountains are nothing more than mountains. Partway through the training, the mountains are no longer mountains. But finally, when the student has mastered Zen, the mountains are once again mountains, but they're somehow not the same as what they were.

Here's the SOA analogy:

Back in the eighties and early nineties, when systems and modules were purely procedural, we used to draw Context Diagrams and consider them to be Level 0 Data Flow Diagrams. Then we used to use the same paradigm to further explode the Level 0 DFD into Level 1 and Level 2 DFDs.

In the mid-to-late nineties, when OO thinking predominated, we stopped using Context Diagrams and DFDs altogether. We started using UML's Class Diagrams and Sequence/Interaction diagrams and began to look down upon procedural thinking.

In the new millennium, with SOA thinking in vogue, we need to start using Context Diagrams once again to define our service contracts, but we must no longer use the same paradigm to "explode" the single system bubble into modules. Leaving the Context Diagram in place, we must dive below that level and independently model the underlying domain using OO thinking. Alternatively, we build the domain model first, and then independently draw a Context Diagram around it, with a single bubble completely encompassing the domain model and terminating dataflows to and from external parties. Either way, we must then reconcile the two layers by creating a layer of "services" that sit within the Context Diagram's bubble and outside the domain model and translate between the external-facing procedural view and the internal-facing OO view. This service layer would be responsible for the specific transformation that I call The Viewpoint Flip.

A diagram would illustrate this better.

So you see, grasshopper, the mountains are once again mountains, are they not? But they're not the same as when you started on this journey. The Buddha-ness pervades all things, but the SOA-ness and Object-ness live in different worlds.

Sun Tech Days Sydney - Day 3 (Community Day, 6 March 2008)

(I've already blogged about the first and second days.) There were 5 tracks on this (third) day, called "Community Day": GlassFish, NetBeans, Mobility, Solaris and Sun University. I attended 3 sessions each from the GlassFish and Mobility tracks.

Alexis Moussine-Pouchkine provided an introduction to the GlassFish project. GlassFish is almost exactly the same product as the Sun Java Application Server. The latter has a couple of extra proprietary bits added, and also provides more frequent updates.

A few tidbits that I noted:

The admin console looks pretty professional, unlike Tomcat's minimal one, and unlike the ugly raw JMX that I've seen in the past with JBoss (I haven't used JBoss in a while, thanks to Spring and Tomcat). GlassFish's admin console is even better than Geronimo's, which I thought was pretty good at the time. It's task-oriented, so users will find it easier to find what they need.

GlassFish logs to a bundled JavaDB database (Cloudscape/Derby).

Apparently, GlassFish has a third container apart from the web and EJB containers. It's called the ACC (Application Client Container). Developers can build a Swing client and bundle it with the ear file. Java Web Start is used to deliver it. Dependency Injection can be used even with the client.

In cluster mode, GlassFish keeps Applications, Configurations and Resources consistent across the cluster. GlassFish uses a dynamic clustering feature called Shoal that is built on top of JXTA.

There's a project called SailFin which is meant to bridge HTTP and SIP. This is useful not only for the telecom industry but also generally, to provide rich media capabilities to enterprise apps.

I haven't explored Sun's Portal offering before (OpenPortal). That's another thing on my growing to-do list.

GlassFish has a number of components:

The GlassFish App Server itself
OpenPortal (portal server)
OpenESB (Enterprise Service Bus, of which more later)
OpenSSO (single sign-on solution)
OpenDS (directory server)
Jersey (for RESTful services)
Hudson (continuous build)
jMaki (aggregates Ajax widgets and provides a common API wrapper)
jRubyOnRails
OpenMQ (message queue)
WoodStock (JavaServer Faces components)
JavaDB (Apache Derby pure Java database)
Apache Roller (blog software, one of the "Enterprise 2.0" offerings)
Slynkr (social tagging software, another of the "Enterprise 2.0" offerings)
SailFin (SIP-HTTP bridging software)

Here's the GlassFish project wiki that provides ongoing detail about the project.

David Pulkrabek from Sun's labs in Prague spoke about the future of JavaME development tools, and his demos were very impressive.

He showed a demo of how to record and replay a set of actions, that could be used in automated testing. Then he showed a demo of how a Sun SPOT device could be used to capture sensory inputs like orientation and 3-dimensional acceleration to control a game on a mobile device. Could this power the next Wii?

Next he showed how real devices and emulators are treated the same by toolkits. A mobile phone plugged into the laptop with a USB cable is detected by the tools, and the debugger can execute applications on the mobile phone, with breakpoints and variable editing, just as in a local emulator. The output of the mobile phone can be redirected back into the toolkit's console.

Very impressive. I think JavaME developers have a pretty good set of tools at their disposal, thanks to the work done at Sun's Prague labs.

But even JavaME pales into insignificance when compared to JavaFX Mobile. This session was from Noel Poore. JavaFX Mobile is a rather unfortunately named piece of technology, and will continue to cause Sun grief because of the needless confusion with JavaFX Script. Let me clarify. JavaFX Mobile is the name of a mobile device platform that Sun acquired when it took over SavaJe in May 2007. JavaFX Script is a new (as yet unreleased) scripting language for the UI, which essentially reduces Swing programming to a declarative style. Yes, JavaFX Mobile supports JavaFX Script, but that's the only (tenuous) connection. Sun should stop these silly and confusing names (The Java Desktop System was another one. That was just a Linux (or Solaris) desktop that could run Java).

JavaFX Mobile is based on the Linux kernel and Java SE. Note that it's Java Standard Edition, not JavaME, the Mobile Edition that the previous session dealt with. This has two major implications. One is that the full range of Java features is now available to mobile devices, not just the subset that JavaME used to provide. Second, from a market viewpoint, it removes the fragmentation that the various JavaME implementations necessarily suffered on account of their having to be tailored to devices. JavaFX Mobile is now a full-fledged platform that can take on the iPhone or Google's Android. It can still run MIDP Midlets, but Sun would encourage developers to build full-featured JavaFX Script-based UIs and applets rather than the comparatively anaemic Midlets, now that the full capabilities of a JavaSE platform are available.

The platform has three components: Core, Frameworks and User Experience (Applications).

Core: Kernel abstraction, Linux kernel 2.6, Core graphics, Core networking, Media engine, Device drivers, Filesystems and a C library (not glibc)

Frameworks: Content management, Java, Web content, Provisioning, Graphics, Connectivity, Multimedia, Networking, Messaging, Telephony

User Experience (Applications): Calendar, Browser, Phone, Camera, App Selector, Personal Utilities, Media Player, Content Viewer, System Utilities, Contacts, Messaging Apps, Home Screen, Themes and third party apps

Messaging includes IM and Presence (OMA IMPS and Jabber).

Jim Weaver (who has written many books on Java, including J2EE 1.4 and JEE 5) spoke next about JavaFX Script and showed a few demos. I'll just sum up my impressions on JavaFX Script.

First, JavaFX Script is to Swing as Groovy is to Java. It's a lightweight scripting approach to building GUIs, and it uses a declarative style.

Second, although JavaFX script is far less verbose than the equivalent Swing code, it still unfortunately looks like the dog's breakfast (compared to Flex, for example). I think it will only become popular when a graphical editor is layered on top of it.

I always like systems that are based on textual files that can be edited by hand if required, compared to systems that store data in binary format. But that doesn't mean I want to use the text editing approach exclusively. "Build graphically and tweak textually" is my motto for GUI development.

Michael Czapski from Sun's Sydney office spoke about JBI (Java Business Integration) and OpenESB.

Historically, approaches to integration have ranged from file transfer through shared databases and EAI to messaging. Messaging is the model currently in vogue. Models have progressed from point-to-point, through hub-and-spokes (brokered) to the "bus", which is a distributed, logically decoupled, anywhere-to-anywhere model.

ESB's facilitate a messaging-based bus model of integration.

JSR 208 deals with Java Business Integration, another unfortunately-named standard that doesn't immediately explain what it does.

This is a standard that governs how ESB components plug into the bus, allowing integrators to mix and match components from different sources to build up a "bus". I think it's more relevant to those who write components like adapters, BPEL engines, XSL transformation engines and the like rather than end-user organisations (like mine) that want to use a bus to integrate their applications. The latter don't care how the "bus" was put together, whether it is a monolithic piece of technology or a pluggable architecture that has components from different sources. [Well, we should care from a vendor lock-in perspective, but functionally, it makes no difference to us.]

JBI standardises component interfaces, component lifecycle (start, stop, deploy, undeploy, etc.), deployment model, monitoring and management, among other things.

It fosters loose coupling through WSDL interfaces, and implements WSDL 2.0 MEPs (Message Exchange Patterns).

The components that plug into a bus are either Service Engines or Binding Components. Examples of Service Engines are Aspect engines, BPEL engines, mashup processors, encoding, ETL, scripting, XSL transformation engines, etc. Examples of Binding Components are BCs for SAP, Siebel, CICS, CORBA, FTP, HTTP, Queues, etc.

OpenESB is Sun's JBI implementation. It uses NetBeans 6 for development and deploys naturally to GlassFish.

Michael demonstated a BPEL process that used two Binding Components (an input queue and an output file), with a Service Engine written on the spot using an EJB with Web Service annotations. The process read in a string from a queue (which was manually input), called the web service to turn it to uppercase, then wrote it into the file. Sure enough, when the file was opened, the string was there, in uppercase. Though it was a simple enough demo, it was fairly impressive.

NetBeans 6.0 is shaping up to be a good development platform for SOA. It has editors for BPEL and XSLT, among other things.

The last session I attended was by Alexis Moussine-Pouchkine again. This was on "Practical GlassFish". He talked about how GlassFish is built, the release cycles, etc.

There's reportedly a graphical installer from a third party (Izpack) for those who don't want to wrestle with the command line.

Alexis also demonstrated the Update Center, which works like Eclipse's.

He showed us some of the asadmin commands for command-line administration. These can obviously be used in scripts as well, which administrators would like.

From a competitive perspective, Sun has a migration tool that helps users automatically (to a large extent) migrate their current deployments on Tomcat, JBoss, WebLogic, WebSphere and older versions of Sun App Server onto GlassFish/Sun App Server. It's reportedly not foolproof, but it could help.

Documentation can be obtained by typing 'asadmin --help' on the command line or online.

That was the end of the three-day Sun Tech Days event. Very useful and informative.

My main takeaway, ironically, was nothing from Sun. It was Grails. I've started doing the InfoQ tutorial, and I'm mightily impressed. I'll blog more about Grails as I learn more.

Sun Tech Days Sydney - Day 2 (5 March 2008)

I blogged about the first day here. A lot more happened today, or so it appeared to me. I saw the most jaw-dropping piece of technology demonstrated today, but you'll have to wait a bit to hear more about it.

Sang Shin spoke about AJAX and Web 2.0 technologies. Sang has a wonderful blog at http://www.javapassion.com. This site is chock full of detailed courses on major Java technologies, all generously made available free of charge. His presentation today was based on some of those courses. It was hard for him to do justice to the depth of the topic in just one hour, but I'm sure his blog and the courses there will provide hours of useful instruction to anyone interested in exploring them in detail.

One of the useful tips I picked up while watching his demo was how to use the Firefox extension Firebug. This lets you monitor AJAX traffic, among other things.

The next session I attended was by a person from Atlassian. This session was on Grails. Now, I'd heard of Grails, but didn't quite know what it was all about. I assumed it was a very different technology from Java, something like Ruby on Rails. Only half right, as it turned out. Yes, the technology was inspired by Ruby on Rails, but it's based on Java technology. To be precise, it's a software stack consisting of Java, Groovy, Spring, Hibernate and HSQLDB.

It's a little hard to describe what Grails is. Those who attended Ben Alex's talk early last year on the coming Spring project tentatively called ROO (Real Object Oriented) will have a fair idea of what I'm talking about. Grails seems to have everything that ROO promised (but hasn't yet delivered on). It's a toolset that lets designers build applications based on the principles of Eric Evans's Domain-Driven Design, and it works very hard behind the scenes to build all the infrastructure required to make the domain objects just work. Persistence, a RESTful web interface, test cases, - all get automatically generated. An increasingly common theme that I'm hearing pervades Grails - "Convention over configuration." In other words, if you stick to standard naming conventions for things that you create, the system will make it very easy for you to build a working application with a minimum of coding.

That's the jaw-dropping technology I talked about at the beginning of this post. Grails is a developer's dream. One can knock together working code in minutes. InfoQ has a Grails guide and example code which I intend to work through as soon as I possibly can. I would recommend Grails to all Java developers looking for the next burst of productivity. Best of all, Grails applications can be exported into standard war files and run on standard app servers, so there is no need for any new run-time technology.

Funny how one can be searching for months for a productive development environment that lets you build applications rapidly yet correctly, and then one fine day, it comes up and hits you between the eyes. Praise the Lord! I intend to use Grails to illustrate concepts with working code from now on. I'll blog about my experiences with Grails as I get some experience with it.

(I also liked Atlassian's byline: "Where VB is only in the fridge.")

Lee Chuk-Munn presented next on JavaDB. This is, of course, the much-renamed Cloudscape/Derby pure-Java database that takes up all of 2 MB of space and supports database sizes of up to 700 GB. It is thread-safe and therefore OK for multi-user use, but is positioned as best for use as an embedded database. Since new owner Sun has to juggle other databases like MySQL and PostgreSQL as well, I suspect that the recommendation to use JavaDB for single-user or embedded use has more to do with positioning than with the actual limitations of JavaDB. Too many capable technologies (Linux, MySQL and Tomcat, anyone?) have been unfairly treated as toys in the past for me to swallow such a recommendation.

JavaDB has stored procedures, triggers, functions, built-in XA (distributed transactions), encrypted databases, crash recovery, etc. It also supports JDBC 4.0, with autoloaded drivers, scrollable and updatable ResultSets, better support for CLOB, BLOB, ARRAY and STRUCT, chained exception handling and XML datatype support. The only enterprisey thing JavaDB lacks at the moment is replication, but a basic version is said to be coming in version 10.4.

A very neat feature of JavaDB is the ability to place an entire database inside a jar file on a USB stick for use as a read-only database.

Another neat feature is the ability to define stored procedures in Java rather than a dialect of SQL. The actual command to create the database procedure merely references the Java static method.

Lee showed us examples of how JavaScript and Java may enjoy bidirectional communication using the long-presumed-dead applet technology. He also showed us Java/JavaScript code to demonstrate client-side persistence using embedded JavaDB.

JavaDB is pretty cool, when you stop to think about it. Relational database technology has been a big yawn for a few years now, but things like this make me sit up and take notice.

Carol McDonald spoke about JSF, AJAX, Woodstock, etc. I'm not terribly interested in JSF and would much rather it simply died. I'm not a big fan of web frameworks because I think all thin-client architectures follow a common design anti-pattern. My money is on SOFEA. Still, JSF is something that refuses to go away. Among the goals for the next version of JSF (2.0) is the now-common refrain "Convention over configuration".

After that were two sessions on security. They covered the usual ground, with nothing very spectacular that caught my attention.

A few tidbits from Raghavan "Rags" Srinivasan's session:
1. C14N stands for "canonicalization", the process of rendering XML documents into a common format (i.e., especially differing use of whitespace, which could otherwise play havoc with cryptographic techniques to detect tampering).
2. SAML can be used to make 3 kinds of assertions:
a) Authentication assertions ("This person (or program) is so-and-so.")
b) Attribute assertions ("This entity has the following properties.")
c) Authorisation assertion ("This principal may read data but not update it.")

OpenSSO is Sun's identity management solution. You may download and try it.

There was another talk on SOA security from a person from a company called Layer7. This was more high-level with no code.

The contents of all lectures will be put up on the Sun Java Tech Days website anyday now.

There was an OpenSolaris Installfest going on in the registration/catering hall, and they were giving out CDs and guidebooks. I'm definitely going to try and install OpenSolaris and report on the experience.

Today marks the end of the official Sun Tech Days conference, but tomorrow is a set of community events, which also I plan to attend.

I've been invited to drop by the GlassFish booth tomorrow to discuss my difficulties with the server.

Sun Tech Days Sydney - Day 1 (4 March 2008)

Today I attended the first day of Sun Tech Days in Sydney, and here are a few of my impressions.

Some major takeaways for me:

1. The Java and Open Source ecosystem has expanded so much in the last decade that Sun can no longer organise a conference to talk about just its own technology. This year, for example, topics included Ruby, JRuby, Rails, the Spring framework, JBoss Seam, MySQL and PostgreSQL, Grails, AJAX, REST, etc.

2. Sun is now irrevocably committed to Open Source. Open Source has become too powerful a force for any company to withstand. It gave me deliciously wicked pleasure to see James Gosling, the "father of Java" and a traditional Open Source skeptic, take the floor and defend Sun's pro-Open Source direction. I know from reading past interviews of Gosling's that he is no admirer of Richard Stallman or the GNU GPL. It must have hurt for him to see his brainchild released under the GPL! ;-D

3. There seems to be some competition hotting up between three players in the Java/Open Source world - SpringSource, Red Hat/JBoss and Sun. I got the feeling Sun was actually aligning with their old enemy Red Hat, because they seem to view SpringSource as their common enemy. SpringSource have taken over Covalent, the Apache services company, so there's a perception that they're pushing Tomcat over all other app servers, GlassFish included. That seems to irk Sun. Later, watching the JBoss Seam demo and learning that it is going to form the basis of a new JavaEE technology called Web Beans, I got the distinct impression that JBoss is proposing a rival to the Spring framework. However, both Sun and SpringSource favour Toplink over Hibernate as the persistence engine for their products, perhaps since Hibernate belongs to JBoss. This whole area bears watching in the near future. It has implications for organisations looking to deploy Open Source Java stacks, because sourcing pieces of the stack from mutually antagonistic parties may create integration problems, even if all the components are nominally Open Source.

4. There is a lot of "low-level" knowledge in the industry about how to use tools, but not enough "high-level" knowledge about why things are the way they are or even what is wrong with the way things are. This is as true of the presenters as of the audience (if audience questions at the end of each talk are any indication). Many presentations focused on syntax and mechanics of how to do stuff ("If you use this annotation, the system will automatically take care of such-and-such for you"), but did not provide more insights into architecture and design rationale. Worse, presenters did not do a good job of answering audience questions at an appropriately high conceptual level. [I felt I could have answered some of those questions better. E.g., "If REST makes the client manage its own state, then how do you secure a service against unauthorised access? Anyone can access the service." Answer: "Consider a simple system in which the userid and password have to be sent with each request. That solves the problem you have described. Now consider more sophisticated authentication tokens that can be sent (and checked) with each request." E.g., "Doesn't the service need to authenticate the client by looking up LDAP?" Answer: "A trusted identity provider has already looked up LDAP or a similar store to authenticate the client, and has provided a token to vouch for the client's identity, which the service now trusts."]

Mind you, the above critique takes nothing away from the fact that I learnt a fair bit at this conference.

1. For example, I had never before heard of the wireless device called a Sun SPOT, one of which was demo-ed at the conference. This tiny device fits in the palm of your hand, and has various kinds of sensors (e.g., light sensor, temperature sensor, 3-axis accelerometer, etc.) The devices can detect each other and a gateway wirelessly and the whole system can be used to collect and collate various kinds of real-world data very simply and display it graphically using a JavaFX Rich Internet client. Very cool. One of the Sun managers said the company is selling these below cost to encourage take-up, so if someone is interested in this sort of device, the Sun SPOT may be worth looking at.

2. I hadn't heard of Mercurial before either. This is a revision control system. Sun has changed their preferred revision control system twice, once from CVS to Subversion, and again from Subversion to Mercurial. From the Wikipedia description and its favourable rating in this comparison of revision control systems, Mercurial seems to be pretty good.

3. I was only vaguely aware that JDK 6 bundled a client-side HTTP server. I must try out this example they showed today:

import javax.jws.*;
...
// Define a web service
@WebService
public class SayHello
{
@WebMethod
public String sayHello()
{
return "Hello, World";
}
}
...
import javax.xml.ws.*;
...
// Publish the service using the bundled HTTP server in the JDK.
// This is a "transient" service hosted temporarily by the client workstation.
SayHello sayHello = new SayHello();
Endpoint endpoint = Endpoint.create( sayHello );
endpoint.publish( "http://localhost:8080/hello" );

I made a quick attempt to run this example but it didn't work. I'll need to do more research.

4. NetBeans 6.0 is not bad. It may be worth waiting for 6.1, though, because there's at least one issue with 6.0 that will be fixed in the next release. That's the ability to generate a simple CRUDish web interface to exercise JPA persistence logic, which was apparently working in version 5.5 but has mysteriously stopped working in 6.0.

5. Carol McDonald's two sessions (one on WSIT, JAX-WS and REST and one on Application development using plain JavaEE, Spring and JBoss Seam) were packed with technical content, but alas, I felt she couldn't add much in the way of design rationale or insight. Her blog entries here and here have more details of her presentation and should be of interest to many.

6. Apparently, SOAP's transport-independence is not just theory. Sun's Metro Web Services stack can use any of these transports - HTTP, JMS, SMTP or TCP. The TCP bit is the most interesting, as I don't think SOAP requires a more heavyweight transport. All of the qualities of service required by SOAP messaging are provided by the WS-* headers anyway, so it's best for SOAP to choose the lightest transport protocol that can possibly work. What about IP itself?

7. OpenSolaris makes for a pretty cool desktop. It boasts all the Compiz magic that Linux offers, so Unix in general is now no desktop slouch.

Some of my pet peeves:

1. A statement was made by one of the presenters that DTOs are an anti-pattern, and that detached entities are the way to go. I have railed against detached entities from the time I first heard about them. Mind you, I have nothing against detached entities as long as they stay within the application tier. It's when they are proposed as a means to export data to other tiers that I object. That immediately exposes the domain model to external parties, resulting in tight coupling. Change your domain model and your clients break. [Incidentally, if you consider the web tier to be part of "your" application and not an external party, you are guilty of "web application thinking" and not "SOA thinking". The web tier of your application is an external consumer of your application's services, as much as any external client.] One may hate DTOs and criticise them as an "anaemic domain model", but DTOs were never meant to model anything. They are mere structures that act as an envelope for a bunch of data items that are exported to other tiers. To the extent that they hide the actual domain model from external parties and decouple them, DTOs are your friend. [If you find it a pain to marshal and unmarshal DTOs, you perhaps haven't been using Dozer. Also, if you consider the XML documents within SOAP requests/responses to be DTOs in XML format, then you may similarly benefit from using TopLink's meet-in-the-middle mapping approach or JiBX's mapped data binding to marshal/unmarshal them. You certainly shouldn't be using JAXB to generate one from the other.]

2. Speaking of which, there was a lot of code generation demonstrated today of the sort I simply hate. I have explained before why, if we want to implement SOA, we cannot simply generate service implementations from domain models. I have also tried to mitigate the evils of code generation by proposing a set of explicit "service" classes that act to decouple the domain model from external parties. Annotating these intermediate service classes and automatically generating web services interfaces and WSDL files does no harm, because the required decoupling has already taken place. But as I complained before, this kind of architectural insight did not accompany the demonstrations. They were training technicians out there today.

Nevertheless, on the whole, I thought it was an entirely rewarding day (and the food was great!) I'll be there again tomorrow and will report on my impressions.