Hi, it’s me again (Web Interface Guy).

Before I start going on and on with all my ideas about where WI should be heading (just the usual stuff: stopping hunger, imposing world peace, serving fries with every app launched), it will help to be clear about what WI is for; what it’s role in life is and should be.  As you would expect, I have a fairly strong opinion on this, but I realize mine may be a rather blinkered view, coloured by the aspirations Citrix has and those I have myself – so please tell me if you think I’m being dumb about this.

Actually, it will help even more if I am clear about what Web Interface is first.  (Thought you knew did you?  Ah-ha!)

As far as I am concerned, WI comprises about a dozen things – in other words, this is what the WI engineering team actually builds and maintains:

  • the normal WI web app (ASP.NET and JSP flavours)
  • PNAgent Services (same two flavours)
  • WI web parts and other bits for SharePoint
  • WI portlets for Java-based portals (like WebSphere, SAP, etc)
  • WI configuration manager (aka the central config service)
  • WI extension to the AMC (our admin tool)
  • WI installer and site manager tool (2nd stage installer)
  • WI core resource access library
  • WI SDK documentation
  • CPS XML services (NFuse, Admin, Config, STA, RADE)

In fact, about the only component we don’t build that logically should perhaps be treated as part of WI is the PNAgent client itself – it is essentially the non-browser UI version of WI.

I mention this list, because I want to use the term ‘Web Interface’ as a shorthand for all of it, not just the first item which is what everyone else thinks of as WI.  (BTW, I have tried to come up with a good term for this “WI in the large” notion but somehow all my acronyms seem a bit lame – WIITL anyone?)

So anyway, back to my point: what is the role of ‘Web Interface’, in this larger sense?

I think the answer is quite simple: WI’s job is to provide users access to their resources.  The emphasis is on the word provide, for which I have a quite specific meaning in mind.

First let me digress a bit: Citrix started using the term Access Infrastructure a couple of years ago to try and explain the value our products offer, both individually and collectively.  That got me thinking, and I came up with this simple way to categorize our products and components as performing one or more of the following basic functions:

  1. Provide access to resources
  2. Deliver resources or access to resources
  3. Enhance the delivery of resources
  4. Control resource access and delivery
  5. Manage (ie. measure or monitor) resource access and delivery

The ICA piece of Presentation Server of course delivers applications remotely, and enhances the delivery in many ways that I won’t tire you with now.  Our SSL VPN products deliver remote network connectivity or access to specific resources (internal web sites, files, etc) and our NetScaler products enhance the delivery of web applications by providing security, compression, load balancing and so on.  Our latest product, WanScaler, does a similar job enhancing network connectivity to branch offices.

Presentation Server, Access Gateway Advanced Edition and NetScaler all support rich policies for controlling their respective resource access or delivery mechanisms, and we are already part way down the path of converging and combining these policy controls to work collectively.

The EdgeSight product line is focused squarely on the final function, of measuring and monitoring all of the above.  The Resource Manager, Report Center, and Dashboard components serve the same function for CPS specifically.

(Okay, you get the idea – there is a cogent strategy in action here.)

For me, the point is that WI is concerned only with the first function, and merely plays a supporting role to the products and components addressing the other functions.  This may seem a trite point, but actually it helps people in Citrix (me in particular!) to understand which of the many enhancement requests or neat suggestions we get for WI are sensible, and whether and how we should go about extending WI to support new features and capabilities in our products.

Right then, here is my definition of what it means for WI to provide users access to resources.  It is WI’s job to

  • Be aware of the existence, location and nature of resources
  • Be aware of how resources can be accessed or used
  • Be aware of users and access scenarios
  • Make the existence of resources and possible actions known and available to users
  • Arrange or orchestrate access to resources (or initiate actions) when requested

I like this definition for lots of reasons, but I’ll highlight only a couple right now.

#1 and most significant, WI is at the intersection of users, scenarios and resources. 

WI (usually) needs to know who the user is, but that can be a much richer concept than the traditional view of simply a user name or id – users can have multiple accounts or identities, and may take on different roles in their work at different times.  WI is a good place to help map between these identities and account for the richness that actually exists.  Authentication of course is important and needs to be flexible – but WI doesn’t necessarily have to perform authentication itself.

WI then needs to take account of the scenario – ‘where’ is the user, how are they using the system, what are they trying to do, what are they expecting to happen?  In the WI team, we spend a lot of time thinking about this aspect – as I noted in my first post, for many users WI is the face of Citrix and although they may not be able to express very well what they want, they can certainly tell when it didn’t happen!

WI needs to understand the resources; what are they, what are they for, what can you do with them, how do they work?  Note that this is more than just knowing how you “get” to the resource – different types of resources may be accessed with the same physical means (eg. ICA connections to published apps or virtual desktops), and the same resource might be accessed in quite different ways depending on the type of user interface.  For example, someone seeing a Word document link in SharePoint may expect Word to run when they click the link; the same person seeing the same resource listed on their BlackBerry might want a summary of the document emailed to them.

Finally we get the juxtaposition of these three aspects: WI has to figure out what can this user meaningfully do with this resource in thisscenario?  And how can that be made to happen?

#2, WI is an orchestrator and must therefore deal with all the complexities and idiosyncracies that come with the territory.  WI offers the user “X”, the user says “do X”, WI must make X happen!

In practice, for the resources WI understands today, that involves detecting the access client / device capabilities, downloading and installing appropriate client components if necessary (or giving instructions on how to do this manually), providing ‘directions’ (translating addresses as necessary based on the user’s location relative to the resource, putting the right settings in launch.ica), obtaining security tickets and access tokens where needed, etc.

I think of WI as aiming to be a bit like the perfect travel agent; the user outlines what they want, the travel agent makes some assumptions and deductions, books everything, then hands over a tidy package with the itinery, tickets, foreign currency, emergency helpline numbers, sick bag, etc all neatly layed out.  (But they don’t actually go on holiday with you.)

Well, that’s the aim anyway!