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… ?