To order Alpha Four or Alpha Five, click above to go directly to Alpha, or call 800.451.1018 or 781.229.4500
|
|
|
|
|
|
Tuesday, October 1, 2002
|
|
VOLUME 1
ISSUE 8
|
|
|
|
|  |
|
|
An Interview with Lenny Forziati
by Jim Chapman
Forward
I believe Alpha Software's new Alpha Five Web Application Server is an extremely important development for the Alpha community. With the release of this software the Alpha Five user and developer will find their skills extended to the world of the internet and intranets. If you know Alpha Five, you know Alpha Five Web Application Server!
Lenny has graciously offered to respond to YOUR questions about this important new product in the next issue of the Alpha Newsletter. If you have questions for Lenny, please send these to me at jc@cknet.net. Please put "Questions for Lenny" in the subject field. I will compile them, submit them to Lenny, and we will all get the benefit of your questions and Lenny's answers in the next issue.
Q: Lenny, you are the lead programmer on one of the most exciting projects that Alpha Software has embarked upon, the Alpha Five Web Application Server. It is my understanding that an early beta version is now available. Is that correct?
Yes, we are very excited to finally have something for users to begin trying out. It is still an early beta and is missing several features so you'll need to be comfortable writing Xbasic, but the core functionality is there and it will let developers begin creating web applications. If you haven't already done so, you can visit to download the beta and view the documentation. And feel free to let me know what you think of it by emailing me at len@alphasoftware.com
Q: Can you give us some insight on how long this project has been underway?
Selwyn and Richard brought me in to define and implement a web enabled version of Alpha Five in November 2001. The initial months were spent researching the competitors and honing my Xbasic skills. It was probably almost 2002 when I started seriously implementing the server.
Q: Can you tell us about your background and how you came to be working on this project?
I started my career in technology back in 1995 when I got my first computer related job with Alpha as their "Internet Marketing Specialist" (webmaster). After just a few months I outgrew that position and was moved to the WebFiler project, which was Alpha's original foray into the Internet. As the WebFiler Hosting Service Manager, I built the server and hosting infrastructure for hosted users as well as programmed a sign-up and billing system to run it all while contributing to the development of WebFiler itself.
As Alpha went through its transitions, I ended up as an independent consultant and then started an application service provider, NorthOfZero.com, providing customer relationship management, business intelligence, and e-commerce. Alpha remained a customer of mine and I stayed in touch with Richard and Selwyn through the years. Then late last year I was in the Alpha office to look at some network issues for them and I got to talking to Selwyn about web capabilities. North of Zero was at a point where it largely runs itself, so here I am.
Q: Can you tell us a little about the philosophy and history behind Alpha Software's decision to develop a web server?
I think Alpha's decision to create the Web Application Server was made to give the people what they want. The customer demand for this offering is high and Alpha Five is certainly powerful enough to handle it. We believe that a thin-client web interface is the way to go for many applications. It really centralizes administration and opens up accessibility.
Q: You mention WebFiler. I remember seeing a demonstration of WebFiler at the Alpha Developers conference in Houston Texas some years ago. Can you tell us how the new Alpha Five Web Server is different from that project?
WebFiler was a stand-alone product and utilized a web browser interface for everything, from creating tables to building applications. This interface was slow and awkward to work in when compared to a polished desktop application. And even though it used standard DBF files, it did not directly support sets, and code developed within Alpha Five was not usable in WebFiler.
The Web Application Server is really more like Alpha Five with a web server built into it, all work is done within the familiar Alpha Five interface. This makes it much easier to learn and much easier to work with on an ongoing basis. And UDFs and scripts that you've created and use within Alpha Five are also usable by the Web Application Server. It is a much more integrated product.
But overall, WebFiler was an excellent product. Its biggest problem was that it was well ahead of its time. Back in 1995/1996 almost nobody was putting database applications on the web. After all, DSL and cable modems were a far-off dream and T-1 access was several thousand dollars per month. I still have one of the original WebFiler product boxes on my bookshelf at home.
Q: One of WebFiler's capabilities that impressed me the most was the ability, over any internet connection, to log into your application remotely, and make changes to table structures, code, etc. Will this type of capability be available with the new Alpha Five Web Server?
Actually, this isn't something we had considered including until now, but only because it didn't seem like something customers would want. Many WebFiler users actually commented that they found this cumbersome and would have preferred to create and modify their tables in Alpha Five instead. The great thing about having the beta available to users now is that we can get feedback and requests for features such as this and add them to meet the demand. Please let us know what the server doesn't do that you would like to see added by emailing me at len@alphasoftware.com .
This is also a good opportunity for me to point out how you could extend the Web Application Server yourself if we don't include a feature you want. This is possible because the server will work with any Xbasic functions already available in Alpha Five, with the possible exception of some of the UI related stuff like Xdialog. So if we don't include the table restructure capability that you are looking for, you could simply add it yourself by creating a web page with Table.add_fields() and Table.delete_fields() embedded within.
Q: When we talk about web servers, we instantly think of the internet, but my guess is that the Alpha community will put the new web server to equally good use on company intranets. This will bring true thin client, client/server capabilities to the Alpha user and developer, allowing any platform that can run a browser to access Alpha Five's data sources, be it Macintosh, Linux, or any other flavor of OS.
I expect that many of applications built for the Web Application Server will be run on company intranets even though the server would do equally well running a public web site. As you mentioned, it will give users a true client-server environment and the remote access capabilities and expanded client platforms will be a true benefit to businesses with remote offices and traveling staff. We get a fair number of inquires about Alpha Five for Mac or Linux and while this isn't quite that, it at least allows heterogeneous access to your applications.
Q: The first question that many users will ask is whether forms created in Alpha Five version 5 can be displayed on the web.
Yes and no. Alpha Five forms are not HTML so there needs to be a translation process. Thanks to some fantastic work by Eavan Chambliss, Cian's younger brother, this translation is very easy for the application developer and the resulting web pages are strikingly similar to the Alpha Five forms. Not all custom code for buttons, events, etc will be able to be translated since the client is just a web browser but I still think that users will be very pleased with what can be accomplished.
Q: Lenny, Microsoft would probably consider that an unfair advantage, having two Chambliss's working for the same company!……. I understand that an HTML editor will be included. Will this be a WYSIWYG editor?
It's not in the beta yet, but the Web Application Server will have a WYSIWYG HTML editor built into it. It will probably just be a new tab on the Code Editor and it will be similar to having something like FrontPage built into Alpha Five. You'll also still be able to use any other HTML editor if you wish.
And I should also mention that the HTML editor will also become available for other tasks in future releases of Alpha Five, such as composing an email.
Q: Help us understand the process in creating an HTML form with a button that will display data on the user's browser. Will we have to embed Xbasic directly in the HTML, or can we call a Xbasic or Action script?
It really depends on how fancy you want to get, it can be as simple as right-clicking a table in the control panel and choosing "Generate Default HTML Form". This form might not be beautiful (is any default form?) but it will allow users to browse, enter and edit records and do a query by expression.
To develop a more custom form, there will be Genies to help with the process. And for the hard-core developers out there, you can fire up the Code Editor and write everything by hand if you really want to.
Q: Assume we have developed a 'standard' Alpha Five version 5 application that is accessing a database that is in use over an Ethernet network. Could Alpha Five Web Application Server also be serving this same data out to the internet or an intranet?
Absolutely, this was an important consideration when we defined the product. The Web Application Server uses the exact same tables and databases and it can access data that is also being used by Alpha Five, either full versions or runtime. We think this is really powerful in that it lets customers continue using their existing applications how they use them now and add on the web capabilities for additional uses.
Q: So the Alpha Five Web Server will honor all table field rules for data input via the web, is this correct?
Yes. The problem we faced with this though is that the Alpha Five engine itself evaluates field rules one at a time, which means any errors are displayed individually. In a desktop environment like Alpha Five this is insignificant but with a web interface, application users would have to submit their data multiple times and only be told about the first error encountered each time.
To solve this issue, the Web Application Server supports a new table/set method, a5w_save_record, which takes care of data type conversion and field rule evaluations all at once. By the time the Web Application Server is released, there will actually be many new functions and methods that simplify tasks like this.
Q: One of the great new features of Alpha Five version 5 is Xdialog. Will Xdialog play a roll in using the new Alpha Five Web Server?
No, not really. We may eventually come up with a way for an Xdialog form to dynamically be converted to HTML to be used in a browser, but in reality HTML is more complete than Xdialog and easier to write.
Q: Security today is not just a concern, it's an imperative. Can you tell us how that issue will be addressed?
Security is of course a priority with any Internet application and we're working hard to make the Web Application Server as secure as possible. There is also a lot to consider as you build an application in order to keep your data safe. This is a very broad subject and instead of trying to give you a quick answer, I think it would make sense to do a future newsletter article that can address security at length.
Q: I understand that Xbasic played a major role in the development of the web server. Is this correct?
Yes, the Web Application Server is 100% Xbasic code and I think that speaks volumes about the raw power that Alpha Five puts in the hands of developers. Cian did have to implement some new functionality at lower levels of Alpha Five, but it is all exposed to developers through Xbasic. If you were really inclined to do so, you could build your own web server using Xbasic instead of using the Web Application Server.
Q: Will the Alpha Five Web Server co-exist with other web servers, such as Apache or IIS?
All web servers bind to a specific TCP/IP port to listen to incoming requests, and only one server can be bound to a specific port. As long as you select different ports for the individual servers, they peacefully coexist. On my development system I have the Web Application Server running on port 80 (the default for web traffic), Apache running on port 81 and IIS running on port 82.
Q: How will the Alpha Five Web Server co-exist with other common internet tools and technologies? I'm thinking here of JavaScript, PHP, Perl, etc.
JavaScript is largely a client-side language, meaning it is run within the browser itself. There is no problem with including JavaScript code within your HTML to be served by the Web Application Server. This is actually an ideal way to do some pre-validation before the field rules even get a peek at the data being entered.
As far as PHP, Perl or any other server-side language, there are a couple of ways to use them. Probably the easiest right now is simply with a sys_shell() command to the PHP or Perl file on the server from within the Xbasic on your web page. The Web Application Server does not directly support PHP or Perl though.
Q: So Alpha Five Web Application Server is an extension of Alpha Five version 5. One program serving your data locally, over an intranet and or over the internet. Can you contrast for us the Alpha Five Web Application Server approach versus the traditional methods of getting your data onto the Internet?
The Web Application Server really incorporates several pieces that are needed to put a database application online. Without it, you would have three layers of software intercommunicating. The first layer would be the actual web server software, such as Apache or IIS. The web server does not really know anything about the data, it just receives requests and returns HTML documents. The third layer would be the actual data. This could be in many forms, such as an SQL server or a dbf file. In between these two layers, you would need a scripting language, such as Perl, ASP or PHP, to tie it all together. Each of these pieces are separate - you would have to setup and configure the web server, have a command of the scripting language, and be able to write scripts to access your data source and return this data to the web server.
I have quite a bit of experience using the other tools out there since I have built several complex web applications with PHP and Active Server Pages, probably the two most common out there, as well as some of the others. These are both powerful programming languages and you can accomplish amazing things with them, but you have to be very skilled in them since they don't include an IDE (integrated development environment). That means you launch your favorite text editor and then write all your code by hand.
While both of these get the job done, the end result is a similar application that took far longer and a much higher level of expertise to build. With the Web Application Server, you get the power and flexibility without having to learn a new programming language, and in many cases you don't have to write any code at all. That means you save a lot of time and frustration without giving up any power.
Q: I know you are still in the early beta stages, but do you have any thoughts on how robust the Alpha Five Web Server will be?
We're making leaps and bounds in this area with true background threading being added to Alpha Five.
It's still early to be able to tell exactly what the performance will be, but we expect that the Web Application Server will certainly handle a busy application such as the Alpha Message Board.
Q: It is my understanding that the web server will be licensed and priced based on the number of concurrent users that be can logged on. Is this correct?
The server will be licensed by simultaneous sessions. We count the number of distinct clients accessing the server within a given time period. So if a Web Application Server is licensed for ten sessions, and 11 users try to access it within a short period, even if they are not accessing it simultaneously, the 11th user will be denied. However, each session is closed out after a period of inactivity, at which time a new client will be allowed access.
Q: Can we define the length of this inactivity or will this be built into Web Server?
This is a setting that you can define from within the Web Application Server Control Panel, though in all but the unlimited license version we will restrict the minimum session lifetime. Actually we expect that most users will set this to a high value since closing a web session would be equivalent to closing Alpha Five in the middle of your work - the application no longer knows where you were and what you were doing so you need to start over.
If you've ever visited a web site and been presented with an error such as "session timed out" after making a few clicks, doing something else, then returning to the site, you've seen firsthand the problems and inconveniences caused by short session lifetimes. Long-time Alpha users that visited the Message Board when it was run on WebFiler will remember the session errors when posting messages. This is solved by longer session lifetimes.
Q: Along this vein, we should probably bring out the fact that an internet session is stateless. I believe Apache, a highly used and well thought of web server, offers approximately 60 or 70 concurrent connections, if I remember correctly. Can you explain the difference between connections and sessions?
I'm not sure of the Apache performance numbers, but it is limited by the number of simultaneous connections. Sessions and connections aren't quite the same thing. A connection is just a request sent by a client asking the server to do something. The limitation here is how fast your server CPU and memory is available to process the requests.
60 or 70 concurrent connections is a very large number because that would be 60 or 70 users clicking a form's submit button all at the same time¹. In a more realistic setting, these 70 users would be accessing the server at slightly different times and the server's CPU, memory and disks would only need to process just a few requests at any given time. To get 70 concurrent connections you'd need to have far more than 70 active users.
Sessions on the other hand are kept alive by the server between connections from each client. When a client first makes a connection to the server, a session is created to allow developers to store state information and this is how we implement licensing. So in a 70 user intranet scenario, you would still need a 70 session license.
Q: I am going to get selfish with this question. Before Selwyn Rabins announced at the last Alpha Five Developers conference, that an Alpha Five version 5 Web Server was under development, I was hoping for that Alpha Software would release Xbasic as a server side scripting language that could be used with any web server. Was this concept considered?
We've toyed with the idea of a "console Xbasic", but it is really just more of a dream of the developers here. We all really enjoy working with Xbasic and would like to see it be an alternative to something like Perl or batch programming, but it would take a good deal of work and distract us from improving on Alpha Five, and take time from projects like the Web Application Server and ADO support. It would be a neat tool to have, but it's probably not too likely that it will actually happen.
Q: Ok, we've come to the end of this interview and I can almost hear our readers clamoring for me to ask this question. Can you give us any indication of the cost of this product?
Pricing hasn't been finalized, heck I haven't even spoken to Richard about it yet. But we're thinking it will probably be less expensive than the runtime. I realize that's a bit vague, but that's all I can really say for now. I'll also add that the Web Application Server will include the familiar AlphaSports application that ships with Alpha Five, extended to include web interfaces of course. The web-enabled AlphaSports will include intranet features such as order review screens for remote sales staff and Internet features such as an online store with shopping cart. This will give users a strong head start in their application development since they can use AlphaSports as a building block. And these features will be detailed in a step-by-step tutorial, making them that much easier to build upon.
¹Actually they don't quite have to be all at the same time. Presumably a client request will take some period of time to process and the connection stays active as long as that request is being fulfilled. So if you had a web page with Xbasic that zipped a full database and it took 2 minutes to complete, each connection would be active for that long and it would be much easier for the number of connections to start piling up.
[PRINTER FRIENDLY VERSION]
|
|
| |