I have a client that sells an enterprise-level solution based around a database. One of my roles with this client is to manage the database logical design (tables and columns) and software that manipulates it. The solution is large and critical to the customers’ operation, so it requires a database administrator (DBA) to maintain it. A DBA can see the logical database design (tables and columns), and can thus start to understand the design and reverse-engineer it. For example, the solution has a table named USER_ACCOUNTS with columns USERID, NAME, CATEGORY, and, STATUS. It’s fairly obvious what the table is for and what the columns means. A customer’s DBA can easily add, remove, and modify rows in that table, in effect bypassing any “User management” application that we provide.

So, one consequence of the customer gaining knowledge of the database is that the customer can manipulate data directly. This avoids any change auditing, relational integrity checks, security checks, and validity checks that we have in our applications. Some of our customers have even written their own programs to manipulate the database directly, even though we provide an application programming interface (API) to hide the underlying design.

This, in turn, causes an even worse problem. We are continually enhancing the solution, and occasionally need to change the logical database design. For example, we often add new table columns, drop obsolete tables, or even completely replace a table. Of course, we provide a migration script that upgrades the customer’s database to the new format, so there are no changes visible to the end user. However, as you can now see, some of customers now have home-grown scripts and applications that no longer work. Needless to say they get upset about the upgrade breaking their programs and having to change their code. In other cases, customers have added or modified data with invalid values, and our new version detects this and reports errors. It’s difficult to explain to them that it’s their fault for not using our APIs.

From the solution provider’s point of view (my client and I), the database design is confidential, as it is an extension of the internal design of the solution, and we need to be able to modify the database design to enhance the product. But in practice, there is now way of hiding the design, as the table layouts are freely provided with DDL files (to create the tables) and the DBA can see everything.

So what is the solution? I don’t know.

We can’t have our hands tied, so to speak, and be unable to change our own tables for fear that someone has written an “unofficial” application against them.

But I don’t know how to hide the database design, either. I have thought of some possibilities, none of which seem too appealing:

1. Mangle the table names and column names. Instead of USER_ACCOUNTS, for example, the table could be named T29, with colums C1, C2, C3, and C4. But then, that makes problem determination difficult, and over time customers would know that T29 is the user accounts table. Plus, this doesn’t affect the data. One could deduce the table purpose by seeing, for example, that the table contains rows with “JOE”, “Joe Smith”, “ADMIN”, “A” (A may mean “active”).
2. Add a check digit column to each table. This wouldn’t prevent the customer from reverse-engineering the database, or from writing queries, but at least it would stop them from changing data. But I haven’t heard of anyone doing this, and this would also make customer support more difficult.
3. Don’t use a database. Not practical – databases are made to hold relational data, and should be used when this need exists.

That’s all I have for today – and no solution.

Building a Simple Web Service – A Tutorial
Web Services Tools Evaluation Guide
Eclipse WTP Tutorials – Creating Bottom Up Web Service via Apache Axis2

So, here’s what I did today. The environment is Eclipse Ganymede (3.4.1) Java EE, Ubuntu Intrepid (8.10), Tomcat 5.5, Axis 2-1.4.1, Java 1.6. A few setup steps related to Eclipse and Tomcat are missing, as I had already installed them a while back. IMPORTANT:In many places it is important to select the correct item in the Project Explorer on the left. Failing to select the correct item will cause steps to fail!

1. Create a new Dynamic Web Project (File -> New -> Other -> Web -> Dynamic Web Project), and name the project “TestService”. It should look like this:
   
2. IMPORTANT:Press “Modify…” to modify the “Default Configuration for Apache Tomcat 5.5″ and add Axis.
   After you press OK, the configuration will now show “”. Then, press Next, accept what’s there, and then Finish.
3. The next step is to create the functions we want to expose with our service. For now, this will be the simple “Hello, world”. To do this, highlight the “TestService” project on the left, right mouse click, then New ->Class. (You can use the File menu, too, but then you will need to enter more information, and you may make a mistake.) Enter the following values and press Finish:
   
   IMPORTANT:Follow Java guidelines and make the package all lowercase – I think the Wizard expect this. Here, I named the package “package” and the class “class” to avoid confusion later.
4. The Wizard will create a stub Java source file. Add the Hello world function to it, and save the changes:

   package testpackage;
   
   public class TestClass {
   	public String helloWorld() {
   		return "Hello, world";
   	}
   }

5. The next step is to create the Web Service (so far all we created was the Dynamic Web Project). To do this, select the TestClass.java source file in the left, right mouse click, and then “Web Services -> Create Web service”.
   
6. IMPORTANT:The defaults here are not all correct. Click on “Web service runtime: Apache Axis” and change it to Apache Axis2. The remainder is fine, so press Next, and then Next again on the Java Bean Configuration panel (this will take a few seconds as the Wizard starts the Tomat server). Finally, press Finish, without checking any of the Launch Web Services Explorer check boxes.
7. We can now start the web service. Select the TestService project on the left, right mouse click, and then Run As -> Run on Server.
   
   Then, press Next and make sure TestService is in the right hand list box (Configured projects). Then, press Finish.
8. You should now see the Axis2 welcome screen. Click on Services and then TestClass. This will display the WSDL. The WSDL is not important now, but we need the URL (probably http://localhost:8180/TestService/services/listServices), so copy it from the browser.
9. The next step is to create a test program. Highlight TestClass.java in Project Explorer, right mouse click, and then New -> Other… -> Web Services -> Web Service Client, and then press Next. You should see this:
   
   Now, three changes are needed: 1) For the Service definition, paste in the WSDL address you copied from before (if you didn’t you’ll have to go back and re-do that step). 2) As before, change the Web service runtime to Apache Axis2. 3) Change the Client project to TestServiceClient.
   
   Then, press Next, which will cause the Wizard to perform some steps for a few seconds, and then display this big screen:
   
   Notice that the Custom package name is all lower case. If you used mixed case earlier, this is where a mismatch may occur. Don’t change anything – just press Finish and wait for the Wizard to complete.
10. This is where it gets a bit tricky. The Wizard generated a client stub, but not an actual client application. We need to do that now. So, locate the TestServiceClient in the Project Explorer, and then “testpackage” under Java Resources: src”. Then, right mouse click and “New -> Class”. Name it TestServiceMain:
    
    Press Finish to create the file.
11. Next, we need a working Java main. Copy in the following text and save the changes:

    package testpackage;
    
    import java.rmi.RemoteException;
    
    import org.apache.axis2.AxisFault;
    
    import testpackage.TestClassStub;
    import testpackage.TestClassStub.HelloWorldResponse;
    
    public class TestServiceMain {
    
            public static void main(String[] args) {
                    try {
                            TestClassStub stub = new TestClassStub();
                            HelloWorldResponse res = stub.helloWorld();
                            System.out.println("Response = " + res.get_return());
                    } catch (AxisFault e) {
                            e.printStackTrace();
                    } catch (RemoteException e) {
                            e.printStackTrace();
                    }
    
            }
    }

    This is basically a template where “testpackage” is the package name, “TestClass” is the class name, “TestService” is the service name, and “HelloWorld” is the function name (upper case all the time).

12. Now, the last step! In the Project Explorer, select TestServiceMain.java, right mouse click, and the “Run As -> Java Application”. In the Eclipse “Console” output window on the bottom you should see “Response = Hello, world”. If so, it all works! Now, you can follow these steps to build a real web service!

To be continued…

As I am currently used to C++ programming, my first solution was to make the parameter “const”, but that, of course, is not possible. So for now I just reworked the code a bit – a patch, not a solution. However, not having const parameters now seems to me like driving without a seat belt, and has me worried. So, once my program is functionally complete, I plan to go back and try to refactor it and solve this problem (this may involve redesigning the classes). When I do get back this, I will probably report what happened, and whether it was successful or not.