On this page:
Given that your application will be successful, other people will want to integrate with it. What will integration mean for your application and how should those people do it? Looking at the problem from the other perspective, you may have the job of integrating multiple applications either to achieve a task or because someone has hired you to do the integrating. How should you do this in the most efficient way for yourself or useful way for your users? This section will discuss these questions.
At a fundamental level the Internet has been successful because it has allowed users to navigate between millions of different web sites. This would not have been the case if it were not built on a number of standard that you should adhere to thoughtfully to allow your users to smoothly navigate to your application from elsewhere. These protocols include:
The basic way that users will navigate into and around your application should be using HTTP GET and POST requests with specific URL's. Users bookmark these URL's and other applications will link to them. Most applications developers did not realize it at first, but these URL's are, in fact, an interface into your application that you must maintain in a consistent way as you change and evolve your software. Otherwise, they will find dead links.
Many applications are now adopting Representational State Transfer (REST) principals
56 for construction
of URL's. This is a pattern in the form the hypothetical URL
http://www.gene.ucl.ac.uk/HGNC/gene/HD (for the
Huntington disease gene, HD). Such a pattern would
be easy to understand and predictable. In fact, most applications have something like this
http://www.gene.ucl.ac.uk/nomenclature/data/get_data.php?hgnc_id=HGNC:4851.
Many applications have many more &'s and ='s in them. In any case, despite the use
of the &'s and ='s the URL's should stay constant from release to release of your
application and be navigable to directly from outside your application so that
other applications can navigate directly to specific data items.
There are many reasons for URL's to be changed in production. Consider an online banking system that does not use the name of the bank in the URL. You would not trust the system. Apache and other web servers provide many options for configuring rules for URL patterns. Ideally, applications should make minimal assumptions about URL patterns. In particular, applications should use only relative URL's and leave as latitude to web administrators as possible.
In order to provide a rich user interface many developers constantly push the limits on what was originally intended as a markup language for science papers. That is important for a satisfying experience but it is important to remain fixed on HTML standards that have been in place for several years to ensure that users can use their favorite browser right across a suite of web applications. Here adherence to standards is not sufficient in itself, you need to test your application with a range of browsers to make sure that browser bugs to not inhibit use of your application.
There are also a number of HTML user interface conventions that are important to consider. Popups can be convenient to allow users to view two screens together but in many cases they can break navigational continuity. In general, users do not like popups. They can especially be a problem when an application brings up a popup with hyperlinks on it and programmatically excludes the browser navigational controls. Then a user who follows those hyperlinks to another location is left without standard browser controls and likely frustrated.
Many of the ASP.NET examples and documentation use VBScript and proprietary Internet Explorer HTML extensions to achieve a richer user experience and make development easier. Consider going the extra mile and researching standards based ways of achieving the same capability. Otherwise, users who prefer to use other browsers will not like your application.
Many organizations put portals together from a large number of individual web applications. Maintaining a consistent user experience across these applications is a major challenge. The applications should externalize authentication so that users do not have to log on multiple times. They should externalize look and feel to cascading style sheets and they should not assume that they are the center of the navigation system by doing something like adding an array of links across the top or left that cannot be hidden.
Users will often need to perform part of a larger task in one application and then use the output in another application. If the first application only allows viewing of data in a HTML page but not exporting of the data in text or binary form then it will be very frustrating to the user. Consider export and import utilities for your application data as well as the HTML user interface and, in addition, tools for sorting and filtering. Consider using standard or commonly known formats for your application data with existing tools.
At a deeper level you should think about the minimum set of data requirements for your application. Do not assume that your users have never attempted to try to solve the problem that your application addresses before. It is more likely that your users will be using your tool to solve a problem that they have been working on for some time. Designing your application to make use of data that users already have can differentiate your application from others that compete with it.
Consider the system administrators that will install and maintain your application and the cost associated with that. Here I mean web servers, web server plug-ins, relational databases, operating systems, etc. The more dependencies your application has and the fewer choices for those the more difficult it is going to be for the system administrator. Now consider the system adminstrator's job when she has ten applications like yours to maintain. If they all depend on different web servers, databases, and operating systems then it will take a large and very highly paid team of system administrators to maintain those applications.
This is an area where languages like Perl, PHP, and Java that are very portable have a distinct advantage over the others. As an example, I could not get BLAST to run on the server that my ISP runs because of shared library dependencies.
It may be additional development work but try to externalize those dependencies as much as possible to allow the maximal flexibility to the people that will run your application. The Spring Framework55 is an open source Java project that helps with externalization of configuration logic through a pattern called inversion of control or dependency injection.
If the applications your organization owns are all written in the same language you may be in luck. But not if they do not publish application programming interfaces (API's) and not if it is too difficult or too expensive to do programmatic integration. Consider publishing an API that to allow other applications to programmatically integrate with your and think carefully about what it will mean to maintain the API for a number of years into the future.
Also consider componentization of your API's. Other applications may want to consume some, but not all, or your application. Quite often those other applications will want to provide their own user interface and only call your API's. If using your API's in this way will require a different web server, database, and operating system than the calling application it will be a pain.
If the applications that you are integrating use different languages you may or may not be out of luck but you will definitely be in for more work. At a low level most applications have a way of calling C and C++ code through shared object libraries. These are dll files on windows and .so files on many UNIX systems. For Java you can call into shared object libraries using the Java Native Interface (JNI). However, to call Java from another language, including C and C++, you will need to load the Java Virtual Machine (JVM). That will be expensive and for CGI programs it will be prohibitively expensive. C# has an apparent advantage here that a C# program can be compiled into a dll. That is not executed natively but still has to be executed by the Microsoft Virtual Machine. However, the Virtual Machine is considerably faster to load that the JVM.
At the next level up is the command line. Many older programs written in C and ++ are good candidates for CGI because they can be executed from the command line. Again, operating system and system libraries can cause problems here, however, there is hope. Perl programs can also work in this way depending on the assumptions that they make to operate. As stated above, Java is not a good option for CGI. However, using web server plug-ins to most of the popular web servers HTTP requests a Java web application can process requests coming in to that web server.
Assuming that your applications are in different languages or in different organizations your best bet for integration will probably be web services and, in particular, SOAP. It is extra work but provides the most in flexibility for programmatic integration. There are a number of tools available to reduce the work involved here. Notably, for Java there is the Apache Axis project57, and for C# there is Visual Studio. Here the approach is to design a Web Services Description (WSDL) document and create an implementation. Then you publish the WSDL document and possibly sample client code.
Given that you have published an external API and maybe web services consuming code is still left with the work of creating a user interface to allow their users to consume the services that your API's provide. That is where the JavaScript API's discussed in the AJAX section can help. They can minimize development work in creating the user interface to potentially just cut and paste of a couple of line of JavaScript. From a different perspective, a web user interface without any apparent hooks for customization can be extended by augmenting the JavaScript library to dynamically manipulate the HTML interface.
There are no user comments.
Please send ideas and opinions by email at alexamies@gmail.com.