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".
  • Untitled Document
    define long running transactions as part of trading partners agreement to conduct electronic commerce The transaction data is commonly represented as an XML document The context of the transaction is now handled in most B2B architecture by a business process engine These relatively new concepts greatly impact the role and design of business object components In our talk we define and present a vision for a new category of BOCs

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

  • Dean Mackie's Workshop Position Paper
    executables to the entire organization was fairly easy so there was no smaller scale advantage to that separation So the strategy that evolved was to develop business rules as an isolated layer within the application Flexible Abstraction The objects within the system were developed by modelling information from three sources the legislative rules corporate policies and business processes Legislative rules are defined external to the organization and are subject to interpretation and legal debate They are subject to change and have effective dates so that for example corporate policies must be developed to manage work that applies before after or spanning effective dates in a manner consistent with all known legislation Corporate policies also evolve around work for which no specific legislative rule applies yet or where legislative rules are ambiguous Business policies help determine corporate workflow resulting in timely and accurate responses to member requests while managing risk effectively Policies and processes also change regularly and can also result in effective dates for rules Attempting to model or even document all the rules governing the company would neither be practical nor cost effective given the amount of effort required to collate and maintain currency of the information At OTPP the strategy used was to automate the activities of one department at a time within the multiple departments involved throughout the company As behaviour for new departments was brought on board objects were refactored to evolve the main abstractions Flexibility was therefore extremely important in the abstractions used Also a clear vision of the fundamental model used was communicated regularly to the development team even as short term tradeoffs and tactical practicalities were acknowledged and implemented The key was the identification of the main units of corporate currency given the legislative rules corporate policies and business processes These are the objects that move into around and out of the company with the information and activities associated to them For this reason the simple notion of a rule is not a first class object but rather rules get embedded into the primary abstractions as appropriate Encapsulation and layering were important to help ensure the flexibility of the design so that it might easily react not only to rule changes but to expansion or shifting of scope as more departments begin using the system Layers The system saw fairly standard layering The graphical user interface GUI was isolated from the business rules by an ever maturing application layer as were back end repositories and integrated systems When we web enabled the application we saw a temptation to violate the encapsulation of the business domain objects We perceived that web application server vendors were encouraging users to remodel their business logic within Enterprise JavaBeans EJBs colocated with the application server itself Instead we chose to enforce the isolation of the domain objects and use a Simple Object Access Protocol SOAP framework to send business information as an extensible modelling language XML payload with Common Object Request Broker Architecture CORBA as the middleware This

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

  • CROSS-ORGANIZATIONAL WORKFLOW INTEGRATION WITH CONTRACTS
    and authorizations to coordinate the interaction We have designed a XML based contract specification language for this purpose called XLBC that will be sketched in section 4 3 1 Business Objects Business objects provide a natural way for describing application independent concepts such as product release order supplier stock and the like see Figure 3 The business objects play a central role in capturing the semantics of actual business entities and processes in a way that is understandable by the business manola98 Business entity objects that reside in this layer essentially contain business data which can be manipulated by their business methods services Business objects can be subdivided in various categories Common Business Objects CBOs are business objects that can be shared across multiple domains e g a currency business object They can be specialized to deal with domain dependent semantics Furthermore we discern business objects with common semantics within a vertical domain also named domain frameworks The OMG is currently putting much standardization efforts in both categories of objects Before we give a CDL example of a business entity object Supplier we present a simplified version of the enterprise model of a IC Manufacturer company see Figure 3 This lot manufacturer produces standardized ICs that are used in the PC manufacturer s products This enterprise model is structured along the axis of the integrated enterprise modeling architecture and represents a componentShipment workflow that is concerned with delivering lots of ICs according to a predefined contract the Release Order doc contract The interface services of business objects as well as the task and workflow objects are textually represented with the Component Definition Language CDL CDL is a declarative language to specify the services of collections of business objects their relations dynamics business constraints and attributes Figure 3 Enterprise Model of Component Manufacturer Motherboard Shipment Business objects are not written in CDL but in programming models for which language mappings are available e g Enterprise Java Beans CDL is a superset of the Interface Definition Language IDL the ODMG Object Definition Language ODL and the ODMG Object Query Language OQL This specification language extends IDL by adding several high level constructs to capture more business semantics IDL indeed merely defines object methods to implement language independent distributed objects which can be plugged in to a broker ORB that provides additional services such as security concurrency and transaction services The goal of CDL transcends this rather low level inter object communication purpose of IDL and is oriented towards delivering distributed business objects based on the Business Object Facility BOF specifying Common Business Objects and delivering marketable business objects by software vendors bodtf97 The following CDL excerpt illustrates the supplier business object associated with the Release Order doc business object 3 2 Business Tasks A business task is the definition of a set of interrelated activities that collectively accomplish a specific business objective possibly according to a set of pre specified policies A business task is associated with a role performed by automated actors in the domain actors can execute multiple roles Business tasks are initiated by events that trigger activities in the organization They can be internal e g rules or external e g customer requests The business process tasks are initiated on the basis of an incoming event e g a customer request and result in an outgoing event e g the notification that a product is ordered Business tasks rely on a collection of business objects to perform their operations i e they change their states Business tasks provide a set of basic building blocks for an application in a specific business domain e g procurement management general ledger etc These building blocks can be specialized and extended to capture domain or application specific processes that are realized at the workflow layer e g on the basis of inheritance or composition The following excerpt shows an example of a CDL definition of the business task process release order performed by the SalesEmployee actor during which the requested quantities of a customer Manufacturer are recorded in the Release Order doc business objects This task is performed after the request to release an order from the Manufacturer has been received by the SalesEmployee Release orders contribute to the agreed upon quantities in the outline agreement this task releases the schedule lines with delivery information in the contract outline agreement 3 3 Business Workflows The workflow layer assigns business tasks to actors according to the state of each process in progress and moves the process forward from one role that performs a business task to the next Workflow objects coordinate and control the overall process logic of business tasks The control of the workflow objects is stored as a set of state transition rules STRs that specify the conditions under which the workflow can proceed from one task to the next Workflow objects are based on an extensive foundation of reusable components viz the core business processes that form the basis for building new applications Workflow enabled business processes can track transactions across department and even enterprise boundaries This type of distributed workflow layer provides the sequence of business activities arrangement for the delivery of work to the appropriate inter organizational resources tracking of the status of business activities and coordination of the flow of information of inter and intra organizational activities Workflow activities may invoke components from existing applications for instance legacy objects and combine them with newly developed applications Several of the workflow activities have a transactional nature which requires long running interactions The requirements of transactional workflows have been described in schmidt98 The CDL excerpt show in the above specifies the componentShipment workflow that handles the delivery process of the IC manufacturer to the PC Manufacturer The workflow is initiated by an external event init component shipment this event will be linked to the contract see below As explained in the above the state transition rules lot shipment and credit limit specify how the workflow proceeds from one business task e g process release order to the next check credit limit 4 Contracts The glue to link inter organizational workflows Virtual enterprises float upon a network of mutual commitments that have been formally represented in business contracts Contracts are statements of shared purpose marshall00 which comprise the mutual obligations and authorizations that reflect the legally binding agreements between two or more trading partners These agreements are generally used to specify delivery times the quality of products the terms of delivery the price of the requested items the business procedures shared terminology etc In this way business contracts and their objectified counterparts can be applied to couple inter or intra organizational business workflows which are defined in term of cooperating business activities and objects in a comprehensive manner 4 1 The Contract Specification Language the Formal Language for Business Communication In this section we will explain a slightly adapted version of the Formal Language for Business Communication FLBC kimbrough97 to specify business contract s between enterprises FLBC was introduced to provide a representation that offers more expressiveness and flexibility than the conventional EDI standards such as EDIFACT and ANSI Our XML version of this language XLBC represents messages as sequences of speech acts that are organized in a layered architecture see Figure 4 ranging from low level communicational building blocks speech acts to workflow loops Each layer is built on top of the lower one We assert that the speech act is the most elementary unit within a business transaction Speech acts define what people do actions while communicating searle69 austin62 They represent a performative act like a request or a promise that in itself constitutes an action Speech acts usually only have a meaning when they come in pairs for instance a request that is followed by a commit We call these pairs of speech acts a transaction A transaction can be defined more formally as the smallest sequence of speech acts that has an effect in the social world of the participants These effects can be defined in terms of obligations authorizations and accomplishments As can be seen in this example the combination of the request of the customer to deliver a product and the promise of the supplier to actually deliver it constitutes a deontic effect the obligation for the supplier to deliver the product and an obligation of the customer to pay the agreed price At yet a higher level we have defined a workflow loop that bundles various transactions For instance a typical workflow loop can be built up from an actagenic and factagenic transaction or conversation During the actagenic conversation an actor requests something from another actor which this actor can reject or accept This leads to a commitment or obligation to keep the promise The factagenic conversation starts after the executor has performed the transaction and s he has declared that s he has created the desired state of affairs The factagenic conversation results in an obligation for the customer to accept the state of affairs if it is conform the conditions of satisfaction The ActionWorkflow loop medina92 is an example of such a workflow loop and the DEMO approach dietz96 provides similar loops Figure 4 The multi leveled communication patterns The workflow loop gives a rather biased perspective of a transaction the analyst takes the viewpoint of either the buyer or the seller Since business transactions are in fact exchange processes we have defined contracts to represent this reciprocity The contracts can be represented as two interleaving workflow loops e g a customer who requests a product e g a computer manufacturer that orders a batch of ICs and a supplier who requests money for it in return e g an IC Manufacturer Depending on the trust between parties engaged in an electronic commerce relationship they make use of various implicit contracts during a business transaction Even at a higher level contracts can be organized in scenarios that are comparable to use cases as they denote a sequence of transactions across different contractual relationships for example in a supply chain For a detailed description of this layered formal business communication language we refer to weigand99 4 2 Workflow Control and Execution Cross organizational workflows should basically comprise the following two essential elements see Figure 5 an execution workflow and a control workflow The execution workflows also called business workflows sequence and synchronize the internal business tasks in an organization or organizational unit Their interface masks off the internal business processes from the controlling workflow This is a realistic assumption as partners mostly do not want to loose autonomy in a trading relationship Cross organizational workflows are managed by patterns of deontic control messages as specified in the contract The workflow control basically comprises two parts the actagenic phase and the factagenic control phase that basically encapsulates the wrapped execution workflow The actagenic control phase initiates an internal workflow execution based on his promise to deliver a service Then the internal workflow takes over the worfklow control allocates the resources to the scheduled tasks and tracks the operations The internal state of the workflow is monitored by the contract object e g to check if the deadlines are being met After the internal workflow has been executed control is given back to the contract object and the transaction will be finalized by the assertion of the customer that the service has been delivered according to the former promise see Figure 5 Figure 5 Cross Organizational Workflow Definition Security aspects for Contract Objects In principle all internal tasks of the enterprise architecture that are required for workflow execution are masked off from the outside world We call workflows tasks and objects private or protected entities However in some cases exceptions need to be specified e g if a customer wants to track the completion of his order in the producer s system This category entails public workflows tasks and objects Therefore the contract includes a special section to specify authorizations or even obligations to execute a task in the connected workflow system Figure 6 Contracts Specify Object Visibility Figure 6 aims to express how the Release Order contract that we are about to define more formally prescribes the visibility of the workflow objects and it s components task and business objects The left hand side represents the enterprise model of the integrated circuit board manufacturer the right hand side the PC manufacturer The white entities represent public entities whereas the gray entities denote private or protected components The advantage of this approach is that the security can be defined for various categories of trading partners Storing visibility information inside the CDL definitions would therefor not make sense Although the figure suggests that the contract links two workflows symmetrically it must be noted that there is a very important asymmetry The activity actually performed is the componentShipment The execution of this workflow takes place at the left hand side The control of this workflow takes place at the right hand side The control is split up in two parts the actagenic part Init Release Order and the factagenic part Eval Release Order Remember that the objects in the right hand side of the picture only store and manipulate the state of the workflow control the actual coordination is supervised by the contract The right hand side control part can be a sub workflow of a more complex workflow let s say inventory management but this is not relevant for the interaction and therefore needs not be taken into account We claim that the asymmetry is fundamental the naive idea that there are two independent workflows that just need to be synchronized symmetrically should be abandoned It is always one of the two sides that controls the other As we said contracts are reciprocal arrangements so the contract also defines a compensating workflow typically the payment It may also be the case that on the scenario level different contractual arrangements are synchronized in a symmetric way But on the workflow level there is fundamental asymmetry 4 3 The CDL XLBC Metamodel CDL defines three categories of business types business objects business tasks and business workflows Workflows are executed by an authorized automated actor and result in an obligation or an accomplishment see the homonymous association classes Business types have static and dynamic features Static features include attributes and relationships to other types We discern three behavioral features an operation an appliance and a state Figure 7 An excerpt of the CDL XLBC Metamodel XLBC contracts are represented at the middle of the metamodel As can be seen in Figure 7 XLBC contracts are composed out of one or more workflow loops which in turn contain several transactions composed out of XLBC messages XLBC transactions manipulate the deontic state of the system a transaction results in a new obligation authorisation or accomplishment The deontic state comprises the actual state of the set of mutual obligations and authorisations at a certain point in time An execution workflow is initiated by a startWorkflowExecution event This category of events is lexically linked to an obligation that is laid down in the contract This means that if one completes an actagenic XLBC transaction e g init release order which according to the contract definition results in the obligation of the seller to ship components the workflow componentShipment is started Execution workflows terminate with a terminateWorkflowExecution event They trigger the control flow which check if the executor s obligation is fulfilled The factagenic transaction is triggered by the terminateWorkflowExecution event This transaction itself triggers an accomplishment if it succeeds that is if the other party accepts the result of the workflow execution 4 3 1 The Contract Specification The following excerpt shows an example of an XLBC specification of a contract called Release Order Contract between a computer manufacturer e g IBM and one of its part suppliers Philips Conductors This contract is a special category of a sales document that states fixed delivery conditions e g the number of parts procured in a period e g a month More in particular this contract describes the obligation of a seller Philips Conductors to deliver the product an IC to the PC Manufacturer IBM workflow w003 as well as the obligation of the semi conductor manufacturer to pay for this delivery workflow w004 The transaction has an identifier CONTRACT ID and a name CONTRACT TYPE by means of which it can be stored in the XLBC component library The roles INITIATOR and EXECUTOR define the agents that play a role in the transaction These roles are identified by the homonymous tags There is a limited but extensible number of role names stored in the thesaurus for the time being we consider only the roles INITIATOR and EXECUTOR The roles that are specified in the contract e g buyer and product refer to business objects that must be defined in CDL The contract does not specify the private details of the workflow execution as explained in section 4 2 The PRED componentShipment in the workflow definition transfers control to the componentShipment execution workflow In the example the ACCOUNT PAYMENT workflow is only named This could be sufficient if this workflow is a standard component defined elsewhere The RELEASE ORDER workflow is defined in some more detail but we have abbreviated it for reasons of space Of the various states only one is worked out the state characterized by the obligation of the seller to deliver the product within one day We have abbreviated the time reference in the deadline which normally is spelled out completely in XML The security section of the contract specifies visible public business task objects and workflows This does not mean automatically that the other party has all access rights to these objects as it might be constrained by local restrictions in the CDL definitions The transactions that are defined in the contract are transaction types which assumingly are stored in the XLBC component library Therefore the structure of these transaction

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

  • Guidelines for Developing Adaptive Plug-and-Play Business Component Systems based on the J2EE
    state for each session e g member variables of a class though In this case they are called Stateful Session Beans This condition is however irrecoverable at a system crash or restart Session Beans without any state are called Stateless Session Beans and the same bean can shared among multiple users Entity Beans are persistent components i e their state is persistently saved for example in a database In the case of a system crash the state an entity bean had after the last completed transaction is available again An entity bean often represents a row in a database table If the persistence guaranteed by the container container managed persistence the deployment descriptor of the bean indicates which fields of a database table correspond to which attributes of the Bean The container then takes care about storing this data With bean managed persistence every enterprise bean is itself responsible for the storage of its state Therefore usually the Java Database Connectivity Interface JDBC is used One proposed benefit using an EJB container is that the developer of EJBs should be released from recurring technical tasks during the implementation The container implementation for coordinating transactions multithreading database connection pooling security checks and lifecycle handling can be reused This should permit the encapsulation of pure business logic within the EJB components and so decisively increases maintainability and modifiability of the new system However our experiences with the development of CROFT show that the availability off these container services and the use of J2EE concepts does definitely not lead necessarily to a scalable and modular system The question is how to use the J2EE concepts To ensure modularity and scalability the business logic must be distributed and mapped to J2EE concepts very carefully Also the interface design of the EJB components must still take technical issues in account For example the influence on the performance if remote calls are used These issues require experienced developers in this field Developers can not concentrate on the business logic alone The next chapter describes the guidelines we have developed to overcome these deficiencies We also noticed that the J2EE is missing some security concepts especially concerning object based security checks In this area we propose some requirements for an extension of the J2EE in the next chapter 4 Problems Solutions 4 1 Modularity One of the major non functional requirements was the request for an easily extensible system see section 2 especially that it should be possible to extend the system by adding new entities in the form of business components and relations without changing and reviewing the code for already existing relations components or other functionality Therefore it was necessary to design a modular architecture in which the following rules are applied No hard coded associations Associations between business components at the moment there are four entities mapped to business components in CROFT person project contact and document can be connected by different associations e g persons are members in projects or persons own documents These associations could be integrated directly into the business components implementing the entity However this solution has some disadvantages in case additional business components are going to be integrated in the system or in case an existing business component should be reused in another system Already existing business components need to be changed if new associations are added to them This problem can be solved by modelling separate associations In the business EJB tier each kind of association is realized by a separate EJB that manages the associations between two kinds of business components An association EJB needs to implement the following functionality Create new associations between business components and check consistency conditions Delete associations between business components and check the consistency Return a list of all business components instances having associations to a given business component instance Return the type of associations reference business association or ownership association All associations are handled by a special component called association manager The association manager can be queried for a list of all associations collection of association EJBs connected to a given business component e g a document Using this method it is possible to extend the system by new associations e g an association between the existing business component person and a newly introduced component task without changing the person component This is possible because the association manager can be used to detect the new association between with the person and the task components A separate association EJB person task introduces all necessary code to create and delete this association This way one is able to build compose able subsystems and furthermore achieves easy extensibility To use this extensibility also the user interfaces needs to be compose able in a similar way see paragraph below and moreover a communication controlling component is needed to connect all these loosely coupled parts see paragraph about the folder component Flexible User Interface To achieve a compose able and easy extensible user interface it needs to be designed modular in the way it is possible to add displays for new associations and business components without changing already existing views Therefore Java Server Pages and web beans are used to generate the necessary HTML code to display the corresponding GUIs For example there is a pair of one web bean and one JSP to display the project homepage This bean uses another web bean that requests all current associations for one business component instance in our example the project component from the association manager EJB For each association found a corresponding JSP with a specialized web bean is returned This way all associations like the persons belonging to that project are resolved in the web bean before they are viewed Each specialized association specific web bean gathers all associated business components using the association EJB The JSP generates then the necessary HTML code to display these component instances in a list This list can be included in the enclosing project s view JSP For example the JSP and its web bean for the association person project returns an HTML coded list of all persons belonging to this project Moreover this association specific web bean and HTML list contains interfaces for adding and removing entries to the relation Thus links between the business component instances can be created using the association EJB via this HTML fragment and the attached association specific web bean Using this mechanism it is possible to extend the system later on by an additional subsystem for example to manage tasks There might be an additional association added to the project business component containing tasks within a given project The project view JSP and its web bean do not have to be changed because the additional relation and its corresponding list all tasks belonging to a project is resolved at runtime by the association manager Its representation as a list is generated by a separate JSP web bean and automatically added as an additional list in the project s view The Folder For the combination of the flexible user interface elements described above a general control communication component is needed The folder component allows the transfer of business components between different masks of the GUI and to collect references to components for further printing etc For example it is possible to open a person s public homepage mark interesting documents and addresses and copy them to the folder Later on the user may visit one of his or her projects workspaces and add the interesting documents in the list of documents associated with this project Afterwards the user has the possibility to visit his or her own workspace and add the gathered addresses The folder component acts on a very abstract level since it doesn t have to know about the type of the components it contains Thus it needs not be changed if further business components or associations are added The folder component acts as an indirect connection between the different business components presentations instead of adding hard coded connections between them e g a button add marked contacts to my private addresses that needs to be updated or changed with every new business component or association introduced Result Due to loosely indirect coupling of business components with separate association EJBs and a central component to resolve the associations at runtime it is possible to design an easily extensible system where new business components can be integrated without changing already existent business components This extensibility can also be achieved for the GUI by realizing a flexible modular user interface with a general control component that connects the single user interface parts and business components together 4 2 Performance Performance is a critical issue in distributed systems A remote call costs a multiple of time and resources compared to a simple local call The main advice is to examine use cases of the system and to extract the most common types of requests to optimise their implementation by reducing the number of remote calls For requests at the persistence layer the number of tables to join should be reduced for frequent calls Based on these general rules we extracted the following general useful guidelines System Usage Analysis A main lesson is that performance issues must be considered from the beginning before system design starts They basically influence the design and our solutions show also that other goals like modularity do not have to be sacrificed for a high performance The main question is will the system be accepted by its end users or not During system usage analysis another important question has to be answered How up to date does the displayed information have to be For a web based information system the most frequent thing a user does is to view information Infrequently users will select dedicated business components and change them Users will also seldom create or remove business components and associations The business components are shown and edited in a web form If the user wants to store the changes then the final request for changing is sent to the business logic layer and the change is performed within a transaction However while a user views or edits an object within a web form somebody else may have changed this object For most systems this case rarely occurs and mostly it is sufficient to inform the user that somebody else changed the object In most applications it is not necessary to have a permanent up to date presentation of the data on every screen on every object like promoted by the observer concept GHJV95 Especially a web user does not expect this behaviour A simple refresh or reload will suffice in most cases These assumptions result in design rules described now in more detail Transfer business components contents per value The presentation layer requires the data contents of the business components but there is no need to preserve identity by means of a single EJBs instance where each client application has an own remote reference on it Instead it is sufficient to get the business component s data and id per value as a copy encapsulated in an object A similar solution is introduced in Bro99 This reduces the number of remote calls dramatically as the control layer can perform local calls on these so called model objects Thus a PersonEJB does not need to have remote getName setName getBirthday and setBirthday business methods Instead the control layer needs to invoke only a single getModel call that returns a PersonModel per value which contains all the data This model object in turn provides access to it s internal data by the methods getName getBirthday etc If a business component has to be changed then the control layer calls the setModel on the EJB The EJB will in turn store the change in the database When to use Entity and Sessionbeans As mentioned above in most cases a set of business components is just shown within lists Stateless session beans are ideal candidates for providing these sets of business components data or associations Examples for such sets are the result set when searching persons or the set of all documents belonging to a person One single stateless session bean can be shared between thousands of users and they all receive their own copies of the current version of the business components data from the database This way the required container resources are minimized Note stateless means not that the bean can not access a common state on the database The result sets delivered by the session beans should be just sets of model objects and not entity bean references Creating entity beans and handling their associations is very resource consuming While container implementations may contain code to improve the performance by caching it still does consume enormous resources when a container holds references to thousands of objects that are only displayed For each displayed object the container must perform a lot of computation just for the unlikely event that a user might change it However creating and referencing entity beans is only necessary while creating removing and changing a business component As a consequence we used session beans that deliver sets of complete model objects for all web forms that present lists of entities Only in those pages where a business component is created edited or removed the corresponding entity bean is contacted when the user requests the change This is performed by extracting the primary key from the model object and using the standard findByPrimaryKey method from the entity bean s home interface We thus use a similar use of session beans as proposed by the wrapped entity bean solution described in Val99 However our solution defers the required entity bean instantiation until its really needed As a general standard we required for each enterprise component a model object an entity bean to incorporate the business logic to create change and remove an entity instance and at least one stateless session bean to perform the queries to search for instances in various ways For each association a separate stateless session bean is required to deliver the set of persons belonging to a single document and vice versa and incorporate the business logic for adding or removing single association links For example for the entity person there are a PersonModel a PersonEntityBean and a PersonSearchBean For the association between documents and persons there is a PersonToDocumentBean that uses PersonModel and DocumentModel objects Optimise for the most common use during design Another point is to improve the performance to optimise the database requests that will be performed very often To find these requests a good starting point is to consider the things the system does mostly In our case it is displaying lists This includes that attribute values are displayed and security checks are performed Thus two good candidates for this type of optimisation are the retrieving of attribute domain values and the object based authorization checks which have to be performed for each entry in a list We now look at these two cases in more detail Often only certain values for attributes are allowed For example for the attribute Person title only a single value from a dedicated set of values such as Mr Miss and Prof can be selected These values are usually stored in separate database tables and a foreign key is stored in the title attribute of a persons table entry this is done because the value may vary according to the language used in the user interface Instead of performing joins or even single requests to retrieve the values for a certain key we used stateless session beans to cache these values This improved the overall performance dramatically The use case that somebody changes these values is very unlikely thus the cost of the caching sporadic invalidating and reloading from the database is low compared to the costs of ongoing requests When performing object based security checks the system often has to navigate through the model to check if a person has a certain right For example a person is logged in and wants to see a project with a list of documents The system has to check for each document whether the document belongs to a project whether the person that is logged in is a member of that project and if the document is marked to be displayed for project members These frequent requests can easily be optimised by caching the projects where a person is a member in a stateful session bean inside the business logic layer If the DocumentModel is also extended by the foreign key of its owner no more database accesses are required Again the use case that a person becomes a member of a project without knowing it himself is or at least should be very unlikely Thus the restriction that a new project member who is logged in must logout and login again to see the complete accessible list is acceptable considering the performance gain In general one should look at the most common use cases and identify their required database requests especially those with many joins or those that are often called Then consider roughly the probability that a result set differs from the previous one by looking at the use cases that would cause a different result set If these use cases are very unlikely look at a simple way to reduce the number of joins and requests Either by flattening tables or caching results in stateful or stateless sessions beans We noticed that using this approach based on use cases helps to identify performance bottle necks faster than profiling But even more important is that potential bottle necks are already found during the design phase to prevent them from creeping in during development This draws the developers attention onto the important performance issues right from the beginning Profiling however helps to identify unexpected existing performance killers later on Results Due to the careful consideration of performance

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

  • REA, a semantic model for supply chains
    paper documents At the Graphic Communications Association s GCA s executive conference last year Gerry Galewski a philosopher on information technologies gave a provocative explanation on why it often takes years to truly appreciate the full potential of new technology Now let s look at how we do business in the 1990s In the 30s and 40s and 50s and 60s professional managers defined the common business processes that we use to this day Then computers and networks were developed And we set out to take advantage of this new technology and automate our processes and naturally we did that based on a cultural context Therefore we called this new capability Electronic Document Interchange But the underlying document model driving the process stayed the same We called it Paperless ordering or Paperless invoicing yet the fundamental process flow stayed the same Even though it enabled entirely different business methods such as just in time inventory we still had not reached that next fundamental level of understanding This is now changing Eureka events have taken place The existence of the Internet has created the ability to re invent the way that we fundamentally do business to make us all more interconnected closer in time and space with less manual work our processes more timely and our operations more and more streamlined Source Business deals on the Internet can be hyperlinked speaking metaphorically like Web pages These hyperlinks are formed by the chains of transactions that animate supply chains They are traversed by business messages not people The REA business model contains an object called a Stock Flow that is the equivalent of a hyperchannel for business messages REA Stock Flows can connect all of the activities in a multi company supply chain in one simple and uniform way one end of a Stock Flow hyperlinks to the previous activity the other end hyperlinks to the next activity If the metaphorical use of hyperlink seems too strained for you think link for business messages instead See How does REA work below for more details Alternative models for supply chains There are several existing software models that have been proposed for supply chain management ERP or Enterprise Resource Planning as exemplified by SAP BAAN PeopleSoft etc EDI or Electronic Data Interchange a set of standards for passing electronic versions of paper documents between companies XML EDI or using the eXtensible Markup Language for to represent EDI transactions as exemplified by XML EDI XML for B2B ecommerce or various initiatives to develop XML standards for ecommerce that are not explicitly based on EDI standards including eCo RosettaNet and BizTalk APS or Advanced Planning and Scheduling systems as exemplified by i2 Trading Hubs as exemplified by Ariba and Commerce One s Market Site EAI or Enterprise Application Integration software as exemplified by CrossWorlds Extricity and Vitria REA is not exactly in competition with any of the above An REA semantic model could be implemented using XML or an EAI scripting language REA could use XML EDI for transactions An REA semantic Web could be used to interconnect ERP systems But the REA supply chain model lives at a higher semantic level that of the whole supply chain across enterprises including all resources events and agents and the relationships between them That is the level required for a semantic Web for supply chain collaboration How is a supply chain different from an enterprise system An enterprise system such as ERP is a system for a single company attempting to integrate most of the business activities within that company A supply chain almost always spans across multiple companies but involves only a relatively few people and resources within each company One enterprise may be involved in many supply chains for different product lines or different markets for the same product line A supply chain is much like a river system with raw materials at the headwaters and customers at the delta with products floating down the river toward the customers A supply chain system is a computer network connecting all of the people along the river A supply chain semantic model is a model of the information flows that accompany the real world supply chain material flows the demand flows the material movements the process activities and the cash flows What s wrong with ERP EDI as a supply chain model A supply chain semantic model should look like a supply chain not a single company ERP systems do not actually have any model of a supply chain nor does EDI nor do the two of them together To use ERP as a semantic model is to break up the supply chain into a network of individual companies whereas the real supply chain is a network of individual people within the companies This is a big difference it can take many complex steps for information to get from the gateway of a company to an individual within the company If the individual is in customer service and EDI is a daily batch job it may take only one day If the individual is in manufacturing it can take several days If the individual is in a different company for example a component supplier the time multiplies Each company boundary is a hindrance to the supply chain information flow To use ERP EDI as a semantic model for a supply chain involving manufacturing the demand flow would go like this Purchase Order EDI Customer Order Master Production Scheduling MPS Material Requirements Planning MRP Capacity Requirements Planning CRP Work Order Purchase Order EDI Customer Order etc Or in acronym form PO EDI CO MPS MRP CRP WO PO EDI CO etc This is not a simple linear flow MPS MRP and CRP are usually batch computer jobs that run at night Often they must be reiterated several times before a stable production schedule is achieved Likewise EDI is often run as a daily batch process That means a single demand signal can take days to go from EDI input to production in a single manufacturing plant It means a single demand signal can take weeks to travel across a multi plant supply chain even if the multiple plants belong to the same company Moreover order changes go through the same tedious process And there is no way in the ERP EDI information flow for upstream schedule problems to travel downstream For example a raw material supplier s inability to meet a delivery schedule could have severe ripple effects on order fulfillment to the end customer Those ripple effects cannot be transmitted through the ERP EDI information flow The ERP EDI information flow cannot possibly keep up with the actual events in the real world supply chain The information lag can be days or even weeks not just minutes or hours Jac Nasser Ford s CEO reports in ComputerWorld that to process orders through the network of suppliers can take a month or more in some cases now Besides slowness ERP systems are proprietary Whereas their internal semantic models are similar especially if they come from an MRP background they are certainly not identical or easily inter operable Where is ERP going To be fair there are several indications that ERP systems are evolving past their current model Each of the leading ERP vendors has either purchased or partnered with an APS vendor and is swiftly developing Internet versions of their supply chain offerings PeopleSoft bought Red Pepper and indicated at one time that they would build their supply chain software on top of Red Pepper s APS system However thereafter the president of Red Pepper Monte Zweben left PeopleSoft PeopleSoft has purchased other APS vendors and the rest of their system appears to be order based Oracle announced support for a Demand Flow model which is compatible with REA and much better suited to Internet collaboration than the MRPII model http www oracle com applications manufacturing SAP broke off a relationship with i2 and then announced that they would build their own supply chain software based on components from ILOG that are compatible with REA BAAN bought Berclain an APS vendor whose internal model is compatible with REA and may be using the Berclain model as the basis for their Internet supply chain offerings Incidentally BAAN has always been a little different internally from the other leading ERP systems while the others were built on top of an MRPII core BAAN was developed from a project management system The APS and Demand Flow models are a lot like REA without the cash flow side See Eli Goldratt s Haystack Syndrome for published details of one very REA like APS model that was a precursor to i2 To the extent that the ERP vendors evolve in this direction their systems will become more like REA or at least they will become more capable of Internet supply chain collaboration However unless they adopt a non proprietary Internet standard semantic model they will still not achieve Tim Berners Lee s vision of revolutionized ecommerce The Open Application Group is an attempt of the various ERP companies to move toward a non proprietary standard for application integration somewhat like a standard set of EAI interfaces However the OAG standards assume a generic ERP model not a multi company supply chain model They may be useful to connect existing ERP systems to a cross company semantic Web but they are not capable of being the semantic Web themselves This is not to denigrate OAG they did what they set out to do develop open interfaces and an REA semantic Web will certainly want to use them APS is better but not good enough Advanced Planning and Scheduling systems were designed to compensate for the weakness in schedule speed and precision of ERP systems They are usually add ons to ERP systems Although most ERP companies have now purchased APS systems they are still add ons Lately APS systems such as i2 have graduated to the supply chain management arena attempting to use their considerable scheduling skills across the whole supply network APS systems can keep up with the flow of events inside a single company But like ERP systems they too are essentially single company systems Even if all supply chain partners adopted the same APS software they would still be running separate systems with some kind of EDI like gateway between them Moreover APS systems are proprietary Their vendors usually provide interfaces to selected ERP systems but seldom to another APS system Also APS systems coming from a focus on capacity scheduling tend to be weaker on material planning than the MRP module of an ERP system And they usually have no process execution or cash flow management capabilities So they are usually still dependent on a legacy ERP system for critical supply chain functions EAI is better yet but Enterprise Application Integration systems like Vitria have a cross company messaging component that can keep up with the actual events of the real world supply chain But EAI systems are still usually lacking some of the key features of an REA model Because their focus is to integrate other applications they do not do very much themselves delegating actions to the separate sub applications that they connect The level of integration may be little more than passing information from one sub application to another They may not understand the relationships between supply chain objects like material flows and cash flows Their idea of a supply chain model may still be designed for a single company with messages going from one company gateway to another Thus they are still subject to getting bogged down in the ERP system One exception to this problem is Extricity which has an explicit multi company software model Most EAI systems provide a scripting language and a scriptable object model so it would be possible to create an REA supply chain model using the EAI system However once again the EAI scriptable object models are proprietary Trading Hubs The problem with trading hubs was described by Walid Mougayar in a recent Business 2 0 article entitled Open Market Misnomer Internet pundits long have preached a vision in which all online businesses and marketplaces enjoy interoperable connectivity and spontaneous brokering of electronic services among dozens of far flung companies But this dream may remain only a dream because the top two forms of business to business commerce models both exhibit classic private club characteristics By invitation only Assume you are a production goods supplier to one of the top B to B companies Dell Computer Cisco Systems or Intel The way you electronically connect to each company is radically different From product catalog searching to inventory status inquiries or order management each company demands adherence to its own set of ebusiness methods and technologies It is agony for the supplier that has to deal with three different integration processes some requiring changes in internal practices or costly human intervention Trading hubs such as Ariba s Ariba Network and Commerce One s MarketSite net are emerging as another popular B to B model They have the potential to be the cutting edge of ecommerce but they currently are costly and require proprietary linkages practices similar to restricted clubs with private access and participation The fast growing electronic trading marketplaces are also riddled with rigid rules of participation and operation That s what makes them efficient On the other hand they seem to have attracted only the elite of ecommerce participants and that s detrimental to the evolution of healthy marketplaces The result is a private network of companies which sounds like old style electronic data interchange networks Most walk ins would probably fail the entrance exam Walid Mougayar Source Walid Mougayar s perceptive analysis contrasts with the cheerleading going on in most other current B2B writings for example BusinessWeek If Ford and GM use two different B2B systems as BusinessWeek uncritically exclaims what does Bosch do who supplies both of them and Toyota Nissan and Daimler Chrysler as well How about XML EDI eCO RosettaNet etc Each of these groups represents an attempt to develop a non proprietary Internet standard for business to business ecommerce To that extent they are moving in the right direction However none of these initiatives has a semantic supply chain model with anywhere near the breadth and depth of REA All of these Internet B2B e commerce standards have focused on purchasing in other words Exchanges in the REA model see below But there is a lot more to the world than purchasing there is also manufacturing and transportation and all of the links between all of the processes in the supply chain Purchasing is a point to point relationship between two companies and it cannot give an overview of a supply chain The action is in the whole supply chain not just two isolated points Some of these initiatives for instance eCo have richer models that could easily accommodate an REA supply chain model The proposal for REA standardization below recommends building an REA XML model on top of one or more of these initiatives Of course it would be easier if there weren t so many of these standards REA is the best REA is the best model for Internet supply chain collaboration because REA is a public domain non proprietary model anyone may use it without restriction REA models can cover whole supply chains across multiple companies the REA model handles all kinds of activities manufacturing transportation purchasing etc and all of the links between activities in a uniform way an REA semantic Web can maintain persistent links across all activities in a multi company supply chain until the chain s work is done the REA model handles all resources products cash labor machines in a consistent way an Internet hosted REA supply chain model can communicate information across multiple companies in any direction in seconds not days or weeks because events are REA s middle name an REA supply chain model readily accomodates an event driven business system see REA supply chain in action below the REA model has been validated for correctness by peer review in the leading accounting journals and accounting is among the most meticulous of business professions the REA model accommodates continuous updates of accounting and performance reports of any kind as in Cisco Corporation s virtual closing where business managers can get instant business overviews that drill down to details an REA model can encapsulate other business models and use them as subsidiary components an REA semantic Web would not need to be developed all at once in an impossible engineering feat it can be developed by piecemeal growth as long as a core standard is preserved an REA supply chain model can either work well with other systems like EAI or it can grow into the whole business system on its own for a seamless combination of supply chain and enterprise systems an REA model can perform planning functions like MRP and APS itself or it can delegate these functions to other systems How does REA work REA works by give and take Remember the acronym Resources Events and Agents In an economic Event an economic Agent gives one economic Resource for example a product and takes in return a different economic Resource for example cash In an REA economic exchange between two companies the Supplier agent gives a product which is taken by the Customer agent In return the Customer agent gives cash which is taken by the Supplier agent In an REA production process components labor and machine time energy etc are given consumed input and completed products are taken produced output in return REA activities are either Exchanges which trade Resources between Agents or Processes which consume input Resources and produce output Resources REA activities are connected by Stock Flows which represent one Resource moving from one activity to the next In planning one Stock Flow represents one dependent demand or one line

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

  • Transactional Business Process Servers:
    principles of modern n tier component architectures We see the need for transactional business process servers TBPS that implement a superset of a subset of the functions of current workflow servers to primarily address automated process definition and management on the application server side 3 Definition A Transactional Business Process Server TBPS is an application server of one or more business process components supporting transactional business processes business transactions Similarly to a workflow server a TBPS manages the automated aspects of a business process that is described in a process definition Differently from a workflow server a TBPS excludes the workflow automated aspects such as worklist management for workflow participants assignment and distribution of work items or invocations of user tools and applications that are in support of manual activities A TBPS is leaner in that it is only concerned with activities that are carried out within the server The activities may still involve external interaction with users and a TBPS provides an interface and event based mechanism for this purpose A TBPS process may also invoke applications incidentally but important computations are carried out within the TBPS Very importantly a TBPS supports business transactions The process activities are given a transactional semantics through an infrastructure service that supports long running business processes and through a mechanism for process and activity compensation The business process that a TBPS supports thus is a transactional unit of work This unit of work may be part of a larger workflow process A TBPS includes a process definition tool and an administration tool that are in accordance with the above functions 4 Requirements Based on the problem we address our general approach and our particular motivations we can elaborate a number of requirements for a transactional business process server and the components that represent transactional business processes These requirements are described in the following subsections 4 1 Transactional data use Since a defining characteristic of TBPS is to support business processes in transactional use of business objects and data the ability to process transactions across various data stores and other transactional resources in distributed environments is essential to a TBPS A TBPS provides the runtime support for business objects representing resources which are to participate in diverse transaction protocols such as the CORBA OTS OMG 1998b and its Java binding JTS for example the X Open DTP standard for distributed transaction processing The Open Group 1996 as well as advanced transaction protocols Ideally TBPS should also allow component managed access to data sources and resources as special cases Some component data models such as EJB attempt to simplify this task by using declarative transactions Monson Haefel 1999 however such facilities are not part of the programming or process modeling language and they are thus unnatural and potentially problematic to use 4 2 Systems compatibility and interoperability Since another defining characteristic of TBPS is to support the representation of transactional business processes as components the processes should be representable as a component of some standard middleware technology such as CORBA OMG 1998a or Enterprise Java Beans EJBs SUN 1998 Depending on the particular form of transactional business process components support must also be provided for component life cycle and runtime management In other words the components must be operable within a standard component service environment and accessible via standard protocols for that environment WebSphere IBM 2000b is an example of such an environment for EJBs Regardless of how the transactional business process components are represented they must be accessible by and also able to access typical enterprise applications and services These include distributed objects such as CORBA objects and object request brokers ORBs EJBs applications integrated through messaging middleware such as MQSeries IBM 2000a workflow servers web servers and other business process components The transactional business process components should offer and be able to execute both synchronous and asynchronous access 4 3 Business process modeling and execution A language for modeling transactional business processes must provide basic constructs for the representation for various kinds of activities data and resources To adequately represent the variety and dynamism of business processes a flexible control model is required The control model should allow activities to be executed concurrently and sequentially conditionally and iteratively It should allow activity instances to execute with or without synchronization and it should allow activity instances to be created and destroyed dynamically It should also support activity composition and decomposition With respect to data representation and flow a transactional business process modeling language should provide for the representation of business objects and for values of appropriate base types These must be adequate to capture references to external data objects or sources Activities should be allowed data parameters and local data variables The flows of data between activities must be represented including normal and exceptional data flows Issues related to the scoping and visibility of data in a business process should be addressed in a way that is consistent with the activity and control models of the language and other language features as appropriate Business processes do not operate entirely according to an imperative plan They are subject to events both good and bad For the good events or at least the events that are not definitely bad some form of event handling is recommended For the bad events some exception handling mechanism is required Ideally both event mechanisms should be flexibly integrated with the process control model Events can constitute one form of communication both within and between processes Support for messaging can be provided as an alternative communication mechanism that may represent some forms of communication more explicitly Access to an external messaging service is important for communicating business process messages to external processes and agencies For transactional business processes naturally transactions should be an integral part of the process modeling language Transactions in the process language should include at least flat ACID transactions both local and distributed Support for advanced transaction models including various kinds of nested transactions and long transactions including

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

  • Which Business Objects
    a copyright release fax signed hard copy is due to Dilip Patel at address in instructions below on the due date Please follow instructions below carefully We are negotiating with Springer to publish PRIOR to the workshop Proceedure for getting your paper into publication of Business Object Workshop Proceedings by Springer Send a note to jeff sutherland computer org confirming that you intend to submit your paper for review and comment Deadline is the due date above for submission of camera ready copy and publishing agreement Follow camera ready copy instructions carefully Addresses and procedures for submission and the schedule for what happens after initial submissions is described in detail The publishing agreement must be signed and submitted in hard copy You will retain copyright The agreement is simply permission to publish in the proceedings Send floppy disk and publishing agreement by Federal Express to Dilip Patel Send email copy to mailto jeff sutherland computer org See the book below for examples of the finished product For half price copy of book contact jeff sutherland computer org Patel D Sutherland J Miller J Eds Business Object Design and Implementation III OOPSLA 99 Workshop Proceedings Springer 1999 I have a few

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

  • OOPSLA'98 Business Object Component Workshop IV
    validation the interaction between enterprise components and manages the business and several aspects of the data integrity of the system This is the most critical layer from the point of view of large scale mission critical systems is the least addressed by publicly available component technologies and is very often confused with the business component itself The resource layer is responsible for physical access to shared resources Data in shared databases is the most common form of resource and this layer is responsible for the persistence aspects of a business component For example SQL would be issued against relational data by code in the resource layer Note that this layer does not make much sense without the Enterprise Layer The Enterprise and Resource layers together form the Shared Resource Domain This is responsible for the integrity of shared resources and for providing services based on those resources to multiple concurrent authorized requesters The boundaries of the shared resource domain are defined by the boundaries of the underlying transaction management infrastructure software in its ability to manage ACID transactions The business component architecture solves some of the more pressing problems of distributed business systems and provides a number of design guidelines Two examples are It separates database resource layer from business logic enterprise layer This enables database schemas and technologies to change without necessarily affecting business logic in the enterprise layer It addresses the object location problem which is often expressed as follows In a client server system where for example does the Customer object live On the server or on the client The business component structure says there will be two Customer objects one in the Shared Resource Domain and one in the Presentation Logic Domain These two may or may not use the same code in their implementations Clearly real systems are more complex than the scope of the structure described above For example where is workflow where are virtual enterprise aspects where are business specific views of the enterprise layer These aspects and others are also addressed by the business component structure but are beyond the scope of this paper The distributed component technology Business component layers are implemented by distributed components A distributed in the sense that it can be re located component is an independently developed executable module see OMG2 It directly supports and enables autonomous development of the business component layer and hence of the business component itself at build and deployment time For the application developer the distributed component technology hides several computational complexities such as thread management communications programming concurrency management These are handled by a run time infrastructure which forms a separation layer and which also makes the distributed component technically independent of underlying software such as ORBs MOMs operating systems etc Thus the underlying technology can be changed without necessarily affecting deployed application code At run time and based on directives defined at design time the infrastructure composes one or more a distributed components into instances of network visible distributed objects Each object type has an interface that is defined at design time Hence the set of composed distributed components comprises the implementation of the distributed object This composition is illustrated in Figure 5 where we also see how a Distributed Component is normally but not necessarily constructed using an OOPL OO Programming Language so that language objects are visible only within the confines of the distributed component Composition of more than one Optionally the infrastructure can compose several distributed components into a single distributed object This is generally appropriate where common application neutral code such as a model view framework persistence management or technical event handling can be separated from business logic It can also be used as a way of customizing a distributed component through specialization Figure 5 Messages sent from other distributed objects are routed by the infrastructure plus underlying system software to the distributed component code If more than one business component then the message is routed to the bottom most which may then pass the message to the next higher one This provides a useful inheritance mechanism Discussion at greater depth is beyond the scope of this paper However one final point should be mentioned messages between distributed objects carry metadata about message parameters The receiving distributed object is responsible for message interpretation This enables interfaces to be evolved without necessarily requiring client distributed objects to be re built and re deployed The Distributed Component approach provides significant advantages including Third parties can specialize distributed components by subclassing one distributed component with another possibly in a different language without re building or touching in any way the original distributed component In addition the ability to place common functionality in a superclass or upper level distributed component means that when the common functionality changes only that distributed component need be re built and re deployed This capability can greatly limit the scope of change Language neutrality a distributed component can be implemented in one of a number of programming languages This means in turn that a single Distributed Object can be composed from distributed components built with different programming languages Source portability across different platforms through technical binding being to the infrastructure rather than to underlying platform specific software Through use of metadata in messages interfaces can evolve without necessarily requiring client to change thus further minimizing dependencies between distributed objects In summary the distributed component approach provides for each layer of the business component both physical plug play software components separation from underlying computational complexities and a distributed object capability that greatly reduces inter object dependencies It does this by providing a clear differentiation between distributed objects and other OOPL objects that are not distributed Business component centered development process This section expands on some important aspects of the business component as a unifying concept throughout the whole software product life cycle taking a 20 000 foot overhigh level view of the development process In a business component approach the development process is centered on autonomy

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



  •