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".
  • William McCarthy and Julia David: The Evolution of Enterprise Information Systems -- From Sticks and Jars Past Journals and Ledgers Toward Interorganizational Webs of Business Objects and Beyond
    being See also my comments above à propos Mark Baker s paper on the increasing identification of UI objects with real entities Your sentence also nicely circumscribes the epistemological justifications for MACK On evolution in general I can also relate most happily to your evolutionary perspectives having myself long found them most enlightening and satisfying See my reference to Teilhard de Chardin in 3 Fifthly There is quite a lot pp 92 104 in my 1986 book advertised at the end of 2 on the significant parallels between biological evolution and the evolution of knowledge and systems Of course the species evolutionary view is merely metaphoric with all the potentially misleading parallels that might be drawn from any metaphor It is also rather complicating inasmuch there is extensive interaction between all evolutions that one might care to identify That can create a confusing picture For example social system evolution and species evolution interact in what we call environmental issues changing the very operation of species evolution That said the full evolutionary perspective is I believe a rich source of most appropriate interconnections for use in many educational situations I can certainly attest that I have found that to be the case So I look forward to your testing of Metaset as a platform for your own efforts in that direction On application evolution As you point out your lower order species applications should be able to interoperate with those based on the highly sentient and highly interconnected enterprise models which I agree fully will have their predicted evolutionary emergence So on the latter theme I d like to point out that in a MACK based world the applications that will replace those lower order species packages will indeed have the simplicity that their users will need but will still be

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


  • Christopher Spottiswoode comments from a Metaset/MACK point of view:
    the MACK RE or Realworld Equivalent empirical concepts are all about Your first sentence just quoted about work items and lists being outdated I quote with approval in my comments on Wolfgang Schulze s paper On that subject you then go on to say Nebulous work item concepts don t fit They aren t objects Work is a consequence of what happens when business objects play together on desktop GUIs as directed by users I would argue that a constructed dialog with associated processing may for certain purposes be regarded as an object and yes more nebulously as a work item However that last sentence is spot on and does not contradict the work as object notion After all a dialog has conditions and outputs and many quantifiable aspects that we associate with work like things But yes your main point is correct traditional work items are too nebulous You have chosen an excellent word there to become driving objects and work must rather be constructed as a function of the complex business model The rest the definitions and quantifications of the resulting work is thus derivative rather than primary And that is precisely the MACK approach too As previously stated the process creation environments of workflow tools will need to be able to interface with a business meta object repository to allow the developer access to the publicly exported attributes or indeed any other meta object information of the business objects How do you see that feature set evolving out of the OMG s OMA Again cf my comments à propos Wolfgang Schulze s paper re that time mismatch Roaming agents autonomous carriers of process knowledge should be considered by the workflow vendors as candidates for a flexible scaleable workflow architecture The Essential Distributed Objects Survival Guide Orfali Harkey Edwards Wiley 1996 points out that the combination of roaming agents a standard object bus and a distributed document facility something that almost all vendors not just workflow vendors should be aiming to use can provide for some very powerful constructs Control of process instances such as termination suspension resumption should be considered as an administrative task perhaps to be managed by the workflow facilities It would require the locating and notifying of agents in the system Process execution also involves the monitoring of process states across the system It will be part of an agent s responsibilities to report on its state and therefore the process state as required presumably to some configurable amount of detail I agree mutatis mutandis Metaset manages the work in an analogous way BTW I enjoyed your colleague Ron Resnick s position paper Distributed Objects on the WWW His demand for a more solid Universal Front End will be very well met by Metaset To stand back a little though I would say that you and Ron have your noses a bit too close to the grindstone of existing and working technology Okay maybe mine is too far See the references to time and

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

  • Texas Instruments Business Object Architecture Team (Ed
    developers Interoperability of independently developed business objects Implementation of business object configurations as plug and play business components of the information system A direct correspondence between the business object model in understandable business terms and the business components of the information system Isolation of infrastructure and business objects from tool or presentation technologies Isolation of technology from business logic Transactional integrity across distributed business objects Direct coupling between a Business Object and its defining meta business object Consistency of business object specification across the development lifecycle Flexible and dynamic business object models Enforced business semantics If I were to adopt those objectives as MACK s and I could certainly state at least those then I would only qualify the two starting with the word Isolation I would try to make it clear that such isolation merely implies the ability where applicable to present and manipulate the one without the other I would steer clear of any implication that MACK has any n tier architectural dogma As I have explained in Ralph Jeff Wolfgang MACK implies needs and fully implements a full integration of the internal model while yet being able to expose appropriate perspectives to the various kinds of user Anything short of such integration tends to oversimplification through loss of generality and easy extensibility and greatly impedes many opportunities for rationalization optimization functionality and in short power with simplicity MACK has learnt to benefit from the demands for coherence with consistency and is greatly helped not hindered by the increasing interconnectedness of our abstract models At the same time such abstraction is safe as it is stabilized both by its RE empirical facets and by its democratic orientation via a boosted demand driven market with reinforced assistance by supply Considering your acceptance and my rejection of the OMG roadmap

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

  • Jeff Sutherland's Object Technology Standards Page
    the OMG great index to CORBA resources Distributed Objects Douglas Schmidt s Home Page check out CORBA tutorial handouts OMG Workflow Workgroup Object Database Management Group The ODMG is a consortium of object oriented database management system ODBMS vendors and interested parties working on standards to allow portability of customer software across ODBMS products You can find information including names phone numbers and Email addresses of all major ODB vendors on the ODMG Home Page ODMG 93 Standard As Chair of the Joint Ad Hoc Committee of ODMG X3H7 and X3H2 Committee I worked on harmonization of OQL and SQL We want OQL to mean One Query Language There is general agreement that ODMG 93 OQL should be integrated with SQL3 and all three groups are currently pursuing this objective Drew Wade maintains a current status page OOPSLA 95 Object Database Standards Panel Chaired by Mary Loomis of HP this panel presented the status of OMG Richard Soley ODMG Rick Cattell X3H7 Frank Manola and X3H2 Jeff Sutherland standards Download my slides PowerPoint 4 0 in zip format David Beech Senior Architect and X3H2 Rep Oracle Corporation Querying Can Be Fun ISO IEC JTC1 SC21 WG3 DBL MCI 151 ANSI X3H2 96 212 and 96 213 This paper is offered as light entertainment to the serious SQL3 standardizer It could be read for example in the closing stages of a long flight or while giving full attention to the administrivia in a meeting However like much comedy it carries a serious message The title may recall for followers of Monty Python s Flying Circus or was it Not the Nine O Clock News a supposed up close and personal interview with Her Majesty in which she confided Ruling Can Be Fun This may have been true at the time but that was several years before her annus horribilis Querying may be fun in the era of SQL 92 but will it still be so with SQL3 In the course of working on the SQL3 ODMG paper 1 I was obliged to become more intimately acquainted with SQL3 queries than I had ever been before and I was surprised by some of the things I learned This raised in my mind the question of whether the language has perhaps become too difficult for its intended users which could mean that the potential simplifications offered by some of the OQL features are not merely an optional luxury but are an absolute necessity Download in PDF format Postscript format Smalltalk Industry Council STIC is an industry consortium of Smalltalk vendors Send email to STIC to get the latest IDC report on Smalltalk use in large corporations with comparisons to C COBOL and 4GL products National Committee for Information Technology Standards Accredited Standards Committee X3 is accredited by the American National Standards Institute ANSI to develop voluntary standards in the area of information technology Several X3 Technical Committees are critical to the future of object technology in addition to the key object oriented language

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

  • Christopher Spottiswoode introduces his comments on the other position papers:
    are generally best solved cooperatively taking advantage of the open market Analysts and designers will formulate their diverse insights directly in people sharable and computer interpretable form in terms of MACK s typologies with their well defined coherences 7 Ralph Paul Haim MACK fully enables the infrastructure needed for the market based cultivation of the total variety of product required to address the degrees of complexity that people can deal with Paul paper Homeric mast Metaset will take first advantage of that Plug and play component based market supported reconfigurability will be pervasive thanks to the completely semantics driven apparently intelligent and visually controlled application specification approach A fully repository based A D environment is indispensable here for actively promoted flexibility with distributed autonomy 3 firstly Thus a complete new MACK compliant operating environment or Universal Front End see Mark Baker s paper will be created collaboratively Profound congeniality will supersede mere user friendliness in the user interface Jeff William 3 Together in a difficult yet supported and managed way Ken Paul William people will be creating their own new appropriate flexible controllable and challenging yet comfortable reality They will be further stimulated to observe patterns Ralph Martin Haim and enabled in their casting them in immediately useful forms All the above is leagues ahead of conventional architectures Andrew Mark Haim 2 and is feasible because of its epistemological appropriateness and hence simplicity Ralph 12 3 Strategy I agree with at least the global requirements that the OMG and all of you have so well expressed However the detailed reality in the IT industry trails far behind Jeff Fred Mark Tom My goal is for MACK to move into that vacuum My public strategy right now is to locate partners for a major joint project I ll call it Team Metaset here If that turns out infeasible at this stage my own programming of Metaset which this Workshop involvement has pushed into the background will be brought into my foreground very soon The aim then would be to go straight for a more demonstrable Metaset product and thereby make Team Metaset more easily sellable 11 As far as I can see right now some relatively minor technical contributions from outside will be required at a later stage 9 I have colleagues locally who are well placed for that role and we would together raise our public profile as soon as it became feasible Sooner or later Team Metaset will get going with partners who could set up the administrative legal and commercial infrastructure for launching the Metaset based market and managing eventual MUCK cultivation 8 Within such a framework it should also be possible to organize a safe and quickly effective technical boost as well to make it happen sooner and better as I said above I would also like to start that growth soon in order to prepare for my own phasing out from technical and operational responsibilities my own long term objective being merely to be a user of ACK based products 11 Haim Such partners could well need substantial incentives Hence also my concern about trade secrets Hence my demand 11 for substantial commitment before they gain access to them which would also be my insurance policy against non performance by partners My position 3 is that the right partners should be able to see enough of my picture at its already published though high level of abstraction If I am unduly optimistic in that belief well then my solo programming will continue until Metaset itself can be more convincing as it will certainly be to an ever growing degree And in due course with relatively little help from the market that will be the case at every level of user capability or receptivity 3 Team Metaset would also in due course liaise with standards bodies I presently have the OMG in mind 1 to promote MACK as a standard and help manage its evolution into an ACK 8 or fully standard Architecture for Common Knowledge On trade secrets To risk rather belabouring the point let me expand on why I am not setting out more details of MACK and Metaset just yet If I do then who knows maybe you will be able to reason me into a position that would be more open and friendly as well as more efficient I have mentioned 11 the need for a MACK realization such as Metaset itself to represent MACK source adequately that is contextually hence meaningfully That is in line with my criticism of command line approaches such as SQL grew from Ralph I have adopted the strategy with a Team Metaset with due incentive to go for a closed development until Metaset itself can host its own open market based evolution 9 11 That ties in with the ability that Metaset will then have to enable its own and MACK s version cohabitation and migration 8 if there are multiple and hence most likely non interoperable currents of development too soon medium term development rapidity might greatly suffer Metaset version 1 will help refine MACK version 1 quickly enough so that all other realizations of the latter will immediately be interoperable unlike those of CORBA 1 I also implied but didn t spell out clearly enough that I wished to remain in control of the residual and as far as I can presently see irreducible central function of MUCK cultivation 8 until I can more confidently trust others to do so responsibly 11 3 That is the conservative approach it might transpire even before Metaset s launch that such control will be unnecessary as the Metaset boosted open market will soon enough and surely enough take care of such concerns Looking ahead Notwithstanding all the help from many colleagues 3 I have been very much alone in this project So there have been many avoidable obstacles Hence what inefficient use of my own time and resources and at what an opportunity cost for us all That

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

  • Christopher Spottiswoode comments from a Metaset/MACK point of view
    that understandability the MVC like function producing typology representations for every kind of user s own contexts Find the phrase your way of seeing things in the faq Your information gathering and joint ownership specification fragments obviously have equivalents in some of Metaset s market related typologies see e g POP in Paul and buying typologies 7 I can also put that specification problem in the context of the burgeoning integration between run time and A D time of which my 1976 IDIOM Interpretable Design for Integrated Operation and Management see 3 was an early precursor and which was emphasized in this Unisys quote in my paper A number of customers now view workflow as the driving technology that is used to control all business processes one of which happens to be software development in an enterprise That closer integration was also implicit in Jeff s summary of last year s Workshop where he called for a tighter coupling between analysis design and implementation Such designtime runtime integration is of course most appropriate to Tom Peters Nanosecond Nineties and the high velocity market that JIT has presaged and the Web is starting to enable far more widely Metaset will enable it in the software component market both from an architectural and an infrastructural point of view Then your final sentence in that paragraph was Unlike typical programming constructs instantiations of business patterns are inherently interactive and so must adapt to their changing environment Such refinement or variation as well as more radical mutation is intrinsic both to MACK itself and to the operation of the market that MACK is designed to boost And there will be relatively few such typical programming constructs remaining which are not transparent to their users Those are the RE methods Further well your description makes

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

  • Jeff Sutherland: Integrating Java, Objects, Databases, and the Web
    order is written whereas one wants them to do so at a far earlier stage There is an effective time mismatch between the RDBMS and the UI tool s own logic That is of course one of the motivating factors behind OODB However see below It also seriously affects transaction design See Ralph Wolfgang The time mismatch is part of the large orthogonality which I noted in my paper between the order intrinsic properties and environment intrinsic properties even though they must combine to determine the actual workflow with all its attendant logic including its actual transaction design and associated resource reservation decisions Such problems then indicate that it might not after all be such a bad idea to contemplate blurring the traditional division into the three tiers that you seem to go along with See also Wolfgang where I point out how an adequate tool for helping people simplify complexity can also be brought to bear on such a complex problem too That is another example of the much vaunted reflectivity of MACK compliant application models in action In the same breath I might point out that in MACK such reflectivity is largely for free as it all takes place within the abstract model where everything is already logically clarified and does not require any dangerous semantic steps through an RE method the RE methods being responsible for the atomic steps between the deemed reality and the abstract model paper synthesis I can generalize my problem above with that snapping onto and with the 3 tier architecture as a whole There are too many sources of procedurality both algorithmic and realtime it is explicit in triggers in DBMSs or class specific methods in OODBs procedural program code and workflows it is implicit in GUI or DBMS or other Business Rule declarative constructs which after all need to be rendered into explicit procedure somehow and there are events both i o related and internally generated such as realtime and error traps They mesh most messily if at all Except of course in sales demos or other Procrustean constructions such as many implemented applications Metaset MACK has a clean integrated and ultimately simpler approach See Wolfgang MACK workflow Ralph and my introduction to these comments On thin clients You have given me another golden opportunity for some comparing and contrasting A Web Based Solution for Business Object Architectures To enhanced competitiveness in an environment of accelerating change businesses are turning to Web based solutions for Intranet client server applications Some potential benefits are Thinner clients Reduced network costs Automated software distribution Lower development and maintenance costs Transparent portability dramatically reduces complexity Simpler technology for MIS to implement Infrastructure for distributed business object architecture It seems to me that the industry is in some danger of falling head over heels in love with the thin client concept Considering the accumulated heaviness of a fully configured Microsoft based hard disk with all its many attendant administrative difficulties only some of which you have

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

  • Business Object Architecture
    with a protocol that allows efficient communication with other objects on the network Consider a typical client server application like an order entry system This system takes a Purchase Order as input and produces a validated order as output The internals of this component should be a black box to the external world The resulting order is input for another subsystem or alternatively an exception condition is raised if the Purchase Order is not valid for processing Figure 2 An Order Entry Business Object To support plug compatible reuse a business component must be encapsulated in two directions The external world must not know anything about component internals and the internals must not know anything about external components other than allowing interested objects to register for notification of specific events or exception conditions The internals of a business component are made of other encapsulated business components For example when a Purchase Order passes through the membrane of the Order Entry business object an internal component must see it validate it look up customer information inventory availability and catalogue pricing and build an order that is consistent with business rules and procedures Each of these tasks is accomplished by embedded components many of them communicating with external data sources External databases must be encapsulated as Business Objects or reuse will not be easily achievable There must be a database access component that causes values from any kind of database to materialize as objects inside the business component Whether object oriented relational or other database access is required a set of class libraries designed to automate this interface will result in a major savings in development resources An Order Entry business object will typically have multiple user interfaces A clerk may be taking the order over the phone entering purchase information validating customer records and credit data and reviewing an order for consistency and customer acceptance Other users may require different presentation screens User interfaces are difficult and time consuming to build at the code level Today much of this process can be automated They should be encapsulated as separate objects that communicate by message passing to the Order Entry object Failure to do this will limit reuse and waste valuable programmer time on laborious time consuming maintenance tasks Users should be able to create interface objects with simple object oriented tools Subsequently the programmer should be able to easily snap user interface objects onto the Order Entry object A simple Order Entry client server component has at least three large grained components one or more presentation objects a business component that models the business process and a database access component that shields the application developer from database access languages database internals and network communications see Figure 3 Figure 3 Client Server Component Business Object programmers focus their efforts on building business components or large grained Business Objects which can be easily distributed on the network Distributing Business Objects System evolution will invariably distribute these Business Objects to maximize network performance and

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



  •