1. ARCH-7: A Class-Based Implementation of the OpenEdge® Reference Architecture
John Sadd
Fellow and OpenEdge Evangelist
Applied Technology

2. Goals for the session
Show practical implications of the OpenEdge Reference Architecture
Show how ABL support for classes is useful
Discuss some interesting issues and choices

3. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

4. Common Infrastructure
OpenEdge Reference Architecture For Service Oriented Business Applications
Design for longevity, flexibility, and competitive advantage
Accommodates evolving business requirements
Anticipates trends in technology
Provides agile and flexible architecture
Presentation
Enterprise Services
Business Components
Common Infrastructure
Data Access
Main Point(s): There are 3 ways Progress enables you to seize the opportunities SOA brings: Architecture, Product, and Standards. 1) In addition to delivering the OpenEdge platform, we are delivering best practices for building competitive business applications. 2) The Reference Architecture is designed to make it easier to develop and sustain competitive advantage.
Supporting Points:
The OpenEdge Reference Architecture (OERA) was designed as our view of the appropriate architecture for Service Oriented Business Applications (SOBA). As such, it is tuned to both the requirements of SOA and the capabilities of OpenEdge.
OERA, presented in summary here, is designed to make it easier to introduce both technical and functional advances into an existing application as needed and as available.
Like most software architectures, OERA is designed as a theoretical blueprint. It is possible to use OpenEdge 10 to write software that adheres 100% to the principles demonstrated in the architecture. Each partner, however, will need to decide which aspects of the architecture to use, and which to ignore.
OERA doesn’t require complete “purity”: It is possible to achieve the desired results without some elements of the architecture, and it is possible to mix-and-match this approach with legacy code and/or more traditional architectures.
Sample Script:
The features that we delivered in OpenEdge 10 go a long way on delivering on the vision of making OpenEdge a service-oriented development platform, but we still have plenty to do. We have a long-range vision of a complete OpenEdge application development and deployment platform built around the core concepts of service oriented business applications. These ideas all build on the current and traditional strengths of OpenEdge. We already have a great language and great platform for building business applications, but there is more we need to do.
So if we‘re going to work together on the development of service-oriented business applications then we need to agree on what they look like. The OpenEdge Reference Architecture is our model for how to build service-oriented business applications. It’s not business domain specific or technology specific. Rather its our model for how to build a competitive, agile, service-oriented business application. If you look behind the scenes at any business application that has remained highly competitive over a long period of time and you will find three distinct characteristics: 1) Continuing attention to the distinct needs of the industry served by the application, 2) it is constantly upgraded to include new features, technology, and functionality, and 3) a strong application architecture that makes it much easier to evolve and enhance then application, keeping it fresh and ahead of the competition.
That’s the idea behind the OpenEdge Reference Architecture. We want to provide the best practices of business application construction to our entire partner base. We worked with dozens of partners and industry experts to pull together an architectural vision designed to help our partners get the most out of our platform and their applications.
It is a model that provides a clean separation between the presentation layer and the business servicing layer so that multiple user interfaces can be used and so that same business serving layer can be access via various integration technologies.
Next is the business servicing layer, which provides a best practices approach to how business logic should be structured. We have a specific model for how business logic should be structured so that the application is easier to enhance. Lastly, there is the data access layer.
This is where Prodatasets really come in as a very powerful tool. Using Prodatasets you can isolate the core of your business logic from the physical layout of your datasource, thus making the application easier to build because it is based on the layout of the dataset and not the data source.
Now, the thing to keep in mind is that the reference architecture is not an product. You can’t order it on our price list. But you definitely can benefit from it. We’re working every day with partners that are applying all or parts of this architecture. We’ll be rolling out classes, seminars, white papers, and templates for implementing the OpenEdge Reference architecture all through 2005.
Details:
Clearly articulate the Value Proposition of the underlying capabilities
Balance competing forces eg user demands vs technical cost, flexibility vs performance, first vs best, art vs craft
Roadmap paths that incorporate Industry Trends, Business and Technical aspirations
Capturing and evolving Valuable Intellectual Property ($)
Design Objectives, Principals, Assumptions, Alternatives and Decisions
System Capabilities, Use, Limits
Essential Artifacts eg Specifications, Practices, Terms
Value Proposition (architectures marketable capabilities)
Reducing complexity, optimizing resources and improving quality through a system of
Models eg SOA, MDA, MVC
Patterns eg Façade, Active Record,
Standards eg
Methods and Techniques eg RUP,
Incorporate proven and applicable industry standards, models and methods
ETC
Data Sources

5. Basic Architecture Principles
Avoid duplicated code!
“ABL is a great language – we want you to write less of it.”
Do every job once and only once.
Outlaw Copy-Paste-Edit!
Factor! Factor! Factor!
Don’t hardwire things that are liable to change!
That’s what the OERA layers are there for…

6. Implementing the OpenEdge Reference Architecture on PSDN

7. For example: Business Entities using Procedures
Server BE procs
Business Entity
beOrder.p
Super Procedure
beSupport.p
SUPER
beEntity.i
RUN daOrder.p
PROC fetchWhere: …
dsOrder.i
{etOrder.i}
{etOrderLine.i}
{etItem.i}
DEFINE DATASET…
Template procedures
Include files
Super procedures
RUN VALUE (…)
Data Access Object
beOrderValidate.p
(optional)
eOrderLineModifyPreTrans:
SUPER

8. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

9. Basic principles of using classes in ABL
Strong typing
Compiler knows exactly what everything is
Compiler cross-checks classes
Much more robust error checking at compile time
Inheritance of common behavior
Definitional, not done at runtime
Compiler checking of validity
Always invoke the most-derived version

10. Overview of server-side classes

11. Top-level class componentbase.cls
CLASS base.componentbase IMPLEMENTS interfaces.iComponent:
/* Base class for all objects. Locates the service manager, which it expects
some startup routine to have created. */
DEFINE PROTECTED PROPERTY servicemgr AS service.servicemgr NO-UNDO
GET.
PRIVATE SET.
CONSTRUCTOR PROTECTED componentbase():
DEFINE VARIABLE sessionObject AS progress.lang.object.
sessionObject = SESSION:FIRST-OBJECT.
DO WHILE VALID-OBJECT(sessionObject) AND
sessionObject:GetClass():TypeName <> 'service.servicemgr':
sessionObject = sessionObject:NEXT-SIBLING.
END.
IF NOT VALID-OBJECT(sessionObject) THEN
FatalError( "Session management service not found!").
ELSE
servicemgr = CAST (sessionObject, service.servicemgr).
END CONSTRUCTOR.
METHOD PUBLIC VOID FatalError (pcMessage AS CHAR):
MESSAGE "Fatal error!" SKIP pcMessage VIEW-AS ALERT-BOX ERROR.

12. The CLASS statement
The CLASS statement identifies the class by name and by package to the compiler
If it INHERITS another class this is named
If it IMPLEMENTS an interface this is named
CLASS base.componentbase IMPLEMENTS interfaces.iComponent:
INTERFACE interfaces.icomponent:
METHOD PUBLIC VOID initializeComponent().
METHOD PUBLIC VOID destroyComponent().
END INTERFACE.

13. Data members and properties
Data members in a class can be PUBLIC, PROTECTED, or PRIVATE
The data type can be a class type
For added control you can define data as properties
GET phrase controls read access and behavior
SET phrase controls write access and behavior
DEFINE PROTECTED PROPERTY servicemgr AS service.servicemgr NO-UNDO
GET.
PRIVATE SET.

14. Constructors and destructors in classes
The CONSTRUCTOR represents the “main block” code
It can have parameters but no return type
It can be inherited and overridden
CONSTRUCTOR PROTECTED componentbase(): …
END CONSTRUCTOR
The DESTRUCTOR represents the code to execute when the object is deleted
It has no parameters and no return type
It is reliably invoked unless the whole session ends unexpectedly

15. The object hierarchy CONSTRUCTOR code locates the service manager
sessionObject
progress.lang.object
CONSTRUCTOR code locates the service manager
CAST
servicemgr
service.servicemgr
DEFINE VARIABLE sessionObject AS progress.lang.object.
sessionObject = SESSION:FIRST-OBJECT.
DO WHILE VALID-OBJECT(sessionObject) AND
sessionObject:GetClass():TypeName <> 'service.servicemgr':
sessionObject = sessionObject:NEXT-SIBLING.
END.
IF NOT VALID-OBJECT(sessionObject) THEN
FatalError( "Session management service not found!").
ELSE
servicemgr = CAST (sessionObject, service.servicemgr).
DEFINE PROTECTED PROPERTY servicemgr AS service.servicemgr NO-UNDO
GET.
PRIVATE SET.

16. Methods in classes
Methods take the place of internal procedures and functions
They define parameters and a return type like functions do
VOID means there’s no return type
Like data members, they are PUBLIC, PROTECTED, or PRIVATE
METHOD PUBLIC VOID FatalError (pcMessage AS CHAR):
MESSAGE "Fatal error!" SKIP pcMessage VIEW-AS ALERT-BOX ERROR.
END.

17. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

18. Business Entities and Data Access Objects

19. Business Component classes
CLASS base.businesscomponent INHERITS base.componentbase:
CLASS base.businessentity INHERITS base.businesscomponent
IMPLEMENTS interfaces.ibusinessentity:
DEFINE PROTECTED VARIABLE dataAccess AS base.dataaccessobject.
METHOD fetchData():
dataAccess:loadData().
CLASS samples.beCustomer INHERITS base.businessentity:
{samples/dsCustomer.i}
CONSTRUCTOR PUBLIC beCustomer ():
dataAccess =
CAST (servicemgr:startService (‘samples.daCustomer',"da"),
samples.daCustomer).
END CONSTRUCTOR.
METHOD PUBLIC OVERRIDE VOID validateData():
SUPER:validateData().
validateCustomer(INPUT-OUTPUT DATASET-HANDLE hdsDataset BY-REFERENCE).
END METHOD.
METHOD PRIVATE VOID validateCustomer(INPUT-OUTPUT DATASET dsCustomer): …

20. CLASS base.dataaccess INHERITS base.componentbase:
Data Access classes
CLASS base.dataaccess INHERITS base.componentbase:
CLASS base.dataaccessobject INHERITS base.dataaccess
IMPLEMENTS interfaces.idataaccess: …
METHOD PUBLIC VOID loadData():
hdsDataset:EMPTY-DATASET().
setFillMode('MERGE':U).
attachDatasource().
fillDataset().
detachDatasource().
END METHOD.
CLASS samples.daCustomer INHERITS base.dataaccessobject:
{samples/dsCustomer.i &REFERENCE-ONLY=REFERENCE-ONLY}
METHOD PUBLIC OVERRIDE VOID attachDatasource():
bufferDatasource('ttCustomer',
'Customer',
'CustNum',
'',
'FOR EACH Customer').
END METHOD.

21. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

22. Common Infrastructure
OpenEdge Reference Architecture: How do you invoke a Business Component?
Client session
Presentation
Enterprise Services
AppServer™ session
Business Components
Common Infrastructure
Data Access
Main Point(s): There are 3 ways Progress enables you to seize the opportunities SOA brings: Architecture, Product, and Standards. 1) In addition to delivering the OpenEdge platform, we are delivering best practices for building competitive business applications. 2) The Reference Architecture is designed to make it easier to develop and sustain competitive advantage.
Supporting Points:
The OpenEdge Reference Architecture (OERA) was designed as our view of the appropriate architecture for Service Oriented Business Applications (SOBA). As such, it is tuned to both the requirements of SOA and the capabilities of OpenEdge.
OERA, presented in summary here, is designed to make it easier to introduce both technical and functional advances into an existing application as needed and as available.
Like most software architectures, OERA is designed as a theoretical blueprint. It is possible to use OpenEdge 10 to write software that adheres 100% to the principles demonstrated in the architecture. Each partner, however, will need to decide which aspects of the architecture to use, and which to ignore.
OERA doesn’t require complete “purity”: It is possible to achieve the desired results without some elements of the architecture, and it is possible to mix-and-match this approach with legacy code and/or more traditional architectures.
Sample Script:
The features that we delivered in OpenEdge 10 go a long way on delivering on the vision of making OpenEdge a service-oriented development platform, but we still have plenty to do. We have a long-range vision of a complete OpenEdge application development and deployment platform built around the core concepts of service oriented business applications. These ideas all build on the current and traditional strengths of OpenEdge. We already have a great language and great platform for building business applications, but there is more we need to do.
So if we‘re going to work together on the development of service-oriented business applications then we need to agree on what they look like. The OpenEdge Reference Architecture is our model for how to build service-oriented business applications. It’s not business domain specific or technology specific. Rather its our model for how to build a competitive, agile, service-oriented business application. If you look behind the scenes at any business application that has remained highly competitive over a long period of time and you will find three distinct characteristics: 1) Continuing attention to the distinct needs of the industry served by the application, 2) it is constantly upgraded to include new features, technology, and functionality, and 3) a strong application architecture that makes it much easier to evolve and enhance then application, keeping it fresh and ahead of the competition.
That’s the idea behind the OpenEdge Reference Architecture. We want to provide the best practices of business application construction to our entire partner base. We worked with dozens of partners and industry experts to pull together an architectural vision designed to help our partners get the most out of our platform and their applications.
It is a model that provides a clean separation between the presentation layer and the business servicing layer so that multiple user interfaces can be used and so that same business serving layer can be access via various integration technologies.
Next is the business servicing layer, which provides a best practices approach to how business logic should be structured. We have a specific model for how business logic should be structured so that the application is easier to enhance. Lastly, there is the data access layer.
This is where Prodatasets really come in as a very powerful tool. Using Prodatasets you can isolate the core of your business logic from the physical layout of your datasource, thus making the application easier to build because it is based on the layout of the dataset and not the data source.
Now, the thing to keep in mind is that the reference architecture is not an product. You can’t order it on our price list. But you definitely can benefit from it. We’re working every day with partners that are applying all or parts of this architecture. We’ll be rolling out classes, seminars, white papers, and templates for implementing the OpenEdge Reference architecture all through 2005.
Details:
Clearly articulate the Value Proposition of the underlying capabilities
Balance competing forces eg user demands vs technical cost, flexibility vs performance, first vs best, art vs craft
Roadmap paths that incorporate Industry Trends, Business and Technical aspirations
Capturing and evolving Valuable Intellectual Property ($)
Design Objectives, Principals, Assumptions, Alternatives and Decisions
System Capabilities, Use, Limits
Essential Artifacts eg Specifications, Practices, Terms
Value Proposition (architectures marketable capabilities)
Reducing complexity, optimizing resources and improving quality through a system of
Models eg SOA, MDA, MVC
Patterns eg Façade, Active Record,
Standards eg
Methods and Techniques eg RUP,
Incorporate proven and applicable industry standards, models and methods
ETC
Data Sources

23. Principles for making calls to the AppServer
You can run a procedure on an AppServer
You can run an internal procedure, but only by binding the AppServer session first
Binding the AppServer is not a good idea
This also requires multiple calls to complete a single request
You want the AppServer to be stateless
You cannot instantiate a class on the AppServer
You don’t want clients directly calling Business Component classes anyway!
So: Define a procedure on the server to handle a specific request for a specific Business Component type

24. The Service Adapter and Service Interface
Presentation
Client session
Enterprise Services
Service Adapter
AppServer session
Service Interface
Business Components
Common Infrastructure
Data Access
Main Point(s): There are 3 ways Progress enables you to seize the opportunities SOA brings: Architecture, Product, and Standards. 1) In addition to delivering the OpenEdge platform, we are delivering best practices for building competitive business applications. 2) The Reference Architecture is designed to make it easier to develop and sustain competitive advantage.
Supporting Points:
The OpenEdge Reference Architecture (OERA) was designed as our view of the appropriate architecture for Service Oriented Business Applications (SOBA). As such, it is tuned to both the requirements of SOA and the capabilities of OpenEdge.
OERA, presented in summary here, is designed to make it easier to introduce both technical and functional advances into an existing application as needed and as available.
Like most software architectures, OERA is designed as a theoretical blueprint. It is possible to use OpenEdge 10 to write software that adheres 100% to the principles demonstrated in the architecture. Each partner, however, will need to decide which aspects of the architecture to use, and which to ignore.
OERA doesn’t require complete “purity”: It is possible to achieve the desired results without some elements of the architecture, and it is possible to mix-and-match this approach with legacy code and/or more traditional architectures.
Sample Script:
The features that we delivered in OpenEdge 10 go a long way on delivering on the vision of making OpenEdge a service-oriented development platform, but we still have plenty to do. We have a long-range vision of a complete OpenEdge application development and deployment platform built around the core concepts of service oriented business applications. These ideas all build on the current and traditional strengths of OpenEdge. We already have a great language and great platform for building business applications, but there is more we need to do.
So if we‘re going to work together on the development of service-oriented business applications then we need to agree on what they look like. The OpenEdge Reference Architecture is our model for how to build service-oriented business applications. It’s not business domain specific or technology specific. Rather its our model for how to build a competitive, agile, service-oriented business application. If you look behind the scenes at any business application that has remained highly competitive over a long period of time and you will find three distinct characteristics: 1) Continuing attention to the distinct needs of the industry served by the application, 2) it is constantly upgraded to include new features, technology, and functionality, and 3) a strong application architecture that makes it much easier to evolve and enhance then application, keeping it fresh and ahead of the competition.
That’s the idea behind the OpenEdge Reference Architecture. We want to provide the best practices of business application construction to our entire partner base. We worked with dozens of partners and industry experts to pull together an architectural vision designed to help our partners get the most out of our platform and their applications.
It is a model that provides a clean separation between the presentation layer and the business servicing layer so that multiple user interfaces can be used and so that same business serving layer can be access via various integration technologies.
Next is the business servicing layer, which provides a best practices approach to how business logic should be structured. We have a specific model for how business logic should be structured so that the application is easier to enhance. Lastly, there is the data access layer.
This is where Prodatasets really come in as a very powerful tool. Using Prodatasets you can isolate the core of your business logic from the physical layout of your datasource, thus making the application easier to build because it is based on the layout of the dataset and not the data source.
Now, the thing to keep in mind is that the reference architecture is not an product. You can’t order it on our price list. But you definitely can benefit from it. We’re working every day with partners that are applying all or parts of this architecture. We’ll be rolling out classes, seminars, white papers, and templates for implementing the OpenEdge Reference architecture all through 2005.
Details:
Clearly articulate the Value Proposition of the underlying capabilities
Balance competing forces eg user demands vs technical cost, flexibility vs performance, first vs best, art vs craft
Roadmap paths that incorporate Industry Trends, Business and Technical aspirations
Capturing and evolving Valuable Intellectual Property ($)
Design Objectives, Principals, Assumptions, Alternatives and Decisions
System Capabilities, Use, Limits
Essential Artifacts eg Specifications, Practices, Terms
Value Proposition (architectures marketable capabilities)
Reducing complexity, optimizing resources and improving quality through a system of
Models eg SOA, MDA, MVC
Patterns eg Façade, Active Record,
Standards eg
Methods and Techniques eg RUP,
Incorporate proven and applicable industry standards, models and methods
ETC
Data Sources

25. The Service Adapter

26. The role of the Service Adapter
You don’t want client objects knowing the details about Business Components
Where they’re located
Exactly what their APIs are
How to route a request to them
The Service Adapter provides a key layer of indirection and discovery

27. The role of the Service Interface
Defines a point of entry for each accessible method in each Business Component
Static parameters for those methods so they are self-describing
Common services invoked consistently and automatically
Authentication, security, context…
So you want client Service Adapters calling Service Interface procedures!

28. The Service Adapter class on the client
CLASS pres.serviceadapter INHERITS base.componentbase:
CONSTRUCTOR PUBLIC serviceadapter():
hAppServer = IF VALID-HANDLE(SESSION:FIRST-SERVER)
THEN SESSION:FIRST-SERVER
ELSE SESSION:HANDLE.
END CONSTRUCTOR.
METHOD PUBLIC VOID fetchData (OUTPUT DATASET-HANDLE dsDataset):
RUN VALUE(getSIPath() + "_fetchdata.p")
ON hAppServer (OUTPUT DATASET-HANDLE dsDataset).
END METHOD.
METHOD PROTECTED CHARACTER getSIPath ():
RETURN ?.
END CLASS.
CLASS samples.pres.saCustomer INHERITS pres.serviceadapter:
METHOD PROTECTED OVERRIDE CHARACTER getSIPath():
RETURN “samples/api/beCustomer".
END METHOD.
END CLASS.

29. The Service Interface procedure on the server
/* becustomer_fetchdata.p */
&SCOPED-DEFINE PACKAGE-NAME samples
&SCOPED-DEFINE COMPONENT-NAME customer
&SCOPED-DEFINE METHOD-NAME fetchData
&SCOPED-DEFINE PARAM-LIST {templates/fetchdata_params.i}
&SCOPED-DEFINE PREFIX-NAME be
&SCOPED-DEFINE DATASET-MODE OUTPUT
{templates/apicode.i}
servicemgr:sessionContextService:setContextId(pcContextId).
authenticationService = servicemgr:authenticationService.
authenticationService:loadPrincipal().
{&PREFIX-NAME}{&COMPONENT-NAME} =
CAST (servicemgr:startService
('{&PACKAGE-NAME}.{&PREFIX-NAME}{&COMPONENT-NAME}',
"{&PREFIX-NAME}"),
{&PACKAGE-NAME}.{&PREFIX-NAME}{&COMPONENT-NAME}).
{&PREFIX-NAME}{&COMPONENT-NAME}:{&METHOD-NAME}({&PARAM-LIST}).

30. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

31. Repeatable elements in an application
Service Adapter
class
Service Interface
procedure
Business Entity
class
Data Access Object
class
Data Source Object
class

32. Business Entity class template/*
File : be<entity-name>.cls
Purpose : Generated from the template for Business Entity classes
Description : Sample Business Entity for <entity-name>
Edited : April 2007 */
CLASS <package-name>.be<entity-name> INHERITS base.businessentity:
{<package-name>/ds<entity-name>.i &REFERENCE-ONLY=REFERENCE-ONLY}
CONSTRUCTOR PUBLIC be<entity-name>():
dataAccess = CAST (servicemgr:startService
(‘<package-name>.da<entity-name>', "da"),
<package-name>.da<entity-name> ).
END CONSTRUCTOR. …
END CLASS.

33. List of preprocessors and other values
PACKAGE-NAME
ENTITY-NAME (or COMPONENT-NAME)
PREFIX-NAME (e.g., ‘be’)
For Data-Sources:
Temp-table name
Database table list
(Optional) database key field list
Field mapping between physical and logical
Base DB query (‘FOR EACH <table-name>’)

34. Business Entity with the blanks filled in/*
File : beCustOrder.cls
Purpose : Generated from the template for Business Entity classes
Description : Sample Business Entity for CustOrder
Edited : 04/04/07 */
CLASS Sports2000.CustOrder.beCustOrder INHERITS base.businessentity:
{Sports2000.CustOrder/dsCustOrder.i &REFERENCE-ONLY=REFERENCE-ONLY}
CONSTRUCTOR PUBLIC beCustOrder():
dataAccess = CAST (servicemgr:startService
('Sports2000.CustOrder.daCustOrder',"da"),
Sports2000.CustOrder.daCustOrder).
END CONSTRUCTOR. …
END CLASS.

35. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

36. OpenEdge Reference Architecture Common Infrastructure
Core Services
Auditing…
ABL Managers
Authorization
Context Management
Presentation
Enterprise Services
Business Components
Common Infrastructure
Data Access
Main Point(s): There are 3 ways Progress enables you to seize the opportunities SOA brings: Architecture, Product, and Standards. 1) In addition to delivering the OpenEdge platform, we are delivering best practices for building competitive business applications. 2) The Reference Architecture is designed to make it easier to develop and sustain competitive advantage.
Supporting Points:
The OpenEdge Reference Architecture (OERA) was designed as our view of the appropriate architecture for Service Oriented Business Applications (SOBA). As such, it is tuned to both the requirements of SOA and the capabilities of OpenEdge.
OERA, presented in summary here, is designed to make it easier to introduce both technical and functional advances into an existing application as needed and as available.
Like most software architectures, OERA is designed as a theoretical blueprint. It is possible to use OpenEdge 10 to write software that adheres 100% to the principles demonstrated in the architecture. Each partner, however, will need to decide which aspects of the architecture to use, and which to ignore.
OERA doesn’t require complete “purity”: It is possible to achieve the desired results without some elements of the architecture, and it is possible to mix-and-match this approach with legacy code and/or more traditional architectures.
Sample Script:
The features that we delivered in OpenEdge 10 go a long way on delivering on the vision of making OpenEdge a service-oriented development platform, but we still have plenty to do. We have a long-range vision of a complete OpenEdge application development and deployment platform built around the core concepts of service oriented business applications. These ideas all build on the current and traditional strengths of OpenEdge. We already have a great language and great platform for building business applications, but there is more we need to do.
So if we‘re going to work together on the development of service-oriented business applications then we need to agree on what they look like. The OpenEdge Reference Architecture is our model for how to build service-oriented business applications. It’s not business domain specific or technology specific. Rather its our model for how to build a competitive, agile, service-oriented business application. If you look behind the scenes at any business application that has remained highly competitive over a long period of time and you will find three distinct characteristics: 1) Continuing attention to the distinct needs of the industry served by the application, 2) it is constantly upgraded to include new features, technology, and functionality, and 3) a strong application architecture that makes it much easier to evolve and enhance then application, keeping it fresh and ahead of the competition.
That’s the idea behind the OpenEdge Reference Architecture. We want to provide the best practices of business application construction to our entire partner base. We worked with dozens of partners and industry experts to pull together an architectural vision designed to help our partners get the most out of our platform and their applications.
It is a model that provides a clean separation between the presentation layer and the business servicing layer so that multiple user interfaces can be used and so that same business serving layer can be access via various integration technologies.
Next is the business servicing layer, which provides a best practices approach to how business logic should be structured. We have a specific model for how business logic should be structured so that the application is easier to enhance. Lastly, there is the data access layer.
This is where Prodatasets really come in as a very powerful tool. Using Prodatasets you can isolate the core of your business logic from the physical layout of your datasource, thus making the application easier to build because it is based on the layout of the dataset and not the data source.
Now, the thing to keep in mind is that the reference architecture is not an product. You can’t order it on our price list. But you definitely can benefit from it. We’re working every day with partners that are applying all or parts of this architecture. We’ll be rolling out classes, seminars, white papers, and templates for implementing the OpenEdge Reference architecture all through 2005.
Details:
Clearly articulate the Value Proposition of the underlying capabilities
Balance competing forces eg user demands vs technical cost, flexibility vs performance, first vs best, art vs craft
Roadmap paths that incorporate Industry Trends, Business and Technical aspirations
Capturing and evolving Valuable Intellectual Property ($)
Design Objectives, Principals, Assumptions, Alternatives and Decisions
System Capabilities, Use, Limits
Essential Artifacts eg Specifications, Practices, Terms
Value Proposition (architectures marketable capabilities)
Reducing complexity, optimizing resources and improving quality through a system of
Models eg SOA, MDA, MVC
Patterns eg Façade, Active Record,
Standards eg
Methods and Techniques eg RUP,
Incorporate proven and applicable industry standards, models and methods
ETC
Data Sources

37. The Service Manager

38. The role of the Service Manager
CLASS service.servicemgr INHERITS base.manager
IMPLEMENTS interfaces.iservicemgr, interfaces.icomponent:
DEFINE TEMP-TABLE ttSessionComponent NO-UNDO
FIELD ComponentName AS CHARACTER
FIELD ComponentType AS CHARACTER
FIELD ComponentRef AS progress.lang.object
FIELD SINGLETON AS LOGICAL. …
METHOD PUBLIC progress.lang.object startService
(pcComponentName AS CHARACTER, pcComponentType AS CHARACTER):
FIND FIRST ttSessionComponent WHERE
ttSessionComponent.ComponentName = pcComponentName AND
ttSessionComponent.ComponentType = pcComponentType NO-LOCK NO-ERROR.
IF NOT AVAILABLE ttSessionComponent OR
NOT ttSessionComponent.SINGLETON THEN
RUN VALUE(cPackage + '/factory.p')
(cClass, OUTPUT oObject, OUTPUT lSingleton NO-ERROR.
RETURN (IF AVAILABLE ttSessionComponent THEN ttSessionComponent.ComponentRef
ELSE ?).
END METHOD.
END CLASS.

39. Invoking Business Component Instances
Service Adapter
class
Service Interface
procedure
Service
Manager
Business Component
class

40. The role of the factory
You can’t create a class instance dynamically the way you can with RUN VALUE(…)
The compiler insists on knowing what’s going on!
The factory has a case for each possible object to create
Organized by package and object type
/* samples/factory.p */
DEFINE INPUT PARAMETER pcObject AS CHARACTER NO-UNDO.
DEFINE OUTPUT PARAMETER objInstance AS progress.lang.object NO-UNDO.
DEFINE OUTPUT PARAMETER plSingleton AS LOGICAL NO-UNDO.
CASE pcObject:
WHEN 'becustomer' THEN DO:
objInstance = NEW samples.becustomer().
plSingleton = YES.
END.
WHEN 'dacustomer' THEN DO:
objInstance = NEW samples.dacustomer().
END CASE.

41. Using a factory procedure
Service Adapter
class
Service Interface
procedure
Service
Manager
Factory
procedure
Business Component
class

42. Alert! Planned (but of course not official) for 10.1C:
Service Adapter
class
Service Interface
procedure
Service
Manager
DYNAMIC-NEW language extension will allow the Service Manager to instantiate classes directly using an expression for the class name.
Business Component
class

43. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

44. Types of Context and State Information
Global context
Application service context
Client connection context
These types can be persisted by a context manager
Client request context
This is transient information
Does not need to be stored persistently

45. The context helper class
A complete implementation will have a context manager as Common Infrastructure
This can persist context for a session, for a user, for the entire application
This implementation uses a context helper class to manage transient state information
This information is passed between client and server as a context ProDataSet

46. ABL programming issues for the context class
The context class manages a ProDataSet instance and supporting methods
But you can’t pass an object (class instance) to the AppServer, only data
Therefore you have to extract the data and pass it to another object on the other side

47. Context helper class flow1
Client Service Requester
cltdatacontext.cls
Create client context instance
Populate data
Extract data
Pass DataSet to Service Adapter
Pass to Service Interface
Create server context instance
Bind context to DataSet passed from client 2
DATASET dsContext
setContext 4 3
Service Adapter 5 6
srvdatacontext.cls
Service Interface
DATASET-HANDLE from client
DATASET dsContext REF-ONLY 7

48. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

49. Using the DataSet builder to generate data for a custom tool to use

50. Getting database data instead of an XMI file

51. Extending the OE Architect Menus

52. Generating Component source files

53. Code generation sample: the template/*
File : be<entity-name>.cls
Purpose : Generated from the template for Business Entity classes
Description : Sample Business Entity for <entity-name>
Edited : April 2007 */
CLASS <package-name>.be<entity-name> INHERITS base.businessentity:
{<package-name>/ds<entity-name>.i &REFERENCE-ONLY=REFERENCE-ONLY}
CONSTRUCTOR PUBLIC be<entity-name>():
dataAccess = CAST (servicemgr:startService
(‘<package-name>.da<entity-name>', "da"),
<package-name>.da<entity-name> ).
END CONSTRUCTOR. …
END CLASS.

54. Code generation sample – the result/*
File : beCustOrder.cls
Purpose : Generated from the template for Business Entity classes
Description : Sample Business Entity for CustOrder
Edited : 04/04/07 */
CLASS Sports2000.CustOrder.beCustOrder INHERITS base.businessentity:
{Sports2000.CustOrder/dsCustOrder.i &REFERENCE-ONLY=REFERENCE-ONLY}
CONSTRUCTOR PUBLIC beCustOrder():
dataAccess = CAST (servicemgr:startService
('Sports2000.CustOrder.daCustOrder',"da"),
Sports2000.CustOrder.daCustOrder).
END CONSTRUCTOR. …
END CLASS.

55. A live look at generating components from templates using OpenEdge Architect Tools for Business Logic

56. Agenda OERA for SOBA and existing materials
Overview of a class-based approach
Server-side components
Bridging the gap from client to server
Using Templates
Introducing Managers
The Context Helper Class
Generating Components from OE Architect
Relational data in classes

57. Relational data in a class-based application
OpenEdge provides comprehensive support for relational data:
OpenEdge RDBMS and DataServers
Flexible language for managing sets of data
Temp-tables and ProDataSets
Support for classes in ABL provides key object-oriented language features:
Strong typing of data and class references
Definitional inheritance
Properties
PUBLIC, PROTECTED, and PRIVATE access modes

58. Data objects in an ABL application?
ABL does not specifically support true objects as data representations
No collections
Relational joins between related data elements
Cannot pass an object as a parameter between sessions
But – mapping relational physical data to objects and back is avoidable overhead
Conclusion: ABL supports the best – most practical – benefits of both worlds

59. In Summary
The layers of the OpenEdge Reference Architecture provide valuable structure that you can fill in without excessive effort
Using templates for standard component types
Using general-purpose supporting code
Classes in ABL can help you define your structure and assure its integrity
Resolve design issues in ways appropriate to your needs

60. For More Information, go to…
PSDN – OE Principles
Other Exchange sessions
ARCH-11: Building a Presentation Layer with Classes
ARCH-5: Modeling with UML
ARCH-12: Design Patterns
ARCH-2: OERA Latest Thinking
DEV-12: Object-Oriented Programming in ABL

61. Questions?

62. Thank you for your time!