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".
  • Hruby: OOPSLA'99 Business Object Component Workshop
    business product or provide a service and quality assurance methods such as various reviewing tasks verification and approval Fig 2 Example of a business service type in the UML notation Modularity and encapsulation of the business process catalogue are at the level of business products and services Fig 2 shows an example of a business product meal which encapsulates attributes such as cost and cook time and tasks such as cook serve get consumer feedback and eat The allowable order of the tasks is specified as a state machine In the traditional way the same business service would probably be specified as prepare meal with the focus on the sequence of the tasks A focus on the result of the service as stressed in this paper allows for specifying the purpose attributes and tasks related to the service precisely without it being necessary to describe a large number of allowable task sequences of prepare meal As a result of this the traditional specification focuses only on the main success scenario and often omits the quality assurance of the products and services The object oriented approach is precise and simpler because the focus on the result of the service allows for a more abstract specification Architecture of the Business Process Catalogue As described in the previous section the first class citizens of the object oriented catalogue of business processes are the final or intermediary products and services that an organization provides The structure of the catalogue is based on the pattern for structuring UML design artifacts 1 and is illustrated in Fig 3 The catalogue consists of eight major components The product relationships specify static relationships between business products services and business partners Business products services and partners can depend on each other contain each other inherit from each other or just refer to each other Static relationships between products and services can be represented by UML static structure diagrams The product interactions specify examples instances of business scenarios in terms of interactions between business products services and business partners The interactions between business products services and partners can be represented by UML sequence diagrams or UML collaboration diagrams The business product described in terms of the purpose responsibilities properties and attributes as well as in terms of the tasks related to the product service or business partner The product lifecycles specify the states of business products services and business partners and the events that affect the state such as creation completion and approval In particular the lifecycle specifies the allowable order of the tasks performed on the product and service The lifecycles can be represented by UML statecharts or activity diagrams The product collaborations specify business process types in terms of their goals and purposes preconditions postconditions and attributes of business products services and business partners that are accessed or modified by the business process The collaboration types correspond to the concept of activity illustrated in Fig 1 The product collaboration relationships specify how business processes are related to each

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


  • Marshall: OOPSLA'99 Business Object Component Workshop
    size of organizations decreases Outsourcing manufacture to order sub contracting niche marketing direct sales and other such trends illustrate this position In a such a world where value networks form and disperse rapidly and continously there is no central point of control and it is not feasible to devise or enforce systems to manage the disparate business processes of participating parties as if they were one process Indeed the processes may be confidential to a party or may be selected from a range of alternatives according to prevailing local conditions or may be delegated legitimately to other parties and so on To avoid such problems in particular premature decisions as to how work is to be done business should describe itself in terms of desired outcomes not prescriptions as to how such purpose is to be achieved This is even recognized in contemporary military organizations where authority is absolute in which mission command and control relies on the use of mission tactics in which seniors assign missions and explain the underlying intent but leave subordinates as free as possible to choose the manner of accomplishment Sander 1997 Naturally the means by which outcomes are achieved must also be described particularly if the processes are to be automated However such process definitions are typically for small grained objectives so are simple and direct Where alternatives exist each may be described separately to be selected at execution time according to the ruling purpose For example selection among alternative shipping modes air road rail is often based on a delivery deadline which depends on its purpose not on the process itself Small grained processes of this nature are often reusable have alternatives and may be refined piecemeal thereby avoiding the need for expensive and risk prone re engineering efforts By communicating purpose between

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

  • Rasmus: OOPSLA'99 Business Object Component Workshop
    scope of the single transaction Data is visible only to the client while the transaction is in progress Data becomes visible to the enterprise upon transaction commit Strategies in Writing Integration Components for BOS For this paper push and pull strategies are from the point of view of initialization of the BOM If you are populating the BOM before a business client needs the data you are pushing If the populating of the BOM is triggered by a business client requesting data then you are pulling Push Strategies Push style integration components act as clients to the BOM They generally assume that someone knows exactly what data a business client to the BOM needs and when they need it Data usually moves around in very large chunks The clients themselves have no persistent state data They contain function only Pre population Client Can be manually triggered where a human supplies parameters as to which legacy data to retrieve Alternatively can be scheduled as a batch job that examines newly arrived data in legacy systems Granularity is usually large ex get all of the data associated with a life insurance application and populate the BOM with it Attempts to read all of the data necessary for the business clients of the BOM to perform their function Typically populates the BOM using the same API application programming interface as the business clients Controls the transactional scope of the BOM interaction If synchronous legacy interaction fails can rollback the BOM transaction Synchronization Client Can be manually triggered but is usually scheduled as a batch job Examines data in both the legacy system and the BOM compares values and decides whether either side needs to be updated Amount of data read can be large Amount of data updated is usually small Granularity will vary depending on whether you have one client or several that do specific pieces Controls the transactional scope of the BOM interaction If synchronous read legacy interaction fails can rollback the BOM transaction Rollback of the legacy system will depend on legacy transactional capabilities Update Client Can be manually triggered but is usually scheduled as a batch job Usually examines BOM data to determine if a particular status ex complete cancelled etc has been reached Will update the legacy system and then remove data from BOM Needs to be intelligent enough not to remove shared data Updates to legacy and deletes of BOM will usually be done in a pseudo two phase commit Deletes will not take place unless legacy updates have been successful Most likely to fail legacy updates will be done first so that legacy is not left half updated If legacy update does fail either compensating transactions can be used or humans can be contacted to fix it usually through an exception log If any of the legacy updates are asynchronous a response client will likely be involved see below Delete of BOM data will be pending until all asynchronous responses have been resolved Response Polling Client Either

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

  • Reenskaug: OOPSLA'99 Business Object Component Workshop
    First we need need several hierarchies tailored to the needs of the different role players This has been done with great success in the specification of Enterprise JavaBeans Second business objects appear to be defined in terms of component composition If so we need a clear specification of a Business Object Schema Caveat My background is role modeling OOram Smalltalk frameworks component composition reuse an Java Beans and Enterprise Java

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

  • Business Object Design and Implementation III
    query system for information uniformity and incremental computation for performance Each idea in our framework can be applied to many other business object implementations 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 Recently the business community discovered the importance of business process engineering and the object oriented community has put much emphasis on the structuring of business applications However there is a gap between the two efforts Our claim is that state of the art business application structures and frameworks do not represent business procedures adequately Business procedures are not modeled naturally i e in the same way as they are described by the business community A Business Object Framework Architecture by Hans Albrecht Schmid FB Informatik Matthias Riebisch Deutsche Post AG Torsten Heverhagen Informatik University Essen Harald Liessmann Wirtschaftsinformatik University We advocate a 5 layer architecture for business object frameworks with the layers presentation business process business entity data access and data storage instead of the more common 3 layer architecture and give reasons why the 5 layers are required Ride The Mainstream with MACK Business Objects and Escape the Divine Programmer Syndrome by Christopher Spottiswoode Metaset South Africa MACK is the proposed standard Metaset Architecture for Common Knowledge where Metaset is a conformant program currently being developed towards full groupware Good groupware is both the product and the facilitator of due commonality and standards Full groupware includes both developer and user facilities combined as a market infrastructure It mediates groups such as supplier organizations market segments and communities of the two together both within and between the groups Session 4 The User Experience Business Object Transitioning by Lenny Estrin This paper describes the experience and history of introducing Business Objects into large organization and illustrates the transition process The road of establishing the Business Objects as a best practice in a large insurance company which has a tremendous investment in a legacy code and which has had problem adopting a new technologies has been a challenging one Working with Business Objects A Case Study by W Hordijk S Molterer B Paech Ch Salzmann Institut für Informatik Technische Universität München We report on the first steps of a case study on the usage and adaptability of business objects BOs This toy world scenario is the first stage of a study for a German automobile company to evaluate business objects especially from the reuse perspective Therefore we transfer a well known example a time planner from UML to CDL realize it on the basis of IBMs San Francisco framework and take a critical look at the resulting benefits of BOs against ordinary object oriented techniques A Dynamic Business Object Architecture for Supporting Strategic Management Planning by Kitty Hung Tony Simons and Srba Cvetkovic The University of Sheffield One of the current problems in the software industry is the communication gap between the business end users and the software developers This gap tends to limit the software developers knowledge in the business in terms of requirements strategies and operations As a result the software delivered cannot meet expectations and end users find it difficult to justify the return on investment from software This position paper presents a Dynamic Business Object Architecture DBOA with an aim to fill this gap Conclusions Complex Adaptive Systems It is useful to apply cas concepts to enterprise business object component systems For example Holland creates a synthesis of seven relevant cas concepts 6 Odell has directly related cas to building distributed object systems 7 The following core concepts can help 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 forms 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 concept in Minsky s Science of Mind or Hofstader s analysis of an ant colony Meta agents an enterprise are formed of aggregates of agents enterprise systems and exhibit emergent behaviors revenue profitability cash flow the indices of value creation 8 9 Tagging mechanism this mechanism facilitates the forming of aggregates from HTML pages to the mechanisms in CORBA or DCOM that allow interobject communication They facilitate selective mating i e firewalls block certain tagged elements to protect the enterprise Thus they preserve boundaries between aggregates They allow us to componentize object models and enable filtering specialization and cooperation They are the mechanism behind the development of hierarchical aggregates that exhibit emergent behaviours like an operating system Nonlinearity property nonlinear systems exhibit catastrophic and chaotic behaviors Traffic flow on the Internet is nonlinear leading to predictions of the collapse of the network Brownouts system loadings scalability effects are often nonlinear The arrival proliferation and destruction of viruses on the Internet is a nonlinear phenomenon that can be modeled like predator prey interactions in biological systems Flows property workflows are examples of flows in action Message routing is a flow Tags condition flows which often exhibit nonlinear behaviors and emergent behaviors Flows typically have a multiplier effect Money injected into the economy has an effect out of proportion to the amount similar to email or other message flows on a network The recycling effect of flows enables the rainforest as well as an enterprise computer ecosystem Individual pieces evolve die are replaced or reused constantly changing the characteristics of the enterprise Living software is software that is constantly changing due to flows as rivers change their course Dead software is eventually detritus that is expelled from the enterprise organism Diversity property persistence of an individual agent depends on the ecosystem of agents that surround it whether the agent is an ant in the rainforest or a business object in an accounting system The evolution of these agents as software changes causes convergence of system

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

  • BOMA Business Object Management Architecture
    Management Architecture Chris Marshall SES Software Next slide Back to first slide View graphic version Notes Chris Marshall is a director of the Object Technology Group which is a subsidiary

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

  • first do document making explicit the intuition underlying the concepts before working on the precise descriptions of the concepts
    For example terms defined in Part 2 and Part 3 must be carefully examined to see that their meanings as defined in those parts do not clash with their ordinarily understood business meanings or specialized terms must be developed instead This overall goal does not preclude the use of formalism and precision in the enterprise viewpoint language Business domain experts frequently deal with formalism precision and highly specialized language in their own domains law accounting etc However the notation and terminology of the language should be such that it can be learned by a reasonably intelligent business domain expert without a great deal of specialized training and directly employed by such a domain expert with a minimum amount of specialized assistance at least at the initial stages of specification MA96 Enterprise Language Refinements The following comments are addressed to clause 3 Enterprise Language Refinements of the Outline for Draft New Standard They list and briefly discuss enterprise language concepts Some of these are concepts included in RM ODP Parts 2 3 and 4 which may benefit from further refinement Others are new concepts One of these new concepts is referred to in this document by the name business rule Annex A Document X3H7 96 07 R2 of this document describes in more detail how business rules may be represented in the specifications of the enterprise viewpoint of RM ODP and shows several examples including an example of a contract It reuses concepts and constructs from RM ODP Parts 2 3 and 4 as well as from the ISO General Relationship Model GRM and from other sources Many concepts and constructs reused in Annex A have been specified in existing ISO standards such as RM ODP and GRM nevertheless they may have to be amplified refined and perhaps in come cases explicitly redefined in order to apply to the enterprise viewpoint of RM ODP Specifically a community RM ODP Part 3 Clauses 5 1 and 5 2 may be determined by its business rules most importantly by the invariant that determines those fundamental properties of this configuration of objects which remain unchanged by any operation action applied to this configuration at the same abstraction level This invariant is preserved during the lifetime of the community by all existing and possibly new actions Both the invariant that defines the community and other properties of the community such as definitions of operations applicable to the configuration of community objects as well as definitions of roles and policies may be considered to be business rules Part 2 Concepts The following modelling concepts have been suggested by US contributors as candidates for refinement composition of behavior The following modelling concepts have been suggested by US contributors as additions action signature application architecture rule The following modelling concepts have been suggested by US contributors as possibly needing correction interface signature Part 3 Concepts The following concepts have been suggested by US contributors as additions to the enterprise viewpoint language agent life cycle The following concepts have

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

  • Minutes, Meeting 7, X3H7 Tech. Comm.
    Doc Date 6 April 1995 Table of Contents Executive Summary Motions Passed Committee Responsibilities see X3H7 95 05 References Chronological Details of Meeting Discussions Tuesday 4 Apr 95 Wednesday 5 Apr 95 Thursday 5 April 95 Reply to Jeff Sutherland

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



  •