Question
· May 30

IRIS Weblink - Basic capabilities

Hi Folks,

I am an architect working on a program involving Weblink. I am new to InterSystems and I am looking for information around basic capabilities of Weblink. I understand that the version we are dealing with (2014) is not supported no need to review that :).

Thank you,

Mike

Discussion (5)4
Log in or sign up to continue

Hi Michael

Can I suggest you first read this article on our mg_web product which is designed for anyone in exactly your situation:

https://github.com/chrisemunt/mg_web/blob/master/why_mg_web.md

Some additional historical background that may help:

Something you should note is that a lot of people refer generically to WebLink, but there were always two distinct parts to it:

- the core WebLink gateway, which provided the physical connection between the web server (usually either Apache or IIS) and one or more Cache databases

- an early web application framework that I designed and built on top of the WebLink gateway, known as WebLink Developer.  This pioneered many areas of functionality that have now become commonplace in Web Applications generally, and was created in no small part as a way to help developers using WebLink and creating for themselves all manner of serious security issues.  The use of WebLink Developer was optional, and many people built their own Cache-based Web Applications using the core WebLink gateway and its APIs.

So, when you say you have a program involving WebLink, you first need to determine if it's actually a WebLink Developer application or separately handcrafted logic that makes use of the core WebLink gateway.

Some technical background that may also help you:

Whilst WebLink Developer was superseded by CSP-based applications and other non-InterSystems frameworks (eg my own EWD framework), the core WebLink gateway continued active service right up until the introduction of IRIS.  InterSystems made the commercial decision to no longer support WebLink in IRIS.

The architecture of the core WebLink gateway was an innovative queue/dispatch mechanism that ran as an add-on module in the Web Server, and made completely stateless, persistent connections to one or more Cache databases.  This had an interesting effect in terms of licensing: each connection consumed a single Cache license, but the queue/dispatch mechanism allowed any number of concurrent web application users to be supported via the configured WebLink-Cache connections. Too few connections to support the concurrent traffic simply resulted in requests being queued and taking longer to be handled, but you'd not actually run out of Cache licenses, no matter how many concurrent users you had: ideal for use on the open Internet where user numbers were impossible to control.

In terms of technical capability, contrary to widespread belief, there was never anything that CSP's core gateway could do that WebLink's core gateway couldn't also do equally well.  On the Cache-side of a WebLink connection, you had full access to all of Cache's capabilities via ObjectScript, including Objects and SQL. My colleague Chris Munt designed and created the WebLink gateway and assisted InterSystems in the design and support of the core CSP gateway, so we have full knowledge of the comparative capabilities of both technologies.

CSP was designed by InterSystems to replace the core WebLink gateway and inherently included an application framework that was completely based around the use of Cache Objects.  Critically, CSP also added an embedded mechanism that enforced stricter licensing by artificially inflating the number of licenses needed to support a given number of concurrent users (leading to the infamous "grace period" and the resulting risk of running out of Cache licenses on a busy system).  When CSP was introduced, WebLink was deprecated by InterSystems and no longer actively promoted, but was retained as a supported product for any existing legacy users.

Unfortunately no viable migration pathway was ever available for legacy WebLink users other than a potentially risky, time-consuming and costly rewrite of applications to CSP, or a rip-and-replace migration to a (sadly) more commonplace mainstream back-end web architecture and database technology.  The result is that there are actually still quite a lot of WebLink users out there, and some are extremely large users indeed!

So, with all that in mind, you can hopefully understand our rationale for creating mg_web and why it's gaining traction with some of the big legacy WebLink users.  We (MGateway) provide technical support for mg_web and, having been instrumental in introducing WebLink in the first place, can provide expert technical assistance in WebLink migrations.  Please contact my colleague Chris Munt in the first instance - his contact details can be found via the mg_web repository.