Composite Application
Framework
Composite Application Framework (CAF) provides the ability to import services provided by back-end systems as external services, model business objects and implement business logic in Java as application services.
The key features of CAF are:
· Modeling of business objects and generation of persistency, lifecycle methods, and optionally, Query methods
● Providing the business logic as services to the user interface layer
● Back-end connectivity: Web services, BAPIs, and RFCs
Business Objects
Business objects represent nodes of business objects in CAF. Here the notion of a business object node represents a data container with a set of attributes defining:
● The structure of business object instances stored in it
● The lifecycle methods create, read, update, delete (CRUD), each working on a single instance per call
● Query methods to retrieve multiple instances based on conditions
Regarding persistency, you have two options with business objects: local and remote. Local persistency means that CAF creates a database model in the system database of the Application Server Java that reflects the structure of your business object. Remote persistency implies that you use RFCs or Web services to persist data in an external system.
When creating business objects, you must consider the following:
● Use local business objects to store data only existing in your composite application
● Avoid pure external data replication. It is possible, but it means that you have to implement synchronization, which is complicated.
Cross-system locking and conflict resolution of simultaneous changes are not handled automatically. Therefore, replication of persistent data between composite applications and their back-end systems may add complexity. This is possible if the same data can be changed at the same time in two or more places.
This can be avoided by:
○ Specific authority or status concepts preventing the change in the back-end system
○ A process design creating the business objects in the back-end systems not before the process within the composite applications ends
○ Storing only references to the business objects in the back-end systems and not persisting their data (redundantly) in composite applications
Application Services
Application services allow for the logical transformation and combination of data from underlying business objects, external services or other application services, triggering actions and performing any kind of business-logic-relevant operation.
When working with application services, the following rules apply:
● Only put simple business logic directly into an application service operation
● Put more complex business logic into external additional Java classes
This enables you to create more sophisticated class designs and, even more importantly, allows a number of developers to work on the business logic.
This means you have to create a plain Java development component (DC) to put your additional classes into and publish them as public part entities.
● Enable application services as Web services. Process logic and UI layer only use these as interface to the business logic. You can do this by adding the respective operation to the Web service configuration that was created.
External Services
● External services based on Web services are recommended.
● An external service is connected to exactly one service endpoint.
There is no transactional bracket to ensure the consistency in case of multiple service endpoints.
● External services are only called out of application services using the generated APIs.
This is because remote business objects may not be used.
All service APIs generated by the CAF framework can be found in the ejbmodule subproject of your CAF project, since all business objects, application services, and external services are reflected by stateless EJB session beans.
More Information
