APL and Web Services

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 71

There has never been a technology that better complements the capabilities of APL than Web Services.

Historically, APL has consistently been capable of performing complex calculations more quickly than any other language.

Web Services provides a seamless mechanism for publishing these capabilities both to other servers and to clients.

During the last year, it became common for APL to have "win backs" where complex calculations are involved. Both in the US and in Europe, we have clients who spent the last several years replicatimg APL applications in VB and other .Net languages, only to discover that the response time, which was seconds in APL, is now 20 or 30 minutes in the new application. Because these applications must deliver a result to a Web browser, response times in minutes are intolerable. Web Services, matched with APL on the server, provide a compelling combination for publishing results generated from APL calculation engines.

However, with any technology solution, no matter how compelling, in the end it is the delivery of that solution that makes an application a success. Connecting an APL application running on the server with a client is the future of computing.

Understanding the client and how it connects to the server is critical. That means understanding what technology has been deployed, the depth of that deployment, and what technology is on the horizon.

If the only goal is to serve a single discrete page, which is either static or includes a simple database query, then any server methodology can be successful. However, in most cases, that single page actually needs to be an integral part of a larger task or application. It is the creation of applications which use Web Services that make APL unbeatable.

What defines the computing client?¶

Looking at today’s computing client, we discover it has become almost monolithic in structure, if not monopolistic in practice.

According to Media Metrix, Nielsen, IDC and OneStat.com …

• IE has 95% of the browser market
• MS Office has 93% of the business application market
• Windows has 94% of the desktop OS market
• Netscape, Mozilla have less than 3% of browser market
• Opera has .9% of browser market

These market share statistics mean that an application which works in the IE browser will run on a larger share of desktops than any other application in the history of computing.

The IE browser is not the browser of a few years ago. No mere display device for HTML formatted pages, it has become a platform on which applications can be deployed. This includes well-formed XML/HTML document structures, accessible at every level. Additionally, the IE browser includes both Jscript and VBScript languages. Using these languages makes it possible to create complete applications which run on the client without requiring the user to download or install anything. Jscript and VBScript also provide complete access to all of the safe OCX controls that already exist on the client machine.

The technologist’s fear of the application¶

The most common trend we discover in IT, whether it be in corporations, or home users, is an extreme reluctance to install software. 80% of all users are still using modems. What do users and IT departments want? Not to download software, and not to install new software. Most corporations now have "zero footprint" requirements.

Even a few years ago, it was hard to foresee this. But in retrospect, it looks obvious. Here’s why.

Starting with Windows 95, Microsoft decided that it would be a great idea to gather up all the .INI files on a user’s system and consolidate them into one huge database, which they called the Registry. Of course, if this file ever becomes corrupted, the operating system not only fails to start, but can only be fixed by reinstalling Windows.

Another spectacular decision by Microsoft was to take all the DLLs on a machine and put them into one system directory, so all shared code could be used by any program on the computer, which seemed like a good idea at the time to some people.

But what happens if, while a program is installing, it overwrites an older DLL with a "newer" version? The DLL is often less than perfectly backward compatible, and programs that relied on the old version will fail even to start. The result is predictable. As developers produce applications, and write information into the massive Registry, troubles develop.

Users have become very reluctant to install new applications, after having a newly installed software package cause other working applications to malfunction. IT departments have also become unwilling to install new applications for the same reason, not having at their disposal the time or resources to debug the problems which occur from installing new software.

The result of this is that users will no longer install new software and corporations demand "zero footprints". This together with IE’s 95% possession of the browser market, produces an environment in which users and corporations want applications with no "installed" components, and which "run in the browser".

Since it has been established that a successful application must now be created in the browser, the next question is what tools are available to us at this time, and will be for the next three to five years?

What languages are on the client today?

• Jscript, the language formerly known as JavaScript
• Vbscript

So, for at least the next three years, if we are going to effectively get to the client, these are the tools we have to work with.

Now that the client situation is well defined, the next question becomes, what do we need on the server side, and how do we communicate between the client and the server, and between servers?

What questions should I be asking about Web Services?¶

• Why should I care?
• Who is going to use this?
• Does this tie me to Microsoft?
• Is it fast?
• How much hardware do I need?

Who is deploying Web Services today?¶

• Amazon has deployed its first web service for affiliates using XML over HTTP, with SOAP to be added next quarter
• Google Web APIs, which include the following:
  • A WSDL file that formally describes the service.
  • Example SOAP messages and responses.
  • Sample code application that uses the above Web service.
  • Very simple to deploy because of Web Services

There are over 10,000 applications which now include the Google Web API using Web Services. This allows a developer to include access to Google search results in their application. The communication with Google is done using SOAP over HTTP with the result being in XML format. This is an excellent resource to begin to understand Web Services. And, it makes an excellent addition to many applications.

How about security?¶

Microsoft, IBM and VeriSign have teamed to create security specifications for Web Services, a move analysts say will help drive adoption of the hyped but still emerging technology.

Web Services without Microsoft¶

• Web Services has taken on a life of its own.
• Independent of vendor or platform
• WS-I providing leadership on technology
• W3C providing standards validation
• Many vendors implementing

With all of this technology, the question on everyone’s lips, is how does this apply to me as an APL developer? How can I make this work for me? What tools do I have to make to take advantage of these developments and still write code in APL?

APL and Web Services¶

To make APL a success in this server/server or server/client environment requires that APL be capable of multithreading, seamlessly integrating with Web Services, and also being able to run in IE without downloading any code. Yet, with all of these requirements, we also need the ability to place existing APL applications into this new environment without bankrupting our businesses rewriting code that has already been debugged and optimized.

With this background, APL2000 has been working to create a solution which makes it possible to publish existing APL applications to the IE client using Web Services with few or no changes.

The ideal application would of course be stateless, that is carrying all the information about the present state of the application with each transaction. However, that has hardly been the requirement for application development over the last 20 years. So, we discover that existing applications rely on state, global variables and system resources which have been initialized for a particular client.

Deploying legacy code in this new environment requires that a Web Services server understand a one-to-one mapping of client to workspace. Additionally, it must support many-to-one and one-to-many as applications evolve. Next, it logically follows that the server, because of finite resources, must deprecate a workspace which has not been used for some amount of time, and reinstantiate that workspace if a request occurs within a specified period.

In line with this server effort, the APL interpreter also needs dynamic memory allocation. This solves both resource issues on the server, and WS-full concerns where server applications are running basically unattended.

Of course, all of this would be futile if APL could not create responses as quickly as Microsoft’s IIS server. The APL2000 WebServer not only multithreads APLs but also outperforms the IIS server, even on simple requests. When the calculation involves any type of mathematical analysis, APL outperforms IIS by orders of magnitude.

Speed and Reliability¶

Because we knew that Microsoft had seriously biased the Windows 2000, NT and XP operating systems to perform well with their IIS server, we were assuming that we might be able to perform at about 80% of the speed of IIS. So, we were truly ecstatic when we were able to serve up 14,623 responses to only 12,498 for Microsoft’s IIS. This meant that Microsoft’s IIS/ASP was only 85% as fast as APL+Web Services.

In addition there is a particularly critical piece of data which is contained in the test results. In the case of APL+Web Services, we had no socket errors and no HTTP errors. However, the Microsoft IIS solution had 743 HTTP errors and 56 socket errors, or a total of 799 failed responses. That amounts to an error rate of over 6%. From the viewpoint of the user, it means that only 94 out of every 100 pages requested are returned, the other 6 are error pages. Even if the users were willing to tolerate having 6 out of every 100 pages fail, it also means that the application would have to be able to function with only 94 out of 100 pages successfully returned, which becomes fairly difficult to design.

Maybe Microsoft looks at this as a feature? The Microsoft solution is to suggest that you buy more copies of their software and install it on more servers. This also means that you will want to buy their clustering software to efficiently manage this group of servers.

So, for a case where you have an application being accessed by 10 simultaneous users, you either buy more software from Microsoft or experience 6% errors. The reason for this is that Microsoft has built their IIS server on the concept that developers want to deploy single pages, not applications. So for each dynamic page that is returned, IIS must start and stop whatever software is required to create the page.

In our case, we were returning an arraysamp.htm page in the Microsoft simple sample group folders. When we performed the same side-by-side comparison on pages that involved mathematical calculations, APL+Web Services outperformed IIS by a factor of 10 or more, depending on the complexity of the calculation.

For those cases where an application is being deployed over the Internet, APL+Web Services is the only choice. IIS/ASP works primarily only for cases where a single page of data is being returned, not as part of an overall application environment.

One of the concerns, over time, for APL developers has been whether the results calculated by APL could be accessed rapidly. With APL+Web Services, requests can be fulfilled at over 250 per second. This means that an APL application is just as accessible over the web using Web Services as it is when directly connected to the interface.

When an application needs a standalone web service/web server, APL+Web Services provides the answer, and does a better job of publishing an application to the web than anything Microsoft has to offer.

APL and the IE client¶

Since we have IE as the default interface on the client, we needed a consistent method for using this resource. Combining this with a desire to make publishing legacy APL applications as simple as possible led to the creation of APL+JS. This is simply the APL interpreter ported to Jscript.

Typically when a browser interface is created for an application, it involves the creation of adhoc HTML pages, linked to other HTML pages, which include snippets of Jscript on each page. Maintaining this collage of pages and code becomes exponentially more difficult as the user interface grows.

Using APL+JS means that your existing application code is simply published to the web, without having to create any HTML pages or learn any Jscript. This is great, if you want to concentrate on writing APL code. It also provides the ability for the developer to create a standalone application, maintain that application, and then make that same application available over the Internet using Web Services with a minimal of effort.

The IE browser has the Web Services methodology built in, which means that all communication between the user interface, and APL on the server, uses Web Services.

This means that an application published to the web is completely compliant with what an IT department expects in terms of protocols and security. Thus the APL developer can concentrate on their application, not on spending time learning HTTP, HTML, XML, SOAP, etc, etc, etc….

So, if a client asks if the APL application will work in their office, there is only one question which has to be asked. "Can your people get to Yahoo?" If the answer is yes, then the application will work in their IE client.

Of course, speed is always an issue, and tests using the Microsoft Application Test Center show that using the APL2000 Server Suite with APL+Web Services supports over 250 transactions per second. Best of all, there is no requirement that the server side be a Microsoft OS. The server side can also be Linux or Unix, with APL2000 running on the server.

Where do we go from here?¶

It is difficult to guess which way Microsoft will jump. However, no matter which turn technology development may take, it is clear that managed code, running in a client, connecting to a server using Web Services will be at the core of the solution.

This means APL+Web Services and APL+JS are methodologies which create a bridge to the future today, and will be the workhorses of tomorrow. Best of all, APL now has a chance to once again shine in computing solutions, in a way we have not seen since the mid 1960s.

Appendix: Basic terms which define Web Services¶

XML (Extensible Markup Language): Language used to exchange data between computers over the Internet.

SOAP (Simple Object Access Protocol): Describes how Web Services communicate over the Internet.

WSDL (Web Services Description Language): Describes Web Services and how to access them.

UDDI (Universal Description, Discovery and Integration): Lets businesses register, advertise and find Web Services in a directory.

WS-I (Web Services Interoperability Organization) Founded by Microsoft and IBM in February 2002