Pharo Spring

January 21, 2011

Pharo Spring and Java (Groovy) Enterprise Integration:

Caveat: Enterprise integration as in through WebServices though a given in the SOA world is not a trifling to work with and is a non-integrated connection. Major Smalltalks do have it, but neither Pharo/ Squeak have it currently in a stable manner near term.

Smalltalk in general has been the most insular to integrate to the enterprise world of computing, due partly to the arrogance/ perceived superiority of its platform vis-a-vis the enterprise world of Java or .Net computing. Past now the decade of denials, all smalltalkers now should find it relatively easier to accept that there is undeniably large asset built in Java/ JVM / J2EE ( primarily Spring ) that is impossible to ignore any further.

To leverage the best the Smalltalk offers in its productivity, efficiency et als, I firmly believe a tighter and more inclusive integration with the Java/ JVM world is to be forged. Primarily what this means is

Direct call interface with JVM as in:

  • JNIPort
  • Redline Smalltalk

Integration with the J2EE stack

  • Integration with Spring Architecture
    • Callable to and from the bean descriptors transparently
    • Utilize the interface to transparently use the now highly proven frameworks of JDBC, MQSeries, Reports as in Jasper or Cognos or thousands of other frameworks that we do not need to reinvent the wheel of.

The primary argument we have to make is that the business logic, complex enterprise development be doable from the Smalltalk environment while all the interfaces that is stable and proven in the enterprise world can be leveraged transparently.

Also this will give rise to the argument that smalltalk work can be safely integrated as a module in a larger context of existing framework of the enterprise IT architecture and be capable of using and sharing the end points as is required.

Pharo Spring: Post this preamble, to introduce this term, as it clearly suggests is deep integration of the Spring Architecture and Pharo Smalltalk. Spring Architecture greatly simplies the enterprise computing in the Java world for standard GUI interfaces, web world both browser/ non browser or a headless no web world. We may over a period of time see great synergies in our GUI world of morphic, Seaside and headless smalltalk that will offer a great incentive to enterprises to adopt Smalltalk as a module in their larger stack.

All Smalltalkers, despite some inherent dislike for the XML based descriptors and dynamism created by external configuration file, will find a huge common philosophical ground in the invocation patterns and orchestration that it brings in.

To integrate deeper with Spring what is required:

  • Be able to have the Spring bean be transparently linkable between Pharo Smalltalk and the other JVM languages of Java, Groovy or Ruby.
    • Callable / reusable as a bean entity. This is currently proposed using the XMLRPC framework to expose a RMI/ Remote proxy mechanism as in a standard distributed world. Both Smalltalk and say the Java/ Groovy end expose their respective Client-Server XMLRPC systems to talk to each bi-directionally. With the two systems proposed to be in the same box/ LAN the inherent intranet latency will not be of huge concern. We can address additional performance concerns much later down the line for servers situated in different distant LANs in a truly distributed environment and even thereof I believe the latency can work towards optimizing it to less than the true EJB style RMI.

This will instantly enable a huge win-win situation for a smalltalk works to quickly plugin to an existing mass base of Spring systems deployed over their favoured App Servers scalably and interact with the existing assets.

  • For a web world of interacting webservers, have a filter mechanism that allows the two systems to bi-directionally redirect links to each other. So a call to a link in Seaside though arrives at the Spring Server, it will redirect to Seaside/ AIDA and smalltalk server will configurably prefix the server:port and web app name prefix strings to the outgoing web page for all its links. All of this should be configured in a simple manner and through the use of configuration files in the spring stack.

Planned Work:

Stage I:

Currently Spring supports a horde of features that are extremely useful in the larger enterprise context but the minimum that I would intend to start and complete as a proof of concept and is usable as a start point are:

  1. Filter adaptor to redirect calls
  2. Bean transparency: bean definition has the extra tag to identify it as Smalltalk bean and have both singleton and prototype capability to begin with.
  3. Integrate XMLRPC module as a scalable unit that can be used more pervasively. ( The issue of datatypes limitation and various other critical note not withstanding, it is far more performant, easy to adapt to than WS Stack. The CORBA/ RMI alternative is a complexity challenge not alluring currently. JNIPort/ Redline Smalltalk will need to mature and again will themselves present a complexity challenge, but perhaps the best alternative currently on a longer term. Alternatives will be explored as we move on to ensure the most performant mode to channel the Smalltalk-Java communications transparently for an end developer)
  4. Pharo Smalltalk linked to the maven/ ant build script to be startable headless/ with UI as required for runtime deployment/ development. Make it integrated to the environment stack of the spring world
  5. Integrate the Smalltalk code management through SVN to have a common code management mechanism
  6. Integrate the build, Unit test mechanism through hudson borrowing from the existing work in that respect.

I guess this much with a small change here n there .. as we go ahead shall be adequate to be a usable proof of concept.

What do I have currently: ( Will update this as I go ahead )

  • PoC on Filter adaptor
  • PoC on XMLRPC
  • PoC on the ant script to invoke PharoUsing Groovy primarily for all the PoC works.. to utilize the power of dynamic behaviour on the JVM side to the maximum, this can be easily converted to Java where required.

    Need to take it from this point onwards to a full blooded implementation, I can argue for with an enterprise to adopt.

Comments, suggestions… ?


MarkupBuilder in Smalltalk

July 6, 2010

Borrowing a leaf from Groovy..

[please read comments: for changes made and my addl replies to critical notes in pharo mailing list.. accepting many as good suggestions to improve the framework for general benefit..]

newBldr := XMLBuilder new.
xmlPreprocessor; attributes: #(‘a=”6″‘ ‘b=”7″‘); test: ‘welcome to builders’ with: [

newBldr attributes: #(‘a=”1″‘ ‘b=”2″‘); trial: ”; attributes: #(‘a=”3″‘ ‘b=”4″‘); trial: ‘testing..’ ;trial ].

or: without going through DNU and array of assocs for attributes:

newBldr xmlPreprocessor; attributes: (Array with: #a->6 with: ‘b’->7); tag: ‘test’ text: ‘welcome to builders’ with: [

newBldr attributes: #(‘a=”1″‘ ‘b=”2″‘); tag: ‘trial’ text: ”; attributes: #(‘a=”3″‘ ‘b=”4″‘); tag: ‘trial’ text: ‘testing..’ ;tag: ‘trial’ ].

newBldr valueStringTrimmed

to get :

‘<?xml version=”1.0″ ?><test a=”6″  b=”7″ >welcome to builders<trial a=”1″  b=”2″ ></trial><trial a=”3″  b=”4″ >testing..</trial><trial></trial></test>’

has its charms to generate the tons of export XML, or SGML in general.. and remember all calls to methods #trial: and #test: are dynamically resolved as they do not exist..! and now extend this to a PropertyBean..

aSimpleBean := PropertiesBean new beanAlias: ‘NewXML’.
aSimpleBean text: ‘TopRoot’.
(aSimpleBean elementProperties) add: #root -> 123; add: #child1 -> 123.

aSimpleBean valueStringTrimmed generates:

‘<?xml version=”1.0″ ?><NewXML>TopRoot<root>123</root><child1>123</child1></NewXML>’

The idea gets a little more interesting.. as we can even cause the same PropertyBean to generate an ini thorugh IniBuilder, json through JSONBuilder, etc..

Specialize the builder with more constructs for say HtmlBuilder now..:

html := HtmlBuilder new.
html html: ” with: [ html
attributes: #(‘onLoad=”1″‘); body: ” with: [ html h1: ‘text’ ] ].

html valueStringTrimmed generates:

‘<html><body onLoad=”1″ ><h1>text</h1></body></html>’


html body: ” with: [  html htmlTableTag tableAttributes: #(‘width=”80%”‘);
headers: #(‘ColumnField01’ ‘ColumnField02’)
rowsArray: #(#(123 32) #(223 32) #(‘asd’ ‘asd’)) ].

can now generate a whole table…!.. just given the header and rows..of any rational size

add plugins to this for href rows on are after each row.. pagination, reading a csv file of data to generate a table.. or db table.. on the fly.. the possibilities are many


Having built up the basic framework now more as an internal trial.. moving from XML outputs to now, I am working on plugging this to Seaside to see if we can use it more potently for renderContentOn: html methods to render easier and extensible html components with JSF like plugin capability..

Wondering if this has extended use for the Pharo.. Smalltalk community to reuse.. the entire capability of a MarkupBuilder system that has:

* Construction of a markup text ( possibly non text..) that can be extended to output to many possible tree based format..: XML, JSON, INI, Properties, etc..

* PropertiesBean that extends the ability to create a class/ instances that can emit at last stage the reqd one/ multiple output formats..

* HtmlBuilder that extends and enables faster html turnaround especially with potential extensible components of Tables, Forms, media/ browser plugin players etc.. Rails like easier access to dump multiple js, css files and little more assist here n there..

* A generic plugin mechanism that can allow per builder instance registry of plugin initialized and respond to..

Just my two cents.. love to see someone comment on this here.. can post the monticello package for anyone to explore if reqd..

Pick the mcz package from the link.. (

Pharo News..

April 29, 2010

Playing with Pharo and waiting for its 1.1 release. Its great to see a free version of Smalltalk at last measuring up to the needs of using it in an business sense and showing it to non-Smalltalker’s and the “IT managers” and not put them off. I am sure this is going to make it difficult for VA and Cincom to create new small-medium shop sales going forward especially with Seaside, Magritte and raft of other frameworks actually being born in Squeak. There obviously is the crying need for better-faster VM, DBMS connectivity natively, Web Services. But if that all does come in, I doubt if there is any space left for commercial Smalltalk but for maintenance of existing customers…!

I am wondering if a Pharo-Groovy bridge and / or Pharo-Ruby bridge would be a good case to make. Solve the issue of interoperability and extensions usage. Invest in a very efficient connector development and you will have all the interfaces for free though to be developed in the Java/Groovy or Ruby. But that is lot more leverage than to natively support 200,000 or more interfaces to stuff we dont even know about..

Would continue to play and check. The new website is also a great start to the advertisement of resurgence in Smalltalk interest. Should stoke the possibility of doing an Indian grouping up for Smalltalk specially look at Pharo. IIIT I believe is using Squeak and am sure have Pharo too being checked out. Need to link up the Indian Smalltalkers now rather than any later..

Dynamic Languages in the Enterprise Application Development World

February 8, 2010

The rise of Python, Ruby and now Groovy with their counterparts in the .Net , JVM world of IronPython, IronRuby and JPython, Jruby is a slow yet steady revolution in the programming paradigm for the computing world.

Since the early days of Smalltalk, which probably was about 3 decades ahead of its time, a slew of languages have adopted the tenets of a programming platform that is based on:

  • Object Oriented Programming and specifically single inheritance structure
  • Memory Management through garbage control
  • The Virtual Memory under the control of the programming platform
  • Bytecode based compilation that targets the specific OS platform through an Object Engine
  • A Mature Collection Class Hierarchy
  • Frameworks and Patterns as in MVC, Design Patterns in general
  • Basic Metaprogramming

This adaptation to the evolving world of programming, includes the most prevalent platforms of Java and .Net. The old but newly visible languages of Python , Ruby and now Groovy are propogating additional features integrated of:

  • Dynamic Typing
  • Closures
  • More deeper metaprogramming
  • No inherent limits or constraints in programming constructs as in interfaces, finalized base classes

And many other syntactical or conceptual adaptations from the past. They have also effected a enhanced integration of regular expresssion, string manipulation and functions/ features that are invoked on plain strings.

To regress and quickly define Dynamic Typing: The unspecified datatype of variables at compile time that is discovered at runtime and assigned as a pointer to the specific data in memory. This implies that inherently there is no allocation of memory space for the variable at compile time or runtime, it is just a pointer. At runtime it is assigned as the pointer to the address of the returned object/ data instance, potentially allowing to change its type through as many assignment statements that may occur in its lifetime/scope. Thereby within a method the same variable can be of totally different datatype and the method can also end up returning any type without restrictions binding its return type. Commonly referred to as “duck typing” or “loosely typed” it is certainly apt to call it dynamic typed.

Closures, from the lambda’s of the Lisp days are a very powerful construct, not so successfully modelled as inner classes in Java but now widely adopted in the dynamic languages is akin to the anonymous functions or the delegates in the .Net world but a lot more capable. The simplest application of closures in the iterations of collections for plain for-each, select, collect, inject, reject capabilities are to be experienced first hand than just read about as a definition. Refer Groovy iterations:

Metaprogramming, through introspection as from a java.lang.reflect to deeper more powerful method interception, delegates or expando’s , have enabled a raft of capability that is probably the underlying strength in the hands of the experienced and weakness when used by inexperienced hands. From Groovy’s , Ruby’s and Smalltalk’s metaprogramming capability are an ascending order of capability that is to be experienced to be deeply imbued. go to the Advanced Smalltalk section.

To the purpose of the article, growth and eventual widespread use of dynamic typed languages, in what can be considered as the mass or popular realm of the programming world. Google in its adoption of python in the early days and ruby on rails adoption by the hordes of small to medium size business as well as Sun, IBM, MSer’s and at ThoughtWorks in its various avatars have baselined the significant impact they have in the business agility and ability to surmount some of the barriers the conventional paradigm offers.

This article is not a diatribe or argument over an oft heard pro’s and cons of typing ( [6] and [7] below) but to emphasize the changing nature of technology development, evolving population of programmers and their ability that will probably see the veritable need of a gradual shift from the imposed restrictions of the current world.

In the decade past it was perhaps the norm to have a 100+ member team to build the next generation product or application that is now fast shrinking to orders of 10 or just a little more for just the core development and unit testing task. This in turn demands higher efficiency from each of the team members in turning around more function points per day than before, higher agility and need to turnaround intial product and its maintenance projects in quicker time.

The dynamic typing by itself is an argument that only the developer himself (or the dev team)  can feel and argue one way or the other effectively for his perception of its efficiency [7]. But it has led the current revolution through the space of frameworks for the web application development world that makes its case presentation near indisputable. Ruby on Rails, Django in Python, Grails from Groovy and ofcourse Springs integration of dynamic languages in its fold and last not the least potent of the rising stars in Seaside from Smalltalk shall be defining the need for enterprise architects and CTO’s to take a deep look through the potential benefits they shall have in adopting these languages, one or more, in the roadmap of their respective enterprises. Comprehensive integration through Web Services/ SOA and other native connections, also helps the cause for multiple systems to co-exist, properly implemented with least pain.

Another major force that should evolve is the changing world of project management with Agility as the key word within even the major long term projects. Break up projects into smaller containable phases and have them driven with all the technical tenets of Extreme Programming. The Unit test driven development paradigm demands higher rigor from the team but at the same begets the reasons to drop the verbose syntax of typed world for the easier , flexible and inherently powerful dynamic world.

It is perhaps not too late for nearly all technology companies to wake up to the call for the change to consider multiple paradigms to exist within the arsenal they deploy for product developments. There is no need to be totalitarian and drive the entire development through the proverbial “ square peg does not fit a round hole” syndrome. It is essential for the enterprise architecture teams, the technology heads ( The CTOs or the tech teams) to infuse the spirit of inclusion of well tested dynamic languages into their development toolset. The toolchain required will need to be rigorously researched and fitment assessed before acceptance, is perhaps essential to mitigate the risks of cowboy programming of the yore.

The newer breed of frameworks of RubyOnRails, Grails from Groovy, Seaside from Smalltalk and the raft of others do inspire a sense of confidence of the stable place in the enterprise toolset for the dynamic programming platforms. Couple this with the rise of base platform and IDE support for Ruby/ JRuby, Groovy , Python and now Pharo Smalltalk/ GnuSmalltalk with a more than minimal required support for an enterprise team support systems, the transition or adoption curve can be easier ( perhaps not easy even now for free smalltalk for more reasons, but seems like now on a path to change that too in very near future)

The question whether it is Smalltalk, Python, Ruby , Newspeak, Groovy or any other can be left to the totality of requirement demands, the available talent pool and the future maintainability. But to move dynamic should not be anymore left to lowest denominator of available capability of developers.

What I would recommend for the uninitiated is to dip through the following links and make up their mind on the way forward.

[1] Groovy: and

[2] Ruby: , and

[3] Python: and

If you are not averse to the break from anything of the past in files, syntax and totally new paradigm that has influenced the world of programming even till now:

[4] Smalltalk: and

Other Links:


Quiet dated but very nice discussion list and especially note from Jim S. in the middle:


Oliver Steele: Chief Architect Lazlo ( then.. )



For the academically inclined a lot of theoretical discussions and references:

[9] On the Revival of Dynamic Languages.pdf