It is important to note that the generated SOAP service tiers have done a great job in advancing the Thinkwise Platform. At the time when these service tiers were released, they were state-of-the-art and solved some important challenges. Many applications have used these service tiers in production environments. But like any technology, it must eventually yield to a successor. The true power of the Thinkwise Platform lies in the fact that a technology switch like this can actually be made.
Why get rid of them?
The main reason to use the generated Java and C# service tiers was to support Mobile. Mobile GUI’s cannot directly connect to the database and needed the service tiers as proxy.Version 2017.1 of the Thinkwise Platform introduced Indicium as the replacement for the generated C# and Java service tiers. Indicium uses a more light-weight protocol, OData, and is easier to develop and deploy as it uses runtime interpretation. Since version 2018.1, Indicium has become a mandatory replacement as Mobile back-end.
Another reason to use the generated Java and C# service tiers was to expose functionality within the application as an API to 3rd parties. This works just fine, but it is rather time-consuming when it comes to generation and deployment. Indicium can do exactly the same and has proven to be faster, developer friendly and more secure.
The last reason to use the generated Java and C# service tiers is to write logic in C# or Java instead of SQL. However, all cool languague features that come with an object-oriented language cannot be leveraged very well.
When writing logic for Thinkwise applications most reasons to use OO-concepts such as encapsulation and abstraction, polymorphism and inheritance are either solved differently using runtime interpretation, clear logic concepts and using AOP.
In the end, the only code that’s written and maintained by the developers are rules, where procedural logic does a fantastic job. Also, most rules are data-intensive, and data access without the overhead and latency of loading, serializing and deserializing this data is quite effective.
What does this mean for me?
For the vast majority of developers, this has no effect at all. Most applications already use Indicium to expose API’s via OData instead of the generated service tiers. Any Mobile application on 2018.1 or higher has already been moved to Indicium.There are a few scenarios where you might have to do some groundwork to upgrade to 2019.1.
Migrating API’s
If you use subroutines typed ‘Operation’ in your project, you will have to change these to back-end subroutines (procedures, functions) and mark them as API. This will allow Indicium to expose the procedure or function as a webservice.
The code (either C# or Java) that was used as template for the operation will have to be moved to SQL. More often than not, this was a call to a task or stored procedure to begin with.
Defining a procedure exposed as an API via Indicium
A role will have to be created for the API callers that grants rights on these subroutines. Indicium will not allow the API subroutines to be called unless you are granted rights to do so.
Communicate with your API callers, as they will have to switch from SOAP calls to OData calls. More info about the way you should call the API’s can be found on the documentation site.
Migrating C# or Java logic
Using a C# or Java service tier as logic layer will no longer be supported. Only Windows GUI’s have supported this for a while. While technically feasable, the use of the logic layers like this was a proof of concept, and was never intended to make it to production.
As far as we know, no applications planning to upgrade to 2019.1 use the C# or Java service tier as logic layer instead of the de-facto SQL logic layer.
If you did hobby something together in your garage, you’ll have to migrate the logic layer from C# or Java to SQL. Since the logic is rather procedural and uses the same logic concepts, porting the code is not a difficult task, albeit labor-intensive, linearly scaling with the lines of code in templates.
Indicium can be used to keep the benefits of having a 3-tier architecture for the Windows GUI.
The future of logic
Will we always keep the logic on the database?
This depends a lot on some development that’s currently being done, the Business Rule Modeler. This modeler allows for the logic written in a template to be modeled instead. Starting with simple rules, we’ll see this increase in complexity with time.
The first release of the business rule modeler will generate SQL code from the modeled rules. However, in the future we might generate rules as offline logic. Or even interpret rules at runtime.
Indicium would be able to choose whether or not to execute a modeled rule in-memory or in the database. A logic concept for an object modeled using the business rule modeler could be executed on different layers. Since the model of a business rule allows Indicium to see what it does, Indicium can choose how to execute each rule.
- Data-intensive pieces logic would be delegated to the database.
- Simple calculations that require no data from the database would be evaluated by Indicium.
- Modeled pieces of logic using a connector would always be executed by Indicium.
This will take time to develop and won’t be available in the near future, but does fit neatly into the runtime-interpreted architecture of the Thinkwise Platform.