July 13, 2017 conference call

A new object model, the CAPE-OPEN Binary Interop Architecture (COBIA), has been proposed as a next step in the evolution of CAPE-OPEN. COBIA will include registration components, binary interoperability standards, and middleware that acts as a bridge between software components. Development of COBIA involves a number of tasks, grouped in phases, which can be performed incrementally. This memo is intended to describe these tasks, and provide an overview of the implementation process.

July 13, 2017 conference call

Postby colancto » 14 July 2017, 06:56

The Methods & Tools Special Interest Group of the CAPE-OPEN Laboratories Network (CO-LaN) held a conference call on July 13, 2017 to address the persistence mechanism provided in COBIA. Bill BARRETT (U.S. Environmental Protection Agency), Jasper van BATEN (AmsterCHEM), Michael HLAVINKA (Bryan Research & Engineering) and myself attended this call.

Starting from comments provided by Michael HALLORAN from the Interoperability Special Interest Group of CO-LaN, the motivations for the solution proposed were discussed and developed.

From the start the CAPE-OPEN standard did not develop its own persistence mechanism. Take a look at the document describing persistence and you will find that it relies solely on COM persistence. Since COBIA is out there to replace COM in whatever it is used for CAPE-OPEN, COBIA needs to develop its own persistence strategy. CAPE-OPEN imposes that any PMC implements at least one of the following COM persistence interfaces: IPersistStream or IPersistStreamInit. But any PMC may also implement other COM persistence interfaces and these may match (or not) the persistence strategy applied by a given PME. So a PME typically tries first its preferred persistence strategy by asking a PMC if it supports it, then falls back on either IPersistStream or IPersistStreamInit if its preferred persistence interface is not there. That leads to some complexity on both sides. Since COBIA is meant to simplify the implementation of CAPE-OPEN, it appeared a bad choice for COBIA to just reproduce the same persistence arrangement as with COM. Better go for a single persistence mechanism. But this is obviously debatable.

It is worth pointing out that the single choice made for COBIA in terms of persistence is not supposed to impact existing COM PMEs and PMCs. COMBIA is there to make interoperabilty work in terms of persistence. A COM PME will be able to persist a COBIA PMC since the COM persistence interface, either IPersistStream or IPersistStreamInit, sought after by the PME on the COBIA PMC, will be present in COMBIA and capable to translate into the COBIA persistence mechanism. So a COM PME won't need to be modified regarding persistence. Same for the other way round.

Next comes the persistence technology chosen by COBIA. COBIA is developing a persistence mechanism which will lead to human-readable persisted data. It seems the proper way to ensure that over time persisted data is still accessible. So a COBIA PMC will provide to a COBIA PME its object data in a serialized form. The COBIA PME will then execute its flowsheet persistence in any way it thinks fit. But at least COBIA won't prevent the whole flowsheet persistence to be in a human-readable form.

You are welcome to provide feedback on the above general motivations. More details will be provided later on.
User avatar
colancto
Administrateur
 
Posts: 92
Joined: 23 October 2012, 11:46

Return to COBIA: CAPE-OPEN Object Model

Who is online

Users browsing this forum: No registered users and 0 guests

cron