ARCH3: Context Management in the OpenEdge Reference Architecture

1
ARCH-3 Context Management in the OpenEdge
Reference Architecture

• John Sadd
• Engineering Fellow and OpenEdge Evangelist

2
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

3
The good (very) old days host-based
FIND FIRST Customer
/ Process Customer 1 /
FIND NEXT Customer
/ Process Customer 2 /
Everything on one box
4
The good (not so) old days client/server
FIND FIRST Customer
/ Process Customer 1 /
FIND NEXT Customer
/ Process Customer 2 /
Client networking
Client PC
Server
5
Client/server limitations Performance
FIND FIRST Customer
/ Process Customer 1 /
FIND NEXT Customer
/ Process Customer 2 /
Client networking
All code executes on the client
Server
Client PC
6
Client/server limitations OpenEdge client
platform only
FIND FIRST Customer
/ Process Customer 1 /
FIND NEXT Customer
/ Process Customer 2 /
Client networking
Server
7
What to do, what to do
AppServer
Host-based
Client/Server
8
The Bigger Picture Today and Tomorrow

• Flexibility for client platforms and integration
  needs

OpenEdgeAppServer
OpenEdge.NET Interface
Purchase Order Business Logic
PurchaseOrderProxy
PO ProDataSet
HeaderData
DetailData
OtherData
WebClient / HTML User Interface
OpenEdgeABL Interface
ABL or WebSpeed Interface
Jonas Grumby
OK
110 Desert Isle Path
Cancel
Minnow, HI
OpenEdgeWeb Services Interface
9
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

10
Improving network performance with the
AppServer
CustProc.p
RUN CustProc.p ON hAppServ (FIRST, OUTPUT
ttCust)
Business logic code executes on the server
AppServer
Client
11
Using a bound AppServer session in
state-aware mode
RUN CustProc.p ON hAppServer PERSISTENT set
hCust.
CustProc.p
RUN FindCust IN hCust (FIRST, OUTPUT ttCust)
/ Process Customer 1 /
RUN FindCust IN hCust (NEXT, OUTPUT ttCust)
/ Process Customer 2 /
AppServer
Client
12
Scalability and bound AppServers
AppServer session
client
AppServer session
client
client
AppServer session
client
AppServer session
client
AppServer session
client
AppServer session
13
Using the AppServer in stateless mode
AppServer session
AppServer session
AppServer session
All client requests
AppServer broker
AppServer session
AppServer session
AppServer session
14
Using the AppServer in stateless mode
FIND FIRST
AppServer session 1
AppServer session
AppServer session
RUN CustProc.p ON hAS (FIRST, OUTPUT ttCust)
AppServer broker
AppServer session
AppServer session
AppServer session
15
Using the AppServer in stateless mode
FIND NEXT
AppServer session
AppServer session 2 NEXT What??
AppServer session
RUN CustProc.p ON hAS (NEXT, OUTPUT ttCust)
AppServer broker
AppServer session
AppServer session
AppServer session
16
Advantages to using stateless mode

• Allows sharing of server resources by many
  clients
• Promotes scalability
• Allows for load balancing and other optimizations
• Allows AppServer access from other platforms

17
Challenges using stateless mode

• Cant run procedures PERSISTENT without binding
  the AppServer session
• Server procedure wont keep track of you
• Cant run internal procedures
• Cant get a procedure handle for non-persistent
  procedures
• Cant maintain client-specific context within an
  AppServer session

18
Unmanaged state-free mode

• Not even a persistent CONNECTION-ID for the
  AppServer broker
• Recommended for use with Web services or other
  connectionless environment
• Service-Oriented Application on the bus
• Issues are essentially the same as with stateless

19
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

20
Context Management Basics

• Target environment is client to stateless or
  statefree AppServer
• Each interaction is independent
• Maintain context between related interactions

21
Dealing with context in a stateless world
binding for the duration of a task

• Run a procedure PERSISTENT on a stateless
  AppServer session
• This binds the session for the life of the
  procedure
• Supports multiple calls that are part of a single
  task
• The session is unbound when the procedure
  instance is deleted

22
Managing context for a task
23
Managing a task by binding a stateless
AppServer
RUN PERSISTENT
DELETE PROCEDURE
Client
AppServer

• This method is strongly discouraged!
• Uncontrolled binding to client
• Not suitable for SOA direction

24
Accessing shared procedure instances

• Pre-start commonly used PERSISTENT procedures as
  part of AppServer start-up
• Use a gateway (Service Interface) procedure to
  route client requests
• Or
• Have the Service Interface start procedures the
  first time they are needed
• Session manager on the server

25
Using a Service Interface procedure and
session manager
Client
Server
UI Procedure
Business Entity
Data-Access Object
DATASET dsOrder
DATASET dsOrder
DATASET dsOrder
RUN fetchOrder IN hdsOrder (. . . , OUTPUT
DATASET dsOrder BY-REFERENCE)
RUN FetchWhere IN hEntity (. .
., OUTPUT DATASET phFetchDataSet BY-REFERENCE)
fetchWhere FILL ATTACH
Client Proxy
Session Manager
26
Using a Session Manager
DEFINE TEMP-TABLE ttEntity FIELD EntityName
AS CHARACTER FIELD EntityHandle AS HANDLE
FIELD DAOHandle AS HANDLE INDEX
EntityName EntityName.
FUNCTION getEntityHandle RETURNS HANDLE (INPUT
pcEntityName AS CHARACTER) DEFINE VARIABLE
hEntity AS HANDLE. FIND FIRST ttEntity WHERE
ttEntity.EntityName pcEntityName NO-ERROR.
IF NOT AVAILABLE (ttEntity) THEN hEntity
startEntity(pcEntityName). ELSE hEntity
ttEntity.EntityHandle. RETURN hEntity. END
FUNCTION. / getEntityHandle /
27
Using a Session Manager - 2
FUNCTION startEntity RETURNS HANDLE (INPUT
pcEntityName AS CHARACTER) DEFINE VARIABLE
hEntity AS HANDLE. DEFINE VARIABLE hAccess
AS HANDLE. RUN VALUE("be" pcEntityName
".p") PERSISTENT SET hEntity NO-ERROR.
IF VALID-HANDLE(hEntity) THEN DO
CREATE ttEntity. ASSIGN
ttEntity.EntityName pcEntityName
ttEntity.EntityHandle hEntity. END.
RETURN hEntity. END FUNCTION. / startEntity
/
28
Alternatives for maintaining context

• Pass context information back and forth between
  client and server
• The context is held on the client
• Store context between client requests in a shared
  data store
• All AppServer sessions can read and write it
• The context is held on the server

29
Using the AppServer in stateless mode
AppServer session
AppServer session
AppServer session
All client requests
AppServer broker
AppServer session
AppServer session
AppServer session
30
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

31
Passing Context between Client and Server

• Context/Parameter temp-table passes context back
  and forth
• Name Value fields allow flexibility
• Or just use a delimited list in a CHAR param
• Context is maintained on the client
• Useful for moderate amounts of data
• Also for context used on the client
• And for context modified on the client

32
Context Between Client and Server -- Batching
Server
Client
Business Entity
UI Procedure
DATASET dsOrder
DATASET dsOrder
context/parameter temp-table
RUN FetchWhere IN hEntity (. .
., OUTPUT DATASET phFetchDataSet BY-REFERENCE)
RUN fetchOrder IN hdsOrder (. . . , OUTPUT
DATASET dsOrder BY-REFERENCE)
Server Gateway Procedure
Client Proxy Procedure
WhereString
NextRowid 63524
33
Using a context temp-table
FIND ttContext WHERE ttContext.ContextName
"WhereString" NO-ERROR. IF NOT AVAILABLE(ttContext
) THEN DO CREATE ttContext.
ttContext.ContextName "WhereString". END. ttCont
ext.ContextValue "OrderNum "
STRING(iOrderNum). / and the same for
NextRowid /

• Useful for any flexible set of parameters or
  context values in a single interface

34
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

35
Context Maintained on the Server

• Hold context in a shared server-side data store
• Typically a database table
• Useful for context not to pass back and forth
• Session context such as language, authorization
  that does not change
• Also useful for large amounts of context data
• Storing context on the server can be the best
  universal approach

36
Built-in support for UUIDs and GUIDs in 10.1A

• Requires a Context ID passed from the client
• GENERATE-UUID
• Universal Unique IDentifier
• Returns a 16-byte RAW (binary) value
• Guaranteed unique across all space and time
• GUID (ltuuid-valuegt )
• Global Unique IDentifier
• Converts a UUID into a 36-character GUID
• XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
• SUBSTRING(BASE64-ENCODE(GENERATE-UUID),1,22)
• Yields a more compact 22-character string

37
Context Stored on the Server
Server
Client
Business Entity
UI Procedure
DATASET dsOrder
DATASET dsOrder
Context ID parameter
RUN FetchWhere IN hEntity (. .
., OUTPUT DATASET phFetchDataSet BY-REFERENCE)
RUN fetchOrder IN hdsOrder (. . . , OUTPUT
DATASET dsOrder BY-REFERENCE)
Server Gateway Procedure
Client Proxy Procedure
ContextID 95847
Context
95847 English Auth
38
ProDataSet and Temp-Table Context

• Store retrieved data in a context table
• For WebSpeed or other clients with no ProDataSet
  support
• RAW fields and BLOBs for generic storage
• Or store as XML in CHARACTER format
• Store successive updates before commit
• Allows partial validation on the server
• Final update ProDataSet rebuilt from context

39
ProDataSet or Temp-Table Data as Context
Server
Client
Business Entity
Web browser
DATASET dsOrder
Browser code
ContextID 95847
RUN FetchWhere IN hEntity (. .
., OUTPUT DATASET phFetchDataSet BY-REFERENCE)
OrderNum 1
Server Gateway Procedure
95847 Order 1 Line 1
95847 Ord 1 L 1 Q 20
Context
95847 Order 1 Line 1
95847 Ord 1 L 1 Q 20
Application
95847 Order 1 Line 2
40
Defining a context management table

• SessionID identify a client session
• ContextID identify a specific task or
  transaction within a session
• ContextName Table name or other tag (like
  WhereString)
• ContextValue Primary key value for a table, or
  string value for another tag
• isBeforeRow flag for ProDataSet rows
• RowSequence for ordering table rows
• TimeStamp when the row was created or last
  updated (also a DeleteTime for cleanup)
• RawData temp-table row data

41
Creating a context row
CREATE ContextStore. ASSIGN ContextStore.ContextI
D pcContextID ContextStore.ContextName
phBufferName ContextStore.ContextValue
cKeyValues ContextStore.RowSequence
piSequence ContextStore.isBeforeRow
FALSE.
ASSIGN ContextStore.TimeStamp NOW
ContextStore.DeleteTime
DATETIME-TZ( DATE(NOW) 1,
MTIME (NOW), TIMEZONE(NOW)).
phBufferRAW-TRANSFER(TRUE, / from buffer to RAW
/ BUFFER ContextStoreBUFFER-FIELD("RawDat
a")).
42
ContextStore rows
wxyz
eOrder
27
1
FALSE
abcd
raw buffer
wxyz
eOline
27 1
1
FALSE
abcd
raw buffer
wxyz
eOline
27 2
2
FALSE
abcd
raw buffer
RawData
ContextID
SessionID
isBeforeRow
ContextValue
ContextName
RowSequence
43
RAW-TRANSFER limitations

• Low-level does not recognize fields or other
  buffer specifics
• Temp-table definitions must match exactly
• Use for short-term storage

44
Agenda

• Client to Database a brief history
• AppServer modes and issues
• Thinking about procedures and context
• Maintaining context on the client
• Maintaining context on the server
• Conclusions

45
Design for the OpenEdge AppServer

• AppServer lets you locate business logic where it
  belongs to improve performance
• AppServer is the basis for all Open Client
  access, .NET support, Web services, etc.
• Stateless or statefree mode gives you the
  greatest flexibility and scalability
• Avoid binding the AppServer to a client session

46
Design context management into your application
as a feature

• Store small amounts of context on client
• Store larger amounts of data on server
• Design general solutions into your application
  architecture
• Consider needs of platforms like WebSpeed and Web
  services for SOA

47
Design for the future

• Prepare your application for future requirements
• WebSpeed for a browser-based UI
• .NET, PDA, or other new UI platforms
• Access as Web Services
• Service Oriented Architecture

48
PSDN white papers on Implementing the OpenEdge
Reference Architecture
-- The Service Interface Layer -- Context
Management
49
Questions?
50
Thank you foryour time
51
(No Transcript)