DEV-14: Understanding and Programming for the AppServer™

DEV-14: Understanding and Programming for the AppServer™
Pat Bonser DEV-14: Understanding and Programming for the AppServer™ Pat Bonser Product Readiness Since the AppServer was first introduced (1996) we have continued to enhance the product and its capabilities…. But what is an AppServer used for? How does it work? How to program it? Think of it as the engine of the business application The OpenEdge AppServer is Foundation for our distributed computing strategy The framework for developing and deploying 4GL procedures as distributed application components Business logic encapsulated into components that can be deployed across the enterprise RPC for the 4GL With OpenEdge10.0A we introduced some changes in terminology: AppServer Agent is the correct terminology for what was previously known as App Server process and Application Server process, these terms are frequently used in this presentation, and are synonymous.

Understanding and Programming for the AppServer
Pat Bonser Understanding and Programming for the AppServer Agenda Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests AppServer Agent is the correct terminology for what was previously known as App Server Process and Application Server Process, and are synonymous. In this session we’ll take a look at the architecture & individual components And then how to use it – connecting and running remote procedures. We’ll then look at the different session models and available operating modes - The most fundamental decision to make when designing and programming an AppServer application is what session model it will use, session-free or session-managed. This decision determines your choice of AppServer operating mode and the available features of the Progress 4GL, some of which support particular operating modes. The decision of which session model to use depends on your particular application requirements, which cover all areas of the application, including network capabilities, available AppServer resources, and critical application functions. DEV-14 Understanding & Programming for the AppServer

Understanding and Programming for the AppServer Pat Bonser
Architecture Clients Data RUN VALIDATE-ORDER VALIDATE ORDER return result RUN CHECK-CREDIT CHECK CREDIT return result Distributed application computing is an architectural approach to designing application software that runs across a network. It maximizes your processing capabilities by allowing you to distribute portions of your business application throughout your enterprise. By emphasizing a flexible, modular use of computer resources, your enterprise can potentially gain greater performance returns, realize the benefits of customized deployment strategies, and provide a security model to ensure the integrity of your application data. Two important aspects of distributed application computing are Application partitioning and the n-tier model. The OpenEdge AppServer provides features and functionality that allow you to take full advantage of both. 1. Application partitioning is the process of segmenting application logic from the user interface and data, with the option of running across multiple computers on a local or wide area network. Depending on your network configuration and performance goals, you can partition your application logic among many available resources on your network. However, application partitioning is more than a style of computing to enhance your overall application performance and deployment options; it is a catalyst for examining current methods of running applications to determine maximum performance, deployment, and security objectives through application distribution. 2. The n-tier model is a computing model that supports flexible network structuring so that you can distribute application logic and the processing load among many machines across your distributed network. Because the n-tier model can support an unlimited number of clients, partitioning and deploying your application in this manner allows you to break up monolithic applications and flexibly reconfigure them to run in a network environment that better supports your computing needs. The n-tier model supports the logical separation of user interface, application logic, and data access across three or more machines. Because of this flexibility, application partitioning is closely tied to two basic deployment approaches in a distributed environment: the logical three-tier model and the physical n-tier model. RUN UPDATE-INVENTORY UPDATE INVENTORY return result DEV-14 Understanding & Programming for the AppServer

Architecture Any client OpenEdge™ Application Server GUI Application Code AppServer Character Data Data 4GL Before Version 9, the client types supported were the 4GL (character and graphical) and HTML via WebSpeed with embedded SpeedScript (an extension of the 4GL for HTML development). Applications were coded in a manner that were “hard wired” to the physical application broker they were connecting to. This meant that any architectural changes at the end user site would ultimately affect the application itself. Along with architectural changes to the AppServer, Version 9.0 (12/98) also saw the introduction of our Open Client technology, allowing Java and ActiveX clients access to the 4GL business logic through proxies, generated by the Open Client Toolkit. With Version 9.1B (9/00), we brought to market innovative technology that allows any Progress client, that being character or graphical, the ability to communicate to the Progress AppServer over the Internet using HTTP instead of the traditional method of TCP used in in LANs and WANs. HTTP Tunneling support was added to the Open Clients in 9.1D. OpenEdge WebClient enables customers to deploy 4GL GUI via a thin client, providing high performance, a rich user interface and a robust, scalable architecture. The Internet- or ASP-enabled application will retain all of its functionality, yet require little bandwidth, and a much smaller footprint, to operate. Please note that while you can launch WebClient from a browser, it does not run in the browser and is a true thin, Progress Windows 32 bit Client. WebClient is suitable for many deployments – LAN, WAN, Intranet & Internet With OpenEdge 10 we added: The ability for Microsoft .NET applications to work with OpenEdge applications Web Service Client applications to work with OpenEdge applications Also in OE10 we introduced the session-free model, which allows you to develop a session-free application. Web Service Client DEV-14 Understanding & Programming for the AppServer

Architecture Any client OpenEdge™ Application Server Web Browser WebSpeed Transaction Server GUI Speed Script Application Code AppServer Character Data Data 4GL The WebSpeed Transaction Server is a separate application server that handles html requests and renders the results back to a browser. A WSTS agent can be a client to the AppServer and vice versa, sharing 4GL application logic. With OpenEdge the packaging has been simplified, there are now 2 application server licenses: OpenEdge Application Server Basic Edition Application server for all types of clients including Progress 4GL (Client Networking and WebClient), HTML Web based applications, and Open Clients (Java and .NET) and outbound Web services). Enables the execution of 4GL-based remote procedures that are stored on a server and called by Progress 4GL, Java, and .NET client applications. Includes networking for connecting to remote OpenEdge RDBMS servers, other OpenEdge Application Servers, or OpenEdge DataServers. Also includes Adapter for SonicMQ, AppServer Internet Adapter, and WebSpeed Transaction Server. The Basic Edition is the entry level OpenEdge Application Server for small to mid-sized deployments that require AppServer or WebSpeed functionality without the requirement for Load Balancing, full Web services, or Sonic ESB support. OpenEdge Application Server Enterprise Edition Also includes OpenEdge Adapter for Sonic ESB, Secure AppServer Internet Adapter, and Web services Tools. The Enterprise Edition is for mid-sized to large deployments of mission critical, transaction intensive applications. NameServer Load Balancer is an optional product for the Application Server Enterprise Edition, providing location transparency and load balancing by directing client requests to available servers. Web Service Client DEV-14 Understanding & Programming for the AppServer

Components AppServer Architecture AppServer Application Server Processes Clients Application Broker Data NameServer 4GL Business Logic Data So what are the components to an AppServer environment? The basic building blocks of a Progress distributed computing environment consist of the Clients, Application Brokers, Application Servers and NameServers. Application Broker -The process that manages client connections. Application Server Process - A process running on an AppServer that executes 4GL procedures in response to remote procedure requests. An AppServer can have any number of Application Server processes to service remote procedure requests from any number of client applications. NameServer - A process that accepts a client request for connection to an AppServer and directs that request to the appropriate AppServer instance. An AppServer instance is one Application Broker and the pool of Application Server processes that it manages. An AppServer instance has a specified configuration and makes a well-defined set of 4GL procedures available for execution by client applications. An AppServer installation is the Progress AppServer product environment installed on a particular machine. Depending on your licensing and resources, you can configure and run multiple AppServer instances using a single AppServer installation. Note that the client can be one of many types including 4GL, Java, .NET, Web services, and WebSpeed Agents. Version 9 AppServer saw the addition of the NameServer, providing, location transparency and load balancing. All requests, can be directed through the NameServer which in turn will connect the client to the appropriate backend process. For configurations that do not need NameServer, the “direct connect” parameter was added in 9.1D to allow clients to connect directly to the AppServer, detailed later in the presentation. AppServer Internet Adapter - AIA & AIA/S Clients - OpenEdge Clients: GUI, Char, WebClient, WebSpeed Agents Open Clients: Java, .NET, Web service Clients DEV-14 Understanding & Programming for the AppServer

Components Application Server Process Executes OpenEdge 4GL procedures Application Server processes are reused Determined by AppServer operating mode Application Broker AppServer NameServer 4GL Business Logic Application Server Processes A process that executes remote procedure requests in the context of an OpenEdge session. Much like a batch 4GL client, almost any 4GL statement that you can execute in an interactive 4GL client you can execute within an Application Server process. An AppServer instance typically contains multiple Application Server processes that start up when you start the AppServer. An Application Server process can also act as a 4GL client to another AppServer instance, by making its own remote procedure calls. DEV-14 Understanding & Programming for the AppServer

Components Application Broker Typically started at system startup-time Manages pools of re-usable application server processes Manages client requests for 4GL procedure execution Application Broker AppServer NameServer 4GL Business Logic A process that creates, manages, and allocates Application Server processes for access by client applications. The Application Broker manages client connection requests and dispatches requests to Application Server processes. Exactly how it does this depends on the AppServer operating mode. From this point on when you see the AppServer it is referring to the Application Broker & the Application Server processes it spawns… DEV-14 Understanding & Programming for the AppServer

Components NameServer Location transparency Inventory Machine A Load balancing 70% 30% Inventory (A and B) Inventory Machine B Clients NameServer The NameServer, introduced in Version 9.0 provides 2 key functions for the AppServer: 1. Location Transparency AppServer registers with NameServer the Application Service(s) it supports Application Service – logical name, e.g.:Inventory, Parts, Account, com.progress.orders Client requests an Application Service rather than a connection to a specific AppServer 2. Load Balancing Multiple AppServers can register to support the same Application Service Connection requests can be balanced across AppServers Weight factor determines distribution A “hot stand-by” using a weight factor of 0 Location Transparency – the developer codes to a logical application service (e.g. Inventory) and the NameServer determines at execution time which physical broker is capable of servicing that request. This enables greater deployment flexibility at the site where machines can be added/removed, brokers can be added/removed, servers can be added to the configuration or even replaced, without affecting the application logic itself. Load balancing Session managed Done by NameServer during initial connection Once connected, services all requests Session-free Done for each remote procedure execution Load balancing – the NameServer allows the configuration of multiple physical broker processes that are capable of executing the same type of business logic (e.g. Inventory) and will balance the load between these brokers based on weighting factors specified, e.g. an environment can be setup where perhaps you may have a high powered Unix server servicing 70% of the connection requests and an NT server handling the remaining 30%. You can also use this for a hot standby, by setting the weighting to 100% & 0%, the machine with 0% will take the processing only when the 100% server is unavailable. Communication with NameServer is with UDP notes cont on next slide Payroll Payroll (C) Machine C DEV-14 Understanding & Programming for the AppServer

Pat Bonser Understanding and Programming for the AppServer Agenda Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests Session managed load balancing If your application is session-managed, load balancing occurs at the time the client connects to the application service. That is, the NameServer distributes the load by connecting the client to an AppServer according to the configured proportion and all requests from that client go to the connected AppServer. Session-free load balancing If your application is Session-free, load balancing occurs both at the time of the initial logical connection and for every remote request invoked on that logical connection: 1. When it first connects to an application service, the client asks the NameServer what AppServer broker it should connect to as many times as there are initial connections specified for the binding and creates a physical connection to each broker as the NameServer specifies. The NameServer specifies the brokers for the initial connection request based on the load-balancing settings for the application service. The result of this physical connection process is the connection pool where the number of connections are distributed across the available AppServers approximately according to the configured load-balancing formula. 2. When it invokes a remote procedure request to a connected Session-free application service, the client asks the NameServer what broker to use for the remote request. The NameServer returns the broker to use according to the configured load-balancing formula. If the client already has a physical connection available to the broker the NameServer specifies, the client uses that connection to run the request. If the client has no available connection to that broker, the client creates another connection to execute the request, up to the maximum number of physical connections specified for the binding. If creating a connection will exceed this connection maximum, the request is queued for the next available connection on any AppServer broker in the connection pool. If creating such a connection fails (because the broker is unavailable), OpenEdge raises a run-time error on that request. So, for a Session-free application service, load balancing is determined with finer granularity than for a session managed application service. DEV-14 Understanding & Programming for the AppServer

Accessing the AppServer
Understanding and Programming for the AppServer Pat Bonser Accessing the AppServer Create server handle CREATE SERVER hdl. Connect to AppServer Ret = hdl:CONNECT(“-S H pisces -AppService Account”). Run procedures RUN AccountBL.p ON SERVER hdl (INPUT account-number). There are basically 5 steps to follow when accessing an AppServer. 1. Create a server handle. 2. Connect to the AppServer 3. Run remote procedure(s). 4. Disconnect from the AppServer. 5. Delete to server handle to free up resources. DEFINE VARIABLE hdl AS HANDLE. DEFINE VARIABLE ret AS LOGICAL. DEFINE VARIABLE account-number AS INTEGER. CREATE SERVER hdl. ret = hdl:CONNECT (“-H gemini -S AppService Inventory”). RUN AccountInfo.p ON SERVER hdl (INPUT account-number). ret = hdl:DISCONNECT(). DELETE OBJECT hdl. The CONNECT( ) method takes up to four character string arguments in the following order, all of which are optional, depending on the configuration of your AppServer environment: 1. connection-parameters 2. userid 3. password 4. appserver-info You use the connection-parameters argument to locate and configure the connection to one or more AppServer instances that support the required business function (application service). The userid, password, and appserver-info arguments apply only to session-managed configurations and are passed from the client application to the AppServer, which passes them to the Connect procedure (if defined). If a Connect procedure is not defined for the connected AppServer, these arguments are discarded. The requirement to specify these arguments depends entirely on the application service defined for the connected AppServer. An AppServer can reject a connection request if: • The Connect procedure failed. • There are not enough system resources (for example, AppServer agents) available to service the connection. • The specified session model for the connection is incorrect (sessionModel and Operating mode between client and server must match, e.g. AppServer must be configured to use state-free mode in order for a 4GL client to connect using the connection parameter –sessionModel Session-free Disconnect ret = hdl:DISCONNECT(). Delete server handle DELETE OBJECT hdl. DEV-14 Understanding & Programming for the AppServer

Connecting to the AppServer
Understanding and Programming for the AppServer Pat Bonser Connecting to the AppServer How does it work? Host=gemini Port=5162 NameServer AS=Inventory Host=zeus Port=3097 AS=Inventory Client Host=zeus Port=3097 Host=zeus Port=3097 AppServer AS=Inventory Host=zeus Port=3097 Here we have the NameServer on gemini and the AppServer on zeus. When the AppServer comes up it registers itself with the NameServer, using the Application Service that has been configured, e.g. inventory, and sends the registration message to the NameServer, specifying what AppService it supports and its location (Host & Port). This is stored on the NameServer. The client makes a request to the NameServer, using the connect method, looking for an AppServer process that supports inventory, the NameServer sends back the location and the client connects to the AppServer. Notes continued from previous slide: Connection parameters argument The connection-parameters argument specifies a comma-separated list of parameters necessary to establish the AppServer connection. These parameters include two types: • A basic set used to connect to an AppServer instance or application service, regardless of the session model. • A set for specifying and managing the session model of the connection. The connect method also supports the URL syntax, with the –URL parameter. The –URL parameter, containing HTTP or HTTPS indicates that HTTP Tunneling should be used to connect to the AppServer. The URL syntax can also be used for “standard” appserver connections, ie appserver and appserverdc .. Connect hdl:CONNECT(“-H gemini -S AppService Inventory”) DEV-14 Understanding & Programming for the AppServer

Running AppServer Procedures
Understanding and Programming for the AppServer Pat Bonser Running AppServer Procedures AppServer Host=zeus Port=3097 Host=gemini Port=5162 AS=Inventory Client Connect NameServer RUN “proc a” on SERVER hdl Run proc a The client is now connected and can execute 4gl procedures using that connection. When looking at any deployment configuration, and particularly in a distributed environment, you need to consider scalability and availability, to ensure maximum processing availability for clients… You need to think of both the AppServer and NameServer in this respect. AppServer – what happens if the client connections are too many, is the server capable of the load, what if it crashes? Similarly on the NameServer – even if the AppServer is capable of the load – what happens if the NameServer goes down - the clients can’t connect and have no access to the distributed application. You need to consider fault tolerance, i.e. have no single point of failure. DEV-14 Understanding & Programming for the AppServer

Pat Bonser Understanding and Programming for the AppServer Agenda Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests The AppServer also allows you to configure and program it for different modes of operation. The supported operating modes provide different mixes of resource consumption and performance characteristics. Thus, one or another operating mode might better meet your overall performance requirements, depending on the application. Choosing an operating mode is a key part of the application design, and will affect how you write the code and how the application will run. Are AppServer requests independent of each other or do they expect to use context from one call to another? Operating Mode is specified when an AppServer is configured, “mix & match to meet requirements” and will determine how client requests are dispatched to individual Application Server processes. This is a design time consideration and will have significant impact on the design and performance of your application. Planning for context management and performance of the application will significantly impact how you develop your application code. There are 3 session-managed operating modes and one for the session-free model. DEV-14 Understanding & Programming for the AppServer

AppServer Operating Mode
Understanding and Programming for the AppServer Pat Bonser AppServer Operating Mode Specified when AppServer is configured Determines how client requests dispatched to individual Application Server processes Design time considerations Design & development of application Application context Performance Goals System resources, network response Request throughput and response time The supported operating modes provide different mixes of resource consumption and performance characteristics. Thus, one or another operating mode might better meet your overall performance requirements, depending on the application. Note that and application CAN utilize multiple operating modes as required in the same session. Use stateless or state-free mode when individual client calls are not related and minimal information needs to be saved in between client requests or when you need scalability without loss of performance, or when you have many clients and limited hardware. With stateless, Progress provides features for you to save context between requests, but you must program these yourself. Programming issues Stateless and state-free processing works well when each individual request to the AppServer can be processed separately, or with minimal context to maintain between requests. And when you do not have persistent procedures that need to be executed remotely. In some cases, it might be significantly more complex to program your AppServer application with one operating mode rather than another. In many cases there might be more than one operating mode and design strategy that is appropriate. Stateless, state-free For the most part, using stateless or state-free makes sense when you need high throughput with minimal computing resources. Even with minimum context to maintain, if plenty of computing resources are available there is no inherent advantage in using stateless; using state-aware (or state-reset) might provide a simpler programming model. State-less mode allows fewer processes to service many different client requests by not maintaining a one-to-one connection between the client and AppServer; state-free mode extends this and allows parallel execution of processes across multiple AppServers. This is where maximum scalability with the fewest resources can be achieved. With stateless, the connection is maintained at the broker and the next request made from the client, may result in a different AppServer process executing the request; with state-free a pool of connections is maintained at the client. DEV-14 Understanding & Programming for the AppServer

Session Models & Operating Modes
Understanding and Programming for the AppServer Pat Bonser Session Models & Operating Modes Connection management Session managed model State-reset State-aware Stateless Session-free model State-free The AppServer operating model is a client setting (session managed or Session-free) : Session managed – a connection based model Session-free – non connection based (Web service clients & 4GL clients) The operating mode (state-reset, state-aware, stateless, state-free) is a mode configured for the OpenEdge AppServer, determined at startup time by the way you configure the AppServer. Once the AppServer is started, it spawns Application Server processes and manages connections and the pool of servers based on the operating mode. Operating mode determines: – Whether an Application Server process is dedicated to a single client once the client connects – How long context is maintained. When the client issues multiple requests to run procedures on the server, one of two things can happen: . Each request can be handled separately by a different Application Server process or . All the requests can go to the same Application Server process. • Session managed — Where a single AppServer handles all requests from a single client to a single application service, and the client manages a physical connection to the AppServer. The client sends its requests and receives the responses over a persistent connection to a single AppServer that supports the connected client. Requests from the same client can only be handled sequentially (single-threaded) by the AppServer both as an application service and as a Web service. • Session-free — Where one or more AppServers can handle all requests from a single client to a single application service, and the client manages no physical connection to any single AppServer. Regardless of the operating mode, a client can invoke synchronous or asynchronous requests to the AppServer, which the client manages depending on the session model. The client sends its requests and receives its responses from one or more AppServers that maintain no connections with their clients. All requests from any and all of its clients are managed in parallel (multi-threaded) whether the requests are for an application service or a Web service. For direct clients of Session-free AppServers (application services), the request management function resides in the client session. For clients of Progress 4GL Web services, the AppServer request management resides in the Web Services Adapter. The only AppServer operating mode that supports Session-free applications is the state-free operating mode. SESSION:SERVER-OPERATING-MODE attribute obtains the current mode. This is a CHARACTER parameter that returns the name of the operating mode as a string: "STATE-RESET", "STATE-AWARE“, "STATELESS“, "STATE-FREE" DEV-14 Understanding & Programming for the AppServer

Operating Modes Session Managed Model State-reset One client per Application Server process Session state is reset on disconnect State-aware Session state is maintained across connections Stateless Connection managed by AppServer Broker Many clients per application server process Context must be managed externally Lets take a look at the different operating modes available to the developer and the impact of each on development effort and resource utilization. In Version 8, there was one operating mode for the AppServer, state-reset, and is the default mode for later versions, for backward compatibility. Prior to Version 9, when the client disconnected, we would destroy that process and start up another. In later versions, we simply reset the context of the process without having to destroy it. The next client that gets it will receive a clean fresh process, without the delay for starting up the process. With state-reset there is a one-to-one relationship between a client and a state-Reset AppServer. The broker receives the connection request from the NameServer and a direct connection is created between the client and AppServer process. The connection is kept until the client disconnects. State-aware functions the same way as a state-reset AppServer with respect to one-to-one direct connections between the client and the AppServer, however the big difference is how context is maintained and managed. When a client disconnects from a this type of process, all context is retained and available to the next client. The developer can use this type of AppServer process to preload variables, temp-tables, persistent procedures that will be needed, and then not have to reload these each time a client connects. However, any context that is specific to a client (i.e.. variables, totals, calculations, etc) may have to be cleaned up by the developer. Running the AppServer in state-less mode allows for fewer processes to service many different client requests, by not maintaining a one-to-one connection between the client and AppServer, however this means a client may get a different AppServer process on the next request, the AppServer will not know who you are or what you were doing in your last request. So you’ll need to “re-establish context/state” if needed for that AppServer. There are AppServer configuration procedures that provide entry points for the developer to manage context, these are covered later in this session. DEV-14 Understanding & Programming for the AppServer

Operating Modes state-aware & state-reset
Understanding and Programming for the AppServer Pat Bonser Operating Modes state-aware & state-reset Session Managed Model AppServer Client 1 Application Server Processes Client 2 Data Application Broker 4GL NameServer Data Client 3 Key point here is to understand how the connection is managed. Care this slide has many builds (each client is mouse build, all others are automatic, during the builds, Client 1 disconnects, allowing Client 4 to reuse that AppServer process!) to show that state-aware and state-reset are treated the same during the connection, that is the AppServer process is dedicated to the client. On disconnect, the operating mode determines what happens to the context – state-aware it is maintained, where as in state-reset the server is “cleared out” state-aware—All requests sent by a client connected to this AppServer go to the same Application Server process. This Application Server process remains dedicated to the same client for the life of the connection. When the client disconnects, the Application Server process deletes any remote persistent procedures that are still active in its context. However, it maintains all other context created during the terminated client connection for access during future client connections. This context remains available until it is removed during a future client connection or the Application Server process terminates. One client per AppServer process Session is maintained across connections Can set context with startup procedure Can use disconnect procedure to reset context state-reset—All requests sent by a client connected to this AppServer go to the same Application Server process. This Application Server process remains dedicated to the same client for the life of the connection. When the client disconnects, the Application Server process resets its context to what it was at startup, removing all context created during the terminated client connection. Connection kept until disconnect Dedicated connection Session state reset on disconnect Throughput limited to number of server processes Client 4 DEV-14 Understanding & Programming for the AppServer

Operating Modes stateless
Understanding and Programming for the AppServer Pat Bonser Operating Modes stateless Session Managed Model AppServer Client 1 Application Server Processes Client 2 Data Application Broker 4GL NameServer Data Client 3 For all modes, if there are no AppServer processes available, and none configured to start when they are all used, the connection request will go to a message queue… when an AppServer process is freed, or started, the connection is directed to that process. Stateless: A connection to a stateless AppServer is really a connection to the broker process. The client remains connected to the broker for the life of the connection. Each client request is sent to the next available Application Server process which is not necessarily the same process as the one most recently accessed. Running the AppServer in Stateless mode allows few processes the ability to service many different client requests by not maintaining a one-to-one connection between the client and AppServer (unbound), however this means a client may get a different AppServer process on the next request, the AppServer will not know who you are or what you were doing in your last request. So you’ll need to “re-establish context” for that AppServer. Connection managed by AppServer Broker Many clients per application server process Context must be managed externally Establish/reset context with activate/deactivate procedures; complex to program if context required is complex. Maximum throughput under heavy client load where resources are limited and requests are short assuming minimal bound connections and connection context is small. Unlike state-reset or state-aware, an AppServer running in stateless operating mode does not dedicate any AppServer agent to a client connection. Instead, all AppServer agents remain generally available to execute remote procedure and user-defined function requests from all connected client applications. A connection in the unbound state can transition to the bound state in two ways: • A client application instantiates a remote persistent procedure in the context of the connection. The AppServer agent that handles the remote persistent procedure request thus becomes bound to the connection. • The AppServer agent runs a procedure that sets the SERVER-CONNECTION-BOUND-REQUEST attribute on the SESSION handle to TRUE. The AppServer agent that sets this attributes thus becomes bound in the connection. Message Queue Client 4 DEV-14 Understanding & Programming for the AppServer

Operating Modes Session-free Model State-free No connection maintained between client and AppServer process Pooled connections 4GL requests on the server handle Web service requests on the WSA Requests dispatched similar to stateless except Multiple requests from one client run in parallel Each request runs independently Context must be managed externally The session-free model was added in 9.1D05, originally to support web service client, introduced in the Technology Preview. With OpenEdge10.0A this model has been extended for all OpenEdge 4GL clients. Session-free model tends to scale more effectively, and can be simpler to program, but this is very much application dependent! The overhead of a session-managed model is not needed if a request to the AppServer is not connection oriented, this is the case when one request doesn’t depend on the outcome of other requests. To support session-free we need to be able to dispatch the requests but maintain no connections. If required, context needs to be maintained by the application, independently. For session-free 4GL clients, connections are pooled on the client, each server handle connected to an AppServer actually represents a pool of connections. For Web service clients, the WSA will pool the connections– similar to how the broker manages stateless requests today….you can set properties on the WSA to manage the pool – i.e. max/min etc…. There is a pool of threads, with connections managed by the JSE, to reduce overhead on the connection requests. It is recommended that you do not use ProcObjects or SubAppObjects as these use persistence, and therefore need context. Session-free doesn’t stop you using these features, however, if you do you’re going back to a session-managed approach (and the overhead of maintaining context). In order to execute multiple state-free remote procedures concurrently, the 4GL client program logically associates each application service with a pool of reusable socket connections to the AppServers that provide the service. Each application service is represented by the AppServer handle. You must specify session-free to connect a 4GL client to a state-free AppServer. The client must handle context management. Different tools, provide different support for this. For example .Net provides significant management ‘under the covers’, whereas, Java requires the developer to handle this themselves. Progress provides helper classes for Java to assist this process. DEV-14 Understanding & Programming for the AppServer

Operating Modes state-free
Understanding and Programming for the AppServer Pat Bonser Operating Modes state-free Session-free Model 4GL Clients AppServer NameServer Client 1 Application Server Processes Open Clients Client 2 Data Application Broker 4GL Web Service Client Data The state-free mode allows for requests to be made over any available AppServer connection (provided it supports the service requested). For cases where session-managed connectivity is not needed, the use of Session-free model can provide increased efficiency and provide better performance. Requests are not tied to one AppServer connection, so they can run in parallel and take advantage of any available AppServer that supports the service. To support the Session-free model we need to be able to dispatch the requests but maintain no connections For Web service clients the WSA will pool the connections, similar to how the broker manages stateless requests …. For 4GL clients, the connections are pooled on the client, each server handle connected to an AppServer actually represents a pool of connections. This pool obviously isn't shared in the same way that the WSA shares connections. In 10.0B Open Clients (Java and .NET) are able to use the session-free model, each AppObject will have a pool of connections The Session-free model allows you to optimize the use of AppServer and increases the flexibility of AppServer resources. Connects to OpenEdge AppServer configured for state-free mode Client application sends requests and receives responses over any available connection on the server handle Requests are handled in parallel Support for Session-free 4GL client connections to AppServer new in OpenEdge 10 The session-free model allows you to optimize the use of AppServer and increases the flexibility of AppServer resources. To support the session-free model we need to be able to dispatch the requests but maintain no connections. The state-free operating mode allows for requests to be made over any available AppServer connection (provided it supports the service requested). For cases where session managed connectivity is not needed, the use of the session free model can provide increased efficiency and better performance. Requests are not tied to one AppServer connection, so they can run in parallel and take advantage of any available AppServer that supports the service. Client 3 Web Services Adapter DEV-14 Understanding & Programming for the AppServer

CONNECT() Session-free connection Pool of re-usable socket connections AppServer handle points to pool Managed transparently by 4GL client Connections allocated as needed Tunable using CONNECT() properties CONNECT() -directconnect – is specified, -H and –S are taken as n/w address and tcp/ip port of an AppServer. Otherwise taken as UDP address of the NameServer -sessionModel sessionModel (Session managed, Session-free) For a Session-free connection, the client maintains a pool of re-usable socket connections; the AppServer handle points to the pool, which is managed transparently by the 4GL client. Connections are allocated as needed. Connections are tunable using CONNECT() properties Parameter Session Model/Default -sessionModel Session managed & Session-free -connectionLifetime nSeconds Session-free -initialConnections nConnections Session-free -maxConnections nConnections Session-free -nsClientMaxPort portNum S Session managed & Session-free -nsClientMinPort portNum Session managed & Session-free -nsClientPicklistExpiration nSeconds Session-free -nsClientPicklistSize nPicks Session-free -nsClientPortRetry nRetries Session managed & Session-free -nsClientDelay nMilliSeconds Session managed & Session-free For more details please refer to documentation: OpenEdge Application Server: Developing AppServer Applications DEV-14 Understanding & Programming for the AppServer

Session-free Some applications not inherently connection oriented Requests executed regardless of other requests i.e. web page request for information Efficiency and Performance Parallel execution on any AppServer Efficient use of resources Performance gains Scalability The Session-free model is specifically designed for application services or Web services that return a complete result, starting and ending any transactions, in a single request. Thus, the AppServer maintains no context for any client that it services. Requests from a Session-free client are handled by any available AppServer (and AppServer agent) that supports the required application service. The Session-free client (or the Web Services Adapter on behalf of Web service clients) manages a pool of physical AppServer connections (the connection pool) that provides access to the Session-free AppServers available to service client requests. Thus, a Session-free AppServer executes requests from all clients as it receives them, and completes each request independently of any prior request. In this session model, all requests from a client are multi-threaded, meaning that multiple requests from a single client can be executed in parallel, as AppServer resources permit. The more AppServers (and AppServer agents) that are available (through a NameServer) to handle requests for a given application service (or Web service), the more requests that the application or Web service can handle simultaneously from a single client. Each Session-free AppServer executes requests as fast as communications and AppServer agent resources permit. Thus, the same client can have multiple requests executed by an AppServer at one time, and each AppServer can execute requests fro m any numb er of clients at one time, both limited by the number and extent of AppServer agents configured for each AppServer. (The session-managed model is specifically designed for application services or Web services that support a single transaction across multiple requests from the same client, returning intermediate results with each request until the transaction is completed. Thus, the AppServer maintains context between requests for each client that it services, and each such client participates in a persistent connection to the Appserver. The connected AppServer is dedicated to serving that one client until the connection between them is terminated. In this session model, all client requests are single-threaded, meaning that the AppServer does not handle another request from the same client until it has completed and responded to any pending request from that client.) When to use state-free mode Use state-free mode when the requests from your application clients are independent of each other, which means requests are executed without regard for the outcomes of other requests. An example is when a web page requests information. The request is sent to the AppServer, the information retrieved and delivered to the client, and the request is completed. There are no dependencies on previous or subsequent requests. Parallel request execution Since state-free mode uses a pool of connections instead of dedicated connections, then a client can make multiple requests that execute simultaneously on different AppServer agents and even different AppServers. For this to work the client application must be designed so that the requests are independent from each other and the order of completion does not matter. Executing unrelated requests in parallel enables application developers to build applications that more fully utilize computing resources and improve performance compared with modes following the Session-Managed model where request execute serially. Example – Looking up customer information Suppose you have a large field sales force connecting intermittently from remote locations to retrieve customer information. State-free mode would work well for this type of data retrieval operation. The sales rep connects, requests data from a customer record, receives the information, and disconnects. There is no need to store any context. Also, the sales rep can request information for the next five customers. Each request can run concurrently, speeding the retrieval process, and minimizing the remote connection time. DEV-14 Understanding & Programming for the AppServer

Session-free Design considerations Procedures can execute concurrently Order of completion not predictable Persistent procedures Create a context Internal procedures execute On same AppServer Serially, losing parallel advantage Reduce scalability Design your application to account for how results are returned for each session model; for Session-free this means requests are returned in no predictable order. Every request (external procedure) runs independently of every other request on the AppServer. No request can create global or persistent data that any subsequent request can ever expect to find, because each request can execute on a different AppServer or AppServer agent. Avoid any completion dependencies. • You cannot specify a connect or disconnect procedure, and none is ever executed on the AppServer. • You can specify activate and deactivate procedures to execute before and after each request, but you cannot use them to maintain any contextual data that is not read and written to persistent storage (a database). Try not use persistent procedures of any kind, unless you cannot avoid it. Using any persistent procedures (or Web service ProcObjects) that are called and instantiated directly by the client forces a bound connection to the AppServer, which limits application performance and scalability. Persistent procedures also complicate the programming of Session-free client applications, which must maintain connection context with every call to an internal procedure or user-defined function. Also, using the AppServer session to create a persistent procedure internally in response to some other client invocation has limited, if any, value. No external procedure invoked by the client can expect to access any persistent resources created by an AppServer session in response to another client invocation, because the latest remote external procedure is likely to execute in a different AppServer agent than the one in which any of these AppServer-created persistent resources reside. If you instantiate a remote persistent procedure in a Session-free application, any network resource that provides the bound connection for the client is unavailable for other clients until that remote persistent procedure is deleted (or released for a Web service ProcObject). If enough clients simultaneously create and use instances of this persistent procedure, the application might have no more physical connections available in its connection pool to serve additional clients. Thus, if all clients that use the application service are always required to create an instance of this remote persistent procedure, the application service is scalable only for the number of clients that can simultaneously create that remote persistent procedure. Even if clients are not required to create this persistent procedure for all uses of the application service, any clients that do so reduce the availability of network resources to other clients and limit the scalability of the application service accordingly. DEV-14 Understanding & Programming for the AppServer

Resource Considerations state-reset state-aware System Resources stateless (bound/unbound) Tradeoffs: Look at it from a resource consideration (hardware resources) vs. throughout and the ability to scale (as the number of clients increases) State-reset/state-aware: one to one relationship, largest resources consumed. Stateless, scales very well with minimal hardware resources State-free provides similar throughput to the stateless operating mode Stateless using Bound/unbound (similar to locking an agent with WebSpeed) probably falls somewhere in the middle. Really depends on how much of the operation is bound…Don’t recommend coding a lot of business logic this way…Use state-reset or state-aware for long periods of ‘boundness’. Because an AppServer running in state-reset and state-aware operating modes dedicates an Application Server process to each client connection, the connected client is guaranteed of having each request handled immediately by the AppServer. Assuming that the general process load on the AppServer platform is light enough, this means that the client can expect relatively fast response time from the AppServer. However, throughput in a state-reset and state-aware connections tends to drop as client load increases, because the number of dedicated Application Server processes available to handle client connections is necessarily limited by the number of Application Server processes that can be started on the AppServer machine. Because a stateless AppServer passes requests from connected clients to any available Application Server process, the number of clients that a single AppServer instance can handle using this operating mode is relatively high. That is, a relatively small number of Application Server processes can support many client connections. If you never set connections to the bound state, a stateless AppServer can make maximum use of its available Application Server process resources to handle client requests. This operating mode thus maximizes throughput for large numbers of clients, especially when they maintain short connections. When session managed connectivity is not needed, state-free can provide increased efficiency and better performance. Clients send requests & receive responses over any available connection on the server handle. As requests are not tied to any AppServer connection, they can run in parallel, taking advantage of any available AppServer that supports the service. Allowing you to optimize the use of AppServer and increases the flexibility of AppServer resources. stateless state-free Throughput DEV-14 Understanding & Programming for the AppServer

Programming Considerations
Understanding and Programming for the AppServer Pat Bonser Programming Considerations state-aware Server Responsiveness state-reset stateless (bound/unbound) stateless Consider the amount of time users will likely spend in the different modules of your application… Balance that with the time it costs to develop the modules to support the different operating modes State-Reset/State-Aware: Lowest development costs (quickest to develop) and fastest server response time Stateless: Higher development costs if context needs to be managed (program context db, write load.p and unload.p)…Slower server response times (client connected to broker, request then goes to AppServer) Stateless with bound, again somewhere in the middle. State-free when no session management is required. Development Costs/ Time state-free DEV-14 Understanding & Programming for the AppServer

Pat Bonser Understanding and Programming for the AppServer Agenda Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests The supported operating modes provide different mixes of resource consumption and performance characteristics. Thus, one or another operating mode might better meet your overall performance requirements, depending on the application. Choosing an operating mode is a key part of the application design, and will affect how you write the code and how the application will run. Are AppServer requests independent of each other or do they expect to use context from one call to another? Operating Mode is specified when an AppServer is configured, “mix & match to meet requirements” and will determine how client requests are dispatched to individual Application Server processes. This is a design time consideration and will have significant impact on the design and performance of your application. Planning for context management and performance of the application will significantly impact how you develop your application code. There are 3 session-managed operating modes and one for the session-free model. If you can use the Session-free operating model, it has the following advantages over the session-managed model: • Both application services and Web services scale much more readily compared to session-managed. • The programming model for Session-free applications — for the AppServer application and for the client application — is simpler than for session-managed applications. Because multiple state-free AppServer instances and their agents can handle multiple requests from one or more clients, multiple requests even from the same client can execute in parallel, vastly increasing the potential response time for a given request. This capability provides the highest degree of scalability compared to other operating modes. If an application requires no context management on the AppServer and otherwise has no programming dependency on a session-managed operating mode, you can choose the Session-free operating mode (state-free). For an existing session-managed AppServer application that meets these requirements (maintains no context), you can immediately change the AppServer operating mode to state-free with no code changes, thus converting the entire application to a Session-free model with potentially greater performance benefits. DEV-14 Understanding & Programming for the AppServer

Managing Context Configuration procedures 4GL procedures available to you to manage context Startup/Shutdown (state-aware & stateless) Connect/Disconnect (all session managed modes) Activate/Deactivate (stateless & state-free) Specified when you configure an AppServer Called automatically at the “right time” When the client issues multiple requests to run procedures on the server, one of two things can happen: Each request can be handled separately by a different Application Server process Or All the requests can go to the same Application Server process. State-aware can use both session & connection level configuration procedures State-reset can use only connection level configuration procedures Stateless can use all context management configuration procedures, but only unbound can use request level procedures. State-free can use activate and deactivate procedures. The AppServer operating mode is determined at startup time by the way you configure the AppServer. Once the AppServer is started, it spawns Application Server processes and manages connections and the pool of servers based on the operating mode. DEV-14 Understanding & Programming for the AppServer

Managing Context Start Application Server Process Stop Application Server Process Session CONNECT DISCONNECT Connection RUN . END PROCEDURE Request There are 3 levels of context, Session – Context – Request, they differ by when they are set and how long they are maintained. The operating modes handle context differently, using various configuration procedures. Session Context is maintained at the Application Server process session level and lasts as long as the Application Server process is running. . Connect/disconnect databases . Load/Store temp-table contents . Run/Delete local persistent procedures Connection Context is maintained at the connection level. Context can be initialized on connect and reset or stored on disconnect. . Authenticate client users . Connect/disconnect client specific databases . Load/store client specific temp-table contents Request Context is maintained at the request level. Context can be initialized at the start of each request, and reset or stored upon completion of the request. Controlling AppServer entry points By default, the client process of an AppServer can run any code that exists on the PROPATH of the AppServer. To maximize security, you should limit the procedures that can be run. You can control AppServer entry points for an Application Server process at run time using the EXPORT method on the SESSION handle. AppServer entry points are the pathnames of procedures in the AppServer PROPATH that a client application can execute as remote procedures (persistently or non persistent). The EXPORT method establishes entry points by allowing you to set and maintain an export list that contains the pathnames of authorized remote procedures. Setting the export list is usually done in the Connect procedure of the AppServer if you are using a state-aware or a state-reset AppServer configuration. If you are using a stateless AppServer configuration, the export list is typically set in the Activate procedure. To set the export list, the AppServer code passes a comma-separated list of procedures that the AppServer can access to the EXPORT method. The list can contain wild cards to make it easier to add entire directories or r-code Libraries. If you want to allow total access to all procedures, just call the EXPORT method without any parameters. DEV-14 Understanding & Programming for the AppServer

Managing Context – Session level
Understanding and Programming for the AppServer Pat Bonser Managing Context – Session level Available to state-aware and stateless Start Application Server Process Stop Application Server Process Session CONNECT DISCONNECT Connection RUN . END PROCEDURE Request Startup Shutdown Startup/Shutdown Encapsulates startup/shutdown logic Connect to DB, load temp table, etc. Use for state-aware, or stateless DEV-14 Understanding & Programming for the AppServer

Managing Context – Connection level
Understanding and Programming for the AppServer Pat Bonser Managing Context – Connection level Available to state-aware, state-reset, and stateless Start Application Server Process Stop Application Server Process Session CONNECT DISCONNECT Connection RUN . END PROCEDURE Request Connect Disconnect Connect/Disconnect Encapsulates a connection Userid, Password, Info Strings SERVER-CONNECTION-ID and SERVER-CONNECTION-CONTEXT available Use for state-aware, state-reset, or stateless Connect runs each time a client connects Disconnect runs each time a client disconnects DEV-14 Understanding & Programming for the AppServer

Managing Context – Request level
Understanding and Programming for the AppServer Pat Bonser Managing Context – Request level Available to stateless, unbound requests Start Application Server Process Stop Application Server Process Session CONNECT DISCONNECT Connection RUN . END PROCEDURE Request Activate Deactivate Activate/Deactivate Encapsulates a stateless request Activate runs before each stateless request Deactivate runs after each stateless request Typical use… use the SERVER-CONNECTION-ID to load/unload the context for the connection from a database use the SERVER-CONNECTION-CONTEXT to load/unload the context for the connection Recap and then move onto considerations and tradeoffs: Specified when an AppServer is configured Determines how client requests are dispatched to individual Application Server processes Will have significant impact on the design and performance of your application The AppServer also allows you to configure and program it for different modes of operation. The supported operating modes provide different mixes of resource consumption and performance characteristics. Thus, one or another operating mode might better meet your overall performance requirements, depending on the application. Use stateless mode when individual client calls are not related and minimal information needs to be saved in between client requests or when you need scalability without loss of performance. Progress provides features for you to save context between requests, but you must program these yourself. Scalability Use stateless processing when you have a large number of clients and limited hardware. Programming can be more complex for a stateless AppServer, but the overall application performance can be better. Use stateless processing when you need to add many clients; stateless applications scale up very efficiently and require less hardware to do so than other operating modes. Programming issues Stateless processing works well when each individual request to the AppServer can be processed separately, or with minimal context to maintain between requests. And when you do not have persistent procedures that need to be executed remotely. DEV-14 Understanding & Programming for the AppServer

Managing Context stateless - bound / unbound To ensure all requests are directed to the same AppServer process Two ways to bind to a stateless AppServer Automatically Run a remote persistent procedure Dynamically Set SESSION:SERVER-CONNECTION-BOUND-REQUEST to TRUE Developing an application for stateless operation requires more programming to manage the context for each request. Stateless will give you best response with less resources but requires more programming…. Be aware that if you go stateless – you may lose the benefit if the process becomes bound. By default, all connections on a stateless AppServer are unbound, that is, all Application Server processes are available to handle requests from any client connection. As long as an Application Server process is not currently handling a client request, it can handle requests from any connected client. A stateless connection becomes “bound” when you run a persistent procedure from the client side or when you set the SERVER-CONNECTION-BOUND-REQUEST attribute to TRUE. A bound stateless connection becomes “unbound” when you delete any remote persistent procedures or set the SERVER-CONNECTION-BOUND-REQUEST attribute to FALSE and no remote persistent procedures are running on the Application Server process. Stateless and bound is useful if most of your application is suitable for stateless, and you have an occasional need to maintain context. As an alternative, you can start up two AppServers, one for stateless and one for state-reset, and then connect as needed for different types of processing. However, at any time during the handling of a client request, a client connection can become bound, that is, the Application Server process handling the request becomes available to handle requests only from the client it is currently servicing. While a connection is bound, all requests from the connected client are handled by the same Application Server process. In the same way it became bound, at any time during the handling of a client request, a bound connection can become unbound, at which point requests from the connected client can be handled by any available Application Server DEV-14 Understanding & Programming for the AppServer

Managing Context stateless Application specific context database Use SESSION:SERVER-CONNECTION-ID attribute Globally unique ID automatically set Recommended for an application specific context db Use Activate/Deactivate configuration procedures to load/unload application context Let the Application Broker do it Use SESSION:SERVER-CONNECTION-CONTEXT attribute Progress character string Set to last value assigned in context of corresponding connection Typical use… use the SERVER-CONNECTION-ID to load/unload the context for the connection from a database use the SERVER-CONNECTION-CONTEXT to load/unload the context for the connection DEV-14 Understanding & Programming for the AppServer

CLIENT-CONNECTION-ID attribute
Understanding and Programming for the AppServer Pat Bonser CLIENT-CONNECTION-ID attribute Session managed Character attribute on a server handle Returns connection ID string for the AppServer connection Session-free Returns unknown-value Logical connection to AppServer represented by a pool of connections NOTE: Comparing Session-free model with session managed model to highlight differences in Session-free. CLIENT-CONNECTION-ID attribute, applies to Server object handle, CHARACTER For a session-managed application, returns connection ID for the physical AppServer connection associated with this server handle For Session-free, the connection is a binding to an application service that relies on a pool of AppServer connections to service requests from the client; because there is no single physical connection between the client and an AppServer this attribute returns the unknown-value. For WebServices, returns an empty string. DEV-14 Understanding & Programming for the AppServer

Managing Context Application specific context database using SESSION:SERVER-CONNECTION-ID Globally unique ID automatically set Recommended for application specific context db Use Activate/Deactivate configuration procedures to Load/Unload context Let the Application Broker do it SESSION:SERVER-CONNECTION-CONTEXT attribute Progress character string Set to last value assigned in context of corresponding connection SESSION:SERVER-CONNECTION-ID Applies to SESSION system handle; readable; CHARACTER This value is assigned by the AppServer broker when an AppServer accepts a connection request from a client application. The AppServer broker and all AppServer agents use the connection ID as an identifier when they log any information associated with the connection. This same connection ID is available to the AppServer agent using the SERVER-CONNECTION-ID attribute and to the connected 4GL client using the CLIENT-CONNECTION-ID attribute on the server handle connected to this AppServer. The value of the connection ID is guaranteed to be globally unique for all time within a single computer network. Connection IDs can be compared to each other strictly for equality, but other types of comparisons are irrelevant. Progress ensures that the SERVER-CONNECTION-ID attribute for each AppServer agent is set to the connection ID for the connection that is assigned to the AppServer agent. Each time a new connection is assigned to an AppServer agent, a new value is assigned to the SERVER-CONNECTION-ID attribute. This attribute is available to any Connect procedure or Disconnect procedure that you have configured for the AppServer. It maintains the same value for these and all other AppServer procedures executed on behalf of the same connection. If the AppServer operating mode is stateless, the AppServer broker resets the SERVER-CONNECTION-ID attribute for each AppServer agent to the ID of the connection each time it executes a request. The connection ID for a bound stateless AppServer agent remains the same until the server process becomes unbound and receives a request from a new unbound connection. If the AppServer operating mode is state-free, this value has no meaning. SESSION:SERVER-CONNECTION-CONTEXT An application-determined value that you set within an AppServer agent. Progress passes this value to each AppServer agent that executes a request on behalf of the client connection identified by the SERVER-CONNECTION-ID attribute. Data type: CHARACTER, Readable/Writeable, applies to SESSION system handle When a client application requests a connection with an AppServer, the App Server broker creates an area to store this value for the connection. The initial value is the unknown value (?). This attribute, while available in all AppServer operating modes, has practical application only on a stateless AppServer, where more than one AppServer agent can service the same client connection. This value is available to any Connect procedure, Activate procedure, Deactivate procedure, or Disconnect procedure that you have configured for the AppServer, as well as any application procedure. Thus, each AppServer agent that services a client connection can pass context information to the next. For an AppServer agent, Progress sets the SERVER-CONNECTION-CONTEXT attribute to the unknown value (?) each time a new connection is assigned to the process. If the AppServer operating mode is state-aware or state-reset, the AppServer agent procedure can also reset this attribute to an application-specific value. However, any such value does not last beyond the current client connection within the current AppServer agent session. Thus, AppServer agents running on a state-aware or state-reset AppServer cannot pass information among themselves using this attribute. In state-free operating mode, any attempt to set this attribute raises a WARNING condition in the AppServer agent, which writes a message to the AppServer log file, and the value remains unchanged. You can handle the WARNING condition by including the NO-ERROR option in the statement that attempts to set the value, and checking ERROR-STATUS:NUM-MESSAGES for a value greater than zero. In state-free operating mode, this attribute always has the unknown value (?). There are 3 levels of context, Session – Context – Request They differ by when they are set and how long they are maintained. The operating modes handle context differently, using various configuration procedures. Session Context is maintained at the Application Server process session level and lasts as long as the Application Server process is running. . Connect/disconnect databases . Load/Store temp-table contents . Run/Delete local persistent procedures Connection Context is maintained at the connection level. Context can be initialized on connect and reset or stored on disconnect. . Authenticate client users . Connect/disconnect client specific databases . Load/store client specific temp-table contents Request Context is maintained at the request level. Context can be initialized at the start of each request, and reset or stored upon completion of the request. Session level Startup/Shutdown Encapsulates startup/shutdown logic Connect to DB, load temp table, etc. Use for state-aware, or stateless Connection level Connect/Disconnect Encapsulates a connection Userid, Password, Info Strings SERVER-CONNECTION-ID and SERVER-CONNECTION-CONTEXT available Use for state-aware, state-reset, or stateless Connect runs each time a user connects Disconnect runs each time a user disconnects Request Level Activate/Deactivate Encapsulates a stateless request Activate runs before each stateless request Deactivate runs after each stateless request Typical use… use the SERVER-CONNECTION-ID to load/unload the context for the connection from a database use the SERVER-CONNECTION-CONTEXT to load/unload the context for the connection DEV-14 Understanding & Programming for the AppServer

Pat Bonser Understanding and Programming for the AppServer Agenda Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests The AppServer also allows you to configure and program it for different modes of operation. The supported operating modes provide different mixes of resource consumption and performance characteristics. Thus, one or another operating mode might better meet your overall performance requirements, depending on the application. Choosing an operating mode is a key part of the application design, and will affect how you write the code and how the application will run. Are AppServer requests independent of each other or do they expect to use context from one call to another? Operating Mode is specified when an AppServer is configured, “mix & match to meet requirements” and will determine how client requests are dispatched to individual Application Server processes. This is a design time consideration and will have significant impact on the design and performance of your application. Planning for context management and performance of the application will significantly impact how you develop your application code. There are 3 session-managed operating modes and one for the session-free model. DEV-14 Understanding & Programming for the AppServer

Running Remote Procedures
Understanding and Programming for the AppServer Pat Bonser Running Remote Procedures Standard AppServer calls - synchronous Blocks the client during an active call Synchronous AppServer Request #1 Request #2 Total Processing Time Prior to 9.1A calls to the AppServer were synchronous, blocking the client until the called procedure was complete. Client DEV-14 Understanding & Programming for the AppServer

Running Remote Procedures
Understanding and Programming for the AppServer Pat Bonser Running Remote Procedures AppServer calls - asynchronous The client can make multiple calls to multiple servers RUN proc ON server ASYNCHRONOUS Request #1 #2 In 9.1A we introduced the Asynchronous AppServer request. When a client connects to an AppServer and issues an asynchronous request, the client is no longer blocked and is able to issue other requests simultaneously on the same or other AppServers, or can continue to enter other information inside the application. When the request(s) are finished, the client is notified of the event and subsequent processing can then take place based on the event finishing (by defining a PROCESS-REQUEST procedure). This is a very valuable approach when consecutive requests are not dependent on one another or if the expected processing time is long and other local actions can take place in the meantime (e.g performing complex calculations or issuing background reports or jobs). Asynchronous AppServer 4GL support includes the ASYNCHRONOUS option on the RUN command. The EVENT-PROCEDURE option is also available on the RUN command. This option is used to name the procedure that will process output parameters and perform error handling. You can also use the PROCEDURE-COMPLETE event on the WAIT-FOR to wait for a specific request to complete. Benefits of Asynchronous calls include: Freeing up the client to make other calls Allowing multiple calls to multiple servers Support for parallelism on both Client & Server - Improving Performance The execution of the RUN statement is context dependent. If the connection to the AppServer is state-free then multiple calls to the RUN statement using ASYNCHRONOUS will allow the requests to run concurrently, provided the AppServer is configured and has the resources available for multiple connections. Session managed ‘RUN … ASYNCHRONOUS’ Multiple remote procedures run Run serially on AppServer Session-free Allows procedures to run concurrently Comparing session managed to Session-free in order to understand the differences with Session-free Code example on next slide. Total Processing Time Client DEV-14 Understanding & Programming for the AppServer

Example Calling procedure RUN BL.p ON SERVER hAppSrv ASYNCHRONOUS SET hRq2 EVENT-PROCEDURE BL-evt-proc IN THIS-PROCEDURE (INPUT-OUTPUT TABLE order-table, OUTPUT iCount). Event procedure Example PROCEDURE BL-evt-proc: DEFINE INPUT PARAMETER TABLE FOR order-table. DEFINE INPUT PARAMETER iCount as INT NO-UNDO. DEV-14 Understanding & Programming for the AppServer

ASYNC-REQUEST-COUNT()
Understanding and Programming for the AppServer Pat Bonser ASYNC-REQUEST-COUNT() Indicates outstanding requests If hAppSrv:ASYNC-REQUEST-COUNT = 0 THEN APPLY “CLOSE” TO THIS-PROCEDURE. DEV-14 Understanding & Programming for the AppServer

CANCEL-REQUESTS() method
Understanding and Programming for the AppServer Pat Bonser CANCEL-REQUESTS() method Session managed Raises STOP for request currently running Purges send request queue of pending requests Session-free Raises STOP for ALL requests currently running Purges queued requests NOTE: Comparing Session-free model with session managed model to highlight differences in Session-free. CANCEL-REQUESTS() method – applies to server object handle. LOGICAL For a session-managed (state-reset, state-aware, stateless) AppServer, raises the STOP condition in the context of the currently running async request and purges the send queue of any async requests not yet executed on the specified AppServer. For Session-free AppServer, raises a STOP condition for all currently running async requests and purges the send queue of any async requests that have not been executed on the specified AppServer. For WebServices, this method terminates the connection to all currently running async requests and purges the send queue of all async requests that have not been executed on the specified Web service. DEV-14 Understanding & Programming for the AppServer

Pat Bonser Understanding and Programming for the AppServer Summary & Questions Architecture Accessing an Application Server Process Operating Modes Managing Context Parallel Client Requests DEV-14 Understanding & Programming for the AppServer

Additional Information
Other Exchange Sessions SOA-03 Open Up Access to your 4GL Applications Using Web Services DEV-12 Bridging the Microsoft and Progress Worlds with the .NET Open Client DONE-02 Where Did You Go Wrong? Diagnostics and Troubleshooting in OpenEdge DONE-04 Best Practices - Designing for Performance: These are a Few of My Favorite Tricks DONE-08 Sizing and Performance Tuning N-Tier Applications DEV-14 Understanding & Programming for the AppServer

Understanding and Programming for the AppServer Pat Bonser Additional Information Documentation OpenEdge Documentation Getting Started: Application and Integration Services Application Server: Administration Developing AppServer Applications Development: Open Client Introduction & Programming Expert Series: OpenEdge Revealed: Achieving Server Control with Fathom™ Management Documentation OpenEdge Getting Started: Application and Integration Services OpenEdge Application Server: Administration OpenEdge Application Server: Developing AppServer Applications OpenEdge Development: Open Client Introduction & Programming OpenEdge Development: .NET Open Clients OpenEdge Development: Java Open Clients OpenEdge Development: Web Services Expert Series – OpenEdge Revealed: Achieving Server Control with Fathom Management DEV-14 Understanding & Programming for the AppServer

Understanding and Programming for the AppServer Pat Bonser Additional Information Education Progress Education Several new courses available, check out the education page on progress.com The following courses cover related subject matter: 4GL Essentials GUI Application Development Developing Distributed AppServer Applications Distributed AppServer Application Administration Distributed AppServer Application Development Dynamic Database Object Essentials Dynamic UI Object Essentials 4GL Performance Tuning Opening 4GL Apps to .NET Clients Opening 4GL Apps to Web Services Clients .NET Client Development with OpenEdge Applications and VB.NET .NET Client Development with OpenEdge Applications and C# Developing & Deploying WebClient Applications DEV-14 Understanding & Programming for the AppServer

Thank you for your time! DEV-14 Understanding & Programming for the AppServer

DEV-14 Understanding & Programming for the AppServer

DEV-14: Understanding and Programming for the AppServer™

Similar presentations

Presentation on theme: "DEV-14: Understanding and Programming for the AppServer™"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DEV-14: Understanding and Programming for the AppServer™

Similar presentations

Presentation on theme: "DEV-14: Understanding and Programming for the AppServer™"— Presentation transcript:

Similar presentations

About project

Feedback