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".
  • Jeff Sutherland's Object Technology Web Site
    receive no SPAM object technology be the first to get updates to Object Technology Web Site Subscribe to Jeff Sutherland s Object Technology Enter your e mail address object technology archive A group hosted by eGroups com Subscribe to OOPSLA

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


  • Adaptive Framework for the REA Model
    of conclusion materialization We selected the Object Query Language OQL Cattell Barry 97 as a specification language for conclusion materialization OQL is a result of the attempt to standardize object oriented query languages by the Object Database Management Group ODMG Its basic idea is to combine the declarative query description of SQL with the object oriented paradigm We first designed a special language for our framework but we found OQL is much better because it is standardized and easy to use for those who know SQL The following OQL query returns the set of the names of the employees whose ages are under 30 Query 1 SELECT e name FROM Employees e WHERE e age 30 ODMG also defined the C Smalltalk Java bindings for OQL A query is executed by a member function method of the Collection class or by an object of the Query class In either case the query is specified by a character string with parameters If all the queries can be defined in advance this approach provides a solution that is easy to understand However if business requirements change at runtime the character strings that represent queries also have to be modified The problem is the strings have no structures connected with the requirements End users or other parts of the system must be responsible for the consistency What we need is a more flexible mechanism that can directly respond to the change in requirements Unlike SQL OQL is a functional language where operators can be composed freely The result of a query expression can serve as an operand in the containing expression This implies that any manipulation on the parse tree that represents a query is legal as long as operand types are correct If nodes of the tree are instances of some classes we can modify the tree without writing any classes or methods what we need is only to create new instances and add them to the existing tree Therefore an OQL query represented by a parse tree is highly adaptive to the change in requirements We use slightly detailed abstract syntax trees instead of parse trees concrete syntax trees because some expressions are too complicated to represent as single nodes For example a select from where expression is composed of multiple kinds of nodes though details are beyond the scope of this paper Figure 3 shows the structure that represents the Query 1 All the sub trees including the terminal nodes are queries which structure is an application of the Composite pattern Gamma et al 95 Suppose we need the names of employees whose ages are under the average instead of 30 The query is written in OQL as Query 2 SELECT e name FROM Employees e WHERE e age AVG SELECT e1 age FROM Employees e1 We can get the new query structure by replacing the node that represents the value 30 with the tree that gives the average age The result is shown in Figure 4 The point is that the structure can be configured dynamically while the system is running 4 Interpreter Pattern The Interpreter pattern Gamma et al 95 describes how to represent sentences in a language and interpret these sentences The pattern is intended for small languages because syntax trees and the operations attached to the nodes would become unmanageable for complex grammars However although OQL is quite a large language we can easily apply the Interpreter pattern to it because it is a pure functional language in which the value of a node is determined only by the values of its sub trees One of the benefits of the Interpreter patterns is that adding new ways to interpret expressions is possible A straightforward way is to see an OQL query as a procedure that starts evaluating the expression when invoked and returns a calculated value when finished However another interpretation is possible We can also see an OQL query as a constraint between the input and the output In this view every time the input changes it will notify the output The output behaves as an observer of the input The important point is that the same representation can be used for both interpretations Query structures are exposed to users but implementation details are hidden from them The former way of interpretation is described in this section the latter will be discussed in the next section Each query class has the operation evaluate that takes a context as an argument and returns the value of the query A context is any object that can respond to the message at A Dictionary object is one example and an instance of the Object class in the active object model is another There are two kinds of terminal queries Identifier and Value The Identifier query returns the result of sending at to the context The Value query returns the constant value that it contains Non terminal queries calculate their values using the results of the component queries Figure 5 shows how the sub query e age is evaluated 1 The Dot query takes e name Alice age 25 as the context 2 The Dot sends evaluate e name Alice age 25 to the left child 3 The left Identifier sends at e to e name Alice age 25 and returns name Alice age 25 4 The Dot sends evaluate name Alice age 25 to the right child 5 The right Identifier sends at age to name Alice age 25 and returns 25 6 The Dot returns 25 as the result Figure 6 illustrates the interpretation process of Query 1 1 The Variable query extracts employees and gives each employee the label e 2 The Select query extracts the employees that satisfy the condition e age 30 3 The Project query applies the query e name to each employee The result is the set whose elements are the names of employees whose ages are under 30 5 Incremental Computation One of the principles of the REA Accounting Model is

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

  • Ride The Mainstream
    a little bit like the then Mark Twain Now the MACK semantic web is represented very differently from XML s Started over 10 years ago Metaset has always been intended as full groupware even though the word did not then exist or was at least not current Whereas HTML and XML are document centric that is knowledge endproduct centric MACK is fully knowledge process centric as its groupware positioning implies and as we shall see at some length even though that may appear a very fuzzy and fluid place to start Seeing through the fog however has revealed some unique technological opportunities with wide ranging impacts So groupware blue skies beckoning and taking to heart the words of Heinz Zemanek a past president of IFIP An architect does not tell people how to live he creates an environment in which people may live their own lives creatively MACK lays diffident though confident claim to the role of appropriate successor to HTML as the architecture of choice for the future knowledge based web of people The heading being derived from a royal context The king is dead Long live the king the claim indeed seems to show a rather royal hauteur towards XML and any other contenders But XML in its present form is a mere start and I think its marvellously modest creator would agree As far as I know the web has never been as grandly targeted as MACK The fog has long clouded everyone s view And what else in the lineage of related standards might be considered contenders but that which the outsider is indicating as the best provisional outline and facilitator of The Mainstream MACK s fundamental simplicity is in striking contrast to the vain intricacies and inexplicable rigidities in ISO s RM ODP particularly as represented by its five viewpoints so this paper does not take that one seriously After first steps through the fog MACK s simple basic representational structure is now set to supersede many other underlying architectures most notably in OO and DBMS What a pity those technological tails ever got to wag the groupware dog Dog being Man s best friend MACK s overtaking of OO and DBMS standards cannot but have a far reaching impact on all IT application structuring and modelling Here the standards quest would otherwise seem at present to be culminating in UML the Unified Modeling Language which is in danger of being grasped by all and sundry e g the OMG and Microsoft as a firm foundation for everything else Alternatively it is the OMG s MOF Meta Object Facility Specification and Appendices that is held to be the bible even though it admits to many holes for example in the areas of complex bindings object identity and evolution and versioning all of which mutatis mutandis are well catered for by MACK A further major current in the development of IT standards is presently towards the process of system development It was specifically omitted from UML most understandably under the foggy circumstances and is now represented by the OMG Process Working Group s White Paper on Analysis Design Process Engineering of July this year Draft Version 1 0 An explicit objective is to facilitate the use of UML though there is also much useful generic exploratory work in it of the CBO Common Business Object variety But MACK s semantically integrated groupware OO DBMS basis in a fully supported market environment cannot fail to transform our joint approach to process too As for the OMG s UML for Business Objects RFP of August this year Draft Version 1 0 well that latest form of the OMG s long running Business Object Architecture saga can only fade away too The present MACK focus on Business Objects in the groupware boosted program product market indicates the main thrust of the anticipated penetration of MACK into wider use It characterizes the immediate contributions from most participants and resulting benefits for them It also highlights the practical activity centredness of both MACK and Metaset Process will return to its proper status as a mere facet of the natural functioning of the wider market with every interested party participating as he or she sees fit in evolving patterns thereby also helping to make the whole thing work better The market niche as seen by this paper The Internet leveraging MACK compliant groupware the New Web or possibly the MackWeb as in due course comprehensively created by the open market will form a new open and non proprietary marketing medium initially mainly for the software and information industries but progressively permeating the entire market During its early steps the new architecture will be the basis for the widely collaborative clearing up of the confusing mess in which computing at present finds itself The resolution itself is a merging of many historical currents to the extent that there is a short and temptingly accurate comment on the whole story Clichés That is after all what one would expect from a phenomenon by the name of The Mainstream However and especially with the various unique technological synergies out in the market it will add up further to a revolutionary process with beneficial impacts across the entire spectrum of human life Together in the market Riding The Mainstream we shall better focus our joint momentum and thereby lead ourselves to more luxuriant and varied vistas than the consumerist desert that presently appears as the road ahead where fine intentions of demand empowerment dissipate in the shallows and seem to evaporate before commercial heat That was a sharp though sympathetic nudge in the ribs for Bill Gates à propos the cover and contents of his book The Road Ahead The Mainstream will continue to show turbulence so the ride will be bumpy but it will work out better because everybody will be able to contribute to where and how we ride it Clearly the resolution of conflict will be a major function and MACK provides for

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

  • Semantic Object Modelling of Large Enterprises
    to a broader federation Organization units cooperate to form chains and networks by which to deliver value This example illustrates the flow of material funds and information in a supply chain from design through procurement to manufacturing distribution and sales units Collaboration between these units differs from that within a unit because there is no central authority to devise and enforce policy Political cultural language and technological barriers between units are overcome through standards codes of practice contracts and law Shared protocols and vocabularies are required to conduct meaningful business within such a federation Shared purpose is the means to coordinate units which are otherwise autonomous by providing the motivation to govern their interaction By extending the concept of purpose beyond the narrow domain of a single unit contracts are the glue by which distributed business is done A contract states the rights and obligations of the units or parties each clause specifying the course of action appertaining to a particular state of affairs A clause authorizes one party to incur an obligation on another party and specifies the action required to fulfil the obligation Actions required when an obligation is canceled or violated are also specified in order to cater for exceptional situations The contract UML diagram shows the elements of such an agreement illustrating how clauses can be structured for implementation in software XML is particularly well suited to this kind of structured document The primary elements of an enterprise model that supports contracts are organization units which contract with others to define both purpose and the processes by which it is to be achieved A unit incurs obligations on others by communicating requests in terms of the contracts or through the authority that is has over them It fulfills its obligations by instantiating appropriate business processes and

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

  • Organization in a Chaotic World
    Development Need for Interoperability Communication Coordination Coordination by Contract Communication by Speech Act Using Business Protocols Entity Process Situation Policy Contract Text Contract Diagram Contract Class XML Contract Enterprise Model Organization Responsibilities Organization Unit Purpose or Contract Manager Customer Request

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

  • OOPSLA'98 Business Object Design and Implementation IV
    the component s operations and 5 any internal component can be run on any processor and the whole component retains its functional integrity These objectives are largely achieved by emerging COM and Enterprise JavaBeans specifications at the syntax level More importantly from a business perspective the Business Object Component must guarantee proper behavior in response to a set of scenarios that ultimately trace back to use cases These scenarios must be evoked by messages in a standardized context including timing and sequencing to guarantee proper operation of the component in any system that uses the component according to its design specification While these minimal requirements were worked out years ago by Sutherland and McKenna SM 93 and pursued by the OMG Business Object Domain Task Force since 1995 they have yet to evolve into any standard approach for building plug compatible business components It is critical that standard Business Object Components be available to enable a business system to function as a complex adaptive system Adaptive means that systems must easily evolve and this requires continuous changing updating adding subtracting and rearranging components When changing one component causes ripple effects throughout a system the cost of rewriting major portions of the system slows evolution to a snails pace This is the state of the 80 of business systems that are viewed as unsuccessful implementations in industry today BMMM 98 Learning 3 A fully integrated component design environment leads to rapid evolution of the software system with emergent adaptive properties resembling the process of punctuated equilibrium observed in biological species It is well understood in biological evolution that change occurs sharply at intervals separated by long periods of apparent stagnation leading to the concept of punctuated equilibrium Dennett 1995 Computer simulations of this phenomenon suggest that periods of equilibrium are actually periods of ongoing genetic change of an organism The effects of that change are not apparent until several subsystems evolve in parallel to the point where they can work together to produce a dramatic external effect Levy 1993 This punctuated equilibrium effect has been observed by teams working in a component based environment with adequate business process engineering tools Use of the SCRUM development process accentuates the effect Schwaber 95 BDSSS 98 For example Figure 3 shows the conceptual context of a component based system Sutherland 98 Figure 3 View of a Business Object Component System A project domain can be viewed as a set of packages that will form a release These are what the user perceives as pieces of functionality Packages evolve out of work on topic areas Topic areas are business object components Changes are introduced into the system by introducing a unit of work that alters a component Figure 4 The unit of work in a SCRUM has been called a Synchstep Figure 4 Firing a Synchstep After one or more Synchsteps have gone to completion forcing some refactoring throughout the system or often simply providing new functionality to existing components a new package of functionality emerges that is observable to the user These Synchsteps are similar to genetic mutations Typically several interrelated components must mutate in concert to produce a significant new piece of functionality And this new functionality appears as a punctuated equilibrium effect to builders of the system For a period of time the system is stable with no new behavior Then when a certain somewhat unpredictable Synchstep completes the whole system pops up to a new level of functionality In a Smalltalk environment with object oriented analysis and design tools that support round trip engineering this process can happen extremely fast much faster than the rest of the development organization can absorb new functionality We found it necessary to slow down the process by keeping the number of developers small and outnumbering them with quality assurance and documentation people on the SCRUM development team The ability to product a complex adaptive business computing system has been demonstrated albeit adaptation has to be manually induced The team organization and tools required to do this are not available to most engineering organizations today It is however easy to visualize an environment with introspective components that can self adapt All of these capabilities await standardization of the syntax and the semantics of flexible business object component environments before large scale adoption is feasible As these capabilities become available as they are in some proprietary environments the concepts of cas become very useful in thinking about the specification and design of enterprise business object component systems Cross fertilization of Business Object Component Architectures with cas Concepts Interactive autonomous business object components evolve independently Some of these components will be intelligent agents roaming the net to perform complex tasks based on enterprise workflows Workflows in these systems must be managed in a more sophisticated way than current Workflow Coalition or the Object Management Group specifications prescribe Schmidt 98 They will exhibit complex behaviors catastrophic events and chaotic interactions all phenomena subsumed under the umbrella of complex adaptive systems cas They are under intensive research for use in predictive economic models let the computer beat the stock market deploy new derivatives or perform arbitrage the building of artificial life forms for the analysis of biological systems computer models that can independently adapt and evolve avatars that can personally represent the creator in an Internet chat room to note only a few examples Holland in his Ulm lectures at the Santa Fe Institute Holland 95 creates a synthesis of seven basic cas concepts four properties aggregation nonlinearity flows diversity and three mechanisms tags internal models buildings blocks These concepts can organize our discussion of business object systems Aggregation property there are two important modes of aggregation in cas systems Aggregation is a basic mechanism in object modeling and is the basis for identity a fundamental object concept Forming components out of objects and enterprise systems from components is higher level aggregation More important are emergent properties such as intelligence that evolve out of dumb subsystems This is the basic

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

  • Which Business Objects
    Thomas Schmidt IBM Software Group 3 MODELLING AND FRAMEWORK ISSUES Organization in a Chaotic World by Chris Marshall SES Software Inc Marietta GA Adaptive Framework for the REA Accounting Model by Hiroaki Nakamura and Ralph E Johnson University of Illinois at Urbana Champaign Business Procedures are not Represented Adequately in Business Applications and Frameworks by Hans Albrecht Schmid FB Informatik and Fernando Simonazzi LIFIA UNLP La Plata Argentina A Business

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

  • Which Business Objects
    Office Applications Making Domain Experts Full Partners Jeffrey Bonar 29 Open Distributed Processing and Business Objects Joaquin Miller 37 The Business Component Approach Peter Herzum and Oliver Sims 46 2 WORKFLOW Using Intentional Information to Coordinate Inter operating Workflows Bill Kuechler and Bill Burg 61 Building Workflow Business Objects Marc Thomas Schimdt 64 Structuring Specification of Business Systems with UML with an Emphasis on Workflow Management Systems 77 A light distributed OO Workflow Management System for the creation of OO Enterprise System Architectures in BPR environments Michael A Beadle 90 Essential requirements for a workflow standard Santanu Paul Edwin Park and Jarir Chaar 97 Fitting the Workflow Management Facility into the Object Management Architecture Wolfgang Schulze 106 Services of Workflow Objects and Workflow Meta Objects in OMG compliant Environments Wolfgang Schulze Markus Bvhm and Klaus Meyer Wegener 115 Using Components in Workflow Activities Stefan Schreyjak 123 An Object Implementation of Network Centric Business Service Applications NCBSAs Asit Dan and Francis Parr 134 3 MODELLING AND FRAMEWORK ISSUES Organization in a chaotic World Chris Marshall 149 Business Object Component Architectures A Target Application Area for Complex Adaptive Systems Research Jeff Sutherland 154 Modelling Domain Specific Application Frameworks with a Dynamic Business

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



  •