SOA-13: Advanced AppServer™ Topics

SOA-13: Advanced AppServer™ Topics
Pat Bonser SOA-13: Advanced AppServer™ Topics Track: SOA – Integration, SOA, and Web Services Title: SOA14: Advanced AppServer Topics Abstract: Discussion of advanced topics in the use of the OpenEdge AppServer. Topics include an in-depth look at the deployment of the session-free AppServers, use of logging to diagnose application problems, and migrating an AppServer application to a new version. Pat Bonser

Advanced AppServer Topics
SOA 13: Advanced AppServer Topics Pat Bonser Advanced AppServer Topics Agenda Architecture & Components Connection Management Session Managed Model Session-Free Model Diagnostics, Logging & Debugging Migration Steps for Deployed Applications Since the AppServer was first introduced (1996) we have continued to enhance the product and its capabilities…. The OpenEdge Application Server is a dynamic, standards-based transaction engine that provides a reliable foundation for high-volume secure transactions, user interface independence, and a service-oriented architecture. OpenEdge Application Server provides a foundation for a flexible and extensible application infrastructure. OpenEdge Application Server supports an open, component-based model for partitioning applications, allowing them to be transformed into modular elements within an integrated environment. This enables business logic to be easily distributed and reused, saving time and resources. By partitioning applications and separating the business-processing logic from the user-interface logic, applications can be made available to users through virtually any interface. Centralized business logic offers a single point to manage access to data and processes for improved productivity. In this session we will have a quick recap of the architecture and components of the AppServer, then review the Session Models and Operating Modes available to you. Take an in depth look at the deployment of Session-Free AppServers Diagnostics & Debugging Migrating Deployed Applications This presentation includes annotations with additional, complementary information SOA-13: Advanced AppServer Topics

Distributed Applications Architecture
SOA 13: Advanced AppServer Topics Pat Bonser Distributed Applications Architecture RUN VALIDATE-ORDER VALIDATE ORDER return result Data Clients 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 SOA-13: Advanced AppServer Topics

Application Server Architecture
SOA 13: Advanced AppServer Topics Pat Bonser Application Server Architecture Any Client OpenEdge® Application Server GUI Application Code AppServer Character Data 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 and deploy a session-free application, one that maintains no physical connections between Client and Server. ABL Web service Client SOA-13: Advanced AppServer Topics

Application Server Architecture
SOA 13: Advanced AppServer Topics Pat Bonser Application Server Architecture WebSpeed is a Client too! OpenEdge Application Server Web Browser WebSpeed Transaction Server GUI Speed Script Application Code AppServer Character Data 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. ABL Web service Client SOA-13: Advanced AppServer Topics

Application Server Components
SOA 13: Advanced AppServer Topics Pat Bonser Application Server Components AppServer Architecture AppServer AppServer Agents Clients Application Broker NameServer ABL 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. AppServer Agent (aka 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 AppServer Agents 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 . AppServer Internet Adapter - AIA & AIA/S Clients - OpenEdge Clients: GUI, Char, WebClient, WebSpeed Agents Open Clients: Java, .NET, Web service Clients SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Application Server Components AppServer Broker Manages pools of re-usable AppServer Agents Manages client connections and requests for AppServer Agents to execute ABL 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… SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Application Server Components AppServer Agents Executes OpenEdge ABL procedures Reuse of AppServer Agents Determined by Operating mode Application Broker AppServer NameServer ABL Business Logic AppServer Agents 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. SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Application Server Components NameServer Location transparency Inventory Machine A Load balancing 70% 30% Inventory (A and B) Inventory Machine B Clients NameServer FAULT TOLERANCE The NameServer, introduced in Version 9.0 provides 2 key functions for the AppServer: 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 – 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. Session managed – Load balancing by NameServer during initial connection and once connected, services all requests Session-free – Load balanced on each remote procedure execution Payroll Payroll (C) Machine C SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Application Server Components AppServer Internet Adapter ALL Clients to OpenEdge AppServer Applications Can connect remotely Tunneling HTTP (AIA) HTTPS (AIA/S) Java Servlet Runs on Web Server with Java Servlet Engine The AIA is a Java servlet that is run by the Java servlet engine (JSE), which allows Java programs to run on the Web server machine. The AIA supports deployment of distributed applications over the Web by extending the AppServer architecture to support HTTP and HTTPS tunneling. HTTP tunneling encapsulates the communications protocol between an AppServer client and an AppServer within standard HTTP requests and "tunnels" those requests through a Web server. HTTPS is HTTP on a Secure Socket Layer (SSL) connection rather than the standard unencrypted TCP/IP connection. HTTPS is used when privacy, integrity, and server authentication are needed in addition to HTTP tunneling. To use the HTTPS protocol, you can use either the WebClient or the standard 4GL client with Client-side Security product. Communication between the AppServer client and the AIA is performed through the Web server using the HTTP or HTTPS protocol. The AIA converts requests that are encapsulated within HTTP or HTTPS to the standard AppServer protocol. The OpenEdge AppServer architecture was enhanced to include AIA to support HTTP tunneling. Tunneling allows AppServer clients to communicate through firewalls without requiring a network administrator to allow additional protocols or ports to be accessed through a firewall. Included with OpenEdge Application Servers SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Advanced AppServer Topics Agenda Architecture & Components Connection Management Session Managed Model Session-Free Model Diagnostics, Logging & Debugging Migration Steps for Deployed Applications SOA-13: Advanced AppServer Topics

Session Models & Operating Modes
SOA 13: Advanced AppServer Topics Pat Bonser Session Models & Operating Modes Connection management Session managed model Client sends requests over persistent connection Requests handled sequentially Operating Modes State-reset State-aware Stateless Progress V8.2 Progress V9 • 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" Do not get confused with Session Model and Operating Mode Session-free - as well as session-managed, are client settings State-reset, state-aware, stateless and state-free - are Operating Modes, configured for the OpenEdge AppServer, with the Progress Explorer and ubroker.properties. Session-free model Client send requests on any available connection Requests handled in parallel Operating Mode State-free OpenEdge 10.0 SOA-13: Advanced AppServer Topics

Session Models & Operating Modes
SOA 13: Advanced AppServer Topics Pat Bonser Session Models & Operating Modes Connection management Specified when AppServer is configured Determines how client requests dispatched to individual Application Server Agents 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. SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser
Session Managed Model Operating Modes State-reset One client per Application Server Agent 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 agent 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. SOA-13: Advanced AppServer Topics

Session Managed Model state-aware & state-reset Operating Modes AppServer Client 1 AppServer Agents Client 2 Application Broker ABL 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 Agent) to show that state-aware and state-reset are treated the same during the connection, that is the AppServer Agent 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 AppServer Agent, which remains dedicated to the same client for the life of the connection. When the client disconnects, the AppServer Agent 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 AppServer Agent terminates. - One client per AppServer Agent - 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 AppServer Agent, which remains dedicated to the same client for the life of the connection. When the client disconnects, the AppServer Agent 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 Message Queue Client 4 SOA-13: Advanced AppServer Topics

Session Managed Model Stateless Operating Mode AppServer Client 1 AppServer Agents Client 2 Application Broker ABL NameServer Data Client 3 For all modes, if there are no AppServer Agents available, and none configured to start when they are all used, the connection request will go to a message queue… when an AppServer Agent 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 AppServer Agent 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 SOA-13: Advanced AppServer Topics

Session-free Model State-free Operating Mode ABL Clients AppServer NameServer Client 1 AppServer Agents Open Clients Client 2 Data Application Broker ABL Web Service Client 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. 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 is not 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 Client application sends requests and receives responses over any available connection on the server handle Requests are handled in parallel Client 3 Web Services Adapter SOA-13: Advanced AppServer Topics

Session-free Model State-free Operating Mode Logical Connection No connection maintained between Client and Application Server Agent Pooled Connections ABL requests on the server handle Web service requests on the WSA Open Client requests on the AppObject 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 ….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.. 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. SOA-13: Advanced AppServer Topics

Session-free Model Design Considerations Avoid dependency on other calls! Procedures can execute concurrently Order of completion NOT predictable Context Management Session or task level Client or Server When to delete 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). 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. SOA-13: Advanced AppServer Topics

Why & When to use Session-free Model
SOA 13: Advanced AppServer Topics Pat Bonser Why & When to use Session-free Model Some applications inherently NOT connection oriented Requests executed regardless of other requests Should not be tied to one AppServer Connection i.e. standalone request for information Efficiency and Performance Parallel execution on any AppServer Efficient use of resources Performance gains Scalability 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. 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. SOA-13: Advanced AppServer Topics

What about ASYNC Calls? Does Async mean parallel execution? RUN proc ON server ASYNCHRONOUS Session-managed Model Allow multiple remote procedures to be executed Run serially on same AppServer Session-free Model Will allow procedures to execute concurrently In version 9 the ability to use the ASYNCHRONONUS option on the RUN statement was added, allowing the client to send multiple requests to the AppServer without waiting for a response before continuing. The execution of the RUN statement is context dependent. If the connection to the AppServer is session-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. However, multiple requests in session-managed must run on the AppServer session that is ‘connected’ to the 4GL client. This results in queuing of the requests on the AppServer as they each wait for their turn to run on that AppServer session. Session-free requests sent using ASYNCHRONOUS can run on any available AppServer session that is configured to handle the requests. Thus queuing can be avoided and requests can run concurrently. SOA-13: Advanced AppServer Topics

Coding Example – RUN ASYNCHRONOUS
SOA 13: Advanced AppServer Topics Pat Bonser Session-free Model Coding Example – RUN ASYNCHRONOUS Internal procedure run in procedure handle Each call to internal procedure queued on the client RUN bl.p ON SERVER hAppSrv ASYNCHRONOUS SET hRq2 EVENT-PROCEDURE bl-evt-proc IN THIS-PROCEDURE (INPUT-OUTPUT TABLE order-table,OUTPUT iCount). This example is here to show syntax for the RUN statement when calling an internal procedure. The syntax same for both session-free and session-managed. PROCEDURE bl-evt-proc: DEFINE INPUT PARAMETER TABLE FOR order-table. DEFINE INPUT PARAMETER iCount as INT NO-UNDO. SOA-13: Advanced AppServer Topics

Enhanced Syntax to support to Session-free
SOA 13: Advanced AppServer Topics Pat Bonser Enhanced Syntax to support to Session-free CONNECT() Method Properties CANCEL-REQUESTS() method CLIENT-CONNECTION-ID attribute Listed here are some areas where the 4GL has been enhanced to support session-free. We’ll go briefly through each one in the upcoming slides. For detail beyond what is covered in this presentation see the AppServer documentation. SOA-13: Advanced AppServer Topics

CONNECT() method -sessionModel Default Session-managed Set to Session-free to use the session-free model fOk = hAppSrv:CONNECT(“ -URL AppServer://host:port/servicename -sessionModel Session-free”). The first parameter of the connection method is the connection string. This is the same as the connection string used for all models. You must specify Session-free to connect a 4GL client to a state-free AppServer. Model and mode must match Session-free Client can only connect to State-free AppServer SOA-13: Advanced AppServer Topics

CONNECT() Session-free connection Pool of re-usable socket connections AppServer handle points to pool Managed transparently by Client Connections allocated as needed Tunable using CONNECT() properties In order to execute multiple session-free remote procedures concurrently, the 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. CONNECT() -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 SOA-13: Advanced AppServer Topics

CANCEL-REQUESTS() method
SOA 13: Advanced AppServer Topics Pat Bonser CANCEL-REQUESTS() method Session managed Model Raises STOP for request currently running Purges send request queue of pending requests Session-free Model 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. NOTE Use ASYNC-REQUEST-COUNT() to check for outstanding requests If hAppSrv:ASYNC-REQUEST-COUNT = 0 THEN APPLY “CLOSE” TO THIS-PROCEDURE SOA-13: Advanced AppServer Topics

CLIENT-CONNECTION-ID attribute
SOA 13: Advanced AppServer Topics Pat Bonser CLIENT-CONNECTION-ID attribute Character attribute on a server handle associated with session-managed applications Session-managed Returns connection ID string for the AppServer connection associated with the server handle Session-free Logical connection to the AppServer is represented by a pool of AppServer connections Returns the unknown value In session-managed the CLIENT-CONNECTION-ID is used to get the connection ID of the AppServer that is associated with the server handle. For session-free this parameter is not used and returns the unknown value. The reason that this parameter is not used is because the server handle is associated with a pool of AppServer connections. (Note that one possible use for the CLIENT-CONNECTION-ID is to generate audit trails for connect, disconnect, and for procedure requests) SOA-13: Advanced AppServer Topics

NameServer Load Balancing
SOA 13: Advanced AppServer Topics Pat Bonser NameServer Load Balancing Session managed Model On Client connection to the AppServer Same AppServer serves all requests from a client Session-free Model On each request Load Balancing for session-managed applications by the NameServer occurs during the initial connection. After the connection is made the same AppServer is used for each request from the client. For OpenEdge 10, when using session-free, each time a remote procedure is the NameServer will determine which AppServer will serve the request. This adds flexibility, but may also increase the overhead. For more information on load balancing see the 'Load balancing and session models" section in the OpenEdge manual titled 'OpenEdge Application Server: Developing AppServer Applications'. SOA-13: Advanced AppServer Topics

Persistent Procedures in a Session-free Model
SOA 13: Advanced AppServer Topics Pat Bonser Persistent Procedures in a Session-free Model A context is created for the internal procedures All internal procedures on a remote procedure Will execute on the same AppServer Will execute serially Losing parallel advantage Reducing scalability 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. SOA-13: Advanced AppServer Topics

Logging Infrastructure
SOA 13: Advanced AppServer Topics Pat Bonser Logging Infrastructure Log Files Unified Format Log Entry Types Logging Levels Log size threshold LOG-MANAGER Log File Analysis LogRead Utility The logging infrastructure provides a means for either standard reporting of run-time activity or logging diagnostic data for troubleshooting problems based on a set of logging characteristics. OpenEdge writes information to a log file. You control the type and amount of information logged using a combination of log entry types and logging levels. Log entry types are categories of information written to the log file. Logging levels control the amount of logging information for any given log entry type and environment. Threshold, log files have a size threshold, allowing more control over the amount of disk space used for log files. When the file becomes equal to or greater than the specified size, the client process renames it and creates a new log file. The default value is 0, which implies there is no limit. Possible Values are – (in bytes). You can specify how many rolled-over log files to keep when a log threshold value is set for a given log file. The specified number represents the maximum total number of log files to keep on disk at any time, including the log currently being written to. The number takes into account any log files that already exist at the time the session starts up plus any new ones created during that session. For example, if there are five log files on the disk at startup and you specify you want a maximum of three, OpenEdge deletes the oldest two. Then, each time it creates a new one, OpenEdge deletes the next oldest one. The default value is 3. Possible values are 0, 2, 3 or greater. LogRead is a GUI utility to read, query, sort, merge and translate log files from all Progress components (e.g. AdminServer, AppServer, Messenger). It is provided as a diagnostic utility to assist in the analysis of log files. SOA-13: Advanced AppServer Topics

Diagnostics, Logging & Debugging
SOA 13: Advanced AppServer Topics Pat Bonser Diagnostics, Logging & Debugging Where to look for an AppServer Application Which Log? AdminServer admserv.log NameServer ns1.ns.log AS Broker asbroker1.broker.log AS Agent asbroker1.server.log AIA aia1.aia.log Database dbname.lg  A log file contains log message header information and log message content. The message content is set by the log entry type and the logging level. For AppServer and WebSpeed, the log is the normal AppServer or WebSpeed log file (for example, asbroker1.server.log). For WebSpeed Messenger, Unified Broker, NameServer, AIA, the log file is specified through Progress Explorer. Not listed here - admclnt.log – Progress Explorer For a 4GL client, specify the log file with the Client Logging (-clientlog) startup parameter What about the Client? -clientlog logfilename SOA-13: Advanced AppServer Topics

Log Entry Types Server/Client Executables 4GLMessages1 4GLTrace DB.Connects DynObjects.* QryInfo SAX ProEvents.* Other AIA* ASPlumbing ASDefault NSPlumbing UBroker.* WSADefault MsgrTrace Log entry types are a set of strings specifying the types of logging information that can be written to a log file. Executable - any Progress executable running ABL including webclient, appserver, webspeed and gui client Client Only – NOT appserver and webspeed Other Components – are what they are AppServer, Messenger etc To set the logging level of the log entry type, use the LOG-ENTRY-TYPES attribute or the Log Entry Types (-logentrytypes) startup parameter with the logging level option. This same functionality is available in the debugger under the following menu choices Diagnostic Monitor Dynamic Objects… DynObjects.* - DB, XML, UI, Class, Other AIA* – Mgmt, Prop, Rqst. UBroker, Default ProEvents.* - UI.Char, UI.Command, Other Ubroker*. – ThreadPool, AutoTrim, , Stats, All ClientFSM, ClientMsgStream, ClientMsgQueue, ClientMemTrace, ServerFSM, ServerMsgStream, ServerMemTrace With OpenEdge 10.1A logentrytypes option has been enhanced to allow you to track Class objects. Note: some log entry types are for internal diagnosis, e.g.the UBroker log entries such as ClientFSM, ServerFSM, ClientMsgQueue etc don't really help with issues unless you have access to the source code. These are very verbose, and should really be used only when directed by Tech Support 1Client only SOA-13: Advanced AppServer Topics

Logging Levels Setting logginglevel StartUp Parameter LOG-MANAGER system handle Ubroker.properties file Logginglevel Values 0 – None 1 – Errors 2 – Basic 3 – Verbose 4 - Extended 0 (None) — Log no entries. This is equivalent to turning logging off. 1 (Errors) — Log OpenEdge error messages. This includes all error messages and is unrelated to the entry types specified. Errors are logged at level 1 (Errors), by default. 2 (Basic) — Log entry type determines the logged information. 3 (Verbose) — Log entry type determines the logged information. 4 (Extended) — Log entry type determines the logged information. By default, the logging level you specify applies to all log entry types. However, you can specify individual log entry types with a different logging level using the Log Entry Types (-logentrytypes) startup parameter. SOA-13: Advanced AppServer Topics

LOG-MANAGER System handle attributes & methods Attributes ENTRY-TYPES-LIST LOG-ENTRY-TYPES LOGFILE-NAME LOGGING-LEVEL LOG-THRESHOLD NUM-LOG-FILES TYPE Methods (OpenEdge 10.1A) CLOSE-LOG CLEAR-LOG WRITE-MESSAGE Using LOG-MANAGER attributes & methods you can change the log levels and log-entry-types, allowing you programmatically control the logging levels and log-entry-types during the execution of your program. OpenEdge 10.1A - New methods have added to the LOG-MANAGER system handle CLEAR-LOG - For an interactive or batch Progress client, the CLEAR-LOG() method of the LOG-MANAGER handle clears all messages existing in the current client log file, and leaves the file open for writing. The Progress client will then write all subsequent messages from the beginning of the log file. CLOSE-LOG - The CLOSE-LOG() method of the LOG-MANAGER handle stops an interactive or batch Progress client from writing messages to the current client log file, and closes the log file. The Progress client will not write any subsequent messages to this client log file. WRITE-MESSAGE (msg-expr [, subsys-expr]) - The WRITE-MESSAGE() method on the LOG-MANAGER handle allows users to write their own application-specific messages to the current client log file. For WebSpeed and AppServer, this is the server log (e.g. wsbroker1.server.log). For the interactive or batch client, this is the file the user identifies by the –clientlog parameter, or by the LOG-MANAGER:LOGFILE-NAME attribute. The CLEAR-LOG() and CLOSE-LOG() methods will work only on interactive or batch clients, not WebSpeed or AppServer. SOA-13: Advanced AppServer Topics

Log File Analysis – LogRead Utility
SOA 13: Advanced AppServer Topics Pat Bonser Log File Analysis – LogRead Utility PSDN.progress.com GUI Utility View, filter, sort, merge, & translate log files Advanced Time adjustment Promsgs translation Date Range Filter Log file format Date format With the LogRead utility, you can: Filter and sort subsets of messages from log files. Interpret log files of different formats from different OpenEdge components (for example, AppServer, NameServer, and Database). Interpret log files from different versions of Progress and OpenEdge. Merge multiple log files (of different formats) together so you can trace through a thread of execution. Translate PROMSGS messages to your preferred language. Adjust timestamps within log files, to synchronize messages in logs from different machines, particulalry useful when the clocks are not “in synch” . . Use the LogRead utility interface to run your own analysis programs over the log file data. RUNNING LogRead (packaged in a PL in a ZIP on PSDN) To run LogRead, run the program logread/logread.w, either with the -p parameter from the command line, or with the 4GL RUN statement. SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Log File Analysis – LogRead Utility Browse, Filter or Query Log SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Log File Analysis – LogRead Utility PSDN.progress.com Select Logs to Merge File Merge SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Log File Analysis – LogRead Utility PSDN.progress.com Analyze the Merge  Scenario for this log merge – client got error (735) – why? Database had been shut down, after client called AppServer: - started a DB - started the NS - started the AS, which connects to the DB on startup - stopped the DB - ran a client to call the appserver and update the DB The client got error (735), which is in clilog.txt. Included are broker, server, nameserver and db logs. SOA-13: Advanced AppServer Topics

Debugging AppServer Code
SOA 13: Advanced AppServer Topics Pat Bonser Debugging AppServer Code Application Debugger – Debug Modes Application Mode, supports distributed Step into AppServer code from Client session Attachable Mode Attach to remote process Debug attached process only No access to calling process Can be used when Server not local No monitor attached Easier to debug from where you are Recap – Debugger Technology Preview 9.1D SP 05 Updated in SP 06 & 07 First official release OpenEdge 10 Application Mode – DEBUGGER system handle Supports distributed debugging, step into code on AS or WSTS - Distributed debugging is the ability to debug associated 4GL processes within a distributed application environment. That is, one debugger session can control both the client process and AppServe process, giving the client session the ability to step into code running on the AppServer. The procedure call stack reflects all procedures in all processes involved, enabling the root client application to be aware of the AppServer processes it is debugging. The root client application is the client application that initiates the Debugger using distributed debugging. Attachable Mode – Attach to remote process Client Side OpenEdge 10.0A Server Side OpenEdge 10.0B Remote debugging provides the ability to debug server-side and remote application procedures. This mode does not allow debugging any procedure in a client application session. Remote debugging allows you to debug application code running on an AppServer process or a WebSpeed agent independently of the calling client application. SOA-13: Advanced AppServer Topics

Enabling Debugging Debugging is NOT enabled by default Client Start →Programs → OpenEdge → Proenv AppServer Enabling debugging You cannot run the Application Debugger on an OpenEdge installation that contains a 4GL interpreter until you enable the system for debugging. If you try to run the Debugger without first enabling debugging, you receive an error message. Debugging is initially disabled because it opens a potential security hole. When running the Debugger, you can examine and modify internal variables and database fields. In a production environment, this means that someone could access sensitive business data while in the Debugger. For this reason, Progress Software strongly recommends that you avoid using the Debugger on a production system. During application development, however, you can choose whether to selectively enable and disable debugging or enable it after installation and leave it enabled for the duration of the development cycle. To enable debugging, use the proDebugEnable command, which has the following syntax: ProDebugEnable {-disable-all|-enable-all} To enable debugging on the AppServer, select the AppServer for which you want debugging enabled. Right-click and select Properties. Select Server and the Advanced Features. Check the 4GL debugger enabled box to enable debugging. SOA-13: Advanced AppServer Topics

Attachable Mode Debugging Code Remotely Ready the AppServer Agent for debugging -debugReady port-number proDebugConfig The Debugger runs in attachable mode when you first start the Debugger and then attach it to a running client process. That client can be any 4GL client or WebSpeed agent running on the same machine or the same LAN as the Debugger. The Debugger gets control immediately upon attaching to the process. Once attached, the Debugger works the same as application mode; that is, you are debugging an already running application. To successfully attach the Debugger, the process you attach to must be in a debug-ready state. You can make the process ready for debugging in a number of ways: • Ready Attachable Debugger (-debugReady) startup parameter. • proDebugConfig command. • Debugger window. This requirement has both security and performance considerations. The Debugger and the 4GL interpreter communicate by opening a socket on a port and establishing a connection. In attachable mode, the interpreter has to open a socket on a known port and wait for a connection from the Debugger. The open connection introduces a potential security hole and a performance degradation. To close the security hole, OpenEdge requires that you have physical or login access to the local machine to make a process debug-ready. To avoid the performance hit of unnecessary polling, you have the option to make the process debug-ready, and thus open the connection, only when you are ready to debug the process. NOTE ( re example in slides) Specify -debugReady with a non-zero port number in the server startup params only if you have configured the broker to start at most 1 agent. If you put -debugReady with a specific port number in the server startup parameters, then all appservers will try to start up with this port, which won't work! If you want to start more than one agent per broker, then you can do: specify -debugReady 0, which will find an available debug port for each agent, although you will have to look in the broker log to determine which port belongs to which agent. use proDebugConfig and enable each agent individually. Start Attachable Debugger Start → Programs → OpenEdge → Debugger SOA-13: Advanced AppServer Topics

Attachable Debugger Local Remote IIn 10.0B, we added the ability to attach to a remote AppServer server process, allowing you to debug AppServer and/or WebSpeed remotely. (support for WebSpeed was added in 10.0A) Otherwise, the same terms and restrictions apply as for 10.0A. This means you can attach the Debugger to an AppServer or UBroker on any supported platform that is running within a LAN. The user cannot connect across the Internet using an http URL. This extension to the attachable debugger support provided in 10.0A will probably more important than the original offering. This is because more and more scenarios involve an AppServer and a non-Progress client, such as an Open Client or Web Service client. In the past, debugging in this scenario could be done only by modifying the AppServer code to use the Debugger system handle to start the Debugger. Using the Attachable Debugger is a more straight forward mechanism. SOA-13: Advanced AppServer Topics

Attachable Debugger SOA-13: Advanced AppServer Topics

Remote Code is Available
SOA 13: Advanced AppServer Topics Pat Bonser Remote Code is Available Debug as usual SOA-13: Advanced AppServer Topics

Detach from Process After successfully attaching to a running client process, the Debug/Attach to Process menu item becomes Debug/Detach from Process. When you choose this menu option, the Debugger disconnects from the socket it uses to communicate with the 4GL interpreter. If the debug-ready state was initiated by the Debugger, it then asks if you want to leave the process in a debug-ready state. Choose Yes or No, as appropriate. No is the default. After you detach from the process, the Debugger returns to its startup state, with the menu item restored to Debug. Attach to Process. You can now attach to another process or close the Debugger. If you attempt to close the Debugger window while it is attached to a process, the Debugger asks for confirmation. If you confirm, the Debugger disconnects from the process and might ask if you want to leave the process in a debug-ready state. Answer Yes or No. The Debugger then shuts down. Note: In attachable mode, the Debugger remains open if you close the OpenEdge session, or when the current application completes, unlike other operating modes, where the Debugger itself shuts down as well. SOA-13: Advanced AppServer Topics

Migrating a Deployed Application
SOA 13: Advanced AppServer Topics Pat Bonser Migrating a Deployed Application Planning an Upgrade Considerations Whats’s New? Enhanced Capabilities Operating Modes Configurations - Fault Tolerance Steps before deployment Upgrade Licenses Convert/Migrate Database Migrate Code SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Migrating a Deployed Application Deploying the Upgrade NameServer NameServer Application Broker AppServer Agents Server Code Existing Client Code Clients Data New This slide has many builds, showing a suggested flow for upgrade – while running the existing application. Register New AppServer(s) With existing NameServer Configure new NameServer Shutdown Clients Upgrade Client (license & application) Reconnect clients to new AppServer(s) Shutdown old AppServer(s) Shutdown old NameServer SOA-13: Advanced AppServer Topics

SOA 13: Advanced AppServer Topics Pat Bonser Migrating a Deployed Application Deploying the Upgrade Register New AppServer(s) With existing NameServer Configure new NameServer Shutdown Clients Upgrade Client (license & application) Reconnect clients to new AppServer(s) Shutdown old AppServer(s) Shutdown old NameServer SOA-13: Advanced AppServer Topics

For More Information, go to…
SOA 13: Advanced AppServer Topics Pat Bonser For More Information, go to… PSDN LogRead Utility White Papers & Presentations Relevant Exchange Sessions: ARCH–3: Context Management in the OpenEdge Reference Architecture SOA-5: Accessing the AppServer from Anywhere & Everywhere SOA–10: Application Servers, Web Services and Integration Info Exchange SOA-13: Advanced AppServer Topics

Documentation & Education
SOA 13: Advanced AppServer Topics Pat Bonser Documentation & Education OpenEdge Documentation Getting Started: Application and Integration Services Application Server: Administration Application Server: Developing AppServer Apps Development: Debugging and Troubleshooting OpenEdge Education Developing Distributed AppServer Applications Distributed AppServer Application Administration Distributed AppServer Application Development 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 SOA-13: Advanced AppServer Topics

Questions? SOA-13: Advanced AppServer Topics

Thank you for your time SOA-13: Advanced AppServer Topics

SOA-13: Advanced AppServer™ Topics

Similar presentations

Presentation on theme: "SOA-13: Advanced AppServer™ Topics"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SOA-13: Advanced AppServer™ Topics

Similar presentations

Presentation on theme: "SOA-13: Advanced AppServer™ Topics"— Presentation transcript:

Similar presentations

About project

Feedback