archive-org.com » ORG » J » JEFFSUTHERLAND.ORG

Total: 379

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Developing an Ontology Service for Business Object Frameworks
    embodied in the framework However as will be described later it is still necessary for the components to know how they relate hierarchically to one another within a particular domain model In contrast to object oriented programming where the hierarchy of the model is statically known at compile time within component programming the hierarchy is external and should be embodied in a separate and distinct facility This paper proposes a line of research into an Ontology Service to contain and disseminate information about a domain model to enable cooperative yet independent domain business components Ontology Service With independent components objects must carry on a real time conversation to service each other requests for data and to establish run time relationships Assuming that the objects engage in the same protocol and that the conversation is a semantic one then an external service will be required to provide meaning for the semantic tokens that are exchanged The ontology will provide such a dictionary and standard of reference Just as loose run time binding between objects via messages or remote invocation provides the means of communication the standard of reference provides the meaning what of the communication Additionally the Ontology Service will also provide for dynamic acquisition This is also a loose run time binding between objects based on the external ontology or model of the essential qualities of the domain It is a mechanism to enforce the deep relationships of knowledge in the domain It is at the scale of components similar to the function of inheritance at the object oriented design and coding level However like components it uses the interface implementation paradigm to minimize the level of implementation detail necessary for component reuse Establishing a Common Frame of Reference for Component Systems In object oriented programming the binding between classes is established at compile time The use of superclass functions by subclassing is an easily mediated inheritance intended to support code reuse However component based programming is orthogonal to this paradigm even though components themselves are objects The features in question that are orthogonal are loose run time binding component independence relative to other components at design time minimal surface area in terms of exposed methods semantic based messaging between components This introduces the problem that in organizing the components and their functions for a particular domain model the hierarchical arrangement of the components is not intrinsic to the component itself Otherwise it would violate the constraints listed above Thus the need to externalize the hierarchy information into a service and allow independent components to have or derive domain model driven relationships This external hierarchy of formalized definitions of the domain model is the ontology and the components access it at run time via an ontology service An ontology service is a specialized cross between a traditional relationship service and a rule base It is in essence the rules which pertain to the object components qua components in the domain model To differentiate the ontology characterizes the essential characteristics of

    Original URL path: http://jeffsutherland.org/oopsla97/khater.html (2016-04-27)
    Open archived version from archive

  • Business Object Management Architecture
    volume but long and lend themselves to the check in check out of rule objects to graphics workstations Simulation of operational transactions must be supported to enable the testing of price plans and forecasting of product revenues Once the new business rule configuration is satisfactory its release into the operational environment poses interesting questions There are two Doing environments to support the operational transactions both of which require read only access to the business rule objects Online Transaction Processing OLTP is a client server environment that supports the customer care activities including Subscriber Management The transactions are short requiring fast response time since the customer is probably on the phone The Batch environment mostly treats the subscriber data as read only and handles the high volume Call Processing and Period Closing transactions Checkpoint commits are common and parallel processing is often required to handle the high volumes in a timely manner The Checking environment supports the informational requirements and requires read only access to the usually summarized operational data The ad hoc queries are usually unpredictable but there should be no locking required Queries must be repeatable in their results so currency of data is not as important as it being in a known stable state Traditionally this has been the domain of relational as opposed to object databases due to the unpredictability of access paths Acting is not so much a technical environment as a business one The lessons learned from the informational environment must be fed back into Business Rule Development to enable the Enterprise to react to changing market conditions Innoverse Architecture ClearSystems has adopted a divide and conquer approach to develop the Innoverse Architecture whose goal is to provide a holistic executable model of the Enterprise As seems to be standard in the development of an Information Architecture e g the Zachman Grid OSI Protocol stacks these divisions are represented as layers Each layer is of either essential complexity the expression of the fundamental problem to be solved or accidental complexity required for implementation but dependent upon current technology constraints We contend that only the Business Model layer is of purely essential complexity and as such can through natural maturation is the only layer that can really achieve stability We believe that a Business Object Architecture see below is the optimal expression of this essential complexity There is of course many a slip twixt the cup and the lip i e everything is uncertain until you possess it In that respect all the following layers are essential to an effective implementation the only real measure of success but the leverage obtained from a correct stable Business Model is immense Business Process User Conceptual Model External Interface Business Model Schema Persistence Technical Infrastructure Figure 1 Innoverse Architectural Layers The Business Process layer defines the operational control tactical and strategic processes of the Enterprise the organization that is the subject of the model and their implementation within the organizational structure There are numerous essential techniques for both business

    Original URL path: http://jeffsutherland.org/oopsla97/anderson.html (2016-04-27)
    Open archived version from archive

  • OMG finds true love
    a universally used full cycle marketing facility helping us all simplify complexity together such as Metaset has always aimed to lead to True any possibly ill cooked dishes to the same basic recipe would certainly be seen in due course to be inferior But that would most likely dull the taste buds of the guests and ruin their appetites That would spoil the occasion and it is the success of an occasion which most quickly spreads the use of a fine recipe And wide use is essential to reaping the intended benefits of a shared architecture reusability and interoperability So it is my position unless persuaded otherwise that Metaset will be the only contender in the race for the first realization of MACK Setting up and managing the institutional and operational system to ensure that that remains so would be one of the immediate tasks of a new team leader Furthermore there are still numerous fine details of MACK to be concluded and divergence on such details would hamper the realizations interoperability as CORBA 1 suffered My present position is that MACK 1 0 must be sufficiently complete to ensure immediate inter realization interoperability with Metaset s and other realizations far superior repository A D and groupware facilities supporting the market wide process and with MACK s innate version capabilities smoothly enabling the further evolution that will most certainly take place I might add that any chef who might be tempted now to try to cook with Jack s recipe however obtained or guessed would do best to join the others overtly in the kitchen Jack rather doubts that there would be too many there and skilled and eager cooks are usually welcome There is a lot to MACK that I have hardly written about yet most particularly on relativity See relativistic realtime in my faq q 3 reply and the allied time component of data issues See the faq q 6 reply I must warn any bold reverse engineers that I would bet no money at all on anyone s ability to carry that one off at this stage without the lengthy and peculiar background of Metaset and MACK Yet another issue supporting a trade secret based approach is that any new team members would have their own or any investing partners investments to recoup and risk taking to reward The incentive of that plum See my faq q 8 11 replies is better not thrown away And our times favour healthy long term diets On trying to share that hindsight anyway The development of MACK was not a bottom up process nor was it top down As usual it was a strange mix of both There are too many detailed facts at the bottom for anyone to select or be pointed out the appropriate ones and see the way ahead from there It is also unreasonable to expect anyone to spot at the top a priori the single and small set of elements and axioms from which MACK is now built Or to see how the entire applied construction will evolve in such terms or be deduced from them as the myth has it without seeing it in action But bit by bit a picture develops which is very different from the accustomed one That is indeed the way of the market a progressive matching of supply and demand In the end the product bought and used is not what was initially demanded nor what was initially supplied It evolves supply suggests and learns demand understands better and adjusts New paradigms do result The strange combinations of opposites continue I repeat my favourite trumpet call Ride The Mainstream But how can an advance be so different from a present direction that the call should be so insistent and yet be so implicit in that history Both a new paradigm and The Mainstream There is surely no easy or immediately convincing answer to that question I do like to philosophize as I did in the Fifthly point in my faq q 3 reply that it is indeed reasonable to expect that the very nature of our infinitely complex reality will forever support such major progress But it is not reasonable to try to convince on that basis in this instance at this stage Paradox again Whenever there is a new paradigm it is those most steeped in the old who have the greatest difficulty in seeing things differently Yet it is also they who by the same token most need a resolution to the known or merely suspected or at least alleged problems in the status quo So mindful of whom I m addressing and of Medawar s Dictum see my paper and faq q 2 reply under the new robes point I think it s worth while to point out but not try to argue some of the many seemingly little but problematic issues that are happily resolved by MACK s different view on things If you recognize the issue good If you don t don t worry just read on We may start with a bald though slightly ornamented summary of part of the fundamental contrast MACK is so very very different from what you are used to if the latter is conventional OO with its classes those superfluous though bashful manifestations of types see the complexity hiding aspects of encapsulation below methods as called or otherwise invoked from within procedural programming language algorithms thus so easily in the real integrated interoperating and workflow centric world confusing algorithm time with realtime And in a visual or otherwise enduser oriented world as distinct from a procedural program code world why should a function call or single object method be the primary implementation of a user instruction method overriding or misconception patching interfaces or ever more confused sets of methods or behaviours interface inheritance II ô aie aie where cook Jack is appropriately provoked to the French expression of excruciating pain See further under misconception of encapsulation below and distributed operations via RPC or RMI Whatever s happened to the old ideal of data base and program data independence Users better understand and build on their roots and interrelate after all on homely and lasting earth than in flashy and evanescent spectacle Let s not expect Distributed Objects to stand on their faces MACK at once captures and encapsulates the distilled essence of OO which is the plain logic that everybody uses all the time Inheritance becomes mere typing with generalization and refinement and their strict logical consequences All so familiar And regulation is a better term for the phenomenon Polymorphism dissolves away once the baggage of procedure calls is shed Everyone knows that everything is polymorphic anyway At least that is the way that everybody s mind is always working It s just a pity that it was ever necessary to give the process a fancy name And encapsulation Ah here is the biggest misconception of all in old OO See below MACK s concept of relativity covers all of that notion that needs to be kept The essence of polymorphism is also found in that concept as in a Shakespearean way signifying nothing Macbeth in Macbeth on life for which in our story read anything OMA based It is a tale told by an idiot full of sound and fury signifying nothing Though I hasten to add the idiot here is not any of our characters it is the situation with its constraints Such of course is the best dramatic tragedy marvellous people ineffective caught in a naturally misconceived situation However evolution s victims do tend to leave instructive historical debris if I may give another unfortunate Job s answer to that form of The Problem of Evil much mouthing of the spirit but no resuscitation of the substance of OO ideals and opportunities The essence of OO is plain logic Unfortunately it has been diluted and even drowned by the floods of words and forms with which the procedural programming tradition has deluged it and no amount of artificial respiration from mantra mumbling BOFs will revive it The logical substance of OO takes new and clearer form in MACK as noted above and is even the basis of its concrete behaviour which so often pleasantly surprises as we shall now see no awareness of the classical object model miscarriage of an ill formed date rape product of blinkered fixation on a misconception of encapsulation with no respect of complexity no deep mutual benefit from interconnectedness Negativity first In this section probably more so than in the others you will find it very tempting to condemn outright with natural but wrong interpretations Try to see my sense rather than its perhaps conceivable nonsense if its terms are seen as in your familiar contexts I am speaking from my own knowledge of how in evaluating large proposals and when my mind is already leaning in the direction of an alternative I like everyone else I suspect so easily try to grasp the too glib way out especially when the situation does not demand and enforce the discipline of the systematically balanced assessment Big IS IT proposals in our complex world increasingly expose us to such temptations The many aspected elephant in the land of the blind allegory tells the story well Talking of Jekyll Hyde characters cf also the introduction in my Workers Day document current OO has a serious problem of that nature and its misconception of encapsulation is at the root of it There is an irresoluble tension between two aspects of such conventional encapsulation effecting complexity hiding within objects the dark and dangerous loner Mr Hyde makes it more difficult to effect and maintain any required collaboration between objects the sociable Dr Jekyll MACK on the other hand promotes a natural and safe blackbox whitebox interplay Let s summarize the conventional position adding parenthetic comments Complexity hiding is part of the public behaviour rather than unfathomable state predisposition of classical modular programming in the loose coupling principle of such merely pragmatic sense classical methods of those island classes see my Booch quote below and the classical object model with its IDL s so meagre support of interrelationship bearing none of the synergy of high granularity and its classical method basis hence often effectively obliging the target object to break out of its own encapsulation else indicating workarounds such as the Facade and Mediator patterns of the Design Patterns book by Gamma Helm Johnson Vlissides popularly known as the Gang Of Four or GOF It is held that behaviour and state are merely dual views of the same thing but that state is too inessential and even variable a matter to be a suitable basis for knowing an object and that therefore a blackbox approach should be taken whereby our representation and hence use of objects is founded on behaviour descriptions as seen from outside though one has to ignore how poor such descriptions are or attempt to enrich them as indeed the JBOF CDL does or otherwise make a silk purse from a sow s ear as in my Workers Day document I accused the TRC Inc team of envisaging despite their own evidently better judgment That conventional position without my parenthetic comments seems so plausible even without the better restatement of the case that you could doubtless make that it appears quite vain to attempt to question it And indeed it is rather foolish as in the absence of the replacement in Medawar s sense all one can do is adduce some facts that will eventually be seen to be part of what should ideally in that mythical fully rational world we tend to believe we are in have been able to displace the current view but which cannot at this stage be expected to do more than just unsettle you a little bit My argument will however gradually develop in a more positive direction As a minor comment to start with one might ask from a MACK like state based viewpoint that if behaviour is such a sufficient basis then why does one find popular constructs such as the GOF State and Memento patterns The supposed state behaviour duality sits very uncomfortably that being how the allegory also portrayed the II and UML neighbours with their jostle for territory that is bound to brew unless More generally come to think of it I might also comment that Metaset has virtually no use for any of the GOF book s patterns which might be a sign that there is a whole set of problems that a mainly declarative and state based approach does not land one in Having said that I must also add that the GOF will feel very much at home with many of Metaset s structures and that the pattern concept is fully subsumed mutatis mutandis in MACK s typology based approach to analysis design and implementation See also my faq q 7 reply As far as the Inheritance aspect of II itself is concerned just two quick comments for now 1 its use tends to lose all sight of true substitutability as distinct from the OMA s so called interface substitutability which is something quite different and 2 even Microsoft insists that their interface based approach with DCOM ActiveX is object based rather than OO Turning positive The background to my contesting of conventional encapsulation may also be seen in this quote from my faq q 7 reply of a quote from Booch Meanwhile here is Grady Booch on the OMG s own World Guide to Object Technology CD Perhaps the most strikingly consistent feature I find among the successful projects I encounter and noticeably absent from those projects which seem to fail is the presence of a strong architectural vision Architecture is unfortunately a much abused word but in my experience a well engineered object oriented architecture has at least two important dimensions to it a sea of classes that capture the vocabulary of the problem space and a set of mechanisms that specify how certain classes collaborate The first dimension is fairly obvious However there are two important lessons that many beginning projects miss First for systems beyond a certain complexity the class is a necessary but insufficient vehicle for decomposition Second no class is an island Indeed this is the point of the second dimension classes collaborate and the common way those collaborations play out is fundamental to the conceptual integrity of an architecture Furthermore actively applying a small set of common mechanisms helps to bring simplicity to an architecture for even the most complex domains where the italics were mine What a fine statement of what should be such an obvious architectural criterion But how the OMG itself seems to have overlooked it in their premature adoption of the OMA as it is at present or miscarriage of an OMA with its historical context adequately portrayed in the little fable It is such collaboration that is hidden or obfuscated by the very basis of the classical object model As a result every procedural language programmer has to work around the problem exposing it to yet further possible complication i e further to my parenthetic comments above in the form of the realtime algorithm time confusion See my paper and faq q 1 reply One can apply workarounds such as the already mentioned GOF Facade and Mediator pattern implementations whose very names incidentally betray some basic problem But no amount of fixes can make order from the classical object model chaos An analogous foul up led to Macbeth s despair already quoted and also to Lady Macbeth s own lament All the perfumes of Arabia will not sweeten this little hand Ok but then how does MACK handle the situation With what shall the poor theory be replaced Rather than further belabour my negative criticisms let s be more positive even though still skating around the black hole I am keeping in the middle of my published MACK descriptions Some more MACK at last Instead of trying to ride the collaboration horse with one single target classical rein let s rather ride it confidently with a complete saddle and harness Let s channel that sea of classes into The Mainstream that history has shown us how to ride MACK pushes out the frontier between the application operating system and the procedural program unit leaving ever less of the latter The latter see my paper and faq q 5 reply is always in the form of the RE method and is encapsulated even more strictly than the conventional method is The former has quite deep roots that was how I described my 1976 IDIOM in my faq q 3 reply It is effectively another Mainstream notion anyway Maybe quot operating system as workflow manager is a better description nowadays for such a concept So let s just call it the o s Thus the o s i e Metaset or any other MACK realization possibly on top of a conventional o s is one vast big Mediator in the GOF sense though its form is more recognizable in the TRC Inc generic agent I quoted in my previous document with its event driven nature that is another good Mainstream start for a move away from the algorithmic procedure based way of thinking But the GOF comments ibid p 277 It centralizes control The Mediator pattern trades complexity of interaction for complexity in the mediator Because a mediator encapsulates protocols it can become more complex than any individual colleague This can make the mediator itself a monolith that s hard to maintain So I immediately point out that Metaset is not unduly complex or hard to maintain nor does it encapsulate application protocols Its own requirements have themselves been decomposed and its structure already built largely in a MACK canonical way What a fine proof of the pudding that is too Yes MACK like conventional OO has types relatively

    Original URL path: http://jeffsutherland.org/oopsla97/spottiswoode.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'98 Business Object Workshop IV Header

    (No additional info available in detailed archive for this subpage)
    Original URL path: /oopsla98/header.html (2016-04-27)


  • OOPSLA'98 Business Object Workshop IV Menu
    Subscribe News Send email OOPLSA 95 OOPSLA 96 OOPSLA 97 OOPSLA 98 OOPSLA 99

    Original URL path: http://jeffsutherland.org/oopsla98/menu.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'98 Business Object Component Design and Implementation IV
    the reuse perspective Therefore we transfer a well known example a time planner from UML to CDL realize it on the basis of IBMs SanFrancisco and take a critical look at the resulting benefits of BOs against ordinary OO techniques Which Business Objects by Robert Haugen Customers or Parties Purchase Orders or Stock Flows Should distributed business objects reproduce traditional business applications In other words are we building single or multi party systems The Business Component Approach by Peter Herzum and Oliver Sims Abstract This paper describes the business component approach to large scale distributed business system development The business component is a single unifying concept that supports system definition and requirements and continues through deployment and customization to subsequent system evolution It does this with minimal transformations across the development life cycle and is supported by appropriate processes architectures and tools Current software component initiatives are aimed essentially at build time components for developers and fall broadly into two categories GUI or PC NC oriented components and components aimed at enterprise object model implementation However if we are to address the multi dimensional systems development problem for mission critical large scale multi user distributed business systems we need a component concept that addresses the entire development life cycle 30 May 1998 Workshop Participant Publishes Business Object Survey The Truth Is Out There A Survey of Business Objects Kitty Hung Tony Simons Tony Rose Email k hung dcs shef ac uk a simons dcs shef ac uk tony rose btrinc com Accepted at Object Oriented Information Systems OOIS 98 University of Paris Sorbonne France September 9 11 1998 ABSTRACT Since the term Business Objects BOs was first coined little tangible evidence has emerged to support the claim that BOs have any beneficial impact on information systems IS development A survey was therefore conducted into attitudes to and adoption of BOs across a wide spectrum of IS disciplines Results of the survey revealed that the concept of BOs was not stable and the adoption of BOs was still understrength 9 May 1998 Odell James Designing Agents Using Life as a Metaphor Distributed Computing July 1998 See also Odell James Agents and Beyond A Flock is Not a Bird Distributed Computing April 1998 1 May 1998 OOPSLA 98 Business Object Workshop Proposal Accepted 5 March 1998 OOPSLA 97 Workshop on Business Object Design and Implementation III 11th Annual Conference on Object Oriented Programming Systems Languages and Applications Addendum to the Proceedings OOPS Messenger ACM SIGPLAN 1998 in press Download PDF RTF Word versions E Mail jeff sutherland computer org Call for Participation due date 1 August 1998 The NCITS Accredited Standards Committee H7 Object Information Management and the Object Management Group Business Object Domain Task Force BODTF will jointly sponsor the Third Annual Workshop on Business Object Design and Implementation Goals of Business Object Workshop IV Enhance the pattern literature on the specification design and implementation of interoperable plug and play distributed Business Object components Clarify the design and implementation of object oriented systems particularly systems in which workflow patterns and the REA accounting model are basic building blocks for production business systems Contribute to emerging architectures for Intranet Internet Extranet applications particularly those applications that integrate business objects web servers object and relational databases and new approaches to client delivery of content Pursue issues developed in last years workshop stimulated by papers on heterogeneous distributed workflow systems Specify business object solutions to mobile agents process engines and systems that exhibit emergent behavior Cross fertilize business object design concepts with experience from the field of complex adaptive systems Provide explicit experience reports on business object systems developed and in production Focus of This Year s Workshop Questions that still need answers from the 1997 Business Object Workshop How do you implement a reusable pattern What patterns are useful for end users How do you deal with application transactions vs TP transactions Long transactions Contracts between clients and servers How do you work with domain business object models And allow dynamic change How do you handle more difficult REA patterns the ones that make accounting interesting and useful How do you differentiate between businesses and their processes How would you build a BPR datablade How would you implement a real time event driven system with generative process planning automated routing and dynamically changing roles of resources How can systems learn from one another What about hierarchies of workflows peer to peer workflow workflow between organizations Should workflow systems be separate from or part of business object systems Should there be a generic workflow execution pattern that is part of every business process object i e should workflow concepts be seamlessly interwoven into all applications Is workflow a solution to reach a goal or should it generate an achievable goal using subservient workflows What about workflow services particularly the level of persistent services How would you implement disaster response as workflow How do you implement goal directed behavior create value through exchange What about systems with emergent properties Who does what How should systems be partitioned What about mobile agents process engines just in time workflows How can we enable learning organizations through building complex adaptive systems How can systems evolve through workflow by moving through an evolutionary adaptive fitness state space Many of the outstanding issues in business object design and implementation for enterprise systems particularly heterogeneous distributed systems are evolving into federated autonomous business object components on the Internet acting collectively to solve business problems in an automated fashion Frank Manola Towards a Web Object Model Mano98 describes the future construction of distributed object systems on the Web The result is counterintuitive Yes there will be CORBA yes Java yes ActiveX but these will be small pieces of a global implementation Such systems are going to be more like stone soup Complex Adaptive Systems Federated distributed component systems are interactive systems Wegn95 Such systems are not Turing machines All interactions in these systems cannot be anticipated Therefore such systems can never be

    Original URL path: http://jeffsutherland.org/oopsla98/oopsla98.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'98 Business Object Workshop IV Menu
    Subscribe to OOPSLA Business Object Component Workshop oopsla2000 archive Hosted by eGroups com News Call for papers Email OOPLSA 95 OOPSLA 96 OOPSLA 97 OOPSLA 98

    Original URL path: http://jeffsutherland.org/oopsla99/menu.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'99 Business Object Component Design and Implementation IV
    business object components object and relational databases and XML Pursue issues developed in previous years workshop stimulated by papers on heterogeneous distributed workflow systems Specify business object component solutions to mobile agents process engines and systems that exhibit emergent behavior Cross fertilize business object design concepts with experience from the field of complex adaptive systems Provide explicit experience reports on business object component systems developed and in production Attendance Attendance to the workshop is limited to facilitate lively discussions and the exchange of ideas Participation will be by invitation only based on the organizing committee s evaluation of the submissions Accepted participants will be notified in September 1999 Submission to Workshop 28 Prospective participants are solicited to submit a 2 3 page position paper or experience report in HTML Word or RTF format by e mail to jeff sutherland computer org no later than 15 September 1999 All submissions must include the full contact information of at least one author Position papers will be placed on the Web for review Background The OOPSLA Workshop on Business Object Design and Implementation is jointly sponsored by the Accredited Standards Committee X3H7 Object Information Management Technical Committee and the Object Management Group OMG Business Object Domain Task Force for the purpose of soliciting technical position papers relevant to the design and implementation of Business Object systems X3H7 Object Information Management The International Standards Organization ISO has approved a new work item to refine and extend the current international standard Reference Model for Open Distributed Processing RM ODP X3H7 the U S technical committee for this new international work item is tasked with the following Refine the enterprise language explicating the relationship of an enterprise specification of a system to other RM ODP viewpoint specifications of that system so as to enable the RM ODP to be used for specification of object based application architectures Ensure that the enterprise language together with the other viewpoint languages is suitable for the specification of a concrete application architecture to fill a specific business need Measure success with a demonstration of the use of the RM ODP viewpoint languages to specify a concrete application architecture OMG Business Object Domain Task Force BODTF The Object Management Group has chartered the BODTF to facilitate and promote the use of OMG distributed object technology for business systems commonality among vertical domain task force standards simplicity in building using and deploying business objects for application developers interoperability between independently developed business objects the adoption n and use of common business object and application component standards And to issue requests evaluate responses and propose for adoption by the OMG specifications for objects frameworks services and architectures applicable to a wide range of businesses Organizers Jeff Sutherland Chair jeff sutherland computer org Secretary X3H7 Object Information Management liaison to X3H2 SQL Database IDX Systems Corporation 116 Huntington Avenue Boston MA 02116 Phone 1 617 266 0001 x2920 Fax 1 617 721 1226 Fred A Cummins fred cummins eds com Enterprise Architect EDS 5555

    Original URL path: http://jeffsutherland.org/oopsla99/oopsla99.html (2016-04-27)
    Open archived version from archive



  •