Inside Trivadis Framework
Abstract
This article describes the architecture of the "Trivadis Framework" developed and used by Trivadis Ltd, a european based consulting and training company. The input for this article was gathered in a interview (17th August 2004) with Urs Meier a consultant working for Trivadis.
The "Trivadis Framework" is actually more a blue print than a framework in the classical meaning. Its architecture is highly complaint with Microsoft's ideas about Service Oriented Architecture. Enterprise solutiosn based on this architecture were successfuly implemented for several european customers with the .NET technology available today.
Note: I can't provide you with the source code of the "Trivadis Framework" because it only comes with a consulting contract... But nevertheless I can describe the architecture and hopefully give you some input for your next solution based on Service Oriented Architecture ;-)
Content
1 Philosophy
2 Architecture
2.1 Calling Services
2.2 Presentation Layer
2.3 Service Layer
2.4 Domain Layer
2.5 Data Access Layer
2.6 Called Service
3 Summary
1 Philosophy
The philosophy behind the "Trivadis Framework" is based on the philosophy of Microsoft's Service Oriented Architecture (SOA) and Pat Hellands SOA Architecture Pattern. If you're not familiar with SOA I highly recommand you to lean back and enjoy the presentation of Pat Helland covering Envisioning the Service-Oriented Enterprise - you won't regret it ;-)
Basic SOA
The SOA promisses better B2B support than the classical client/server architecture. Its promoted as the outcome of the logical evolution of todays computing and their problems. We are still living in the century where computers prefer to talk to humans instead other computers. The system integration stragegies today are usually based on "Fax and Pray" and "ALT-TAB Integration" princible ;-) says Pat Helland.
The following picture is from the Article Designing Applications and Services published by Microsoft in December 2002. The 166 pages guideline published along with the Article describes a service oriented enterprise architecture.
Pat Hellands SOA Architecture Pattern
Pat Hellands introduces the terms of "Fiefdom" and "Emissary" to better understand the requirements of a SOA. This good concepts introduces a lot of requirements that are dificult (or at least not intuitive) to implement with todays .NET techonlogy - and I quess that's why Microsoft builds the next generation Widbey and co.!
Emissary "A service whose primary functions are to help prepare a request to be submitted to other services and to help interpret a service's response to the request." from Microsoft Glossary.
If you're intrested in this topic I recommend the presentation Autonomous Computing: Fiefdoms and Emissaries from Pat Hellands.
2 Architecture
Now you know the philosophy of SOA let's look at the architecture of the Trivadis Framework/Blueprint.
2.1 Calling Services
The architecture forsees most of the client architectures currently known. The old-school Rich Client bound together with business logic. The Smart Client that updates itself automatically. The Mobile Client that is a little smaller and weaker than their brothers, but fit in the pocket of the user. Last but not least the Browser Client that runs everywhere - even in the Internet Cafe at the end of the universe ;-)2.2 Presentation Layer
The Presentation Layer simply consists of a ASP.NET Application that is the verlängerter Arm (???) of the Browser. He interacts either directly with the Business Facade in the Intranet szenario or throgh Remoting or Web Services if living in the DMZ...2.3 Service Layer
The Service Layer exposes the Business Facade in a heterogenous (Web Services) or homogenous (Remoting) way.2.4 Domain Layer
If you look at the inner architecture of the Domain Layer you see a lot of DataSets and DataTables - that's not only because the Trivadis Ltd has its strainght in ORACLE and SQL Server technology, the typed DataSets are a intuitive and powerful fundament for building a SOA today.
A Calling Service request the data to process a Use Case exposed by the Business Facade and get's all important data from the database in one single object, the DataSet. If you design you're Business Facade and Use Case DataSets clever, the outcome is a very performing system with a minimum of round trips to bothering the Domain Logic. Even more you can easyley merge parts of the DataSet that contain Immutable Data (e.g. Product Catalog) to a local cached DataSet.
Where are the Buisness Rules implemented, you might ask yourself. Even tough it's not visible in the grapic the Trivadis Framework covers them very elegant. The Business Rules (that can be validated off-line) are together with the DataSet-Definitions part of the client implementation. They can be validated immediately. If the Business Components get a DataSet from the client, they validate the Business Rules again (security reason...) and do the parts of the validation that only can be done online in a performant way.
If you're proud owner of the Book Pattern of Enterprice Application Architecture of Martin Fowler have a look at Table Module which is an alternative to a clumby Domain Modal and mapps better to a relational database. To even simplify the usage of this pattern and the gattering/updading of the right tables in a DataSet, Trivadis wrote a Component for that. Can't tell you more, its top secret ;-)
I was Joking, acutally I only don't know how to exactley explain. I try anyway... This Component called "TMDA" has knowledge about the database meta data and thus know if a complexs DataSet want's to be merged to the database, what order they have to be processed. It has also some functionality to automatically write timestamps, based on XML configuration. BTW: The Business Rules are also configurable through XML and allow you to add or remove them in the runtime enviroment.
2.5 Data Access Layer
Something special about the Data Access Layer is the Dependency-Inversion Principle to make the Domain Layer independent from the Called Service (e.g. database) and not the opposite way around. Cool innit? The book Agile Software Development from Robert C. Martin explains this and other nice patterns. I recently bought the book and I can recommend it fully. Other Patterns explained are Single-Responsibility, Open-Closed, Liskov Substitution and Interface-Segregation...
2.6 Called Service
The Called Service can be another service, of course. The RDBMS or XML also data belongs in this layer.
3 Summary
A SOA is not only another 3-tier model with WebServices in between the layer. It's more and also requires a different approach on how to build the Damain Layer. The Trivadis Framework made IMHO a very good architecture and I hope you got an inside look and some new ideas for your next project based on SOA.
