WS-AppServer BusObject Mapping (1)

Suppose you are involved in a Cordys project with a good amount of detailed business logic to be developed in WS-AppServer, UI development, and data storage in some RDBMS and/or External Information System. You will need to come up with the database model (relational modeling), the domain model (OO modeling), UI’s, etc, typically resulting in 3 main categories of WS-AppServer classes. Let’s take a next perspective, and depict a layered organization of these classes as per class instances. At the same time, lets include quite a number of possible combinations on how the data for a certain class instance is collected with help of other classes or RDBMS/EIS.

Not every project will need this much layers and combination of classes, however the above picture will illustrate you the subject of this blog post. It gives a runtime view; the design view with inheritance, association and composition is quite a different view, and not relevant here.

Class instances in WS-AppServer are so called BusObjects. BusObjects which directly map to a database table are called StateBusObjects; transient instances are called CustomBusObjects. A CustomBusObject which has no corresponding class definition in the WS-AppServer Repository is called an AnonymousBusObject.

Notice a BusObject in the Business layer or UI layer possibly can be directly derived from the data in the database in case the structure happens to be 1 to 1.

As the Cordys platform is very much XML-based, this approach is also visible in WS-AppServer, where the object data inside the BusObject is represented as an XML document. Apart from the fact this integrates well into the Cordys ESB, it also gives advantages in the subject of BusObject mapping, as mapping on the XML layer handles more smoothly as compared to mapping  with help of native object properties.

Mappings can be bi-directional: one direction to collect the data and the other direction to update the data. Next are scenario’s of BusObject mapping:

• When querying a record from the DB, the XQY layer returns an XML data structure. It needs to be mapped to the structure of the WS-AppServer class definition. Possible situations:
  • 1 to 1 mapping
  • The class name is different from the table name, and so to be mapped.
  • One or more attributes do have names different from the column names.
  • Table/column names are in upper case, whereas the class definition uses camel case, and so to be mapped.
  • The resulting structure from the DB query is nested, but the class definition is flat.
  • The class definition only has a subset of data elements as compared to the DB query result.

• A domain object like a Claim needs to have its data collected and mapped from claim business data in EIS and claim process data in the RDBMS. Subsequently, several UI objects needs to get there data from the Claim object, where those UI objects can have different structures as per the user role perspective (claim handler, approver, financial controller, fraud investigator, etc), or as per the claim process step in the BPM.
  Notice the ‘intermediate’ role of the Claim domain class here as between the backend structures and the UI structures.

In the next 2 articles, we will subsequently dive into more details wrt these 2 scenario’s as to see what facilities WS-AppServer offer us to support these mappings.