Introduction
In today's enterprise environments, there are many applications in a company, big or small. Quite often some of these applications need work together. That's what integration comes to play. People often talk about Web Service, CORBA, COM, etc. these fancy things to make the middleware part. For some these things might be needed, for others they might be resolved through the idea proposed in this article: integrate through Web interfaces. The latter solution may be proved to be universally applied, low cost, time saving and little responsibility for the applications to be integrated (this is the most headache problem within an enterprise).
In the past several years, most enterprise applications have been web enabled, which means they have web interfaces for users and almost surely for administrators. For instance, some old mainframe applications have done so through WebSphere from IBM. Newer applications may be impossible to have no an web interface in this World Wide Web era. More often many of these applications do not provide the APIs or the APIs are hard for others to use because of the platform, programming languages, etc. If the project you work on asks help from other projects, others may have no time or may not be willing to help or even they have no way (the system is from third party) to help. This is where the integrating through web interfaces come to rescue. The author has been a technical lead for a project at AT&T Wireless Service, Inc. in the past two years, and found this is a way of fast, low cost and little help from third party.
An Example
Considering an example the author has been working on in the past two years: A legal division needs the Billing information, service account information, call details from several 2G and 3G systems, some are on mainframes and others are relational databases for requests from some legal agencies. Originally, people will have to login on six systems (more in the future). Many times they have to scrape the data on screens and eventually put it together. It is a painful and tedious process. That is why a new integrated system which can handle requests in a uniform way is utterly needed.
The new system requires all the information be collected together to generate the final reports in a single request from users. For the systems involved, each of them has its own presentation layer. Directly accessing these systems will require a lot responsibilities (creating APIs and provide detail original architectures) from other division and business logic are even hard to battle with. Fortunately, most of these systems have been web enabled and using the web interfaces to integrate these systems become a necessary (and probably easiest) way to go.
Where We Start
For the concrete technical details, this article only talks the essential part using C# to do the integration work. The author also used Java technologies to do the same thing for some cases with less satisfied results, but he would like to talk it in other place since this forum is not focused on Java technologies.
Many may wonder to use the System.Web package in .Net. The author has tried but found it is probably not feasible since it is hard to get the tablized data and handle the scripting in the html pages (but the author hope readers can explore to see if the idea of this article can be realized with this package. If so, it would be a greater improvement of this article). What the author used are microsoft.mshtml.dll and interop.SHDocVw.dll. Their documentation can be found at MSDN web site.
Join the conversation! Your thoughts help the community grow.