Tuesday, October 13, 2009

Programming in PL/SQL and Java

For those of you who have worked with the TIA Solution in more details, you know that the programming language PL/SQL for many years has been a central tool in the making of it. This is the language our business logic is written in, and it continues to serve us well in terms of features, performance and productivity.
Sometimes we meet people who are not used to the Oracle technology stack including the PL/SQL language. A few of those find it intriguing that TIA relies on a language “invented” many years ago. What we usually do is to explain the benefits of PL/SQL which we believe by far outweigh the drawbacks. Usually PL/SQL is being compared to slightly newer languages like Java or C#. The benefit to TIA Technology by writing business logic in PL/SQL is centered on productivity and performance. The TIA solution is an extremely feature rich integrated solution capab├Že of supporting thousands of users, where most of the business benefits are based upon data access and manipulation of the data. As such the TIA solution is a traditional database heavy solution with less emphasis on advanced graphical user interfaces. Furthermore, we have deliberately made a choice only to utilize the Oracle database. Because of this we can utilize PL/SQL with all of its most advanced features inside the Oracle database to quickly get to the most optimal and best performing business logic with the least effort for the developers. We basically do not have to write any “plumbing” code to get the desired results in terms of updating the database. Compared to Java and C#, these languages do not have any elegant built-in runtime support for accessing a database. SQL statements have to be embedded in the code as textual strings and there is usually a lot of plumbing code which has to be written and maintained when writing business logic. And since TIA does not have to deal with the complexity of being database agnostic there is really no gain – just pain, should we choose to write business logic in Java instead of PL/SQL.

More information on PL/SQL can be found through Wikipedia (http://en.wikipedia.org/wiki/PL/SQL). If anyone has a deeper interest in why PL/SQL is a good choice for an Oracle application like the TIA Solution, please check out http://www.developer.com/db/article.php/3308841/Sample-Chapter-Efficient-PLSQL.htm .

Now, the fact that most of the business logic resides inside the Oracle database and is written in PL/SQL does not mean that Java is out of the question. On the contrary, Java plays an increasingly important role for the TIA solution as a programming language. We have merely decided that we want to use Java where it is best, which we believe is for creating middle-tier components and user interface. To that end, TIA began the journey into Java land a few years ago, when programming for version 6.0 started. With the 6.0 release in March, the first real Java components were released, enabling TIA to fit into a modern service oriented architecture. We are now in the middle of releasing all of the services forming our service catalogue and of course Java plays a key role in that. This also means that our partners will have to look to Java to build up skills. Having Java knowledge and specifically experience with the Oracle SOA suite will become an important aspect of working with the TIA Solution in the future. And that will be amplified when we are gradually moving into utilizing the Oracle Application Development Framework to design and build the TIA solution.

We believe that it is wise for everybody to choose the optimal tool to get the work done. Do not use a hammer to drive in a screw.

When making the world’s best general insurance solution, we believe the right choice is PL/SQL for business logic and Java for the rest.


morisil said...

It is true that direct data access abilities of PL/SQL lower amount of boilerplate code drastically. From the other side there are some techniques like closures or reflection in Java, which can highly reduce amount of plumbing code.

The lack of reflection in PL/SQL promotes code generation techniques (which are known to provide hardly maintainable software), or heavy usage of dynamic SQL statements which should be designed very carefully due to risk of SQL injection vulnerabilities.

Another drawback of PL/SQL is it's modus operandi (based on session state, especially in forms), which is non-compatible with multi-tier application patterns like resource pooling. The latter are required in Internet TIA front-ends which can be exposed to very high load (peak of web-quotations during intensive marketing campaign). TIA SOA is a tier designed to overcomes all these limitations, and here at NCDC we are very fond of it.

Java is a great language when it comes to integration of PL/SQL code with "external world" like third-party services. I call it a "glue code" which usually sits in some middle-tier. Java on top of TIA SOA opens new gates to the future like:

* Domain Specific Languages on top of TIA

* complex Business Process Management solutions

* Domain Driven Design - generic user interface

* Model Driven Architecture - generated user interface, domain objects and data access layer

But some questions arise now. How much TIA business logic will be implemented outside PL/SQL in the future? For example customizable Business Process Management solution instead of "traditional" batch processing approach. As TIA plans to build future ADF GUI based on TIA SOA, it could be either very thin presentation layer, or something thicker in-between which could in fact become higher level Java TIA API?

Anonymous said...
This comment has been removed by a blog administrator.
Matt said...

It is one thing is for the Partners to re train in the technologies that TIA is adopting but another to know how TIA is applying these new technologies.

For Partners to generate a good experience for TIA customers it’s inevitable that they will need to utilise the methods that TIA provide to enrich the customer experience, but this must be done without changing core TIA code or building custom code monoliths that will unrealistically increase the cost of ownership for the customers.

TIA has always provided its customers and Partners with a rich toolkit to allow the customer experience to be tailored to the specific requirements of the customer and the target insurance industry. This toolkit has been both PL/SQL based and within Oracle Forms and libraries. Utilising these tools without compromising implementation projects or increasing the cost of ownership to the customer has been the objective that TIA Partners have been striving to achieve for many years, and I believe that TIA Partners have now become pretty good at doing this.

Does TIA intend to sketch out a road map for their Partners to become familiar with the ways that TIA is applying the technologies they are now adopting?

For example; ADF, like Oracle Forms, could be implemented and utilise the TIA DB business logic in many ways and, like Oracle Forms, it’s likely that only a subset of these will result in good integration with TIA.

So in the forthcoming TIA core implementations that will use ADF will TIA still supply a toolkit for Partners and customers to enhance their TIA experience?

Can this toolkit be used without generating high volumes of custom code that will inherently increase the cost of ownership to TIA customers?

How will TIA guide its Partners and customers in utilising these tools most efficiently?

Even though we’ve put down the hammer and picked up the screwdriver we still need to know which way to turn it!

Flemming Louw-Reimer said...

Thanks for the comments.

I agree that Java as a language has some nice features that PL/SQL don't. However, my point is that PL/SQL is a good choice as a language for writing business logic with a lot of data access.

For TIA we are still keeping our business logic in the database in PLP/SQL but of course going forward there will be more Java code for managing the routing of Web Service calls etc. INrtoducing ADF will not mean we are going to write more business slogic in Java.

Regarding toolkits we will definately provide (and have already started) documentaion, examples etc. for working with Java in relation to TIA as well as ADF. This will come in form of SDK's for our partners and customers to use.