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".
  • BOMA Business Object Management Architecture
    Next nbsp nbsp Last nbsp nbsp Index nbsp nbsp Home nbsp nbsp Text nbsp nbsp Slide 1 of 33 Notes Chris Marshall is a director of the Object Technology Group

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



  • up with a standard definition of account The business had 13 incompatible definitions and could not resolve them Well here at LANL which is also a large institution we have the same kind of problems At one point I was thinking of proposing a Business Object like approach But to make people agreeing on the needs is more than a challenge For example although they are not talking in terms of Objects they cannot agree on the definition of a building Some will measure distances from inside side to inside side of walls Some others will include the walls themselves This resulted in different implementations of non interoperable systems I am interested to know more about why such efforts are doomed and how Business Objects can still help in this domain Your idea of patterns is seducing but I was wondering how you can practically use it I could imagine how to use and reuse software components implementing Business Objects in the development of an IS I could also imagine that during the Analysis phase of a reengineering effort we could recognize some patterns across different domains applications I have more difficulties understanding how Analysis Patterns could help in reconciling

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


  • phase of a reengineering effort we could recognize some patterns across different domains applications I have more difficulties understanding how Analysis Patterns could help in reconciling opposite business views Assume one group builds an accounting framework which they want to spread around an organization This framework will typically have many classes and in effect contain many analsysis and design decisions Business Objects rarely stand in isolation in practice most business objects will have many links to others A department who wishes to use the framework has to accept the whole thing So they look at the decisions that are in the framework and if they sufficient points of discomfort they will not use the framework With patterns however its not an all or nothing decision they can use what they like and change what they like The result is not as good as if they had adopted the framework but not as bad as ignoring the framework and not using any patterns Of course a really good framework will be sufficiently malleable that users can override all the decisions that they don t like ie provide a suitably abstract account or building But building such frameworks and making them comprehensible

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

  • Christopher Spottiswoode comments from a Metaset/MACK point of view
    seems to me that your conception of a Business Object is rather too rigid Of course one must blame current technology for at least part of that as proven by the well recognized fragile baseclass problem With MACK on the other hand I must be getting rather boringly predictable there is no such problem But you might well object one wants some rigidity for interoperability e g as in EDI or the next generation thereof more fully implementing electronic trading and other synergetic value creation or in order to build on the next version from the original developer To which the response is easy Yes but that is then the minimum rigidity that needs to exist None should be imposed for technological reasons And analogous rigidities or prescriptiveness might also be sought in the analysis pattern domain where we would in addition be mindful of the growing integration between A D and operation in an ever more dynamic and demand driven world as indeed was already implicit in the IDIOM name itself Interpretable Design for Integrated Operation and Management that I trademarked in 1976 Find the references to that name in the faq In MACK both analysis patterns and business objects are implemented as typologies each in its own way in its sphere of applicability 7 Business objects typologies apply to business entities while analysis patterns typologies apply to meta or business model entities The uniformity of approach is part of the simplicity of the architecture and caters for the gradations between business objects and analysis patterns Differences in expected features are possible analogously to the way in which one programming language can be used without undue restriction for many different purposes You might well wonder how I can equate an analysis pattern which is typically multi object or orthogonal

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

  • Christopher Spottiswoode comments from a Metaset/MACK point of view
    that facilitates building a business system Jacobson s idea that a business can be modeled as a system is of course correct but this is not the same thing as being able to represent the business as understood by the community and culture that are its core Your qualification is correct in principle but in practice that community and culture are influenced by good formalizations Demand is satisfied when it happily adopts the terms of appropriate Supply The market makes reality The Context we started with in general and Alexandrian terms is that a business can be seen as an ongoing response to a set of problems and opportunities see my POP below The success of the response is measured against business objectives one of which may be to make a profit And because of the ongoing nature of the response the business reflects a corporate culture that shapes its actions over time Another part of the Context was that a key requirement in modeling a business should be to separate the organization from the business But beware of oversimplification for the sake of convenience in analysis The medium is often the message The mechanisms of the organization may be unique assets and major contributors to competitive advantage They may represent strategic opportunities The internal organization is NOT the business but rather the machinery that the business uses to provide resources and money to support business activities The underlying organizational and functional views merely clarify and support the aspects of the business model Internal processes and activities e g creating a budget scheduling training allocating staff are organization activities not business events at the strategic i e core process level Finally although recognizing that the model should be driven by the business and NOT by any potential system solution or way of conceptualizing a solution there is a need to be able to bridge the gap from business to possible systems in a way that is as simple and consistent as possible End of continuous quote Despite my various apparently disparaging comments I can really relate to your high level approach Then you continue in the same thoughtful and thought provoking vein The highest level Business Patterns are frameworks which we call business themes following Peter Coad s description of object patterns as repetitive forms just like those in music The culture and objectives of a business can be expressed as a small series of business themes Each theme addresses a variation on the question why are we in business but in a way that is particular and practical rather than the abstract language often used in Mission or Vision statements Business Themes are those patterns that constitute the real Vision behind a business They are applied reapplied combined varied and reused in practical realizations that constitute the life of the business I particularly like that last sentence abstractions and practicalities can be brought a whole lot closer together than they usually are The conventional expression of a pattern in

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

  • You certainly seem to be in that chapter
    They also relate to your Accounts Together many of your Behavioral Patterns address parts of the very problem set that the innocent questions section in my paper addressed and is inherent in all multiply interconnected situations The latter are of course rather important to my whole theme interconnectedness being the abstract or conceptual equivalent of complexity Please note I have only just looked at that chapter so I am in luck to find that common interest to start me off again I start by setting the scene that both of us are addressing even though from different viewpoints The need is to discover and pursue the implications in all presently relevant contexts of any single and apparently isolated event It is forward chaining in a distributed logic world In OO it is all about object collaboration 7 Such request analysis and method despatch would of course be a central function in any realization of the generalized object model whose dropping from the OMG s OMA I so regretted in my paper We must also bear in mind that in general in a componentized world the resolution must allow for multiple independent designers and the consequences may be discovered either at design time or in run time or both depending on the degree of binding The behavioural consequences may be non temporal and purely logical hence needing only to be seen in algorithm time or they may have a realtime component that is relevant to users that is there are workflow implications That would of course be relativistic realtime paper OMG back on track 6 Jeff Marímba So what do we do about that whole complex scene The key to the successful and clear resolution of that general problem lies in how chains of responsibility are specified or more generally in the terms in which a multi object operation is analysed and understood MACK has one appropriate and general purpose key However it is rather central to the whole architecture so I shalln t go into its details here But it is also the problem area that your Behavioral Patterns address and it seems to me that you the Gang of Four are unduly modest and have provisionally ignored a number of important issues Once again I start with my rather hackneyed time component of data and shall focus on two related aspects of it user realtime and workflow and transaction definition and management On user realtime I would like to quote with approval your own rendering in a 21 Jun 1996 e mail to Jeff s obj tech mailinglist of one of the points from the IEEE article Basic reading for OO developers Control flow that is visible to the user should not be hardcoded into a class It s not clear whether you approve of it and certainly I suspect that it might have a major impact on conventional OO design Anyhow I definitely do approve of it It seems to accord completely with my observation in my paper

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

  • Christopher Spottiswoode comments from a Metaset/MACK point of view:
    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

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

  • Wolfgang Schulze, Markus Böhm, Klaus Meyer-Wegener: Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments
    than final The MACK process or operation on the other hand is qualitatively different as is its correspondence with human activity items It also permits a great simplification of the whole concept of workflow thanks to enabling that much vaunted reflectivity on processing too See MACK workflow below Service availability My initial reaction here is that that set and classification of services is both too simple and too complex On the one hand operations such as transfer and delegation for example are too simple just plain like that to support the delicate diplomacy and distribution of responsibilities that might be required True you provide for any one operation to be a nested workflow in itself but a nested structure does not permit a more intricate mixing of operations from different levels for more complex needs Here we are back at that complex collaboration problem where I started Thus extension via type specific functionality cannot be general purpose enough That argument is a virtual repeat of the second bulleted point under 2 above On the other hand as a whole the picture is unduly complicated by having to cater for that particular set of states For example aborts might be managed by an outer layer Again as you say your exposition is merely illustrative but I think I have raised some structural problems that aren t so easily provided for within any framework such as you have described Or am I barking up the wrong tree somewhere Please correct me if so Your last paragraph asserts To sum up all of the mentioned services should be offered and realized by the workflow object itself and not by some other infrastructural element In contrast Metaset has its infrastructural kernel functionality in control but while driven by attached users it is guided totally by application objects in the form of typologies many of which might also be in code generated form hence nicely part of the kernel from an execution point of view Such locally central control is part of what is meant by Metaset s being an application operating system That also puts the finger on another function of operating systems namely to manage resource contention An added advantage of a MACK realization s integrated workflow management is then that resource management is closely part of the picture too which is easily seen to offer many opportunities for optimization of end user convenience as well as efficiency But it also easily seems that it will horribly complicate design After all there is usually a sharp dividing line between such functions which more or less coincide with the lower two tiers of the common 3 tier architecture From a MACK viewpoint that division is an oversimplification and while its removal might seem an unmanageable complexification the easiest way for me to respond now is merely to note that Metaset was designed to help people simplify complexity in the CASE domain as in many others More to the practical point we might note that in a MACK compliant world smooth version migration will eliminate many of the reasons for a division between the two functions of database management and workflow management taking business rules into account cf the old program data independence justification for DBMS that incidentally is virtually contradicted by the very idea of OODB That division I allege is one of the artificial complications in the present that is best cut out You then go on to note The workflow object gains a life of its own and is visible as an entity throughout a software system In Metaset actual workflow processes play that role in an integrated way 3 Workflow Meta Objects are first class objects where by a Workflow Meta Object you understand a set of procedural rules or a workflow script in some formal language How do you respond to Mark Baker s flat statement in his paper that Work items and lists are outdated I would agree with him strongly I am very happy to see this sentence When actor selection is done by some specific algorithm e g based on some trading approach it is very hard to capture this policy in the workflow description It underlines the importance in a MACK compliant world of its integrated market picture 4 Workflow Meta Objects are the key to workflow reuse You open with this sentence Growing exploitation of workflow technology within an organization may quickly lead to the introduction of a vast number of different workflow types Would you say that that accords at least partly with this statement in my paper But either such an object one single workflow object for any one business object in all environments would again be unmanageably complicated or there would in real life be an explosion of such larger granules in an attempt to compartmentalize the complexity Anyway you then go on to say In order to keep the set of workflow types manageable minimal and structured it is necessary to reuse existing workflow types Reuse here means the possibility to build new workflow types by composition of existing ones But you seem to mean manual composition even though repository assisted Is that so Surely not 5 The Workflow Facility can be built using existing CORBAservices This is of course where my problems with Workflow through CORBA really start boiling over Firstly simplistic ACID transaction management is not suited to every real life workflow expectation that users have gained from everyday manual practices For example the Isolation part of ACID is in general incompatible with long transactions and the resulting inacceptability of the pessimistic or consistency approach to resource reservation The thereby sought serializability oversimplifies for mere technical convenience Ralph Together such considerations help explain why there is all that work going on in Germany on advanced transaction management Stefan Secondly trying to embed the general procedure or interface defined object s behaviour within your realtime meta objects places intolerable constraints in general on the algorithm time granularity of object definition

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



  •