Progress Webspeed
Progress Webspeed
Progress Webspeed
OPENEDGE 10
2009 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.
These materials and all Progress software products are copyrighted and all rights are reserved by Progress Software Corporation. The
information in these materials is subject to change without notice, and Progress Software Corporation assumes no responsibility for any
errors that may appear therein. The references in these materials to specific platforms supported are subject to change.
Actional, Apama, Apama (and Design), Artix, Business Empowerment, DataDirect (and design), DataDirect Connect, DataDirect
Connect64, DataDirect Technologies, DataDirect XML Converters, DataDirect XQuery, DataXtend, Dynamic Routing Architecture,
EdgeXtend, Empowerment Center, Fathom, IntelliStream, IONA, IONA (and design), Making Software Work Together, Mindreef,
ObjectStore, OpenEdge, Orbix, PeerDirect, POSSENET, Powered by Progress, PowerTier, Progress, Progress DataXtend, Progress
Dynamics, Progress Business Empowerment, Progress Empowerment Center, Progress Empowerment Program, Progress OpenEdge,
Progress Profiles, Progress Results, Progress Software Developers Network, Progress Sonic, ProVision, PS Select, SequeLink, Shadow,
SOAPscope, SOAPStation, Sonic, Sonic ESB, SonicMQ, Sonic Orchestration Server, SonicSynergy, SpeedScript, Stylus Studio,
Technical Empowerment, WebSpeed, Xcalia (and design), and Your Software, Our TechnologyExperience the Connection are
registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and/or other countries.
AccelEvent, Apama Dashboard Studio, Apama Event Manager, Apama Event Modeler, Apama Event Store, Apama Risk Firewall,
AppsAlive, AppServer, ASPen, ASP-in-a-Box, BusinessEdge, Business Making Progress, Cache-Forward, DataDirect Spy, DataDirect
SupportLink, Fuse, Fuse Mediation Router, Fuse Message Broker, Fuse Services Framework, Future Proof, GVAC, High Performance
Integration, ObjectStore Inspector, ObjectStore Performance Expert, OpenAccess, Orbacus, Pantero, POSSE, ProDataSet, Progress ESP
Event Manager, Progress ESP Event Modeler, Progress Event Engine, Progress RFID, Progress Software Business Making Progress,
PSE Pro, SectorAlliance, SeeThinkAct, Shadow z/Services, Shadow z/Direct, Shadow z/Events, Shadow z/Presentation, Shadow Studio,
SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, SmartDataView, SmartDialog, SmartFolder, SmartFrame,
SmartObjects, SmartPanel, SmartQuery, SmartViewer, SmartWindow, Sonic Business Integration Suite, Sonic Process Manager, Sonic
Collaboration Server, Sonic Continuous Availability Architecture, Sonic Database Service, Sonic Workbench, Sonic XML Server,
StormGlass, The Brains Behind BAM, WebClient, Who Makes Progress, and Your World. Your SOA. are trademarks or service marks
of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and other countries. Java and all Java-based marks
are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Any other trademarks contained
herein are the property of their respective owners.
Third party acknowledgements See the Third party acknowledgements section on page Preface6.
December 2009
For the latest documentation updates see OpenEdge Product Documentation on PSDN (http://communities.progress.com/
pcom/docs/DOC-16074).
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface1
1.
Introducing WebSpeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed request round-trip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Before the first request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web request round-trip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web programming and WebSpeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed and the OpenEdge platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OpenEdge Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed and the OpenEdge Reference Architecture . . . . . . . . . . . . .
11
12
12
15
15
16
18
19
19
110
2.
Configuring WebSpeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSpeed configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring your Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying the location of static files . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring virtual directories for the IIS Web server . . . . . . . . . . . . . . .
Configuring virtual directories for the Apache Web server . . . . . . . . . . .
Testing the Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported Web servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported Web browsers and preference settings . . . . . . . . . . . . . . . .
WebSpeed administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AdminService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ubroker.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unified Broker framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NameServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting up the WebSpeed environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a working application directory . . . . . . . . . . . . . . . . . . . . . . . . .
Moving application files to appropriate directories. . . . . . . . . . . . . . . . . .
Compiling Web objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintaining the WebSpeed Transaction Server and
NameServer log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
22
23
23
24
24
25
25
26
27
27
27
210
211
214
214
214
216
216
217
Contents
Configuring a WebSpeed Transaction Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing the WebSpeed Transaction Server . . . . . . . . . . . . . . . . . . . . .
Configuring a WebSpeed Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Messenger-only installation . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Messenger executable . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing the Netscape Web server configuration file . . . . . . . . . . . . . . . . .
Where to place the Messenger executable file . . . . . . . . . . . . . . . . . . . .
Managing the WebSpeed Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . .
218
219
221
221
222
223
224
225
3.
31
32
32
32
33
33
34
36
37
39
312
313
313
316
317
317
317
318
318
4.
41
42
43
44
46
48
412
414
418
418
419
420
424
427
431
433
433
436
442
442
443
443
444
444
444
445
Contents2
Contents
A.
447
447
448
449
A1
A2
A3
A5
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index1
Contents3
Contents
Figures
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 31:
Figure 32:
Figure 33:
Figure 34:
Figure 41:
Figure 42:
Figure 43:
Figure 44:
Figure 45:
Figure 46:
Figure 47:
Figure 48:
Figure 49:
Figure 410:
Figure 411:
Figure 412:
Figure 413:
Figure 414:
Figure 415:
Figure 416:
Figure A1:
Contents4
12
16
19
111
34
36
37
39
43
45
47
49
412
414
425
426
429
431
432
433
436
443
445
446
A2
Contents
Examples
Example 41:
Example 42:
Example 43:
Example 44:
Example 45:
Default web-disp.p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secure web-disp.p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passing unique identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring ubroker.properties file for firewall . . . . . . . . . . . . . . . . . . .
Checking NameServer access using NSMAN -name NS1 -query . . . .
428
429
430
434
440
Contents5
Contents
Tables
Table 21:
Table 22:
Table 23:
Table 24:
Table 25:
Table 26:
Table 31:
Table 32:
Table A1:
Table A2:
Table A3:
Table A4:
Table A5:
Contents6
23
26
211
212
222
223
310
317
A2
A3
A4
A5
A6
Preface
This Preface contains the following sections:
Purpose
Audience
Organization
Typographical conventions
Example procedures
OpenEdge messages
Preface
Purpose
This manual introduces you to the WebSpeed environment for developing Web
browser-based business applications that support real-time database access and management. It
explains the structure of a WebSpeed environment and how transactions are processed. The
manual discusses configuring WebSpeed environments and the development tools to which you
have access. Finally, the manual gives basic information on deploying WebSpeed applications
and securing your WebSpeed environment.
Audience
This manual is for anyone interested in learning how to create applications with the WebSpeed
development environment. Knowledge of WebSpeed or SpeedScript programming is not
required. However, you should also have a working understanding of the Internet and of the
World Wide Web, and some experience creating and editing HTML pages.
Organization
Chapter 1, Introducing WebSpeed
Introduces the WebSpeed architecture, including general information on the WebSpeed
round trip process, Web programming, and the Progress OpenEdge platform.
Chapter 2, Configuring WebSpeed
Provides information about configuring WebSpeed environments. The chapter also
includes basic information about configuring your Web server.
Chapter 3, Tools and ABL Support
Describes the tools and utilities used in WebSpeed application development.
Chapter 4, Running and Deploying WebSpeed Applications
Provides information on launching WebSpeed in various environments, starting
information on securing your WebSpeed environment, and how to access the WebSpeed
sample applications.
Appendix A, WebSpeed Configuration and Management Utilities
Describes the syntax for commands and utilities documented in this manual. If this manual
provides the primary documentation for a command or utility, the syntax for that
command or utility appears in this appendix.
Preface2
Preface
Like most other keywords, references to specific built-in data types appear in all
using a font that is appropriate to the context. No uppercase reference ever
includes or implies any data type other than itself.
UPPERCASE,
Wherever integer appears, this is a reference to the INTEGER or INT64 data type.
Wherever character appears, this is a reference to the CHARACTER, LONGCHAR, or CLOB data
type.
Wherever numeric appears, this is a reference to the INTEGER, INT64, or DECIMAL data type.
References to built-in class data types appear in mixed case with initial caps, for example,
References to user-defined class data types appear in mixed case, as
specified for a given application example.
Progress.Lang.Object.
Preface3
Preface
Typographical conventions
This manual uses the following typographical conventions:
Convention
Description
Bold
Italic
SMALL, BOLD
CAPITAL LETTERS
KEY1+KEY2
KEY1 KEY2
Syntax:
Fixed width
Fixed-width italics
Fixed-width bold
UPPERCASE
fixed width
Example procedures
This manual provides numerous example procedures that illustrate syntax and concepts. You
can access the example files and details for installing the examples from the following locations:
The Documentation and Samples located in the doc_samples directory on the OpenEdge
Product DVD.
http://communities.progress.com/pcom/docs/DOC-16074
Preface4
Preface
OpenEdge messages
OpenEdge displays several types of messages to inform you of routine and unusual occurrences:
Compile messages inform you of errors found while OpenEdge is reading and analyzing
a procedure before running it; for example, if a procedure references a table name that is
not defined in the database.
Startup messages inform you of unusual conditions detected while OpenEdge is getting
ready to execute; for example, if you entered an invalid startup parameter.
Continues execution, subject to the error-processing actions that you specify or that are
assumed as part of the procedure. This is the most common action taken after execution
messages.
Returns to the Procedure Editor, so you can correct an error in a procedure. This is the
usual action taken after compiler messages.
Halts processing of a procedure and returns immediately to the Procedure Editor. This
does not happen often.
OpenEdge messages end with a message number in parentheses. In this example, the message
number is 200:
If you encounter an error that terminates OpenEdge, note the message number before restarting.
Choose Help Recent Messages to display detailed descriptions of the most recent
OpenEdge message and all other messages returned in the current session.
Choose Help Messages and then type the message number to display a description of a
specific OpenEdge message.
Preface5
Preface
On UNIX platforms, use the OpenEdge pro command to start a single-user mode character
OpenEdge client session and view a brief description of a message by providing its number.
To use the pro command to obtain a message description by message number:
1.
OpenEdge-install-dir/bin/pro
2.
3.
Type the message number and press ENTER. Details about that message number appear.
4.
Press F4 to close the message, press F3 to access the Procedure Editor menu, and choose
File Exit.
Preface6
Preface
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN MICROSYSTEMS, INC. AND
ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY
LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE
SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN MICROSYSTEMS, INC.
OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR
FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE
DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF
LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE,
EVEN IF SUN MICROSYSTEMS, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
OpenEdge includes DataDirect software Copyright 1991-2007 Progress Software
Corporation and/or its subsidiaries or affiliates. All Rights Reserved. (DataDirect Connect for
JDBC Type 4 driver); Copyright 1993-2009 Progress Software Corporation and/or its
subsidiaries or affiliates. All Rights Reserved. (DataDirect Connect for JDBC); Copyright
1988-2007 Progress Software Corporation and/or its subsidiaries or affiliates. All Rights
Reserved. (DataDirect Connect for ODBC); and Copyright 1988-2007 Progress Software
Corporation and/or its subsidiaries or affiliates. All Rights Reserved. (DataDirect Connect64
for ODBC).
OpenEdge includes DataDirect Connect for ODBC and DataDirect Connect64 for ODBC
software, which include ICU software 1.8 and later - Copyright 1995-2003 International
Business Machines Corporation and others All rights reserved. Permission is hereby granted,
free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, provided that the above
copyright notice(s) and this permission notice appear in all copies of the Software and that both
the above copyright notice(s) and this permission notice appear in supporting documentation.
OpenEdge includes DataDirect Connect for ODBC and DataDirect Connect64 for ODBC
software, which include software developed by the OpenSSL Project for use in the OpenSSL
Toolkit (http:/www.openssl.org/). Copyright 1998-2006 The OpenSSL Project. All rights
reserved. And Copyright 1995-1998 Eric Young ([email protected]). All rights reserved.
OpenEdge includes DataDirect products for the Microsoft SQL Server database which contain
a licensed implementation of the Microsoft TDS Protocol.
OpenEdge includes software authored by David M. Gay. Copyright 1991, 2000, 2001 by
Lucent Technologies (dtoa.c); Copyright 1991, 1996 by Lucent Technologies (g_fmt.c); and
Copyright 1991 by Lucent Technologies (rnd_prod.s). Permission to use, copy, modify, and
distribute this software for any purpose without fee is hereby granted, provided that this entire
notice is included in all copies of any software which is or includes a copy or modification of
this software and in all copies of the supporting documentation for such software. THIS
SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY. IN PARTICULAR, NEITHER THE AUTHOR NOR LUCENT MAKES ANY
REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
PURPOSE.
OpenEdge includes software authored by David M. Gay. Copyright 1998-2001 by Lucent
Technologies All Rights Reserved (decstrtod.c; strtodg.c); Copyright 1998, 2000 by Lucent
Technologies All Rights Reserved (decstrtof.c; strtord.c); Copyright 1998 by Lucent
Preface7
Preface
Technologies All Rights Reserved (dmisc.c; gdtoa.h; gethex.c; gmisc.c; sum.c); Copyright
1998, 1999 by Lucent Technologies All Rights Reserved (gdtoa.c; misc.c; smisc.c; ulp.c);
Copyright 1998-2000 by Lucent Technologies All Rights Reserved (gdtoaimp.h); Copyright
2000 by Lucent Technologies All Rights Reserved (hd_init.c). Full copies of these licenses
can be found in the installation directory, in the c:/OpenEdge/licenses folder. Permission to use,
copy, modify, and distribute this software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright notice appear in all copies and that both
that the copyright notice and this permission notice and warranty disclaimer appear in
supporting documentation, and that the name of Lucent or any of its entities not be used in
advertising or publicity pertaining to distribution of the software without specific, written prior
permission. LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS. IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
OF THIS SOFTWARE.
OpenEdge includes http package software developed by the World Wide Web Consortium.
Copyright 1994-2002 World Wide Web Consortium, (Massachusetts Institute of
Technology, European Research Consortium for Informatics and Mathematics, Keio
University). All rights reserved. This work is distributed under the W3C Software License
[http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231] in the hope
that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
OpenEdge includes ICU software 1.8 and later - Copyright 1995-2003 International Business
Machines Corporation and others All rights reserved. Permission is hereby granted, free of
charge, to any person obtaining a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, provided that the above copyright notice(s)
and this permission notice appear in all copies of the Software and that both the above copyright
notice(s) and this permission notice appear in supporting documentation.
OpenEdge includes Imaging Technology copyrighted by Snowbound Software 1993-2003.
www.snowbound.com.
OpenEdge includes Infragistics NetAdvantage for .NET v2009 Vol 2 Copyright 1996-2009
Infragistics, Inc. All rights reserved.
OpenEdge includes JSTL software Copyright 1994-2006 Sun Microsystems, Inc. All Rights
Reserved. Software distributed on an AS IS basis, WITHOUT WARRANTY OF ANY
KIND, either express or implied. See the License for the specific language governing rights and
limitations under the License agreement that accompanies the product.
OpenEdge includes OpenSSL software developed by the OpenSSL Project for use in the
OpenSSL Toolkit (http://www.openssl.org/). Copyright 1998-2007 The OpenSSL
Project. All rights reserved. This product includes cryptographic software written by Eric
Young ([email protected]). This product includes software written by Tim Hudson
([email protected]). Copyright 1995-1998 Eric Young ([email protected]) All rights
reserved. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse
or promote products derived from this software without prior written permission. For written
Preface8
Preface
permission, please contact [email protected]. Products derived from this software may
not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written
permission of the OpenSSL Project. Software distributed on an "AS IS" basis, WITHOUT
WARRANTY OF ANY KIND, either express or implied. See the License for the specific
language governing rights and limitations under the License agreement that accompanies the
product.
OpenEdge includes Quartz Enterprise Job Scheduler software Copyright 2001-2003 James
House. All rights reserved. Software distributed on an AS IS basis, WITHOUT
WARRANTY OF ANY KIND, either express or implied. See the License for the specific
language governing rights and limitations under the License agreement that accompanies the
product. This product uses and includes within its distribution, software developed by the
Apache Software Foundation (http://www.apache.org/).
OpenEdge includes code licensed from RSA Security, Inc. Some portions licensed from IBM
are available at http://oss.software.ibm.com/icu4j/.
OpenEdge includes the RSA Data Security, Inc. MD5 Message-Digest Algorithm. Copyright
1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.
OpenEdge includes Sonic software, which includes software developed by Apache Software
Foundation (http://www.apache.org/). Copyright 1999-2000 The Apache Software
Foundation. All rights reserved. The names Ant, Axis, Xalan, FOP, The Jakarta
Project, Tomcat, Xerces and/or Apache Software Foundation must not be used to
endorse or promote products derived from the Product without prior written permission. Any
product derived from the Product may not be called Apache, nor may Apache appear in
their name, without prior written permission. For written permission, please contact
[email protected].
OpenEdge includes Sonic software, which includes software Copyright 1999 CERN European Organization for Nuclear Research. Permission to use, copy, modify, distribute and
sell this software and its documentation for any purpose is hereby granted without fee, provided
that the above copyright notice appear in all copies and that both that copyright notice and this
permission notice appear in supporting documentation. CERN makes no representations about
the suitability of this software for any purpose. It is provided "as is" without expressed or
implied warranty.
OpenEdge includes Sonic software, which includes software developed by ExoLab Project
(http://www.exolab.org/). Copyright 2000 Intalio Inc. All rights reserved. The names
Castor and/or ExoLab must not be used to endorse or promote products derived from the
Products without prior written permission. For written permission, please contact
[email protected]. Exolab, Castor and Intalio are trademarks of Intalio Inc.
OpenEdge includes Sonic software, which includes software developed by IBM. Copyright
1995-2003 International Business Machines Corporation and others. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or
sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
provided that the above copyright notice(s) and this permission notice appear in all copies of the
Software and that both the above copyright notice(s) and this permission notice appear in
supporting documentation. Software distributed on an "AS IS" basis, WITHOUT
WARRANTY OF ANY KIND, either express or implied. See the License for the specific
language governing rights and limitations under the License agreement that accompanies the
Preface9
Preface
product. Except as contained in this notice, the name of a copyright holder shall not be used in
advertising or otherwise to promote the sale, use or other dealings in this Software without prior
written authorization of the copyright holder.
OpenEdge includes Sonic software, which includes the JMX Technology from Sun
Microsystems, Inc. Use and Distribution is subject to the Sun Community Source License
available at http://sun.com/software/communitysource.
OpenEdge includes Sonic software, which includes software developed by the ModelObjects
Group (http://www.modelobjects.com). Copyright 2000-2001 ModelObjects Group. All
rights reserved. The name ModelObjects must not be used to endorse or promote products
derived from this software without prior written permission. Products derived from this
software may not be called ModelObjects, nor may ModelObjects appear in their name,
without prior written permission. For written permission, please contact
[email protected].
OpenEdge includes Sonic software, which includes code licensed from Mort Bay Consulting
Pty. Ltd. The Jetty Package is Copyright 1998 Mort Bay Consulting Pty. Ltd. (Australia) and
others.
OpenEdge includes Sonic software, which includes files that are subject to the Netscape Public
License Version 1.1 (the License); you may not use this file except in compliance with the
License. You may obtain a copy of the License at http://www.mozilla.org/NPL/. Software
distributed under the License is distributed on an AS IS basis, WITHOUT WARRANTY OF
ANY KIND, either express or implied. See the License for the specific language governing
rights and limitations under the License. The Original Code is Mozilla Communicator client
code, released March 31, 1998. The Initial Developer of the Original Code is Netscape
Communications Corporation. Portions created by Netscape are Copyright 1998-1999
Netscape Communications Corporation. All Rights Reserved.
OpenEdge includes Sonic software, which includes software developed by the University
Corporation for Advanced Internet Development http://www.ucaid.edu Internet2 Project.
Copyright 2002 University Corporation for Advanced Internet Development, Inc. All rights
reserved. Neither the name of OpenSAML nor the names of its contributors, nor Internet2, nor
the University Corporation for Advanced Internet Development, Inc., nor UCAID may be used
to endorse or promote products derived from this software and products derived from this
software may not be called OpenSAML, Internet2, UCAID, or the University Corporation for
Advanced Internet Development, nor may OpenSAML appear in their name without prior
written permission of the University Corporation for Advanced Internet Development. For
written permission, please contact [email protected].
OpenEdge includes the UnixWare platform of Perl Runtime authored by Kiem-Phong Vo and
David Korn. Copyright 1991, 1996 by AT&T Labs. Permission to use, copy, modify, and
distribute this software for any purpose without fee is hereby granted, provided that this entire
notice is included in all copies of any software which is or includes a copy or modification of
this software and in all copies of the supporting documentation for such software. THIS
SOFTWARE IS BEING PROVIDED AS IS, WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T LABS MAKE
ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
PURPOSE.
OpenEdge includes Vermont Views Terminal Handling Package software developed by
Vermont Creative Software. Copyright 1988-1991 by Vermont Creative Software.
Preface10
Preface
OpenEdge includes XML Tools, which includes versions 8.9 of the Saxon XSLT and XQuery
Processor from Saxonica Limited (http://www.saxonica.com/) which are available from
SourceForge (http://sourceforge.net/projects/saxon/). The Original Code of Saxon
comprises all those components which are not explicitly attributed to other parties. The Initial
Developer of the Original Code is Michael Kay. Until February 2001 Michael Kay was an
employee of International Computers Limited (now part of Fujitsu Limited), and original code
developed during that time was released under this license by permission from International
Computers Limited. From February 2001 until February 2004 Michael Kay was an employee
of Software AG, and code developed during that time was released under this license by
permission from Software AG, acting as a "Contributor". Subsequent code has been developed
by Saxonica Limited, of which Michael Kay is a Director, again acting as a "Contributor". A
small number of modules, or enhancements to modules, have been developed by other
individuals (either written especially for Saxon, or incorporated into Saxon having initially been
released as part of another open source product). Such contributions are acknowledged
individually in comments attached to the relevant code modules. All Rights Reserved. The
contents of the Saxon files are subject to the Mozilla Public License Version 1.0 (the "License");
you may not use these files except in compliance with the License. You may obtain a copy of
the License at http://www.mozilla.org/MPL/ and a copy of the license can also be found in the
installation directory, in the c:/OpenEdge/licenses folder. Software distributed under the
License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either
express or implied. See the License for the specific language governing rights and limitations
under the License.
OpenEdge includes XML Tools, which includes Xs3P v1.1.3. The contents of this file are
subject to the DSTC Public License (DPL) Version 1.1 (the "License"); you may not use this
file except in compliance with the License. A copy of the license can be found in the installation
directory, in the c:/OpenEdge/licenses folder. Software distributed under the License is
distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
implied. See the License for the specific language governing rights and limitations under the
License. The Original Code is xs3p. The Initial Developer of the Original Code is DSTC.
Portions created by DSTC are Copyright 2001, 2002 DSTC Pty Ltd. All rights reserved.
OpenEdge includes YAJL software Copyright 2007, Lloyd Hilaiel. Redistribution and use in
source and binary forms, with or without modification, are permitted provided that the
following conditions are met: 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the distribution. 3. Neither the name
of Lloyd Hilaiel nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission. THIS SOFTWARE IS
PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Preface11
Preface
Preface12
1
Introducing WebSpeed
WebSpeed is an ABL (Advanced Business Language) development and deployment
environment. It allows you to build applications that use HTML, XML, WML, DHTML, and
most other mark-up languages (MLs) as the user interface. This means that WebSpeed can be
used for applications where users are accessing the application using:
A system making requests for information using XML and HTTP or HTTP/S as the
transport protocol.
Intranet applications that allow internal users to access and modify data.
Internet applications that allow external, consumer access (for example, a shopping cart
application).
WebSpeed architecture
Introducing WebSpeed
WebSpeed architecture
The WebSpeed environment is similar to the OpenEdge AppServer environment. A
transaction server, which consists of brokers and agents, execute requests from a client. The
unique piece of the WebSpeed environment, the WebSpeed Messenger, is a process that runs
on your Web server capturing and redirecting client requests. Figure 11 illustrates the
complete architecture for a WebSpeed deployment environment.
WebSpeed Server
Host
*ML Client
AdminServer
Internet or
Intranet
NameServer
ubroker .properties
WebSpeed
Broker
Web Server
WebSpeed
Messenger
Figure 11:
WebSpeed
Agents
OpenEdge
Database or
DataServer
The dashed arrows in Figure 11 indicate connections that do not occur in all WebSpeed
configurations. The WebSpeed agents might not have direct access to a database or a dataserver.
Depending on how you architect your application, the procedure that the agent runs in response
to a Web request might call another procedure over an AppServer to process database requests.
The Progress NameServer might not be used in all configurations, as described in the
NameServer section on page 14.
WebSpeed components
The components of the WebSpeed environment are the WebSpeed Workshop, the WebSpeed
Messengers, and the WebSpeed Transaction Server. The WebSpeed environment can also
include a NameServer, which can support both AppServer and WebSpeed transactions.
A default WebSpeed installation provides one predefined WebSpeed broker and one predefined
NameServer. You can use these predefined components as templates from which you create and
configure additional instances of the WebSpeed broker and, if needed, the NameServer.
12
WebSpeed architecture
WebSpeed Workshop
The WebSpeed WorkShop contains the tools that you use to develop and test WebSpeed
applications. The default WebSpeed Workshop installation also includes a version of the
WebSpeed Transaction Server scaled to support a single developers activities. The Workshop
includes the following:
WebTools You use the browser-based WebTools to access information on your server,
such as the status of CGI Variables. You can also access database information, use the
WebSpeed File tools, and access virtual system table data. You can use the Scripting Lab
to write and test WebSpeed code, such as HTML that includes Embedded SpeedScript,
and send operating system commands. With the Editor WebTool, you can create, open,
save, and print files; check syntax; and compile code.
PRO*Tools PRO*Tools is a set of utility programs that are useful for developing and
running OpenEdge applications. For example, one of the PRO*Tools allows you to edit
your PROPATH. The Color Changer, Screen Scaling Utility, and ProtoGen PRO*Tools
do not apply to WebSpeed.
WebSpeed agent An application process that can execute Web objects, perform
database transactions, and dynamically merge data into HTML format. The agent is the
standard character ABL client running in batch mode. An AppServer agent is a single
AVM instance running on the AppServer.
Note: The agent process is inherently stateless. This means that the agent is only busy
when a request is being processed. It will be idle at all other times.
13
Introducing WebSpeed
Maintain the status of each agent in its pool and dynamically scale the number of
agents according to changing demand.
Note: If you start a WebSpeed broker without specifying a username, the Broker inherits
the account that the AdminServer is using. This is generally the system account,
which might not have access to network drives.
WebSpeed Messenger
The WebSpeed Messenger listens for WebSpeed requests coming in to the Web server. The
Messenger asks the NameServer where to send each request. Alternately, the Messenger can
bypass the NameServer as described in the NameServer section on page 14. The Messenger
then handles the transfer of data between the Web server and the WebSpeed Agent. There are
Messengers for use on different Web servers: a CGI Messenger, an ISAPI Messenger, and an
NSAPI Messenger.
There is also a Messenger that works with Microsofts Active Server Pages, the WSASP
Messenger. Using the WSASP Messenger, you can call out of an Active Server Page to a
WebSpeed application.
The WebSpeed Messenger always resides on the same machine with your Web server. Because
the Messenger is not itself an OpenEdge application, it is sometimes the only part of the
WebSpeed environment installed on a Web server machine. This is sometimes incorrectly
described as a Messenger-only deployment. Your WebSpeed applications cannot run without
a WebSpeed Transaction Server. Messenger-only installation is a more appropriate term for
this setup.
NameServer
The NameServer is a basic part of the OpenEdge architecture. It maintains a list of available
AppServers and WebSpeed Transaction Servers. Those servers register the application services
that they provide with the NameServer. The NameServer can then direct client connection
requests to a broker that supports a requested application service. This provides scalability and
location transparency to your applications.
The NameServer can also provide load balancing and fault tolerance for OpenEdge server
applications. Load balancing allows you to balance client workload among multiple brokers that
support the same application service (that is, the same set of procedures and resources). This
ability makes the NameServer very useful in deployed applications that handle large volumes
of requests.
The NameServer works through the UDP network protocol. For various reasons, some network
administrators might not want UDP on their networks. To accommodate this preference, the
OpenEdge architecture includes a No NameServer connection procedure. If you employ the
No NameServer connection procedure in a WebSpeed application, you must configure the
WebSpeed Messenger to point directly to a specific WebSpeed broker. This approach can limit
the scalability of your application. For more information, see Chapter 2, Configuring
WebSpeed.
Language support
The WebSpeed development environment also includes a programming language, SpeedScript,
and a number of pre-coded conveniences, such as global variables, preprocessors, and APIs, to
simplify your development. For more information on these elements, see Chapter 3, Tools and
ABL Support.
14
Start an AdminServer.
Start a database in multi-user mode with properties supplied by the AdminServer from the
file.
conmgr.properties
3.
ubroker.properties
4.
Start a WebSpeed broker with properties supplied by the AdminServer from the
file.
ubroker.properties
5.
The broker spawns its WebSpeed agents using the information it received from the
AdminServer.
6.
The broker registers itself and the application services that it provides with the
NameServer.
By default, the broker sends a message every 30 seconds to notify the NameServer that it
is still available to accept requests. If the NameServer does not get a message, it deletes
the broker from its available list. These messages are not part of the request process.
7.
Start a Web server, which makes its WebSpeed Messenger available to transfer Web
requests.
15
Introducing WebSpeed
AdminServer
W eb Server
W ebSpeed
Messenger
HTML
C lient
2
NameServer
3
4
5
W ebSpeed
Broker
6
7
Figure 12:
W ebSpeed
Agent
The numbered steps of a Web request in Figure 12 are explained in the following sequence:
1.
The HTML client, running in a Web browser, generates a connection request. The request
is in the form of a URL and is sent to a Web server, which forwards it to a WebSpeed
Messenger.
2.
The Messenger sends a request to the NameServer for an available WebSpeed broker that
supports the required application service.
Note: In a No NameServer configuration, the Messenger is hard-wired with connection
information for a single WebSpeed broker. The Messenger passes all Web requests
directly to that broker.
16
3.
The NameServer selects a broker, which supports the requested application service, from
the pool of brokers that have registered with it. The NameServer sends the brokers host
name or IP address and the brokers port number to the Messenger.
4.
Using these details, the Messenger connects to the broker and requests a WebSpeed agent
to process the request. This request is put in a queue by the broker, so requests are not lost
in peak load times.
If there are requests in the queue, the broker checks for an available agent in its pool. The
broker allocates the next available agent to the request and marks that agent as busy. The
broker then returns that agents port number to the Messenger.
Note: If there are no free agents and the brokers maximum number of agents has not
been reached, the broker starts a new agent to process the request.
6.
The Messenger connects to the agent through that port and passes the Web request to the
agent.
7.
The agent executes the Web request and creates an HTML page that it returns to the
Messenger.
8.
9.
The Messenger passes the HTML page to the Web server, which passes it back to the
HTML client.
Step 2 through Step 5 create only small amounts of network traffic, usually less than 500 bytes.
The large amounts of data are in the final request and response, Step 6 and Step 7. The data sent
from the Messenger to the WebSpeed agent includes all of the environment variables, as well
as the input parameters from the URL or HTML form. The environment variables alone can be
up to 3000 bytes. When the response comes back from a WebSpeed agent, it could be a simple
HTML page of around 1000 bytes, but it also could be a large.ZIP file or similar. With special
programming, WebSpeed can send binary files to the Web browser.
All of these components (the Web server, the WebSpeed Messenger, the WebSpeed broker, the
WebSpeed agents, and the NameServer) can reside on a single physical machine. However, you
can also distribute them on separate machines, with the following restrictions:
The Web server and the WebSpeed Messenger must reside on the same physical machine.
The WebSpeed Transaction Server (the WebSpeed broker and the WebSpeed agents)
requires an AdminServer on its machine. The broker and the agents that it supports must
reside on the same physical machine. You can have multiple WebSpeed Transaction
Servers spread over several machines, but registered with a single NameServer.
See Chapter 2, Configuring WebSpeed, for examples of how to distribute the components
across a network. You can also distribute the databases over a network. For more information
about distributing OpenEdge databases across a network, see OpenEdge Data Management:
Database Administration. For information on accessing a non-OpenEdge data source, see the
appropriate OpenEdge DataServer guide. When you read these manuals, which describe a
typical client/server environment, substitute the term Agent for Client.
17
Introducing WebSpeed
Cascading Style Sheets (CSS) Provides a simple mechanism for adding style
characteristics to Web documents. For more information, refer to
http://www.w3.org/Style/CSS.
Extensible Markup Language (XML) XML is a simple and flexible text format
derived from SGML. It was originally designed to meet the challenges of large scale
electronic publishing, but it is also playing an important role in the exchange of a wide
variety of data on the Web. For more information, refer to http://www.w3.org/XML.
Wireless Markup Language (WML) WML inherits traits based on HTML and XML
and is used to run simple code on the client. For more information, refer to
http://www.w3.org.
Web-based applications developed using WebSpeed are run in a Web browser. A Web browser
provides the host environment of client-side computation, including objects representing
windows, menus, pop-ups, dialog boxes, text areas, anchors, frames, history, cookies, and
input/output functionality. In addition, the Web browser provides a means to attach scripting
code to events such as a change of focus, page and image loading, unloading, error and abort,
selection, form submission, and mouse actions. WebSpeed coding appears within the HTML,
and the displayed page is a combination of user interface elements and fixed and computed text
and images.
For information on supported browsers, see the Supported Web browsers and preference
settings section on page 26.
18
19
Introducing WebSpeed
Enterprise
Services
Users
Presentation Layer
Integration Layer
Figure 13:
Unmanaged Data
Stores
The procedures in the Data Access layer manage handling data from your data stores. These
procedures retrieve information from wherever it resides in the physical data stores and arrange
the data into logical datasets that meet the business needs for the procedures in the Business
Servicing layer. Other procedures in the Data Access layer extract the data changes from the
logical datasets and commit the changes to the proper places in the physical data stores.
The procedures in the Business Servicing layer act on requests received from users through the
Presentation layer or from enterprise services through the Integration layer. These procedures
handle the business tasks required to fulfill an order, for example. The procedures in the
Business Servicing also push data changes in the data sets back to the Data Access layer.
110
111
Introducing WebSpeed
The essential difference between WebSpeed and ABL applications is how they gather
information from and present results to the user. A WebSpeed application uses an HTML client
(or a client based on some other markup language). This point positions WebSpeed applications
as elements of the OE Reference Architectures Presentation layer, as shown in Figure 14.
Enterprise
Services
Users
Presentation Layer
Integration Layer
Figure 14:
Unmanaged Data
Stores
Validating that the fields in a form are filled in with appropriate values.
User interface control tasks, such as populating a secondary combo box based on the
selection in the primary combo box.
The following tasks are generally not appropriate for the Presentation layer:
112
2
Configuring WebSpeed
This chapter provides configuration information for the WebSpeed environment, including
aspects of your Web server, as described in the following sections:
WebSpeed administration
Configuring WebSpeed
Install the necessary WebSpeed components. You can distribute WebSpeed components
over a number of machines, but the WebSpeed Messenger must be installed in the scripts
directory of your Web server.
Configure the machines where WebSpeed components are installed. This includes setting
the appropriate environment variables and setting up your Web server.
For more information on installing WebSpeed, see OpenEdge Getting Started: Installation and
Configuration.
22
Directory
Contents
path
path\dhtml
path\img
Images
Note:
that points to
(where document_root_dir
Caution: These files are only used for the WebSpeed Workshop. For security reasons, they
should not be available in nondevelopment environments.
23
Configuring WebSpeed
Note:
24
The Apache Web Server must be restarted after you make configuration changes.
2.
3.
Use ping functionality to determine if connectivity exists between the Web server and
WebSpeed components. To accomplish this, conduct a round-trip test from the browser to
a WebSpeed agent using the CGI Messenger (cgiip.exe). This test instructs the
Messenger to make a connection to the broker and an available agent.
An example of ping for a Web server in Windows follows:
http://localhost/scipts/cgiip.exe/ping.
http://localhost/scipts/cgi-bin/wspd_cgi.sh/ping.
Note: The host name (identified as localhost in the example) differs depending upon the
environment in which WebSpeed operates; your installation choice (for example,
on a local machine) dictates the path.
CGI 1.1 For example, Microsoft Internet Information Server (IIS), Apache, Netscape
Enterprise, or Fast Track Server
25
Configuring WebSpeed
26
Setting
Disk Cache
5000K
Memory Cache
1000K
Number of Connections
Font
Enabled.
WebSpeed administration
WebSpeed administration
WebSpeed administration consists of the following:
The ubroker.properties file, which dictates property values for the WebSpeed
Transaction Server, WebSpeed Messengers, and the NameServer
The OpenEdge Explorer and Progress Explorer tools, which allow local and remote
administration and configuration of WebSpeed and other OpenEdge components
The management utilities, which allow administration from the command line of
WebSpeed and other OpenEdge components
This framework provides a consistent structure for all the OpenEdge server products installed
on your network.
AdminService
The AdminService supports the managing of WebSpeed and other OpenEdge products (for
example, NameServer, database, DataServer).
The AdminService runs as a service on UNIX and Windows platforms. In Windows, it starts
automatically by default. To start the AdminService on UNIX or Linux, use the proadsv utility.
To start the AdminService if you have altered the default behavior:
1.
From the Windows taskbar, choose Start Control Panel Administrative Tools
Services.
2.
Alternately, you can run a command from a command prompt or a batch file similar to the
following:
Where version is the version number of OpenEdge. You can find the version number for your
installation by going to the OpenEdge folder in your Windows Start menu and choosing
Version Info.
ubroker.properties file
The ubroker.properties file is the property file for the WebSpeed Transaction Server,
WebSpeed Messengers, and the NameServer. All values that define instances of the WebSpeed
Transaction Server and the NameServer are stored within this file. The command-line utilities,
the OpenEdge Explorer, and the Progress Explorer access this information through the
AdminServer when working with instances of all processes.
27
Configuring WebSpeed
The ubroker.properties file resides in the install-path/properties directory. It is a fully
commented file containing information relevant to setting properties for your WebSpeed
configuration.
Note:
The AppServer and the DataServers also use the ubroker.properties file to store
configuration data. For the purposes of this guide, the ubroker.properties file focus
is on the WebSpeed Transaction Server and the NameServer. See the appropriate
manual for details about viewing and editing configurations applicable to the other
products.
From a Windows machine, you use the OpenEdge Explorer or Progress Explorer tool to create
and configure instances of the WebSpeed Transaction Server or the NameServer on the
Windows platform or remote UNIX platforms. It is possible to edit the ubroker.properties
file manually. See the Editing the ubroker.properties file section on page 28 for more
information. Advanced users can also use the mergeprop utility to apply changes to the
ubroker.properties file. For more information on the mergeprop utility, see the chapter on
managing OpenEdge property files in OpenEdge Getting Started: Installation and
Configuration.
The ubroker.properties file consists of a hierarchical structure of configuration entities,
where parent entities provide configuration information that you can override or extend in each
child entity. Each configuration entity has a name that begins the entity definition, and the
definition contains configuration settings for one or more product instances. When configuring
your WebSpeed environment, you work most often with the [UBroker], [UBroker.WS],
[NameServer], [WebSpeed], and [WebSpeed.Messengers] configuration entities.
Editing the ubroker.properties file
You can edit ubroker.properties directly using any text editor to create new WebSpeed
Transaction Server and NameServer configurations or edit existing configurations. The
simplest way to make new configurations in the ubroker.properties file is to copy an existing
Transaction Server or NameServer definition and then modify the values of the copys
properties to suit your needs. When you do this, you must be sure to supply each definition with
its own uuid setting, as described in the list of required unique parameters later in this section.
From a Windows machine, you can also use the OpenEdge Explorer or Progress Explorer tool
remotely to create and configure instances of the WebSpeed Transaction Server or the
NameServer on the UNIX platform.
If you instead edit the configuration using a text editor, note that:
28
You should not directly change the values in the ubroker.properties file unless you
have a complete understanding of how the changes affect WebSpeed components. If you
have the OpenEdge Explorer or Progress Explorer tool available from a remote Windows
machine, use it to make all changes to this file on your UNIX machines.
For complete definitions of all the properties and detailed information on how to set them,
see the install-dir\properties\ubroker.properties.README file.
WebSpeed administration
If you create additional instances of the WebSpeed Transaction Server and the
NameServer, you must be sure that each of the following parameters has a value unique to
the entire ubroker.properties file:
defaultService You can only set one default service on each NameServer. If you
configure two WebSpeed Transaction Servers to use the same NameServer and
specify that the Transaction Servers perform the same application service, the
Transaction Servers must also support the same business function.
WService=<appservice-name>
uuid A universally unique identifier for a Transaction Server. If you use the
OpenEdge Explorer or Progress Explorer tool to create the new Transaction Server,
this property is automatically set. If you manually add Transaction Server
definitions, generate a unique uuid for each Transaction Server definition by using
the following command:
install-path\bin\genuuid
If you create additional instances of the WebSpeed Transaction Server and the
NameServer by copying an existing instance, be sure that each of the following parameters
has the correct values for the new instance:
srvrStartupParam Identify the startup parameters for your agents. Copy the
value from the ubroker.properties files [UBroker.WS] section to your new
Transaction Server definition, and modify.
userName and groupName You can optionally specify a username and a group
name that the Transaction Server runs under; if you do not specify these names, the
Transaction Server runs under the username and group name of the user who starts
the AdminServer.
Note:
If you install the NameServer on a separate host from the WebSpeed Transaction
Server, the NameServer installation includes its own copy of the properties file. You
also must configure WebSpeed to use a remote NameServer.
29
Configuring WebSpeed
You must ensure that all related properties and sections of the file are properly specified for each
Transaction Server or NameServer instance. If you do edit the file directly, use the appropriate
configuration utility (NSCONFIG or WSCONFIG) to validate the product configuration that you
have edited. For more information on utilities, see the WebSpeed command-line utilities
section on page 210or the section on the NSCONFIG utility in OpenEdge Application Server:
Administration.
You can check the WebSpeed configuration status from the tools. See the online help
for more information.
WTBMAN Use the WTBMAN utility to control the operation of a WebSpeed Transaction
Server. The utility allows you to start a Transaction Server, query its status, start and stop
additional WebSpeed agents, trim by a certain number of agents, and shut down the
Transaction Server.
Note:
Because the WSCONFIG utility does not run across the network and no AdminService is
installed during a Messenger-only installation, you cannot use the WSCONFIG utility to
check a Messenger-only installation.
For more information, see Appendix A, WebSpeed Configuration and Management Utilities.
210
WebSpeed administration
NameServer
The NameServer serves as a hub through which a WebSpeed Messenger can locate a WebSpeed
Transaction Server that provides the application services needed to fulfill a Web request. The
NameServer provides location transparency that can ease deployment of your applications. The
Enterprise version of the NameServer can also supply load balancing. Load balancing can
improve performance and provide fault tolerance.
Understanding the NameServers load balancing option
Load balancing is a feature that allows client connection requests to be distributed, based on
load, among multiple Unified broker instances that support the same Application Service. If you
have installed the load-balancing option, the NameServer assigns client connections to the
appropriate Unified broker instances based on weight factors that you specify.
If the weight factor that you specify for each Unified broker instance is appropriate in relation
to the others, the effect is to assign more connections to broker instances with greater resources,
and thus to balance connection load among all the instances. You can set the load-balancing
weight factor for each Unified broker instance in the OpenEdge Explorer, the Progress Explorer,
or by editing the priorityWeight property in the ubroker.properties file.
Percentage weight factors
Properly specified, these weight factors give some sense of the amount of work that an
individual WebSpeed Transaction Server instance can handle. For example, Table 23 shows
the effect of weight factors specified for three WebSpeed Transaction Server instances
registered for the same application service.
Table 23:
WebSpeed Transaction
Server name
Weight factor
% of time selected
WS1
20
20
WS2
20
20
WS3
60
60
The selection algorithm used by the NameServer guarantees that WS1 and WS2 are each
selected 20% of the time and WS3 is selected 60% of the time. Thus, if the sum of weight factors
for all WebSpeed Transaction Server instances that support the same application adds up to 100,
each weight factor specifies the exact percentage of time that the NameServer selects the given
WebSpeed Transaction Server instance over time.
211
Configuring WebSpeed
Arbitrary weight factors
You can specify any sum of values (not necessarily 100), but the weight of each is always
proportional to the sum, as shown in Table 24.
Table 24:
WebSpeed Transaction
Server name
Weight factor
% of time selected
WS1
2/7 = 28.57
WS2
2/7 = 28.57
WS3
3/7 = 42.86
The NameServer uses the User Datagram Protocol (UDP). Some sites have restrictions
that prohibit the use of UDP.
If you choose not to use the NameServer, configure your Transaction Server to indicate that it
should not register with a NameServer. The online help for the OpenEdge Explorer or the
Progress Explorer has details on doing so with each tool. Then, configure your Messenger to
connect directly to the Transaction Server. For more information, see the Configuring a
WebSpeed Transaction Server section on page 218 and the Configuring a WebSpeed
Messenger section on page 221.
212
WebSpeed administration
You can also eliminate the NameServer by directly editing the ubroker.properties file,
although using the tools is less error-prone. For more information on the ubroker.properties
file, see the ubroker.properties file section on page 27.
To eliminate the NameServer by editing the ubroker.properties file:
1.
2.
Find the broker definition for your Transaction Server. For example:
[UBroker.WS.wsbroker1]
registerNameServer=0
Find the definition for your Messenger. For example, if you use CGIIP:
[WebSpeed.Messengers.CGIIP]
5.
registerNameServer=0
Add and set the port number for your broker. For example, if you are using the default
wsbroker1:
Port=3055
7.
Note:
When you eliminate the NameServer, the Messenger can only access one WebSpeed
Transaction Server (broker). One of the advantages of using the NameServer is that
you can run multiple brokers.
213
Configuring WebSpeed
You can also create other subdirectories in the working directory, or you can create
procedure libraries and other directories in your PROPATH for when you are ready for
deploying a production application.
The brokers working directory is added automatically to the PROPATH of the broker and agents;
the broker and agents use the PROPATH to locate your application files. The brokers working
directory is not explicitly named in the PROPATH, but is referenced using a dot (.). The dot is
interpreted as the current working directory by each process that searches the PROPATH. If you
choose to place your application files in a different directory, you must add that directory to the
PROPATH or reference the file with a subdirectory in its pathname. This is an extra step that you
can avoid by placing all of your files in the same working directory. For more information about
setting the PROPATH, see the PROPATH and other standard OpenEdge environment variables
section on page 216 and OpenEdge Application Server: Developing WebSpeed Applications.
214
JavaScript files
You should place JavaScript (.js) files in a subdirectory of the Web server root directory. Then
you can reference the relative path in the SRC attribute of the <SCRIPT> tag.
For example, if the JavaScript file, myscript.js, is in a subdirectory of the Web server root
directory called javascript, the <SCRIPT> tag might look like the following:
tagmap.dat
If you modify the default tagmap.dat, place a copy of the modified tagmap.dat into your
working directory. If you do not modify the file, you do not have to copy the file because the
default tagmap.dat is used.
Offset files
An offset file (.off) is created whenever you use the AppBuilder to map an HTML file to a Web
object. Agents use the offset file information to dynamically generate an HTML page. The
purpose of the offset file is to provide the location of the HTML form fields in the HTML file.
You ensure that the agents can find your offset files by placing them in your working directory
or in the directory with your running Web objects (or r-code). If an offset file is not current for
its HTML-mapping Web object, the agent generates a new offset file from your mapped HTML
file and the available tagmap.dat file.
Note:
Some of the files described above are ASCII files and some are binary. Some transfer
methods automatically handle the differences. Other methods require that you specify
a type. When in doubt, specify binary.
215
Configuring WebSpeed
You can change most of these settings using the OpenEdge Explorer, the Progress Explorer, or
by editing the WebSpeed property file, ubroker.properties. Note that it is not necessary to
modify the Windows registry or the system environment variables (through the Windows
Control Panel).
PROPATH and other standard OpenEdge environment variables
When you install the WebSpeed Transaction Server, the installation process sets the PROPATH
for you in the ubroker.properties file. The PROPATH initially includes a number of
subdirectories in your installation directory. In addition, the PROPATH includes a dot ( . )
directory reference. When the agent sees the dot, the process substitutes the name of its current
working directory. For example, the agents resolve the dot to their brokers default directory,
which is the working directory.
You can override installed PROPATH settings using the PROPATH property in the properties file
(ubroker.properties).
Working directory settings
The properties file relies on a default setting for the working directory that you specify during
installation. You can remove or modify the references in the properties file to establish your
own working directory settings for both the WebSpeed Transaction Server and the NameServer.
For more information on OpenEdge environment settings, see OpenEdge Getting Started:
Installation and Configuration.
216
brokerLogFile
After you decide where you want the log files to reside, you can specify the location for each in
the OpenEdge Explorer, the Progress Explorer, or by directly editing the ubroker.properties
file. For more information, see the WebSpeed administration section on page 27.
Because the log files receive the WebSpeed and NameServer startup and shutdown messages,
OpenEdge system messages, and trace messages, the files can grow quickly. If you have the
Append option set in the Transaction Servers configuration, these log files do not truncate
automatically. In this case, you should periodically trim the files with a text editor. You might
want to archive the contents of the files as you do it. For more information on maintaining log
files, see the Maintaining the WebSpeed Transaction Server and NameServer log files section
on page 217.
If you have the Append option set in the Transaction Servers configuration, these log
files do not truncate automatically. In this case, you should periodically trim the file
with a text editor. You might want to archive the file contents as you do it.
For more information on how to configure the log files for your environment, see the
Configuring WebSpeed and NameServer log files section on page 217.
217
Configuring WebSpeed
Make sure the AdminService is running. If the AdminService is not running, you must
start it. (For information on starting it, see the AdminService section on page 27.)
2.
Start an existing NameServer or create a new NameServer instance. You can create and
start a NameServer by using either the OpenEdge Explorer or the Progress Explorer; or
you can edit the ubroker.properties file to create an instance and then use the NSMAN
utility to start the instance. When you configure a NameServer instance, you can set it to
start up by default whenever the AdminService starts.
Note: The NameServer can be on any machine in your network, even a UNIX machine.
You can configure a WebSpeed environment without a NameServer. For more
information, see the No NameServer configurations section on page 212.
If you are using the tools, see the online help for information about creating and starting
an instance. If you are editing the ubroker.properties file, see the Editing the
ubroker.properties file section on page 28.
To start a local instance of the NameServer from the command line, use the following
command:
nsman -name NS1 -host host-name -port port -user user-name -start
Where host-name is the name of the host machine on which you want the instance to run,
port is the port number on the AdminService, and user-name is the user ID of the system
218
Note: The WebSpeed Transaction Server consists of a broker and agents. The default
WebSpeed broker is wsbroker1. When you start the broker, the agents are also
started.
To start a remote instance of the WebSpeed Transaction Server from the command line,
use the following command:
wtbman -name broker -host host -port port -user user -start
Where broker is the name of the WebSpeed broker, host is the name of the host machine
on which you want the instance to run, port is the port number on the AdminService, and
user is the user ID of the system account under which the Transaction Server will run. If
you specify a host name, the tool prompts you for a user name (if you do not supply it) and
password.
By using either the tools or the command-line utilities, you can also stop a NameServer or
WebSpeed Transaction Server instance, check its status, and increase or reduce the number of
running WebSpeed agents. For more information, see the OpenEdge Explorer and the Progress
Explorer online help and the Managing the WebSpeed Transaction Server section on
page 219.
219
Configuring WebSpeed
Dynamically starting additional agents
To start additional agents, enter the following command:
Where broker is the name of the WebSpeed broker specified in the ubroker.properties file
and number-to-start is the number of additional agents you want to start. The number you
specify must not exceed the maxSrvInstance value in the ubroker.properties file or your
license limit.
Trimming running agents
To trim agents, enter the following command:
Where broker is the name of the Transaction Server and number-to-trim is the number of
agents you want to stop.
Stopping the WebSpeed broker
To stop the broker and all the agents in its pool, enter the following command:
To force an immediate shutdown of the Transaction Server and all its agents, enter the following
command:
wtbman -help
220
There is also a Messenger that works with Microsofts Active Server Pages, the
WSASP Messenger. Using the WSASP Messenger, you can call out of an Active
Server Page to a WebSpeed application.
221
Configuring WebSpeed
Messenger
Messenger executable
Microsoft IIS
ISAPI
wsisa.dll
Microsoft IIS
WSASP1
wsasp.dll
Netscape
NSAPI
wsnsa.dll
CGI-compatible
CGI
cgiip.exe
1. The WSASP Messenger calls WebSpeed applications from an Active Server Page. It cannot coexist with the ISAPI
Messenger.
The NSAPI executables reside and run from the install-path\bin directory. The CGI
Messenger and ISAPI executables reside and run from the \scripts directory on the Web
server.
Note:
To configure a Netscape Web server to work with the WebSpeed NSAPI Messenger,
you must edit the Netscape Web server configuration file (obj.conf). For more
information, refer to the Editing the Netscape Web server configuration file section
on page 223.
You can use the sample file cgiip.wsc to set up a file association for running the CGIIP
Messenger under Microsofts IIS Server. For details, see the cgiip.wsc file, which is located in
the install-path\bin directory.
Note:
You must restart an ISAPI or Netscape NSAPI Web server after installing and
configuring the Messenger.
222
Description
Init fn=load-modules
shlib="pathname"
funcs=WSNSAinit,WSNSAdefault,
WSNSAshutdown,WSNSAwebspeedCheck
Init fn=WSNSAinit
NameTrans fn=WSNSAwebspeedCheck
Service method=(GET|POST|HEAD)
fn=WSNSAdefault
223
Configuring WebSpeed
Each line you add to obj.conf must be on a single line. Do not add line breaks within a
command line. Use forward slashes (/) in pathnames. Here is an excerpt from a sample
obj.conf file (the additions that you must make for the WebSpeed Messenger are bold):
Init ...
Init ...
NameTrans fn=WSNSAwebspeedCheck
NameTrans ...
NameTrans ...
PathCheck ...
PathCheck ...
ObjectType ...
ObjectType ...
224
http://host-name[:port]/wsnsa.dll[/WService=appservicename]?WSMAdmin
Where host-name is the name of the host on which the Messenger is running, port is the port
that your Web server uses (if different from the default port 80), and appservice-name is the
name of the application service.
For example, the following URL requests the Administration page for the NSAPI Messenger on
a host named mars:
http://mars/wsnsa.dll/WService=wsbroker1?WSMAdmin
If you are running an ISAPI Web server, use the following URL:
http://host-name[:port]/scripts/wsisa.dll/[/WService=appservice-name]
?WSMAdmin
If you are running a CGI Web server, use the following URL:
http://host-name/scripts/cgiip.exe[/WService=appservice-name]?WSMAdmin
http://host-name/cgi-bin/wspd_cgi.sh?WSMAdmin
Where host-name is the name of your Web server machine, port is the port that your Web
server uses (if different from the default port 80), scripts is your Web servers scripts
directory, and appservice-name is the name of the application service.
225
Configuring WebSpeed
226
3
Tools and ABL Support
This chapter introduces you to the tools and utilities used in WebSpeed application
development. There are Windows-based and browser-based tools. You access the
Windows-based tools through the AppBuilder. Browser-based tools, also known as WebTools,
can be launched by starting a browser from the AppBuilder, or you can run them by supplying
a URL directly in a Web browser.
This chapter includes the following sections:
AppBuilder
WebTools
Language support
AppBuilder
The AppBuilder is a multi-purpose application development environment. You can use it as a
visual programming environment to create character- or GUI-based client/server applications.
In addition, you can use the AppBuilder to createWebSpeed applications.
The AppBuilder is installed as part of the OpenEdge Studio and WebSpeed Workshop
products.
This manual focuses on using the AppBuilder in the context of WebSpeed applications. For
more information about using the AppBuilder for other types of applications, see OpenEdge
Development: AppBuilder.
You cannot manipulate nonvisual objects graphically at design time, and they do not
have a visualization element at run time.
WebSpeed wizards
You can use the WebSpeed wizards to create Web objects without writing any HTML or
SpeedScript code. The WebSpeed wizards prompt you for the necessary information and
automatically generate the required code.
Note:
WebSpeed wizards do not conform to modern coding practices and might not be
appropriate to your development objectives. They are useful for quickly generating
small, stand-alone applications.
32
Report Creates a tabular view of the database fields you specify. You can add
navigation buttons for displaying the first, previous, next, and last set of records. You can
also include a text entry field to allow the user to enter search criteria.
Detail Creates a form to display database data, based on the selection criteria you
specify. You can add transaction control buttons to allow users to add or delete records and
to submit or reset changes.
HTML mapping Maps form fields in an existing HTML file to database fields.
AppBuilder
Templates
The AppBuilder provides templates to assist you when you create HTML files. From the main
window of the AppBuilder, choose File New to see the list of templates that are available.
The following WebSpeed templates are available:
Detail Allows you to create an HTML Detail Page with Embedded SpeedScript. It
creates an updatable form to display a single record from a Progress SmartDataObject
or from a database. Optionally, you can add transaction control buttons to allow users to
add, submit, reset, delete and cancel their updates. You can also add navigation buttons
and an entry field that allows the user to enter search criteria.
HTML Mapping Permits you to create a new HTML Mapping procedure and
associate form elements defined in a static HTML file with WebSpeed field objects, such
as database or data object fields.
CGI wrapper A Web object that dynamically generates HTML within the context of
SpeedScript.
Frameset An HTML file that creates three frames (a banner and two columns). The
template also contains markup that displays a message when the browser does not support
frames.
Report An HTML file with preprocessor definitions for creating a tabular view of
database fields with navigation buttons.
Table A file for formatting database results into an HTML table. This is not a
stand-alone file since it does not contain all the required HTML tags. It is meant to be
inserted into another HTML file.
33
Figure 31:
In addition, you can start the AppBuilder from the Application Development Environment
(ADE) Desktop and any tool that has a Tools menu, like the Data Dictionary or the Procedure
Editor. You can also start the AppBuilder directly from an operating system command shell.
For more information about starting the AppBuilder and about the AppBuilder main window,
see OpenEdge Development: AppBuilder.
Connecting to a database server
You must connect AppBuilder to a database server before you can begin to develop WebSpeed
applications. The database must be either the same database that is connected to the WebSpeed
broker, or it must have the same schema.
To connect to a database server that is running:
1.
2.
Choose Connect.
3.
Choose Options>>.
4.
5.
Type the pathname of the database in the Physical Name text field.
6.
Click OK.
For more detailed information about starting database servers, see OpenEdge Getting Started:
Installation and Configuration.
Specifying a default browser
To run and test your WebSpeed applications, you must specify a default browser.
To specify a default browser:
34
1.
2.
AppBuilder
3.
Specify the pathname of the browser that you intend to use during development.
For example, C:\Program Files\Netscape\Communicator\Program\netscape.exe and
typical pathnames for
Netscape Navigator and Internet Explorer, respectively.
2.
3.
Type the URL of the WebSpeed broker in the Broker URL field.
The following code shows the general syntax for specifying a broker URL:
http://host_name[:port]/scripts_dir/messenger/WService=broker
host_name
Specifies the name of the machine that is running the Web server.
port
Specifies the port number of the Web Server. The port number is optional if the Web
Server uses the default port number, which is 80. For example, if a Web Servers port
number is 88, the initial part of the URL might be specified as http://myhost:88.
scripts_dir
Specifies the Web server scripts directory for a CGI or ISAPI Messenger. Omit this
component if you are using an NSAPI Messenger.
messenger
35
Click Test to verify the connection. (Be sure that you specify the path of your default
browsers executable file before testing.)
5.
Click OK.
The AppBuilder is running on the same machine as the WebSpeed Transaction Server
Both the AppBuilder and the WebSpeed Transaction Server have the same working
directory
Both the AppBuilder and the WebSpeed Transaction Server have the same PROPATH
settings
The working directory and PROPATH are set during installation of WebSpeed. For more
information, see OpenEdge Getting Started: Installation and Configuration.
Use remote mode when the WebSpeed Transaction Server is on a remote machine, and when
either of the following conditions are true:
The WebSpeed Transaction Server and the AppBuilder have different PROPATH settings.
The WebSpeed Transaction Server has a different working directory than the AppBuilder.
(In remote mode, files are saved in the WebSpeed Transaction Servers working directory
on the remote machine.)
To change the development mode, click the Development Mode toggle button, which is the last
button in the AppBuilder tool bar as shown in Figure 32.
Local mode
Remote mode
Figure 32:
Note:
If you have network or other problems and cannot access a remote WebSpeed
Transaction Server, you can switch to local mode to create and save source files.
However, you cannot compile source files that contain embedded SpeedScript unless
remote mode is enabled.
AppBuilder documentation
Detailed online help for all the AppBuilder features is available from the main Help menu and
from Help buttons on most dialog boxes. Also, see OpenEdge Application Server: Developing
AppServer Applications for more information about using the AppBuilder.
36
Replace the default error message with a message that you create
Pass a URL to the client browser, which directs the client browser to a specified Web site
To access the WebSpeed Error Customization Utility, you must enable the Administration
Utility. You can do this through the OpenEdge Explorer or the Progress Explorer. Or, you can
add the following line to the [WebSpeed.Messengers.messenger type] section of the
ubroker.properties file:
AllowMsngrCmds=1
After you have enabled the Administration Utility, use a Web browser to go to the WebSpeed
Messenger Administration Page on any machine that has access to the utility. Use a URL with
the following format:
http://host_name[:port]/scripts_dir/messenger/WService=broker?WSMAdmin
When you have accessed the WebSpeed Messenger Administration Page, select Customize
Messenger Error Messages, which displays the WebSpeed Error Customization Utility shown
in Figure 33.
Figure 33:
37
There is a limitation on how many error messages you can customize. Currently, the
file can contain customizations for no more than 32 error messages.
wsCusErr.txt
Another way to customize error messages is to directly edit the wsCusErr.txt file, which, if it
does not already exist, you can create in the Messengers log file directory. Use any editor that
allows you to save as an unformatted text file.
Entries in the wsCusErr.txt file have the following syntax:
error_number 0|1|2
message|URL
error_number
The first entry causes the specified messages to be displayed whenever an 8239 error is
generated. The second entry directs the client browser to the specified Web site whenever any
other error is generated.
38
WebTools
WebTools
WebTools are a collection of browser-based utilities that allow you to perform development
tasks and to access information. Each tool is directly accessible by clicking a link from the
WebSpeed WebTools menu.
You can access WebTools by specifying the WorkShop URL in your browser
(host_name/scripts/cgiip.exe/WService=wsbroker1/workshop, for example). If you have
WebSpeed installed locally, you can also access WebTools from the Tools menu in AppBuilder.
Select Tools WebTools from the AppBuilder main window.
Figure 34 shows the WebTools menu.
Figure 34:
39
WebTool
Application Manager
Data Browser
310
(1 of 3)
Description
Editor
File Tools
WebTools
Table 31:
WebTool
OS Command
(2 of 3)
Description
Scripting Lab
Agent Variables
Databases
Messages
WebSpeed variables
WebTool
Object State
(3 of 3)
Description
ProPath
Developers Corner
Help
Running WebTools
You can access WebTools by specifying the WorkShop URL in your browser. For example:
http://host_name/scripts_dir/messenger/WService=broker/workshop
You can also access WebTools on a machine that has the WebSpeed development environment
installed. From the menu bar in AppBuilder, select Tools WebTools.
Caution: You can access the WebTools only when the agent application mode for broker is
set to Development (the default). If you leave the mode set to Development when
your application goes live, end users can start WebTools and gain unauthorized
access to system files and utilities. Always be sure to set the agent application mode
to Production on brokers that serve deployed applications. See OpenEdge
Application Server: Developing AppServer Applications for more information about
configuring WebSpeed brokers.
312
Language support
Language support
The following sections discuss parts of the ABL and OpenEdge environment that are either
specific to WebSpeed or useful in designing WebSpeed applications.
WebSpeed preprocessors
WebSpeed API
XML
JSON
SpeedScript supports extensions that allow the use of XML through SAX and the
Document Object Model (DOM) interface. These extensions provide the basic input,
output, and low-level data manipulation capabilities required to use data contained in
XML documents. For more information about XML support, see OpenEdge
Development: Working with XML, which describes XML support in the context of the
ABL. However, the information also applies to SpeedScript, which is based on the
ABL.
Database events (such as CREATE and DELETE) can be handled in the same way
Both can be written using the same AppBuilder tools (Procedure Window, the Section
Editor, and the TreeView)
ABL applications are usually state-aware, while SpeedScript applications are often
stateless. The distinction between state-aware and stateless applications is briefly
discussed in OpenEdge Application Server: Developing WebSpeed Applications.
GUI widget events are not used in WebSpeed SpeedScript applications. Visual elements
are handled by HTML, rather than as GUI widgets.
The preprocessor {&OUT} statement is used to output data to the HTML page, rather than
the DISPLAY statement. For information, see OpenEdge Application Server: Developing
WebSpeed Applications.
Very few ABL events apply to WebSpeed applications, except database events. The one
essential event in SpeedScript is WEB-NOTIFY. However, in normal use, this event is
handled exclusively by the agent control program (web-disp.p).
WAIT-FOR
Some procedures that are available through include files and the Insert Call button of the
Section Editor are only appropriate for WebSpeed applications. Some of these are:
hidden-field-list
set-cookie
get-cookie
See the WebSpeed API reference in the online help for a list of the public APIs.
SpeedScript includes special extensions, including a virtual Web output device (WEB) to
define Web page output streams to your Web server and the WEB-CONTEXT system handle
to access the request environment. However, most of these extensions are wrapped in the
API functions, method and event procedures, and preprocessor definitions provided with
WebSpeed.
These examples also rely on SpeedScript preprocessor references, especially {&OUT} and
{&DISPLAY}, to direct output to the WebSpeed-defined output stream, WebStream. You can find
the definitions for these preprocessor references (and several others) in
install-path/src/web/method/cgidefs.i. For more information on the {&DISPLAY}
preprocessor reference, see OpenEdge Application Server: Developing WebSpeed Applications.
314
Language support
SpeedScript versus JavaScript
It is a common practice to use both SpeedScript and JavaScript when developing WebSpeed
applications. SpeedScript has advantages for developing the business logic of applications,
while JavaScript is a good programming tool for adding user interface elements to Web
applications.
If you use either the Report or Detail templates in AppBuilder to create a WebSpeed Web
object, you can view the resulting HTML source file and see a combination of SpeedScript and
JavaScript. The templates will help you create SpeedScript to implement database queries and
updates, and they will create JavaScript event handlers (like onMouseOver, onClick, etc.) to
implement interactive features of the WebSpeed applications.
The <SCRIPT> tag for JavaScript employs the same syntax as the <SCRIPT> tag for Embedded
SpeedScript, as shown:
<SCRIPT Language="JavaScript">
JavaScript Code
</SCRIPT>
In some situations, you do not need a <SCRIPT> tag. JavaScript event handlers, for example, do
not require a <SCRIPT> tag when they are used as an attribute to an HTML tag, as shown in the
following example:
<BODY onLoad="alert(Done);">
Some other factors that you should keep in mind when using JavaScript in WebSpeed
applications are:
End users of your WebSpeed application will be able to see your JavaScript code when
they view HTML source in their browsers. They can see the HTML output that Embedded
SpeedScript generates, but they do not see the actual SpeedScript source code. (This is
because the SpeedScript code executes on the server side while the JavaScript executes on
the client-side browser.)
No static or dynamic HTML can be generated from the JavaScript code that is between
HTML <SCRIPT> tags.
SpeedScript is executed on the server side by the WebSpeed agent. JavaScript is executed
on the client side by the Web browser.
315
tagmap.dat A file that contains default mappings between HTML form element types
and SpeedScript field object types for HTML-mapping Web objects. Each entry in the file
includes the location of the default web.input and web.output control handler procedure
for the field mapping. This file is also where you can define your own mappings and
custom tags for your application. This file resides in your WebSpeed installation directory
(install-path/).
web-disp.p The control program that runs on all WebSpeed agents and executes all
Web objects. The SpeedScript source resides in install-path/src/web/object. It
manages various transaction states that can affect the whole application. This SpeedScript
procedure is included with the development environment because it is central to the
operation of WebSpeed applications. How web-disp.p manages Web objects can affect
how and when you might set and evaluate transaction states in each Web object. This
program also initializes the utility object web-util.p (residing in the same directory),
where most API functions and method procedures reside at run time. WebSpeed has a
special set of procedure-calling conventions. The first convention relies on the
run-web-object method procedure. This procedure is the standard method to execute a
Web object from within another procedure. It is also the basic method web-disp.p uses to
execute Web objects in response to Web requests.
316
Language support
WebSpeed preprocessors
The preprocessor is a function of the ABL compiler that also applies to SpeedScript. On its
initial pass through source code, the compiler looks for preprocessor directives and performs
text substitutions when it finds them. All directives begin with an ampersand (&).
The WebSpeed preprocessors, which are listed in Table 32, provide consistent access to the
Web environment, especially the Web output stream. The definitions of WebSpeed
preprocessor names reside in install-path/src/web/method/cgidefs.i.
Table 32:
WebSpeed preprocessors
Preprocessor name
Assigned value
&WEBSTREAM
STREAM Webstream
&OUT
&OUT-FMT
PUT {&WEBSTREAM}
&OUT-LONG
EXPORT {&WEBSTREAM}
&DISPLAY
DISPLAY {&WEBSTREAM}
WebSpeed API
WebSpeed APIs include a set of standard WebSpeed functions (user-defined SpeedScript
functions) that provides a variety of services to Web objects. API functions handle low-level
Web object tasks such as formatting URLs and returning specific values from the CGI
environment. All API functions are available for your application. The source resides in several
include (.i) files under install-path/src/web/method, including cgiutils.i, cookies.i,
and message.i. Access to these functions in a Web object is provided by including
install-path/src/web/method/cgidefs.i.
For more information on WebSpeed API functions, see the WebSpeed API appendix in
OpenEdge Application Server: Developing WebSpeed Applications. This information is also
available through the AppBuilder online help. Choose Help Help Topics from the
AppBuilder menu bar. Then select the Find tab and type WebSpeed API in the top field of the
dialog box.
XML
Extensible Markup Language (XML) is supported directly in WebSpeeds SpeedScript (ABL)
language, allowing you to exchange data between OpenEdge-supported data sources and XML
documents. XML, considered the standard for exchanging data between disparate applications,
is a markup language like HTML. However, unlike HTML, XML describes document content
in terms of the data without regard for how it is to be displayed.
WebSpeed contains an industry standard XML parser, allowing developers to use SpeedScript
to create programs that send and receive XML documents to/from other XML-enabled Web
applications using Document Object Model (DOM) and SAX interfaces.
317
JSON
JavaScript Object Notation (JSON) is supported directly in WebSpeeds SpeedScript (ABL)
language, allowing you to exchange data between OpenEdge-supported data sources and JSON
data. Specifically, you can serialize ABL ProDataSets and temp-tables to and from JSON data.
JSON developers use JSON as an alternative data interchange format to XML. XML is widely
used to exchange data in a heterogeneous environment. However, some developers consider
XML as too verbose for exchanges between a web browser and a web server as part of a rich
internet application. For example, JSON is widely used in AJAX applications.
318
Examples Contains the source for Web object examples described in this manual,
including HTML and offset files. It also contains additional examples of interest.
Method Contains the source for various SpeedScript compile-time include files
(similar in function to C include files) that define some of the method procedures and API
functions used by WebSpeed to construct Web objects.
Objects Contains the source for the main Web object dispatch procedure web-disp.p
and the utility object web-util.p.
Support Contains all of the tagmap utility procedures for HTML-mapping Web objects
that are specified in tagmap.dat and that define the default web.input and web.output
control handlers for supported HTML form element and SpeedScript field object types. It
also contains some run-time procedures for debugging and interpreting the offset file for
an HTML-mapping Web object.
Template Contains skeleton files used to create new Web objects and other types of
support objects and files, including:
A file that defines the New File links that use these templates in the AppBuilder Files
component (web.cst).
An embedded SpeedScript template for generating a table of database fields that can
be executed by another Web object (table.html)
Language support
Super procedures These are .i and .p files that contain the definitions of WebSpeed
super procedures. To use super procedures, you include the .i file in your ABL code rather
than running the .p file directly. Super procedures are in the install-path/src/web2
directory.
For more information about super procedures, see OpenEdge Deployment: Managing ABL
Applications.
Templates Code relating to WebSpeed Report, Detail, and HTML Mapping wizards is
in the install-path/src/web2/templates directory. These files can be used as models
for creating custom templates that can be made accessible to the AppBuilder through a
.cst file.
There are two kinds of files in the template directory. First are the .w and .i template files.
These are used to create new objects that can be made available from the AppBuilder
palette. More information on using .w and .i template files to extend AppBuilder can be
found in OpenEdge Application Server: Developing AppServer Applications.
The second type of file is the HTML template files (.dat files) for the report and detail
wizards. These can be used as examples of how to create new wizards that create
embedded ABL files (.html files). Each .dat file has a companion .w file with the same
filename (for example, wreport.w and wreport.dat) that acts as a SpeedScript wrapper
for the .dat file.
319
320
4
Running and Deploying WebSpeed
Applications
This chapter includes information about deploying WebSpeed, including important security
considerations, as described in the following sections:
WebSpeed security
Note:
This chapter includes several screen shots showing taks performed in the Progress
Explorer. You can also perform these tasks in the OpenEdge Explorer.
For example, before launching a WebSpeed application, you should make a data source
available to the WebSpeed broker and agents for your application. When you shut down your
application, the broker and agents should shut down before the databases. If agents lose their
database connections prematurely, you might have to complete the shutdown manually.
In most cases, when a machine or component fails, you only have to restart that machine or
component. If your data source in a complex distributed configuration fails, data integrity
concerns might make it necessary to bring down other components before restarting your data
source.
The examples of WebSpeed configurations in this section are meant to illustrate which
components must reside on the same machine and how to establish links between the various
WebSpeed components on different machines. You can adapt these examples to your needs, as
described in the following sections:
42
Single-machine configuration
Single-machine configuration
The most basic configuration for WebSpeed is to install the WebSpeed Workshop application
on the same machine as your Web server and a data source. The WebSpeed Workshop uses a
subset of the OpenEdge development tools focused on developing and testing WebSpeed
applications. With the Workshop, you do not have access to the graphical interface design
capabilities of the AppBuilder.
Figure 41 shows the components installed in a single-machine configuration.
Note:
The WebSpeed Broker and the WebSpeed Agents it controls are collectively referred
to as the WebSpeed Transaction Server in this figure.
AdminServer
W eb server
N ameServer
W ebSpeed
W ebTools
W ebSpeed
AppBuilder
W ebSpeed
Messenger
W eb
browser
Figure 41:
W ebSpeed
Transaction
Server
Data source
The WebSpeed Workshop includes the WebSpeed Development Server, which supports a
single developer. The WebSpeed Development Server comes with only two WebSpeed Agents.
The WebSpeed Development Server includes the Progress OpenEdge Personal RDBMS. The
OpenEdge Personal RDBMS can handle up to five local connections: one for the WebSpeed
AppBuilder, one for the OpenEdge Explorer or the Progress Explorer, and three for the
applications that you are developing. This is suitable for the needs of a single developer.
As Figure 41 shows, the Web server, the WebSpeed WebTools, and the WebSpeed Messenger
form an interdependent unit. While the Web server can handle non-WebSpeed traffic in addition
to the WebSpeed traffic, the WebSpeed WebTools and Messenger cannot operate
independently from the Web server.
To set up a single machine configuration:
1.
2.
43
2.
3.
4.
5.
6.
7.
Start the Web browser by choosing the WebTools from the AppBuilders Tools menu as
needed.
44
The WebSpeed Broker and the WebSpeed Agents it controls are collectively referred
to as the WebSpeed Transaction Server in this figure.
Phobos
Mars
W ebSpeed
AppBuilder
W eb
browser
AdminServer
NameServer
W ebSpeed
Transaction
Server
W eb server
Deimos
W ebSpeed
W ebTools
W ebSpeed
AppBuilder
W ebSpeed
Messenger
D ata source
W eb
browser
Figure 42:
This configuration uses the WebSpeed Transaction Server and some data source on the central
machine and the WebSpeed Workshop on the workstations. Figure 42 shows a central
machine, Mars, configured to support two development workstations, Phobos and Deimos.
The WebSpeed Transaction Server supports a team of developers creating WebSpeed
applications. You can start up as many WebSpeed Agents as you have licenses for. Depending
on the locking strategies for WebSpeed Agents you use in your applications, any given Agent
might serve the needs of several developers or only one developer. Because the WebSpeed
Transaction Server does not include a database, you must install either the Progress OpenEdge
Workgroup RDBMS or the appropriate DataServer to connect to your non-OpenEdge database.
To set up a central development machine configuration:
1.
2.
3.
Install the appropriate components for your intended data source on Mars:
4.
If you use the OpenEdge Database, install the OpenEdge Workgroup RDBMS.
Install the WebSpeed Workshop, which includes the AppBuilder, on Phobos and Deimos.
45
2.
Start the data source (and the data server broker, if needed) on Mars in multi-user mode.
3.
4.
5.
6.
7.
Start a Web browser by choosing the WebTools from the AppBuilders Tools menu on a
workstation as needed.
46
The WebSpeed Broker and the WebSpeed Agents it controls are collectively referred
to as the WebSpeed Transaction Server in this figure.
Ganymede
OpenEdge
Studio
W eb
brow ser
Callisto
W ebSpeed
AppBuilder
Jupiter
Europa
AdminServer
W eb server
NameServer
W ebSpeed
W ebTools
Static H TML
files
W ebSpeed
Transaction
Server
W ebSpeed
Messenger
D ata source
W eb
brow ser
Figure 43:
This configuration has the WebSpeed Messenger installed on the Web servers machine,
Europa. The host machine, Jupiter, uses the WebSpeed Transaction Server. Because the
WebSpeed Transaction Server does not include a database, you must install the OpenEdge
Workgroup RDBMS or the appropriate DataServer to connect to your non-OpenEdge database.
One of the workstations, Ganymede, has OpenEdge Studio installed to gain access to the full
capabilities of the AppBuilder. The developer using Ganymede can alternate between
developing Web applications and non-Web-based applications. The other workstation, Callisto,
has the WebSpeed Workshop installed.
To set up a development network with a dedicated Web server configuration:
1.
2.
3.
Install the appropriate components for your intended data source on Jupiter:
If you use the OpenEdge Database, install the OpenEdge Workgroup RDBMS.
47
5.
6.
2.
Start the data source (and the data server broker, if needed) on Jupiter in multi-user mode.
3.
4.
5.
6.
7.
Start a Web browser on a workstation by choosing the WebTools from the AppBuilders
Tools menu as needed.
48
Prometheus
Calypso
OpenEdge
Studio
AdminServer
W eb
brow ser
Hyperion
W ebSpeed
Transaction
Server
AdminServer
W ebSpeed
Transaction
Server
Pandora
W eb server
Saturn
W ebSpeed
W ebTools
AdminServer
Static HTML
Files
D ata source
NameServer
W ebSpeed
Messenger
Sales LAN
Manufacturing LAN
Titan
AdminServer
N ameServer
Figure 44:
Atlas
W ebSpeed
Transaction
Server
AdminServer
D ata
source
In this configuration, the NameServer machine, Saturn, is the central communication point that
routes requests to the WebSpeed Transaction Servers on both LANs. Requests start from
workstations, like Prometheus (which has OpenEdge Studio installed on it). A workstation
passes the request to the Web server machine, Pandora, which has the WebSpeed Messenger
installed. The Messenger asks the NameServer on Saturn to find a WebSpeed Transaction
Server that can handle the request, by specifying an application service with the WService
parameter.
49
2.
3.
4.
5.
Install OpenEdge Studio or the WebSpeed Workshop on Prometheus and your other
workstations, according to your development needs.
6.
Install the appropriate data source components on Hyperion and Atlas, depending on what
you use as your data source:
If you use the OpenEdge Database, install the OpenEdge Enterprise RDBMS.
410
2.
Start the data sources (and data server brokers, if needed) on Hyperion and Atlas in
multi-user mode.
3.
4.
5.
6.
7.
Start a Web browser on a workstation by choosing the WebTools from the AppBuilders
Tools menu as needed.
Note:
If one of the data sources fails, you should stop all the WebSpeed Transaction Servers
that support applications that use that data source. Bring the data source back up and
then restart the Transaction Servers. This helps ensure data integrity.
411
The WebSpeed Broker and the WebSpeed Agents it controls are collectively referred
to as the WebSpeed Transaction Server in this figure.
W eb
browser
Uranus
AdminServer
Oberon
Your
R-code
N ameServer
W eb server
Static H TML,
.gif, and Java
Applet Files
W ebSpeed
Transaction
Server
Data source
W ebSpeed
Messenger
Figure 45:
This configuration has the WebSpeed Messenger product installed on the Web servers
machine, Oberon. The main machine, Uranus, has the WebSpeed Enterprise Transaction Server
and some data source. The end users only need a Web browser to link up to your applications;
they do not need any OpenEdge product installed on their machines.
To set up a deployment network with a dedicated Web server:
1.
2.
3.
412
Install the appropriate components for your intended data source on Uranus:
If you use the OpenEdge Database, install the OpenEdge Enterprise RDBMS.
5.
Install your r-code on Uranus and include its location in the WebSpeed agents PROPATH.
6.
Copy any Java applet, static HTML, and .gif files needed for your applications to the
Web servers /docroot/webspeed directory on Oberon.
2.
Start the data source (and the data server broker, if needed) on Uranus in multi-user mode.
3.
4.
5.
413
The WebSpeed Broker and the WebSpeed Agents it controls are collectively referred
to as the WebSpeed Transaction Server in this figure.
Thalassa
OpenEdge
Studio
W eb
browser
Neptune
D evelopment
W eb Server
W ebSpeed
W ebTools
Static HTML
Files
Proteus
W ebSpeed
Messenger
Deployment
W eb Server
Static HTML,
.gif, and Java
Applet Files
W eb
brow ser
W ebSpeed
Messenger
AdminServer
W ebSpeed
Transaction
Server
Development
data source
Triton
Galatea
Nereid
AdminServer
AdminServer
AdminServer
NameServer
N ameServer
W ebSpeed
Transaction
Server
D eployment
data source
Your
R-code
Development side
Figure 46:
Deployment side
In this configuration, the dedicated Web server machine, Neptune, has two Web servers
installed. One Web server handles the development workload, and the other handles the
deployment workload. This allows the developers to experiment with the environment without
bringing down the deployment side. Each of the Web servers requires its own WebSpeed
Messenger, but only the development Web server needs the WebSpeed WebTools.
On the development side, the Messenger routes requests to the NameServer on Triton. Tritons
NameServer only has the WebSpeed Transaction Servers on Proteus registered, so it looks there
for a Transaction Server to handle the request. Proteus has the WebSpeed Enterprise
Transaction Server and either the OpenEdge Enterprise RDBMS or a non-Progress data source
installed on it.
414
2.
3.
4.
Install the WebSpeed Messenger on Neptune using the development Web servers
Document Root directory and scripts path.
5.
6.
Install OpenEdge Studio or the WebSpeed Workshop on Thalassa and your other
workstations, according to your development needs.
7.
Install the WebSpeed Messenger on Neptune using the deployment Web servers
Document Root directory and scripts path.
Note: Since the WebSpeed WebTools are only meant for developers, you should remove
access to them through the deployment Web server. During the Messenger-only
installation, do not choose the option to either create a virtual directory or copy the
static HTML files.
8.
9.
10. Install the appropriate data source components on Proteus and Nereid. This depends on
what you are planning to use as your data source:
If you use the OpenEdge Database, install the OpenEdge Enterprise RDBMS.
11. Install your r-code on Galatea and include its location in the WebSpeed agents PROPATH.
12. Copy any Java applet, static HTML, and .gif files that your applications must the
deployment Web servers /docroot/webspeed directory on Neptune.
415
416
2.
Start the data source (and the data server broker, if needed) on Proteus in multi-user mode.
3.
4.
5.
6.
7.
Start a Web browser on a workstation by choosing the WebTools from the AppBuilders
Tools menu as needed.
2.
3.
4.
5.
Note:
If one of the data sources fails, you should stop all the WebSpeed Transaction Servers
supporting applications that use that data source. Bring the data source back up and
then restart the Transaction Servers. This helps ensure data integrity.
417
WebSpeed security
WebSpeed is an application service technology for Web browser applications. OpenEdge
supports a number of special-purpose security options for WebSpeed that are tailored for the
WebSpeed environment, including:
Data privacy over the connection between the WebSpeed Messenger and the WebSpeed
Transaction Server using SSL
Note: WebSpeed agents, as ABL (Advanced Business Language) database clients, can
also access the OpenEdge RDBMS using SSL.
418
WebSpeed security
There are a number of things you can do to avoid this possibility. One approach is to start your
agents with the run-time client (-rr) startup parameter. This parameter ensures that agents can
only run precompiled code. This allows you to leave uncompiled procedures on the PROPATH
without concern that they can be run from a Web browser. However, this approach does not
allow you to take advantage of WebSpeeds compile-time flexibility. Depending on how you
want to write your application, this might be important.
You can also use the check-agent-mode API function to allow some routines to work for
Development but not for Production. For more information on the environment options, see the
UNIX ubroker.properties.README file, or see OpenEdge Application Server: Developing
WebSpeed Applications.
Yet another approach is to move any procedures off of the PROPATH that you do not want a Web
user to run. For example, if you do not want a Web user to run the runscrpt.w procedure, then
you must move it into a directory that is not included on the PROPATH and is not relative to the
PROPATH.
Caution: One of the most important security considerations is to deny end users access to
WebTools. Access to WebTools allows users to run utilities that can potentially alter
or damage your system. Therefore, you should make sure that your WebSpeed agents
run in production mode for deployed applications. None of the WebTools can run in
production mode.
By default, the WebSpeed agents run in development mode. You can change to
production mode by using the OpenEdge Explorer or the Progress Explorer to
change the agents properties. See OpenEdge Application Server: Developing
WebSpeed Applications for more information.
The following aspects of your configuration should be secure when deploying WebSpeed:
Network traffic
Web server
WebSpeed server
Application
The following sections briefly discuss each of these topics. Security is a broad and complex
topic. You might want to consult with an expert on security about your particular deployment
isssues.
419
You should purchase the highest level of encryption possible for your locality. Most
countries now allow 128-bit SSL, while some are still limited to 40-bit. The Digital
Certificate provider will let you know the highest level that you can purchase.
If you are hosting a private Web site or an intranet, then you can generate your own certificates.
This has the benefit of being free, but the users of your site will have to accept their Web
browsers warning that the certificate from your site is not trusted. To generate your own
certificates, see your Web servers documentation.
After you have enabled SSL, you can use https instead of http as the URL protocol for your
Web site, and then the data will be encrypted. For example, if your Web site address is:
http://www.mysite.com
https://www.mysite.com
420
WebSpeed security
Hiding your Web server type and version
It is good practice to hide the brand and version of your Web server process to make it harder
for script-kiddies to find out which Web server you are using.
To see how your Web server responds, use a Telnet session to access the port that the Web
server is listening to. The default port is 80. The following procedure shows the commands to
type. Replace the hostname with your Web servers name. You might find that when you type
GET / HTTP/1.0 it might not be echoed back to you:
To check your Web server response:
1.
2.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Fri, 11 Jul 2003 16:59:53 GMT
Content-Type: text/html
. . . HTML text of the default page . . .
In the previous example, you can see that the Web server is Microsofts Internet Information
Server (IIS) Version 5.1.
If you can modify the HTTP headers, make the Server setting return a generic name, like
WebServer. Consult your Web servers documentation to see if it is possible and how to modify
the HTTP headers.
Changing your script directory names
You should not use the standard script directory names. If you have an Apache server, do not
use cgi-bin. If you are using Microsofts IIS, do not use Scripts. See your Web server
documentation for instructions on how to create a different script directory.
Most Web servers also ship with default home pages, as well as demonstration scripts. These
generally should be disabled or deleted.
Hiding the CGIIP executable name from the end user
Hiding the WebSpeed Messenger name from the end user also provides a level of security.
When you access a WebSpeed application, the URL used will look similar to the following if
you are using Windows as the Web server:
http://www.mysite.com/scripts/cgiip.exe/WService=Orders/main.r
421
http://www.mysite.com/cgi-bin/wspd_cgi.sh/WService=Orders/main.r
Using the default names is bad security practice because it lets people know what application
server you are using, in this case WebSpeed. For example, if you perform a Google search for
wspd_cgi.sh or cgiip.exe, you will find many sites using WebSpeed. Some of these are not
securely deployed.
Microsoft IIS
If you are using Microsoft IIS, then WebSpeed includes an example file explaining how you can
hide the Messengers name. It is called cgiip.wsc and, by default, is located in the
C:\InetPub\Scripts directory. It is recommended that you rename the file to something that
is meaningful only to you, for example, orders.inet. The extension (.inet) must be an unused
extension on your machine. You should also delete the cgiip.exe and wsisa.dll Messenger
files in the Scripts directory.
If you open the orders.inet file using a text editor, you will see instructions on how to
configure IIS to run this script when it is part of the URL.
Note:
If you are using IIS 4.x or 5.x, you might find that the Configuration button mentioned
in the instructions is disabled. To enable the Configuration button, first choose the
Create button just above it.
Use the extension you have chosen (for example, .inet) instead of the .wsc extension
mentioned in the instructions.
At the end of the newly created orders.inet file, change the WebSpeed service name from
For the example above, use Orders.
wsbroker1.
All lines beginning with # are comments. The only required line is the one that references the
service name or host and port of the WebSpeed broker.
Assuming that you have changed the Scripts directory to be web, the URL becomes:
http://www.mysite.com/web/orders.inet/main.r
If you have more than one WebSpeed service, then you will need a .inet file for each service.
UNIX
There are many different Web servers available on UNIX. To find out which Web servers
Progress Software Corporation has tested and certified, search the Knowledge Center. You can
access the Progress Knowledge Center from the Support page at
http://www.progress.com/support/index.ssp.
422
WebSpeed security
Each of these has different configuration instructions. You should read the documentation
supplied by the Web server vendor to determine how to enable CGI applications. Rename the
Progress-supplied wspd_cgi.sh to something that is meaningful only to you and change the
WebSpeed service name from wsbroker1. If you have changed the cgi-bin directory to web and
allowed.inet scripts to be run as CGI programs, then the URL you would use is:
http://www.mysite.com/web/orders.inet/main.r
http://www.mysite.com/scripts/cgiip.exe?WSMAdmin
Or:
http://www.mysite.com/cgi-bin/wspd_cgi.sh?WSMAdmin
423
424
WebSpeed security
Figure 47 shows a deployment model that uses separate machines for the Internet production,
intranet production, and the development/test servers. The databases are all installed on the
same machine as the WebSpeed servers. This is the preferred route if your machine has the
capacity to host both, as it will provide the best performance.
Internet/Untrusted Zone
Internet
Demilitarized Zone
(DMZ)
Internet
Web
Server
Intranet/Trusted Zone
Internet
Production
Server
Internet
NameServer
Internet
WebSpeed
Server
Internet
Database
Intranet
NameServer
Intranet
Web
Server
Intranet
Production
Server
Users
Intranet
WebSpeed
Server
Dev/Test
NameServer
Dev/Test
WebSpeed
Server
Figure 47:
Intranet
Database
Dev/Test
Web
Server
Development
Test Server
Developers
& Testers
Dev/Test
Database
425
Internet
Demilitarized Zone
(DMZ)
Internet
Web
Server
Internet
NameServer
Internet
WebSpeed
Server
Internet
Database
Intratnet
WebSpeed
Server
Production
Server
Intranet
Database
Users
Intranet Server
Intranet
NameServer
Intranet
Web
Server
Developers
& Testers
Figure 48:
Dev/Test
Database
426
WebSpeed security
** CRC for table does not match CRC in program. Try recompiling. (1896)
If you already have r-code deployed, use the RCODEKEY function of PROUTIL to tag the existing
r-code without the must recompile.
See OpenEdge Data Management: Database Administration for more information on using the
and RCODEKEY features of PROUTIL.
DBAUTHKEY
Make sure that certain r-code can only be run by certain users
Because each request must go through this code, any changes made to web-disp.p are system
wide.
If you want to change this code, you should move it into your applications source tree and
rename it. This way, when a service pack installs a newer version of web-disp.p, your changes
are not overwritten. You should also compare your code with the new code shipped in the
service pack to make sure you also incorporate any bug fixes or enhancements.
427
Note:
Example 41 and Example 42 do not run. Much of the code has been removed. The
purpose of these examples is to show program flow.
Example 42 shows a simplified, secure web-disp.p. You insert the bold text into the original
replacing the AppProgram = ... code.
web-disp.p
This code stops PING, DEBUG, and RESET, changes the extension of any requested program into
r-code, checks that the r-code file exists, and verifies if this r-code is valid for this user by
looking up a database table called UserPrograms. You must create a table called UserPrograms
containing (at least) both these fields. Also, UserID is a variable that you must instantiate.
428
WebSpeed security
You usually use a cookie, hidden fields, or URL parameters to hold the users ID. This should
be encrypted in a suitable manner. See the Parameter passing section on page 430 for an
example of encrypting this ID.
Example 42: Secure web-disp.p
/* Set the web-request trigger. */
ON "WEB-NOTIFY":U ANYWHERE DO:
DEFINE VARIABLE vLocn AS INTEGER NO-UNDO.
OUTPUT {&WEBSTREAM} TO "WEB":U.
/* Parse the request/CGI from the web server. */
RUN init-cgi IN web-utilities-hdl.
/* Initialize for web-request. */
RUN init-request IN web-utilities-hdl.
/* Remove current extension */
vLocn = R-INDEX (AppProgram, ".").
IF vLocn > 0 THEN
AppProgram = SUBSTR (AppProgram, 1, vLocn - 1).
/* Add a .R */
AppProgram = AppProgram + ".r".
/* Can this User run this program OR does it exist? */
IF NOT CAN-FIND (UserPrograms WHERE UserPrograms.UserID = UserID
AND UserPrograms.Program = AppProgram)
OR SEARCH (AppProgram) = ? THEN
AppProgram = "NotValidProgram.r".
RUN run-web-object IN web-utilities-hdl (AppProgram) NO-ERROR.
/* Run clean up and maintenance code */
RUN end-request IN web-utilities-hdl NO-ERROR.
/* Output any pending messages queued up by queue-message() */
IF available-messages(?) THEN
output-messages("all", ?, "Messages:").
OUTPUT {&WEBSTREAM} CLOSE.
END. /* ON "WEB-NOTIFY" */
After creating your new-web-disp.p, you must change the agent parameters to reference it, as
shown in Figure 49.
Figure 49:
429
Parameter passing
If you want to pass parameters between Web requests, you can use hidden fields on forms, URL
parameters, cookies, or a combination of each technique. Each technique has pros and cons.
Hidden fields only work on forms, URL parameters are visible to the end user, and cookies are
not allowed by some users.
The simplest way to pass many parameters between Web requests is to use the database. You
pass a unique identifier for each user or session between requests, and use this as a key into a
state table held in the database. This technique requires that only a small token be passed
between requests, as the majority of the data is safe and secure in the database.
Do not pass the unique identifier in plain text. Doing so makes it very easy for an end-user to
change the value (even in hidden fields or cookies) and become someone else. Use code, similar
to the code shown in Example 43, to prevent people from changing the unique identifier,
unless they know the hidden words, in this case Web and Speed.
Example 43: Passing unique identifiers
/* This code assumes that the Unique ID will not contain any colons (:). */
DEFINE VARIABLE vToken
AS CHARACTER NO-UNDO.
DEFINE VARIABLE vUniqueID AS CHARACTER NO-UNDO.
/* WebEncode function */
FUNCTION WebEncode RETURNS CHARACTER (pUniqueID AS CHARACTER):
RETURN pUniqueID + ":" + ENCODE ("Web" + pUniqueID + "Speed").
END.
/* Use this to encode the Unique ID, then pass as parameter */
vToken = WebEncode (vUniqueID).
/* Use this to decode the token passed as a parameter. */
vUniqueID = ENTRY (1, vToken, ":").
IF vToken = WebEncode (vUniqueID) THEN
/* vToken has not been modified */
ELSE
/* ERROR - vToken has been modified */
430
WebSpeed security
Firewalls
A firewall is the first line of defense for basic network security. It is usually a separate device
that sits between the untrusted network (the Internet) and the trusted network (the intranet). The
role of a firewall is to stop unauthorized access of information in the trusted network by
individuals on the untrusted network, but allow defined access from the trusted to the untrusted.
An analogy for a firewall is a moat around a castle with the drawbridge being the firewall
device. The drawbridge is controlled by guards who only allow certain traffic in, usually after
inspecting it, and will allow outbound traffic if it has permission.
There is usually a third network commonly referred to as the DMZ or Demilitarized Zone. This
network is separate from both the others, but it can communicate with both. This is a semitrusted
area that is protected by the firewall, so only certain traffic can come in. Any traffic coming
from the DMZ into the trusted network must abide by strict rules, so errant requests are denied.
There are three physical network ports on a DMZ-enabled firewall, one for each network.
Figure 410 shows a firewall with a DMZ. This is the usual configuration for a firewall.
Firewall Device
Internet
D MZ
Intranet
Figure 410:
431
Firewall Device #1
Internet
D MZ
Firewall Device #2
Intranet
Figure 411:
432
Firewall configuration
Using a firewall poses additional configuration issues because you must configure the firewall
to allow communications between the OpenEdge server host machines on particular ports using
TCP or UDP protocols. In OpenEdge Application Server: Developing WebSpeed Applications,
the entire round-trip request is shown. All of these messages must go through the firewall.
Figure 412 illustrates which ports must be open and what protocols the messages use.
DMZ
Internal
H ost: webserv1
IP addr: 1.1.1.1
Internet
Web Server
Internet
NameServer
H ost: inet_ns
IP addr: 5.5.5.5
N S Port: 5678
WebSpeed
Messenger
WebSpeed
Broker
H ost: fire1
WebSpeed
Agent
Host: webspeed1
IP addr: 4.4.4.4
Broker Port : 7800
Max 5 Agents: 7801-7805
Host: fire2
IP addr: 2.2.2.2 on D MZ
and 3.3.3.3 on internal
Figure 412:
Firewall configuration
Note:
The firewall fire2 has two network cards, one for the Demilitarized Zone (DMZ) and
one for the Internal network. Each of these has its own IP address, as shown.
433
Example 44. The port range must be big enough to cope with all the potential simultaneous
requests from the Internet. In this case, there are 20 ports available. You can make this range
bigger if needed. Also, you must change the setting for the NameServer to point to the correct
host.
Example 44: Configuring ubroker.properties file for firewall
[WebSpeed.Messengers]
.
.
minNSClientPort=5680
maxNSClientPort=5699
controllingNameServer=InternetNS
.
.
[NameServer.InternetNS]
.
.
hostName=inet_ns
location=remote
portNumber=5678
.
.
Between the Internet and Web server webserv1, allow inbound and outbound traffic from
the Internet on port 80 (the default for HTTP) to the Web server. This is a standard
configuration on most firewalls. If you are using HTTP/S (HTTP over SSL), then the
default port is 443.
434
UDP from IP Address 1.1.1.1 to 5.5.5.5 on port 5678. This is the inbound
NameServer request traffic.
UDP from IP Address 5.5.5.5 to 1.1.1.1 on ports 5680 to 5699 inclusive (assuming
the above settings in the ubroker.properties file). This is the outbound
NameServer response traffic as specified in the Messengers ubroker.properties
file on the Web server.
TCP from IP Address 1.1.1.1 to 4.4.4.4 on port 7800 for the inbound request.
TCP from IP Address 4.4.4.4 to 1.1.1.1 on port 7800 for the outbound reply.
TCP from IP Address 1.1.1.1 to 4.4.4.4 on ports 7801 to 7805 inclusive for the
inbound request.
TCP from IP Address 4.4.4.4 to 1.1.1.1 on port 7801 to 7805 inclusive for the
outbound reply.
Most firewalls accomplish this by using port forwarding. This means that when the firewall
receives a request from a host on a certain port in the DMZ, it is passed through to a particular
host on the internal network. When the webserv1 machine makes a request to the NameServer,
it cannot see IP address 5.5.5.5 directly, and it has to pass the request to the firewall machine
fire2. The firewall then makes the request on the internal network to IP address 5.5.5.5 on its
behalf. When the response comes back from the NameServer to the firewall, the firewall will
send it on to the Messenger on the DMZ network. As an analogy, think of the firewall as a
language interpreter where the WebSpeed Messenger speaks English and the NameServer
speaks German. The Messenger needs to talk to the NameServer but cannot do so directly, so it
forwards the request to the interpreter who, in turn, makes a request to the NameServer on the
Messengers behalf. The response is given to the interpreter by the NameServer, who then
forwards it to the Messenger.
This is achieved by setting the hosts file on webserv1 to have the host inet_ns set to 2.2.2.2,
as shown below. When the Messenger looks for host inet_ns, it uses the IP address 2.2.2.2,
which is the firewall host fire2, as shown:
127.0.0.1
2.2.2.2
Note:
localhost
inet_ns
You do not must have an entry for fire2 in the hosts file as the DMZ machines never
communicate with it by name; DMZ machines believe that communication with other
machines never travels beyond the internal network.
Similarly, the Messenger cannot communicate directly to the WebSpeed server host webspeed1
at IP address 4.4.4.4 either. So, another entry needs to be made in the hosts file to make the
Messenger communicate with the firewall instead of the real host, as shown:
127.0.0.1
2.2.2.2
localhost
inet_ns webspeed1
435
Figure 413:
Note:
The NameServer and WebSpeed server hosts do not need the firewall IP address in
their hosts file because they only respond to requests and do not make them.
436
2.
Right-click on your LAN connection and select Properties from the pop-up menu. The
Local Area Connections Properties dialog box appears:
3.
Choose Properties. The Internet Protocol (TCP/IP) Properties dialog box appears:
437
438
4.
5.
6.
Highlight TCP/IP Filtering in the list and then click Properties. The TCP/IP Filtering
dialog box appears.
You can set the filter to allow all packets as shown, or you can restrict the ports allowed
by adding them into the appropriate areas:
Note:
If you must use DNS, then you also must allow UDP port 53 and TCP port 53. For the
Web server, you need port 80. For HTTP/S, you need port 443.
[WebSpeed.Messengers]
...
logFile=@{WorkPath}\msgr.log
loggingLevel=1
...
You might have received a Web server internal error. This is usually caused by a Web server
misconfiguration related to the executability settings for CGI programs. Check your Web
server documentation to make sure you have configured it to run your WebSpeed Messenger
correctly.
If you use the Messenger Administration tool, you can test the configuration of your WebSpeed
application. For more information, see the Configuring a WebSpeed Messenger section on
page 221.
439
WS.Sports2000_WS
Now, try to access the application again. After the error is returned to the WebSpeed Messenger,
check the NameServers log file. You should see something similar to the following:
If you do not see the Request received in the log file, then the firewall is losing the inbound
NameServer request. Otherwise, the outbound request is being lost. After debugging this stage,
make sure to reset the logging setting.
Accessing the WebSpeed broker
This time, set the WebSpeed brokers logging setting to verbose and make the request. You
should see something similar to the following (at a time just after the NameServer log entry):
440
441
HTTP/S performance
442
Figure 414:
HTTP/S performance
Using HTTP/S to encrypt the traffic between the Web browser and the Web server provides
very good security for the data, but it also introduces performance degradation. In general, for
each request that is made to the Web server, the Web browser and Web server must go through
at least 8 and up to 13 handshake messages before the actual data is sent. Also, one of these
handshake messages needs the Web browser to generate a long random number, which is a slow
process.
Because a Web page is usually made up of multiple requests, using HTTP/S as the protocol
slows down the Web page being displayed. For example, a Web page with 15 images on it will
mean 16 individual requests to be made to the Web server.
HTTP/1.1 has features that should allow one connection with multiple requests to work, but the
implementation into the Web servers and the Web browsers has not been completed. There are
hardware SSL accelerators on the market that will alleviate most of the performance issues on
the Web server side when using SSL.
443
444
If you are using a hosts file entry to fix this problem, then you really should fix the
DNS problem and remove the entry in the hosts file.
Subnet 10 .x.x.x
Hostname: Hydra
10.1.1.1
Netw ork # 1
192.168.123.1
Network #2
Figure 415:
Multi-homed server
The clients on the 10.x.x.x subnet will not be able to access services on the host unless they use
the correct IP address 10.1.1.1. Likewise, the 192.168.x.x subnet must use 192.168.123.1. To
make all these clients connect to a single AppServer on the host, set up the hosts file on the
machines in the 10.x.x.x subnet to read as follows:
127.0.0.1
10.1.1.1
localhost
hydra
127.0.0.1
192.168.123.1
localhost
hydra
445
Figure 416:
This enables the NameServer to tell the clients, regardless of what subnet they are on, to connect
to the machine called hydra. It is then up to the client machine to decide what the appropriate
IP address is.
446
For detailed instructions on creating a local copy of the Sports2000 database for use
with a sample application, see the chapter on working with sample applications in
OpenEdge Getting Started: Progress OpenEdge Studio.
The HTML source files that are compiled to create the Web objects (r-code) for the sample
applications are in the install-path/src/samples/web directory.The r-code that WebSpeed
agents actually run is in the install-path/tty/samples/web directory.
Before you can run sample applications, you must have WebSpeed running on a Web server. In
addition, you must set up WebSpeed to run while connected to the Sports2000 sample database.
To set up WebSpeed to run while connected to Sports2000:
1.
2.
Copy the sports2000trgs folder (which contains database triggers) from your OpenEdge
installation directory to your working directory.
3.
4.
Start a WebSpeed broker connected to your working copy of the Sports2000 database. See
the Configuring a WebSpeed broker to connect to a database section on page 449 for
instructions on completing this procedure.
http://host_name/scripts_dir/messenger/WService=wsbroker1/samples/web
/internet/home.r
http://host_name/scripts_dir/messenger/WService=wsbroker1/samples/web
/extranet/login.r
447
http://host_name/scripts_dir/messenger/WService=wsbroker1/samples
/web/intranet/advisor.r
For example, if you are running a local IIS Web server and using the CGIIP Messenger,
the URL would look similar to the following:
http://localhost/scripts/cgiip.exe/WService=wsbroker1/samples/web
/intranet/advisor.r
Complete the setup procedures described in the Running sample applications section on
page 447, and make sure that WebSpeed is running in conjunction with a Web server and
the Sports2000 sample database.
2.
3.
http://host_name/scripts_dir/messenger/WService=wsbroker1/samples/web/
intranet/advisor.r
For example, if you are running a local IIS Web server, using the CGIIP Messenger and
the default broker, the URL would look similar to the following:
http://localhost/scripts/cgiip.exe/WService=wsbroker1/samples/web
/intranet/advisor.r
448
To view the HTML source file of any Web object, select the object and click View Code.
The following procedure assumes that you have started Progress Explorer and have
connected to the appropriate host machine. You can also perform these tasks with the
OpenEdge Explorer.
Select and expand the node labeled WebSpeed in the tree view.
You should see the default broker name, wsbroker1, in the tree view, as shown:
449
3.
4.
Add the pathname of your working copy of the Sports2000 database to Agent startup
parameters using the -db option.
In the figure in Step 3, the database is specified as c:\WRK\sports2000.
Note: In this example, the database is located on the same machine as the WebSpeed
broker with a shared memory connection. If the server for the database is running
on a remote machine (or you want to use client/server mode), you must specify the
host name (using the -H parameter) of the databases machine and the service name
(using the -S parameter). For more information about client/server connections, see
OpenEdge Application Server: Developing AppServer Applications.
5.
Click OK.
6.
450
A
WebSpeed Configuration and
Management Utilities
This appendix explains the use of the WebSpeed configuration and management utilities, as
described in the following sections:
WSCONFIG utility
WTBMAN utility
probkup
Figure A1:
dbname
sports
qualifier
incremental
parameter value
-vs 708
Command components
Component
command
Executable
db-name
Database name
qualifier
parameter
value
Note:
A2
Description
Enter parameters for UNIX and Windows exactly as shown in the syntax descriptions.
WSCONFIG utility
WSCONFIG utility
Use the WSCONFIG utility to help validate existing WebSpeed Transaction Server or WebSpeed
Messenger configurations defined in a properties file, such as the ubroker.properties file.
This utility displays the property settings associated with a WebSpeed Transaction Server or
Messenger configuration, and checks that the syntax and values are valid.
The WSCONFIG utility runs locally on the machine where the WebSpeed components that you
want to check are running. Because the utility does not run across the network and no
AdminServer is installed during a Messenger-only install, you cannot use the WSCONFIG utility
to check a Messenger-only install. Table A2 shows the WSCONFIG utilitys syntax.
Table A2:
WSCONFIG syntax
Operating
system
UNIX
Windows
Syntax
wsconfig
[
[
[
[
[
-name component-name ]
-propfile path-to-properties-file ]
]
]
-messenger
-validate
]
|
-help
]
Parameters
-name component-name
Displays one or all of the Messengers for you to view. If -name refers to a Messenger and
the -messenger parameter is used, then information appears for that one Messenger. If
-name does not refer to a Messenger and the -messenger parameter is used, then
information appears for all the Messengers. The Messenger names in Windows are CGIIP,
WSISA, WSNSA, and WSASP. The Messenger names on UNIX are CGIIP and WSNSA.
A3
Checks the syntax and values of property settings defined in the specified properties file.
-help
A4
Command
wsconfig -messenger
WTBMAN utility
WTBMAN utility
Use the WTBMAN utility to control the operation of a configured WebSpeed Transaction Server.
The utility allows you to start a Transaction Server, query its status, start and stop additional
WebSpeed Agents, trim by a certain number of agents, and shut down the Transaction Server.
Table A4 shows the WTBMAN utilitys syntax.
Table A4:
WTBMAN syntax
Operating
system
Syntax
wtbman
-name transaction-server-name
{
|
|
|
|
|
}
-kill
-start
-stop
-query
-addagents number-to-start
-trimagents number-to-trim
[
|
]
[
-port port-number ]
}
UNIX
Windows
-help
Parameters
-name transaction-server-name
Stops and removes the Transaction Server from memory, no matter what it is doing.
-start
A5
Specifies the name of the machine where the AdminServer is running. If a host name is
not specified, it defaults to the local host name.
-user user-name
Specifies a user name and prompts for a password when logging into a remote machine.
A user name and password are required only when you use the -host parameter and
specify a remote host name. If you specify a remote host name with the -host parameter
but do not specify a user name with the -user parameter, you receive a prompt for a user
name and password.
When you specify a user name with the -user parameter, Windows supports three
different formats:
A user name as a simple text string, such as mary, implies a local user whose user
account is defined on the local server, which is the same machine that runs the
AdminServer.
A user name as an explicit local user name, in which the user account is defined on
the same machine that runs the AdminServer except the user name explicitly
references the local machine domain, for example .\mary.
Domain\User,
-port port-number
Specifies the port number of the machine on which the AdminServer controlling the
WebSpeed Transaction Server is running. If a port number is not specified, it defaults to
20931.
-help
A6
WTBMAN utility
Examples
Table A5 shows several examples that use the wtbman command. Assume that the Transaction
Server name is wsbroker1; the user name is tom; and the AdminServer is on the remote host
finance at port 9999.
Table A5:
Command
A7
A8
Index
Symbols
documentation 36
main window 34
object palette 32
specifying a broker 35
specifying a browser 34
starting 34
templates 33
wizards 33
&DISPLAY 317
&OUT 317
&OUT-FMT 317
&OUT-LONG 317
&WEBSTREAM 317
A
Accessing
IP Packet Filter settings 437
Web server 439
WebSpeed agent 441
WebSpeed broker 440
AdminServer
defined
WebSpeed in Windows 27
Advanced 28
Agent
defined 13
starting dynamically 220
trimming running 220
Application files
appropriate directories 214
Application Manager WebTool 310
Architecture
WebSpeed 17
B
Blank Template 33
broker
defined 13
setting up 419
browse.html 318
Browser (HTTP) response times 443
CGI Messenger
executable 222
CGI Wrapper
template 33
CGIIP executable name
hiding 421
Index
Changing
agent parameters to reference web-disp.p
429
script directory names 421
Code Section Editor 33
Compiling Web objects 216
Configurations
Messenger-only installs 221
overview 22
restarting 42
Configuring
ubroker.properties file for firewall 434
F
File Tools 310
Firewalls
configuration 433 to 436
configuring ubroker.properties for 434
debugging 436 to 441
with DMZ 431
Frameset Template 33
frameset.html 318
Control handlers
defined 316
GENUUID utility 29
Data integrity
restarting configurations 42
hmapmain.i 319
Database
locking r-code 427
servers 34
Databases WebTool 311
DBAUTHKEY 427
Debugging
firewall configurations 436 to 441
Host name
setting 436
HTML files
deploying 215
HTML Mapping
wizard 32
html-map.w 319
HTTP/S performance 443
Development modes 36
include.i 318
DMZ 431
inet_ns 435
Index2
is 13
ISAPI Messenger
executable 222
J
Java class files
deploying 215
Index
Network traffic
securing 419
Load balancing
NameServer 211
M
Main Template 33
main.html 318
Messages WebTool 311
Messenger
debugging 439
defined 14
downloading executables 222
executable location in Windows 222
managing 225
Messenger-only deployment 14
operating system compatibility 222
overview 221
performance 444
script file location 224
Method directory 318
Method procedures
defined 316
Microsoft IIS 24, 422
Messenger executable 222
Multi-homed servers 445 to 446
Multiple IP address servers, see
Multi-homed servers
Multiple Web servers 444
Nonvisual objects 32
NSAPI Messenger
executable 222
NSAPI-type Web server
obj.conf file 223
NSMAN -name NS1 -query 440
n-tier deployment
Messenger-only installs 221
O
obj.conf file
modifying 223
sample 224
Object palette 32
Object State WebTool 312
objects directory 318
Offsets
deploying 215
OS Command WebTool 311
P
Parameters
passing 430
Passing unique identifiers 430
Performance
browser response times 443
HTTP/S 443
multiple Web servers 444
WebSpeed Messengers 444
priorityWeight property 211
NameServer
checking access using NSMAN -name
NS1 -query 440
defined 14
linking with other NameServers 48
load balancing 211
"No NameServer" configuration 212
predefined instance 210
validating configurations 210
Netscape
Messenger executable 222
PRO*Tools
defined 13
procedur.p 318
PROPATH
minimizing 430
PROPATH environment variable 214,
216
Index3
Index
ProPath WebTool 312
Property file
overview 27
R
Register with NameServer setting 446
Remote development mode 36
Starting configurations
deployment network with separate Web
server 412
development network with central
machine 44
multiple LAN development environment
48
shared development/deployment network
414
single-machine 43
Report Template 33
Static files
location 23
Report Wizard 32
S
Sample applications
running 447
Script directory names
changing 421
script.html 318
Scripting Lab WebTool 311
T
Table template 33
table.html 318
tagmap.dat file
defined 316
deploying 215
Security
application 418
changing script directory names 421
Firewalls 431 to 432
hiding CGIP executable name 421
locking r-code to the database 427
Microsoft IIS 422
modifying web-disp.p 427 to 429
network traffic 419
passing parameters 430
PROPATH 430
Web server 420
WebSpeed 418 to 432
WebSpeed agent production setting 427
WebSpeed application 427 to 430
WebSpeed Messenger Administration
tool 423
WebSpeed server 424 to 426
Setting
host name 436
minimum and maximum agents 443
Source files 318
Tools
PRO*Tools 13
WebTools 13
Transaction broker
default directory
creating 214
U
ubroker.properties file 434, 440
configuring for firewall 434
editing 28
hierarchy 28
location 28
modifying for firewall 434
overview 27
unique values needed 29
validating edits 210
WebSpeed Messenger logging 439
UNIX
Web server security 422
Index4
Index
URLs
WebSpeed broker 35
uuid
in ubroker.properties 29
V
virtual directories
Apache Web server 24
Microsoft IIS 24
Virtual System Tables WebTool 312
Visual objects 32
W
Web objects
compiling 216
deploying 214
making secure 418
Web server
Apache 24
checking response 421
configuring 23
hiding type and version 421
Microsoft IIS 24
multiple 444
securing 420
testing 25
UNIX 422
web.output
defined 316
web-disp.p 427
defined 316
WebSpeed Workshop
components 13
WebSpeed
application security 427 to 430
architecture 17
broker 35
changing script directory names 421
components 14
configuration in Windows 22
deployment architecture 12
examples directory 318
firewalls 431 to 432
hiding CGIIP executable name 421
method directory 318
Microsoft IIS 422
minimizing PROPATH 430
modifying web-disp.p 427 to 429
WebTools
defined 13
web.cst 318
web.input
defined 316
Weight factors
arbitrary 212
fail-over 212
load balancing 211
percentage-based 211
setting to zero 212
Wizards 33
templates 319
Working application directory
creating 214
Index5
Index
Working directory
environment variable 216
WSCONFIG utility A3
described 210
wrap-cgi.w 319
WSMAdmin page
URL 225
WSASP Messenger
executable 222
Index6
WTBMAN utility A5