Speaking at the Object World West Conference in San Francisco last month, Alan Doniger, POSC's technical director presented POSC's effort in the field of co-operative industry migration as a success story in the application of object technology. The objectives of the POSC initiative are to organize the E&P computing industry's migration to object technology with the goal of providing interoperability through re-use and exchangeability of software components. The usual benefits of cost, risk and cycle time reduction were claimed and the mantra of "core business, buy not build and outsource" recited before presenting the results of POSC's Interoperability Architecture Group.
RFT
Comprised of members from POSC, Chevron, Elf, Schlumberger and Prism, this team is working on a request for technology (RFT) to define and build E&P Business Objects (BO). Despite the "success" claim, it is still early days for this group which is considering such basic level issues as
Which features should be standardized to facilitate interoperability
How should the BO interface be designed
What services should be provided by BOs?
How should the Object Management Group's CORBA specification be implemented?
Clay Harter (Chevron) speaking for the POSC Interoperability team listed the various levels of compliance with the Business Object paradigm. Level 0 means that applications are required to use the same data store to achieve interoperability, level 1 means that applications can run against different data stores, and so on, with increasingly robust handling of issues such as data integrity and inter application coordination.
Nirvana?
The ultimate, level 5, implies that users can create "virtual applications" from plug and play components. It is interesting to note that the combined efforts of POSC to date have only specified a level 0 compliant model (Epicentre). Some members of the POSC object group have already have expressed alarm at the prospect of having to jettison their Epicentre developments and there is debate as to the extent to which the new POSC BO's will be Epicentre derived or a radical departure. This is an important issue because as you climb the levels of Object Interoperability, the standard data model's role is considerably reduced.
The move to objects is undoubtedly important, but it is too early to talk of "success". Many issues need to be resolved first such as what object model will prevail - competition between the UNIX CORBA model and the Microsoft ActiveX/DCOM is hotting-up with Software AG (the developers of the corporate heavyweight package SAP R/3) now offering ActiveX on Solaris. Other UNIX implementations of this technology will be rolling out in the next few months. Another weak aspect of POSC's BO push is the relatively poor attendance in the BO group. Few oil companies are prepared to get their hands dirty with this low level stuff these days and most vendors are either working on their own on this technology, or adopting a wait and see approach.
Discovery bogs
Meanwhile at an altogether more prosaic level, Discovery, the collaborative effort between POSC, PPDM and major E&P software vendors plus a few Oil Cos. to come up with a workable commercial strength subset of the POSC Epicentre data model, is rumored to have gotten bogged down somewhat. The objective of the Discovery project, initiated in 1995 is to develop a physical relational data model that is a subset of Epicentre. This is not the first time such collaboration has been attempted, POSC and PPDM tried it before in the early 80's and it ended in tears then. Officially Discovery is still there, and is still intended to make up the next major release (Release 4.0) of the PPDM data model, providing it is adopted by the PPDM membership at the next AGM. Our inside track on project Discovery suggests that this is unlikely. The process involved in "subsetting" Epicentre into a PPDM format has been painful and inconclusive.
Express
The essence of the problem is that Epicentre is defined in Express, a complex and rich language with high level properties such as inheritance and complex attributes. Mapping to any relational projection is a difficult process, which stressed the Discovery team to the limit and beyond. PDM understands that Discovery members are not overly keen in getting involved in other projects from hell like this - "total burnout" was how the state of most project members was described to PDM. Whether or not Discovery makes it to PPDM V4.0, one thing is clear. The mapping of Epicentre to the relational plane has proved a Herculean task for some of the best brains in the E&P data modeling business. This means either that we should be taking on some more rocket scientists for our model building, or maybe looking for an easier way of doing business. Objects? We wish!
Click here to comment on this article
If your browser does not work with the MailTo button, send mail to pdm@the-data-room.com with PDM_V_2.0_199708_1 as the subject.
© Oil IT Journal - all rights reserved.