(Please first read my Introduction to these comments on your papers.)
From your first slide:
My concern is that the BOF should greatly simplify the effort required by application developers to develop solutions to business problems. I am hopeful that this presentation will help potential submitters understand the requirements I see for the BOF from an application developer's perspective, so they can respond accordingly to the RFP.
I agree with all your high-level requirements as you described them in the context of a customer order. They are a necessary (though not sufficient) bill of requirements.
However, especially in the light of your first sentence I’ve just quoted, it is not clear to me how you see the closing of that gaping distance between CORBA and that simplifying BOF. Sure, you are hoping that - with the help of the "level of abstraction" you define - RFP responders will solve that problem, but it must be feasible if the industry is to persist with the OMG’s present architecture!
I really liked this bit too:
Why do we need a Business Object Model that is different from the model of objects used for other computations?
First, we should minimize the transformation effort required to implement models for business domains. This is important for development of flexible systems that meet user requirements. The more involved the transformation, the greater the difficulty in meeting user requirements.
Second, we should conceal computational mechanisms necessary to support applications in a distributed, heterogeneous environment. OMG technology has introduced several new dimensions of complexity which will increase the effort and risk of application development if these problems must be solved in every project by application developers.
Third, we must assure compatibility of independently developed components. Application developers must ensure the compatibility of the business concepts and methods, but there must also be compatibility of underlying mechanisms such as transaction management, concurrency, relationship management, notification and persistence. Without this compatibility, we cannot hope to develop a marketplace in sharable business application components.
Fourth, with a higher level of abstraction and a stable architecture, we can begin to integrate intelligence into business applications with such mechanisms as constraints, agents, expert rules and adaptive mechanisms. Today, such capabilities are limited in scope and difficult to integrate because of inconsistencies and inaccessibility of information across business applications.
Metaset will meet all your needs beautifully, and especially those of the last two points! And it will eliminate the need for any older "model of objects used for other computations".
Your "Enterprise Model" pictured on the following slide is then superfluous with MACK, which makes no architectural distinction between the various kinds of object mentioned (though obviously the user might often see them more-or-less as you say).
My only real problem with your whole approach is that you seem to accept the terms of the OMG’s BOF RFP, and MACK certainly can’t fit their demand for CORBA-compliance!
Though - considering your Second point - maybe you wouldn’t mind sacrificing that minor technical detail? If you did, then the hesitation I expressed à propos your first slide falls away.
So would you agree that the present OMG infrastructure does not meet the bill?
The OMG infrastructure seems so remote from meeting your so well-expressed demands, as do all other efforts such as ISO’s RM-ODP, the Web/Java line, and even this Workshop! From where - if not from MACK - do you see a hope that such a mighty bill can be met adequately and in a reasonable timeframe?