The first time I got a question about running ObjectStudio headless (i.e., without any GUI running), I was a little taken aback. “We can’t do that”, I thought. “ObjectStudio was written as a Windows GUI application.” I figured it would take some careful redesign work to disentangle the Windows GUI assumptions, but I was wrong. […]
The first time I got a question about running ObjectStudio headless (i.e., without any GUI running), I was a little taken aback. “We can’t do that”, I thought. “ObjectStudio was written as a Windows GUI application.” I figured it would take some careful redesign work to disentangle the Windows GUI assumptions, but I was wrong.
Converting ObjectStudio Fat-Client Applications to Server-Based
Don’t get me wrong, we knew all along that some customers with complex business logic written in earlier versions of ObjectStudio would be very interested in making that functionality available in a web-server world. ObjectStudio 8.0 brought all of the amazing web-services capabilities of Cincom® VisualWorks® to ObjectStudio users as well, so that was a natural evolution. In my imagination though, that was going to happen first with a regular (i.e., GUI-based) ObjectStudio running on Windows servers. I was very interested to learn that customers have already been doing exactly this for years with headless images running on Linux servers.
Of course, you can only expect to run your domain logic code in a headless image. Any code using GUI items is out. Less obvious is the fact that your code has to run without using any ObjectStudio primitives. To run a headless image, you must shut down the ObjectStudio Subsystem, but invoking an ObjectStudio primitive will try to start that Subsystem, which will start the GUI as well. Running without primitives would have been unthinkable in earlier versions of ObjectStudio, but in ObjectStudio 8.x, it is not as hard as you might think. First, the current ObjectStudio uses more Smalltalk code and fewer primitives than it used to. Second, most of the fundamental required primitives are part of the Cincom Smalltalk™ foundation, and thus can run without starting up the ObjectStudio Subsystem.
You may also find yourself using an ObjectStudio primitive unnecessarily. There was an example of this in Base ObjectStudio as well. A method was sending #asciiValue to a character, which eventually invoked an ObjectStudio primitive. A better idea in a case like this would be to send #asInteger instead—you get the same result from a Smalltalk method. We in ObjectStudio support and development are always happy to help in a situation like this, where we can work together to find a better way of doing something.
There are other things to be aware of as well. For instance, you can’t use the regular ObjectStudio Runtime Packager to create your image, since it makes assumptions about a startup controller. If there is some interest in this topic, we could explore some of the issues further in this blog. Even better, from my point of view, would be for customers who are actually doing this now to share their knowledge about what works and what doesn’t with each other. The ost-dev list would be a possible forum for that kind of conversation. If you are not on that list already, please contact Product Manager, Arden Thomas (firstname.lastname@example.org) to ask about joining.