The Xillium Service Platform is put in place to allow for fast and quality construction of service oriented enterprise solutions that are secure, performant, capacious, agile, and robust. It does so by following a well-chosen set of time-honored architecture approaches and technologies, and by staying true and faithful to
* Service oriented architecture * Plain HTTP service invocation + JSON responses * A very thin Java-database interworking layer * The most important design patterns and abstractions
Xillium is built upon open source frameworks, most notably the Spring Core framework, and leverages the best of the modern Java technologies. It is a platform still in fast evolution but its merits already proven to be viable in creating solutions as large as a real-time mass-access trading system and as small as an online calculator.
Xillium is a very small framework, yet it strives to provide good coverage for all things you need to build modern enterprise solutions that are mean and lean. It also get out of your way where you already have good standard tools and don't really need more help, giving you more flexibility, less dependencies, and a more proveable application.
from Java, HTTP, and databases, like service invocation protocols (plain HTTP & HTTPS), data encryption (SSL/TLS), security,
Every enterprise application is a database application and, remember this, your enterprise data will, and should, outlive your Java application. Besides, inside an enterprise it is typical that many applications access the same business data, and new applications come while old ones take a bow all the time. For this, any application-centric approach to data persistence is just plain wrong.
The popular ORM approaches might have a place in small, standalone application development, where databases are merely perceived as persistence mechanism just like file systems. ORM approaches are inheritantly application-centric, not data-centric. When it comes to enterprise solutions, the most popular ORM solutions are still buggy, non-performant, already over-complicated, and still under-delivering. To patch itself to become what they promise to be, ORM solutions are forced to incorporate more and more RDBMS mechanisms that truely belong to an RDMBS and are already provided much more efficiently and robustly thereof. This is an uphill battle that will never be won.
As it turns out, ORM is also unnecessary. Your very serious enterprise solution development team already have decent SQL expertise. And when you really need to play with Java objects, as opposed to result sets, inside your applications, you still don't need a database wrapper, but a very efficient and flexible object mapper.
Welcome to Xillium data persistence layer.
Data are not objects.
SQL is also a much better tool than ORM. Yes, it is power tool, and must be properly used. But the same is also true with ORM, only which is
To create an enterprise application that performs well, you need SQL expertise in your development team.
Morever, write to the specifics of your database of choice to gain the correctness and performance for your data persistence layer. If your choice of database is MySQL, write to the specifics of MySQL. If it is Oracle, write true and proficient PL SQL.
and Java-database interworking is a