Presentation given on the ESUG 2002 conference. The presentation illustrates a strategic position of Smalltalk in an environment which is based on other technologies like Java or .NET.
3. Recent developments
Web enabled
Using web standards
HTML
XML
Soap
WDSL
UDDI
Poor support for distribution, connectivity (i.e.
with Java and J2EE)
4. Smalltalk market share
Negligible – (don’t blame ESUG)
Largest in 1994 (according to STIC) when
Smalltalk was competing with C++
Steep decline since 1995 when Sun
announced Java
Now a niche player?
5. Can you sell Smalltalk to your
management?
Proven technology is what they want
If it’s not Java it’s not modern
Or the old arguments:
Smalltalk is slow
Too pure OO
Object-orientation has failed
6. The Java onslaught
Many (if not most) Smalltalk developers
moved to the Java world
Many see Microsoft .NET as a more
attractive alternative, with possibilities to
continue to work with Smalltalk (Dave
Simmons’ SmallScript)
7. But there is another alternative …
Basic idea is to use Smalltalk as an
Enterprise Application Integrator (EAI)
Several architectures are possible to do this
I will propose a business-centred architecture
8. What is a business-centred architecture?
Hub-and-spoke architecture
All business logic in the hub
Publish-and-subscribe mechanism in the
spokes
Adapters implementing the spokes
Smalltalk in the hub, anything else in the rest
10. What is business-centred?
All business logic is concentrated in one
logical component
There is no business logic in any other
component
Esp. ERP, CRM
Also messaging middleware is connected without
business logic in the middleware tier
This component is placed in the hub
11. Why Smalltalk?
Smalltalk is eminently suited for the business
logic component because:
Language and problem domain are closer than
any language I know
For the business domain component other
concerns are important (vs. service components):
Flexibility
Extensibility
12. Characteristics of the domain component
1. There is an OO model of the business
2. This model is a Roger Rabbit model
3. The model is written in UML
4. It is implemented in Smalltalk as an
executable
5. It attempts to be an exact replica of the
business in software – a kind of simulation
model
13. OO model of the business
Not new for many of you
Recapitulating:
OO is (as far as I know) the only modelling tool
that effectively deals with complexity
Only OO models can deal with the scalability
problem (Alan Kays dog house metaphor)
Three alternatives exist:
Process modelling
Data modelling
Distributed agent models
14. Roger Rabbit models
Also called: “active objects”
What is active in the “real” world is passive in
the model and vice-versa
Business processes unfold in a backward-
chaining process of objects delegating
responsibilities (Responsibility Driven Design,
CRC sessions)
Process model is a “pull model”
“Out of Control”
15. UML
Smalltalk can be the modelling language but I
hope we can agree that this is not ideal
UML models need to be executable (OMG
target in 2.0 and MDA)
Close mapping between programming
language and UML needed for the business
component
UML support needed in IDE’s!!!
16. The Smalltalk executable
Logical component:
Can be implemented distributed
EasyBoard model
CORBA
Others …
Probably needs fault-tolerance support (question
for the audience)
Contains no technical issues (i.e. database
transparency, user interface unaware, etc.)
17. Modelling issues: Simulation science
The running executable is like a running
simulation
Executable models need to deal with
dynamic behaviour, esp.:
Waiting lines
Stochastics
Smalltalk has deep roots in simulation!
19. Hub-and-spoke: the spokes
This is where Java (or whatever) comes in
Publish-and-subscribe mechanism
Well known to Smalltalkers
Adapters in VisualWorks and VisualAge
Based on event model in the domain
MVC dependents
20. Links between hub and spokes
Events out, messages in
No direct dependencies between business
component and “outside world”
21. Current work
Of course, this architecture is not dependent on
Smalltalk
Currently implemented in Dutch Public Order and
Security (mainly Police) with Java used for the hub
Java creates many problems
J2EE by long not ready for domain implementations
Too much focus on database connectivity
Too little support for active objects
Internal concurrency not allowed
Management could not be convinced to use
Smalltalk
Don’t sell Smalltalk – sell it’s strengths. Use the standard technologies for the technical areas. IT is growing up: this means that emphasis will be less on technical issues, and will move to business alignment.
Hub-and-spoke and bus architectures are the two most important logical architectures in EAI (Enterprise Application Integration).
Bus architectures are generally considered to be more scalable, but these architectures typically put a messaging component in the critical location.
“…anything else…” of course means J2EE or .NET currently.
What we will try to achieve is maximum reuse and maximum business alignment. This is difficult with many large scale enterprise tools such as CRM software. The strategy here is to use the software – but avoid to implement business logic in it. Or if you do make sure it is an easily adaptable replica of the “real” business logic component in the centre.
We might say that Smalltalk is used as a business modelling language. Don’t sell Smalltalk: sell business modelling.
But … business modelling is not business modelling. There are various strategies here. Use OO for what it’s best in: reducing complexity in large models.
Modelling is an art. Technology is not. This is the critical component, but I argue that for large companies this can be done with a relative small group.
Most systems I see use one of the first two of the metaphors. Distributed agent model are becoming popular, but are mainly seen in the academic area.
Usually complex business processes are not modelled as such. They are generated. The stratum from which they arise is the object infrastructure which decides, on an ad-hoc basis, what the ‘best” sequence of events will be to do the thing needed. The thing needed is a responsibility of an object, for example:
An insurance policy that want to sell itself
A ship in a harbour that wants to unload
A criminal that wants to arrest himself
Notice that objects in the model are active, while passive in the real world and vice-versa. This is a pattern. It is just a modelling trick, which reduces complexity.
“Pull models” is an industry term. Look for this on the web. Also called DTO (deliver-to-order). This is typical backward chaining process generation.