Date: Sun, 29 Oct 2006 00:51:35 -0400
Reply-To: Don Henderson <donaldjhenderson@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Don Henderson <donaldjhenderson@HOTMAIL.COM>
Subject: Re: Alternative to SAS/IntrNet
In-Reply-To: <000d01c6fa51$7d60d1f0$782275d0$@net>
Content-Type: text/plain; charset="us-ascii"
Alan,
What security hole are you referring to that is exposed by allowing the
broker to run?
I know on IIS that .exe files are not allowed, by default. But you can
enable specific .exe files that are to be allowed and you have to specify
the complete path (e.g., \inetpub\scripts\broker.exe). So you are not
enabling any/all .exe files.
Your comment about a security hole is pretty non-specific. If you can
provide a description of what kind of security risk you think is exposed by
enabling the Application Broker cgi program and that you are concerned
about, perhaps I can address it.
-don
> -----Original Message-----
> From: Alan Churchill [mailto:SASL001@savian.net]
> Sent: Saturday, October 28, 2006 1:26 AM
> To: 'Don Henderson'; SAS-L@LISTSERV.UGA.EDU
> Subject: RE: Alternative to SAS/IntrNet
>
> Don,
>
> It opens a potential security hole by allowing a CGI broker to run.
> Regardless, it runs very fast.
>
> I look forward to the book so I can read more about it but it did require
> me
> to open up my web server a bit to allow everything to work properly.
>
> Alan
>
>
> Alan Churchill
> Savian "Bridging SAS and Microsoft Technologies"
> www.savian.net
>
>
>
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Don
> Henderson
> Sent: Friday, October 27, 2006 1:09 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Alternative to SAS/IntrNet
>
> David/Alan,
>
> Just a couple of points. WRT to the issue of CGI, while it may be outdated
> in the opinion of some/many, it has one primary advantage: it runs
> virtually
> everywhere. There are very few if any issues with getting it to run on
> [insert your favorite] web server.
>
> CGI got a bad rap because it was mis-used, not because it is an inherently
> inferior technology. Are there better technologies for some/many of the
> things that CGI programs can do? Yes. But if CGI works, is portable, and
> performs well, why should we discard it just because it is "outdated"
> (whatever that means).
>
> Quoting myself, :-), from Chapter 3 of my upcoming book "Building Web
> Applications with SAS/IntrNetC: A Guide to the Application Dispatcher"
> (and
> since Axom used a very similar API for how requests were communicated from
> the browser to the server as used by the Application Dispatcher, I am
> guessing that many of the techniques will work there as well):
>
> The Application Broker is a CGI program. CGI applications
> are quite often broadly categorized as less than optimal
> due to the fact that the CGI process must execute on the
> web server. For CGI applications that are "doing all the work"
> this is a valid criticism. However the Application Broker
> is a very lightweight application; it is doing very little
> work other than communicating a request for services to
> another computer. Thus, the typical criticisms of the
> Application Broker as a CGI program are often misplaced
> (except in the case of rarely used Launch Services where
> all the work is done on the web server since for Launch
> Services the SAS Application Server is also running on
> the web server).
>
> For heavily loaded systems where performance is critical,
> the reader may want to consider one of the two additional
> versions (an ISAPI and a GWAPI version) of the Application
> Broker that SAS has developed.
>
> Note that there are now non-CGI versions of the Application Broker. I am
> not
> sure how widely they are used (or even if they are used). Except for
> applications that have an incredibly large number of concurrent
> transactions
> (e.g., 1000s), you will likely see very little performance benefit to
> these
> alternatives. I recall that when SAS R&D was originally considering this
> they evaluated the time used by the broker in an average request. If my
> memory serves me correctly it was significantly less than 1% of the
> overall
> elapsed time for a request. So if you take 1% of a 5 second request, that
> is
> 05 seconds. If you reduce that by an order of magnitude (e.g., to .005
> seconds), your 5 second request will now take 4.955 seconds instead of 5
> seconds.
>
> Next, WRT the issue of the licensing costs, my memory of the difference is
> very different from yours. I also don't believe that a single user PC
> license allows the use of Axom as you describe. Both of these issues are
> something that can probably be easily checked. And I suspect it is
> something
> that will differ based on the type of license a site has. Let me also
> emphasize that I am not saying that I agree with, like, dislike, the
> licensing and pricing policy. I am just stating that it is something to be
> factored in to the consideration to take Axom public.
>
> Regards,
> -don
>
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
> david.l.ward@GMAIL.COM
> Sent: Friday, October 27, 2006 12:50 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Alternative to SAS/IntrNet
>
> Alan,
>
> As a clarification, Axom does not rely on CGI nor was it designed with
> this
> outdated (even in 1999) technology in mind. Axom was built as a TCP/IP
> application server with an open communication protocol. This made it easy
> to develop several different kinds of clients such as ISAPI, Microsoft
> .NET,
> Perl, etc. It also makes it easy to create your own client. "Web-
> enabling"
> SAS code means passing a request from a web server to SAS in some way, and
> Axom gives flexibility in how that is accomplished.
>
> To address the licensing question, I think that your post could be
> misleading. From what I recall, the type of SAS license a customer has
> restricts WHO may use the software, not HOW they might access it. It
> doesn't matter if they use some kind of terminal services software, batch
> script, or a web browser connecting to a web server to control SAS. The
> issue is if they are permitted to do so. SAS has historically offered a
> license "uplift" to extend the permitted user base which, from what I
> understand, costs far less than the full IntrNet product. When I was
> involved with SAS it was a percentage of the Base SAS fee.
>
> You are also forgetting about situations where a single user would like to
> develop, run, or demonstrate web applications with SAS on their own
> computer. Axom would allow them to do so without breaking any license
> restrictions. Universities could also make use of the software so that
> their students could learn how to code SAS for the web again without
> stepping outside of the bounds of their license restrictions.
>
> I hope that helps clarify things. Feel free to correct me where I am
> wrong.
>
> David Ward
>
> Alan Churchill wrote:
> > David,
> >
> > SAS/IntrNet (and I presume Axom as well), rely on a cgi approach for
> > web submission. There are 2 issues I see right away with an
> > alternative to
> > SAS/Intrnet:
> >
> > 1. Licensing.
> >
> > Just because you can technically accomplish submitting SAS
> > jobs over the web doesn't mean that SAS still won't charge you for
> > doing it regardless. I can
> > technically bypass both IntrNet and Integration Technologies
> > but SAS still requires a fee for those products.
> >
> > 2. There are better means (IMO) for submitting SAS code over the web
> > than CGI. For example, ROR, ASP.NET, J2EE, Perl, etc.
> >
> >
> > I think the offer is generous but I am unsure as to the applicability
> > considering that major web deployment advances have been made since
> > you originally wrote it. #1, though, is the real issue here.
> >
> > Alan
> >
> >
> > Alan Churchill
> > Savian "Bridging SAS and Microsoft Technologies"
> > www.savian.net
| 
