OraTransplant

Books I am reading

I’ve ordered a bunch of new books. Most of them are about Service Oriented Architectures, as I want to get a good fealing on all the ins and outs of SOA. We’re evaluating the (possible) benefits of SOA to our system and organization. I will report back to this blog once I’ve read a couple of these.

I also threw in “Cost-Based Oracle Fundamentals” by Jonathan Lewis as a bonus when ordering through Amazon. I’m about half way through the book. It’s a very very very interesting read. It tries to unravel how the cost based optimizer calculates the cost and cardinality of a (possible) execution plan. You have to read some pages twice or three times before you really understand all the nitty gritty details. It does give you a great insight in how the CBO is working and why it sometimes coming up with surprising results. I’ll probably post a few blog articles over the coming weeks with the most important highlights. If you really want to understand how the CBO is working you’re probably better off just buying the book yourself and not wait for my blog postings.

The other books I’ve ordered:

Blog interview by Grant Ronald

Grant Ronald recently approached me with the idea of a “blog interview”. He is starting a series in which he’s going to interview a number of fellow Oracle bloggers. He decided to start with me, and I’m honored. Read below for the full interview or read it on his site.

Grant: Tell us about Eurotransplant and what you do

Wilfred: Established in 1967, Eurotransplant is a not-for-profit organization that helps coordinate the supply of organ donations and related information to relevant institutions in six European countries. All patients waiting for an organ transplant are put on a waiting list at Eurotransplant. Whenever a donor becomes available in any of the participating countries all available information about that donor is transmitted to Eurotransplant 24×7. Eurotransplant then matches this donor against all patients on the waiting list and assigns the organ(s) to the appropriate recipients. We also coordinate some of the logistics and financial consequences.
We have an IT department of 25 people. As the System Architect I’m responsible for the overall architecture and I determine our future technical policy.

Grant: What are the IT Challenges you have faced in Eurotransplant?

Wilfred: The current system was initially designed and developed in 1996. Remote access by hospitals and physicians was offered via dial-up connections and using telnet to run a SQL*Forms 3.0 character based application. In the late 90’s this was upgraded to client/server Forms 6i running on Citrix Metaframe over dial-up connections or VPN over the internet. At that same time the database was upgraded from version 7 to 8i. This sufficed for a number of years, but an increasing number of users demanded a light-weight user interface and access from any location not just the workstations with the appropriate VPN and Citrix software installed.
When I joined in November 2004, we decided to start upgrading most of our technical infrastructure. We set out to replace Forms/Reports 6i running on Citrix Metaframe by two brand new Oracle Application server 10g running Forms/Reports over the public internet. We also wanted to upgrade our 8i database to 10g and we needed to replace the hardware running these databases.
All of these upgrades had to be performed while keeping a 24×7 operation running 365 days a year. We cannot afford any unscheduled downtime. Organ transplantation is a matter of life and death to the people involved.

Besides the upgrade to the latest versions of Forms/Reports and the database, we also started our first web development efforts. The user interface of an Oracle Forms application is just not suitable for some of our (external) users.
We have a lot of ad-hoc users that require a light-weight interface. For example, we can contact a physician in the middle of the night to let him/her know that an organ is available for his/her patient. The physician can then lookup all sorts of information about this donor. Oracle Forms with its function keys and Query Mode is good for the “back office/professional users” but was not the right user interface for this type of ad-hoc application. Over the last two years we developed a number of J2EE applications using JHeadstart UIX projects and a disconnected Java Swing application.

Grant: With the upgrade of client/server Forms to the web, how did you plan this and what were the challenges?

Wilfred: Users require a Java Virtual Machine to run Oracle Forms on the web. We had the choice for Oracle’s own JInitiator or the more well known Sun JRE. We decided to go for Sun’s JRE since we had a higher chance this is already installed at a workstation and sysadmins at hospitals are more willing to install Sun JRE than Oracle JInitiator.
We opted for Sun JRE just about at the same time Oracle announced official support for Sun JRE to run Forms. In the beginning this led to some issues, especially since the use of Sun JRE was not that well documented back then. In the end, this was all resolved and Oracle Support and Development did a great job working with us to get the Sun JRE environment up and running.
We also had some work to get the Forms converted from 6i to 10g. Oracle Forms comes with a Migration Assistant that makes changes to a form and checks for use of obsolete features. During testing we found several more changes we wanted to make to the forms during migration. A simple example is that moving from Citrix (which is Windows based) to Linux also meant that all filenames became case sensitive. So all properties in a Form that refer to files (such as the name of the menu and attached libraries) had to be converted to the same case as used for naming these files. We ended up building our own Migration Assistant based on the JDAPI of Oracle Developer Suite. This is a great Java API with which you can open a Form, make any changes you like and save the Form again. We ended up with about 30 different modifications to be made to all forms. You can find the full list of the changes on my blog.
Once these were identified the process of upgrading the Forms to the web was reasonably straight forward allowing us maintain the rich Forms behaviour but have the benefit of being web deployed.
We wanted to offer our users a transition period of two months. During these two months we kept running the old client/server environment on Citrix Metaframe and the new Oracle Forms 10g environment in parallel. This gave users (and their sysadmins) enough time to make the transition.
During this two months transition period, we would just continue developing and releasing new features and bug fixes on our system. This is where our new Migration Assistant came in handy. Development stayed at version 6i. When deploying a form to the version 6i Metaframe server we would also run it through our Migration Assistant. The resulting Forms 10g file would be put on the application server.
The development not only used Oracle Forms, but also Oracle Designer 6.0. We planned to migrate to Designer 10g soon after closing this transition period. In the end, we decided the Migration Assistant is doing a great job and we postponed the Designer migration until we have more resources available.

Grant: You mentioned that you started some application development on the J2EE platform. What did you see as the positive aspects of using the Java platform?

Wilfred: We wanted to move away from the rich (but sometimes) complex user interface of Oracle Forms for a certain part of our user base. It is still great for our "professional" users that can appreciate the richer user interface. However, we also have a lot of ad-hoc users that require a light-weight and intuitive interface. This means we have to move to more “self-service” web applications.
The decision between .NET and J2EE was quite easy for us. We come from a typical Oracle background. Oracle is investing heavily in J2EE and this means that the transition from Forms/Reports/Designer to J2EE is much easier for us than a transition to .NET. A lot of documentation exists to introduce J2EE development to Forms developer. Also Oracle is still increasing the possibilities to integrate an Oracle Forms application with a J2EE application.

We developed four web applications using Oracle UIX as the view layer. We generated the first cut drafts of these applications using Oracle JHeadstart. This development experience is very similar to what we were used from the Forms/Designer background. JHeadstart plugs in to JDeveloper and you use it to declaratively specify your application through highly functional metadata, using simple property editors. Using the JHeadstart Application Generator you can generate a fully functional Oracle ADF application. This development experience is quite similar to the Forms Generator in Oracle Designer, but much more light weight and pragmatic. All of these JHeadstart/UIX applications were developed by Forms/Designer developers with little or no Java experience. I can’t imagine how we could have turned them into productive Java developers without using JHeadstart and JDeveloper. The productivity features of ADF and the declarative and visual nature of JDeveloper were key in success of this project.
We also developed a Java Swing application with some supporting web services. This application is used by a transplant coordinator who is dispatched to a hospital whenever a donor becomes available. The coordinator uses this disconnected (offline) Swing application on a laptop to collect all sorts of information about the donor. The coordinator can then synchronize this information with the central Eurotransplant system via a wireless (UMTS or GPRS) connection. This was a more complex environment and we hired an experienced Java developer to help us out with this one. He worked with two of our own people to develop this system. These two internal developers came from a .NET and PHP background.
Unfortunately one of these developers has left Eurotransplant and that leaves us with a job opening for an experienced Java developer. Apologies for this shameless plug, but interested people can get more information about this role from my blog.

Grant: What IT plans do you have for the future (e.g. BPEL, SOA, Web Services, Ajax etc etc)?

Wilfred: We will continue to develop more and more web applications. We will move from UIX to JavaServerFaces (JSF) as soon as possible. The JSF version of JHeadstart was just released, so these applications will migrate shortly.
I see an increase of data exchange with external parties. In the past, a lot of information was exchanged by phone or fax and re-entered in our systems. Investing in an electronic interface with Eurotransplant isn’t profitable to a lot of hospitals. For some hospitals the volume of exchanged information is relatively low. Building such an interface traditionally required considerable investments and was very proprietary. With emerging XML based standards in healthcare, such as HL7, I expect more and more hospitals wanting to exchange data with Eurotransplant electronically. Their business applications will support such industry standards for data exchange. That makes it much less costly to develop an electronic interface with Eurotransplant.
We can also benefit greatly from a Service Oriented Architecture (SOA). Eurotransplant is a classic example of a service oriented organization. We offer services to participating hospitals and other organizations. Most of the work we do is initiated by these external organizations. If you look at it, matching a donor against all possible recipients on the waiting list and returning all these results is a classic example of a business service. If we would also model this as technical services in a Service Oriented Architecture, this would make us much more flexible. The different components of our system would be less tightly coupled and that can dramatically increase flexibility and decrease maintenance costs.
We are seriously looking at SOA enabling our current systems. Almost no organization can afford a complete rebuild and re-architect of their systems. That’s one of the promises I like about SOA. We can take bits and pieces of our existing applications and SOA enable them. Having this extra services abstraction layer will enable us to more easily redesign parts of the system as long as the external service interface remains stable. With our existing monolithic system it has become very hard to redesign parts of the system without impacting almost every other part of the system.
We also require an ever increasing flexibility and agility to change our business processes. The rules and regulations for organ allocation constantly change and these have to be reflected in our systems. That’;s one of the reasons why we can benefit from things like a Service Oriented Architecture, BPEL and Oracle Business Rules.

Grant: Thanks for being my first blog interview