Smalltalk in large scale enterprise architectures
Download as ppt, pdf0 likes339 views
The document discusses the evolution of Smalltalk in large-scale enterprise architectures, highlighting its declining market share since the rise of Java and the competition for modern applications. It proposes a business-centered architecture using Smalltalk as an enterprise application integrator, emphasizing its suitability for modeling business logic. The architecture features a hub-and-spoke model, focusing on flexibility and extensibility while integrating various components with a publish-and-subscribe mechanism.
Smalltalk in large scale enterprise architectures
- 1. Smalltalk in Large-Scale Enterprise Architectures Rob Vens http://www.robvens.com rob.vens@reflektis.com
- 2. Traditional Smalltalk Applications Client-Server Fat client GUI intensive
- 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 (dont 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 its not Java its 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 IDEs!!!
- 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!
- 18. Criterion The business component can and will run with all other components unavailable
- 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
- 22. Thank you
Editor's Notes
- #8: Dont sell Smalltalk sell its 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.
- #9: 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.
- #10: 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.
- #12: We might say that Smalltalk is used as a business modelling language. Dont sell Smalltalk: sell business modelling.
- #13: But business modelling is not business modelling. There are various strategies here. Use OO for what its 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.
- #14: 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.
- #15: 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.