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".

  • If it is appropriate the author s employer may sign this agreement If the author is a US government employee and this work was written in that capacity this agreement applies only to the extent allowable by US law If the work was prepared jointly the author who signs this agreement confirms that all co authors agree to the terms stated here and have given authority for this agreement to

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


  • Developing an Ontology Service for Business Object Frameworks
    a chocolate is the sum of the labor cost and the cost of the ingredients needed to produce the chocolate Next we extend the model in part I with the model in part II The chocolate manufacturer decides to use machines for the production of chocolate Changes in the company s economic activities require structural redesign as well as redesign of procedures For example the existing cost calculation can t be reused and need to be redesigned We assume that the product cost includes the cost of using the machines Figure 2 REA model II The Activity Pattern The activity pattern figure 3 redesigns REA s economic event using modeling techniques described in Hay 1996 and Fowler 1997 The economic events in the figures 1 and 2 sale cash receipts production order etc are subtypes of activity not shown in figure 3 The activity relationships such as the dual relationship between sale and cash receipt are no longer hardwired in the conceptual structure If the chocolate company decides to use machines for production it suffices to define equipment consumption as a subtype of activity The cost calculation procedure is now defined as the sum of the cost of the outflow events resource consumption events linked to the inflow event production order Changes in the economic activities have no effect on this procedure Figure 3 the Activity pattern The colored part of the model Figure 3 represents the knowledge level specifications Fowler 1997 An example of an activity relationship type is an exchange relationship between sale and cash receipt Activity relationship instances are constrained by activity relationship type instances Examples of relationship types are exchange sell chocolates for cash transformation make chocolates and commitment sales order Exchanges and transformations are refinements of the duality relationship Transformation and exchange are terms taken from Fisher 1906 Transformations represent activity relationships where resources are converted into other resources A manufacturing process such as the making of chocolate is a good example of a transformation labor raw material and equipment are transformed into chocolate Exchanges represent activity relationships where resources are traded with an outside party Selling chocolates to a customer for cash is a good example of an exchange Different rules apply for transformations and exchanges For transformations the cost of the inflow economic activity is the sum of the costs of the outflow economic activities The cost of a chocolate is the sum of all the resources needed to manufacture the chocolate This is not true for an exchange The cost of a cash receipt is not the sale amount The monitoring of imbalances of an exchange relationship is very important How much does a customer owe us How much do we owe a vendor an employee etc This is not true for a transformation Commitment is a term taken from Ijiri 1975 Ijiri 1975 p 130 describes commitment accounting as recognizing changes in resources when parties in the exchange commit themselves to the delivery of resources even if no such commitments have

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

  • An Object implementation of Network Centric Business Service Applications (NCBSAs)
    services expected of a transaction monitor The basic functions of a standard transaction monitor are well known e g CICS Encina Tuxedo 3 15 9 We summarize them briefly here in order to highlight the additional properties of a Coyote monitor Transaction monitors are responsible for scheduling transaction invocations Transaction programs or applications are registered to the transaction monitor in an administrative operation Each registered application has a function name known to clients so that they can request it associated with this function name is a registered entry point or program which is scheduled when a request for that function is received Incoming requests to the transaction monitor appear as messages typically from remote clients An incoming request is logically queued by the transaction monitor until computing resource is available to execute it This occurs when some other transaction completes and frees up a process or thread in a pool managed by the monitor When a thread becomes available the transaction monitor allocates it to the first queued incoming request starts on the allocated thread the application program registered to the requested function passing it any additional parameter data also in the request Having started the transactional application in response to an incoming message the transaction monitor is responsible for supervising the execution of the transactional application In particular it will intercept all outbound requests to recoverable resource managers such as databases that may be local or remote and to other remote transaction monitors if this transaction monitor can participate in managing a distributed transactional protocol Finally the transaction monitor is also responsible for the transactional behaviour of the applications which it monitors Definition of standard ACID transactional properties i e atomicity consistency isolation and durability can be found in 16 15 A primary function of standard transaction monitors is to provide a commit abort protocol This allows a transactional application to be ABORTED if either a serious error is detected by the monitor during processing of the transactional application or if the application explicitly requests it The transaction monitor will then ensure that all effects of processing on behalf of this transaction instance are undone in the persistent resources of the participating resource managers e g databases A schematic view of a Coyote monitor is shown in Figure 1 At this level the architectures of a classical ACID transaction monitor and a Coyote monitor are essentially the same However a Coyote monitor differs from above summary description of standard transaction monitor functions in several respects A server application started by a Coyote monitor is not by default an ACID transaction rather it is a durable conversation for which there is no system guaranteed abort operation to undo all its effects An application level log of all interactions with the client and other remote resources and transaction managers is maintained by the Coyote monitor A service application registered with the Coyote monitor can have a group of programs or interfaces associated with it The interfaces define the primary action and its associated application defined compensation and modify actions Multiple related interactions that follow a logical conversation thread may be dispersed in time and hence the monitor maintains persistent conversation states and an interaction history The Coyote monitor has special support for enabling reliable execution of a service request on behalf of a particular conversation with a particular user even if action requests are reissued and is reliably compensated by the application defined compensation action if the user so requests The Coyote monitor checks validity of invocation sequence as defined by the application during its registration The monitor also enforces service contract i e checks to see if the user is allowed to invoke this method Ÿ The Coyote monitor provides additional features to compensate an entire conversation or a defined group of service requests within the conversation should compensation of the group be explicitly requested or automatically if some essential request within the group fails to execute successfully In short the novel features of a Coyote monitor is that it shifts the definition of a transactional application away from the concept of a system guarantee that all persistent effects are removed on failure towards supporting the concept of persistent conversations in which it is easy to provide and manage application defined compensation of actions and provide the end user with a reliable view of cancelling reissuing and modifying particular service requests Coyote application Development model A network centric service application has to guide a client which may be an end user or possibly another unknown program through a unit of business This is typically a long running interaction in which there are short bursts of automated activity at the Coyote server interspersed with periods of waiting for subcontracted servers in the network to respond the user to decide what to do next or activities to happen in the real world as part of the service fulfilment goods to be moved money to transfer or time between a reservation and use to elapse Thus a Coyote application consists of Interfaces its service interfaces specifically service contract presented to clients the application will also depend on the service interface definitions for any services which it uses from other applications in the network in a subcontracting mode Action methods the implementations of each short running action which can occur in providing the service each action involves responding to a specific event processing based on this event and the state of the service conversation and sending out messages and action requests to the client and other servers Scheduling rules the definition of the application s trigger events i e combinations of response messages time outs and user requests which will trigger execution of an action by the application and the rules to determine which action is to be scheduled when events occur The developer of a network centric service application is required to provide all of the above information The Coyote monitor plays the role of enforcing constraints defined in the service interface gathering and saving the event data interpreting the scheduling rules of the application and then triggering the execution of action methods for the application following those rules We claim that the Coyote approach provides both a convenient and powerful structure for developing network centric service applications and a coherent model for characterizing their behaviour An example conference trip reservation Consider a typical multi organization long running business application Travel planning including conference registration Figure 2 shows the participating organizations and their interactions The end users need to make complete travel plans associated with attending this conference Each may run a local travel arrangement application on his her desktop laptop but is more likely to contact an intermediary Travel Service provider that co ordinates various end user service requests and maintains special business relationships with various business service providers e g airlines hotels As part of the conference registration the conference organizers provide via the Conference service application not only a seat at the conference and conference proceedings but also arranges hotel accommodations for the entire duration of the conference The conference organizers make special arrangements with the hotel via the Hotel Service application to provide this accommodation They also collect appropriate fee via the Acquirer gateways through the credit service providers e g Amex Visa MC The end user provides all the necessary information by processing an HTML form and is typically unaware of all the business activities behind the scene An end user may also require a separate arrangement with the same or another hotel for an extended stay unrelated to the conference For example the end user may decide to arrive early for some unrelated business activity e g giving a talk at the local University and stay a day longer beyond the conference for some sight seeing Additional activities may depend on various factors availability of suitable flights availability of hotel accommodation and of course no conflict in schedule The conference provider is clearly not interested in providing services beyond what is absolutely required for conference attendance The unpredictable schedule of a busy client may also require partial attendance or modification of the schedule on the fly The key requirements imposed by this overall application on the participating organizations and their underlying systems are as follows Multiple organizations e g Service providers for Travel Conference Hotel Airline etc need to interact to provide all the required services to the end user All the services demanded by an end user may not be known in advance and may change during the course of the conference For example the requested and granted services may be cancelled by or on behalf of the end user at a later time However each organization is responsible for delivering its services Each service provider develops its own application without the a priori global knowledge of interactions across all organizations Finally the organizations do not need to be in constant communication during the course of this long running overall application Multiple interactions between server parties e g Registration and Cancellation may be related Note that implementation of the registration at the conference site service results in invocation of services that atomically perform reservation of a hotel bed and conference registration fee payment as well as local book keeping such as updating the number of proceedings to be printed etc Here each transaction accesses modifies its local database s in an atomic fashion and hence preserves desired integrity relationships within a site Each organization is also responsible for managing its own interactions with other organizations and hence needs its own persistent application log of the interactions between them In the above example the travel server co ordinates its interactions with conference hotel and airline sites The conference program server is responsible for ensuring all services that come with a conference registration and co ordinates its interactions with the hotel and the acquirer gateway servers The end user or the travel server never gets involved in the conference program server backed activities Each site also passes minimal essential information about its clients to other servers as well as hides its implementation of the ways it provides the services particularly if it is dependent on the services of other sites Without such information barriers all participating sites may be aware of the relationship across all other potentially hostile sites It may also jeopardize the businesses of intermediate sites since the end client may directly contact final service providers Additionally the global state maintenance may impose unduly burden on each service provider The proposed Conversational Service Transaction model and runtime services provided by a Coyote monitor aids in the development of NCBSA In the next Section we will explore how these services can be provided to an oo implemented NCBSA 3 An Object implementation of Network Centric Business Service Applications NCBSAs The preceding sections defined the need for NCBSAs and the requirements which must be met by an infrastructure for them However this was done with no reference to objects In this section we take up the question of how one would implement both the NCBSAs and their infrastructure using Object technology and concepts This adds a level of detail both to the description of NCBSAs and their required infrastructure it also raises some interesting questions about ways in which Object standards could be extended to assist in the evolution of cross enterprise electronic services 3 1 Service Invocations and Service Contracts Being able to contact uniquely identify and interact with service invocations is a key part of the NCBSA economy Hence we will need a ServiceInvocation class Particular services such as combined conference trip booking service airline reservation service hotel booking service would be subclassed from this ServiceInvocation class It is usually the case that ServiceInvocation objects have to be persistent e g a travel booking has to survive from the time that the booking is made to the time when it is used possibly months later During this lifetime there will be a number of specific interactions with the client of the service defined as actions in the preceding section These actions are an important part of the interface of the service invocation but are associated with the implementation of the service invocation only via a level of indirection Hence rather than treat these actions as methods of the ServiceInvocation object directly we introduce a ServiceContract object associated with each ServiceInvocation object defining its interface see Figure 3 The methods of the ServiceContract object will be the actions of the service invocation To illustrate in the hotel booking example creation of booking upgrade or date change of a booking and cancellation are independent actions on the hotel service invocation These functions are then the defined methods on the service contract 3 1 1 Properties of ServiceContracts sequence checking for reliable execution Besides defining the set of action interfaces of a service invocation a ServiceContract contains all information which defines the responsibilities undertaken by the provider of the service The ServiceContract object SCO provides information on the responsiveness committed to by the server This may be provided in the form of the mean and some high percentile response times for responses to action requests which could be used by clients to set reasonable time outs There could also be a more general indication of whether processing was interactive or batch oriented Another function of the SCO is that it defines sequencing rules for valid sequences of actions within a service invocation This is particularly valuable in a network centric environments where there is great variation both in message delivery time and in processing response time Service requests and their actions are uniquely numbered The ServiceContrac t object implementation enforces these sequencing rules thus eliminating invalid or duplicated requests Thus a series of calls to a ServiceContract object newBooking newBooking upgrade cancel upgrade cancel will actually be received at the ServiceInvocation object as the filtered sequence newBooking upgrade cancel The sequencing rules cause two newBooking actions to a single service invocation to be treated as duplicates and cancel is supposed to be a final action which cannot be followed by other actions on the same service invocation Other invalid sequences would be reported back to the client as errors Finally ServiceContract object which is created upon invocation of a BSA by an user and based on the service contract defined a priori between the invoking user and the service provider decides which action requests are to be permitted In summary the ServiceContract interface defines properties of the service made visible to external clients usually in other organizations The ServiceInvocation offers an interface to the implementation of the service called from within the service provider s organization 3 1 2 Separating monitor checking aspects of a services from the service implementation An alternate way of looking at this separation between ServiceContract and Service Invocation is as follows In providing business services in a conventional network environment the value of transaction monitors is widely accepted Orbs as presently defined by OMG standards provide a limited set of the scheduling interface enforcement and reliability management provided in existing transaction managers In a network centric business service environment extensions to transaction manager functionality are required to handle the greater openness extended transaction models and more ad hoc cross organizational interactions of a public network environment In these terms the ServiceContract object represents processing to provide rule and interface enforcement for a BSA Users of this service see and make method calls on the ServiceContract object not the ServiceInvocation object which implements the service The ServiceInvocation object represents the actual implementation of the service and has method interfaces which would be called by the transaction monitor after it had allocated an execution thread to an incoming request 3 1 3 ServiceEventHandler and asynchronous responses to subcontracts of the service implementation A Network Centric Business Service Application NCBSA is typically incremental It provides a ServiceContract interface but its service implementation makes wide use of other services available in the network For the best response time to clients these subcontract service invocations will be made in parallel since it is assumed they are executing on independent server engines scattered across the network Hence the action requests made to subcontract services will need to be asynchronous calls Therefore in this environment service invocations last for a long time however are actively executing only in brief bursts when triggered by any request from the service invocation client or a new asynchronous reply arrives from a subcontract service It is convenient to structure the ServiceInvocation implementation as a set of internal methods and a set of event driven scheduling rules Once again we separate out the functionality which is really rules to be followed as part of the monitor scheduling into a separate object i e ServiceEventHandler There is one ServiceEventHandler for each ServiceInvocation Methods in the ServiceEventHandler correspond to different trigger events relevant to this ServiceInvocation The methods in the ServiceInvocation object are now the segments of algorithmic processing which are shceduled in response to some trigger event following the rules in the ServiceEventHandler More specifically the ServiceEventHandler is driven whenever a new reply or message arrives from a subcontract or a new request arrives from the client of this service invocation Using knowledge of which other events replies have already been received together with the rules defined in the ServiceEventHandler the appropriate method of the ServiceInvocation is allocated a thread and called This observation reinforces the need to separate out ServiceContract object from ServiceInvocation object Although the ServiceContract interface defines as its methods the set of action requests which can be made the implementation i e the set of methods on the ServiceInvocation object will not be a set of independent procedures one for each defined action In general in the presence of asynchronous responses to subcontracted requests a service invocation which allows clients to make action requests A and B and processes action A by sending out subcontract network requests AF1 AF2 would be more likely

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

  • Business Processes and Workflow Management in an Enterprise Resource Planning Context
    A customer services domain framework represents a generic solution for general problems and provides a set of classes and design patterns within the customer services domain It also contains guidelines on how to customise these in order to derive specific applications CSDF is to be used by application developers across several industries to develop specific applications within the CSD 2 An overview of the development of a CSDF 2 1 Generic Reusable Business Object Modelling This paper outlines the use of the GRBOM approach and is described in detail in a paper written by the authors Choudhury et al 1997 We have developed a customer services domain framework using the GRBOM modelling approach At the heart of the framework is a core business model CBM which is a representation of the core business processes the core businesses objects and the interactions between these The GRBOM is built within the five dimensions of this framework which are genericity reuse change patterns and business object modelling We utilise Jacobson s use case engineering Jacobson et al 1995 Rumbough s OMT Rumbaugh et al 1993 and business design patterns to build the business object model Digre 1997 explains genericity as the staged refined of entire models which uses stepwise instantiation to go from the general to the specific or from the specific to the general Genericity is a controlled process which utilises principles of specialisation inheritance relationships and contexts to leverage reusable industry models and rapidly provision tailored business solutions The GRBOM is a reference model of a particular domain within a specific industry Figure 1 shows the GRBOM genericity dimension showing how the customer services domain fits into the telecommunications industry and how the telecommunications industry fits into the world of industrial sectors as we understand it A CBM can be built for each level of the genericity diagram By reuse we mean that the CSDF can be reused in the development of multiple applications and also it can be reused by different organisations of different industrial sectors i e horizontally reused across vertical industries The CSDF must incorporate the ideas of change and must capture factors that cause change and factors with which to analyse change Change is an important factor to consider if we are going to use the model in this turbulent business environment Figure 1 Genericty Diagram for Customer Services Domain of the Telecommunications Industry 2 2 Customer Services Business Object Class Diagram Model An object oriented model of the CBM was developed Each of the business objects and business process objects and links from the CBM were mapped to class diagrams as shown in Figure 2 and the result is a complete object oriented customer services domain framework Examples of the type of generic business processes of the CSDF include Launch and Withdraw Products and Services Bill and Collect and small grain business objects such as customer product bill In the development of the core business model and the subsequent class diagrams business design patterns for the

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

  • OMG finds true love
    to a repeating pattern of economic exchanges or Give Take events Resources represent the goods and services being exchanged Events represent the exchanges and Agents represent the parties to the exchange REA patterns have been used in several real world business applications including an IBM payroll system They are one of the featured techniques in the OOPSLA 97 Business Object Workshop REA differs from traditional double entry based systems in several ways including REA processes preserve the unity of the economic events while supporting all of the views required by traditional accounting systems Double entry systems fragment the events In an REA system there is only one repeating pattern the REA template This radically simplifies the system It will especially simplify the semantics of distributed cooperative business object interactions Extending REA to manage supply chains Supply Chain Management is todays battleground for competitive advantage According to the Automotive Industry Action Group more than half of a products cost is in the supply chain And as Stalk and Hout discovered less than 5 of the time is devoted to adding value to products 9 Silo systems cannot manage supply chains adequately Nor can point to point interfaces between silos the EDI approach Distributed objects shadowing the actual flows of events are made to order for managing supply chains which are inherently distributed systems REA templates by themselves are insufficient but if extended to handle planning scheduling and operational issues they can form the links in the chains Extensions include The dependent demand pattern from MRP to balance supply and demand and generate the structure of the chains usually shaped like river networks 4 Constraint based scheduling to synchronize the events in the flows 6 Embedded work flow management to present a dynamic To Do List as the main operational user interaction pattern Graphical visualizations and spreadsheets are better analytical interfaces REA templates are composites which can be nested and aggregated fractal in David Taylors terms so they can be employed top down from the overall management level or bottom up by opportunistically linking nodes in the supply chain peer to peer Here is a simplistic example REA Links simplify distributed business object semantics Each REA Link potentially encapsulates a distributed processing link Each REA Process is a dual or two sided exchange where each agent can live on a different processor An REA Link must be able to manage either local or remote interactions One of the knotty issues of distributed business objects is the semantics of interaction especially when considering sets of arbitrary and unknown objects REA Links can simplify this issue because there are only a few repetitively used classes and their semantics of interaction can be largely predetermined Needless to say subclasses will emerge for different industries but in this case the semantics can be predetermined by industry Related work Oliver Sims Newi system of cooperative business objects was one of the inspirations for the distributed object nature of REA Links 2 David Taylor has developed a business

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

  • Business Objects and Business Rules
    workflow backends from which they receive work since this precludes thin clients from participating effectively as workflow clients Plug and play support for business objects and applications Third party providers or developers of business objects and applications should be able to workflow enable their components and plug them into the distributed workflow infrastructure cheaply They should not have to know any details about the workflow backends that are going to use these components in the course of workflow execution Disconnected operation Workflow participants may be mobile and infrequently connected to the network Location independent disconnected workflow participation must be natural to the workflow execution model Recursive Decomposition of workflows dynamically The execution model must support dynamic recursive decomposition of workflows Work items assigned to participants may be dynamically refined and implemented as nested workflows in a recursive manner In other words late binding of work items should be allowed and it should not be necessary to statically define every step and nested steps of a workflow prior to its execution To summarize a distributed workflow infrastructure must be based upon the principles of loose coupling between heterogeneous workflow backends and heterogeneous workflow participants service providers It must allow significant autonomy to workflow participants and service providers with respect to how they receive and perform work The relationship between the workflow backends and participants should be based on a peer to peer execution model as opposed to a tightly coupled client server model The Workflow Reference Model from WfMC In this section we present a quick overview of the components of the WfMC Reference Model and the interfaces between them Figure 2 Figure 2 WfMC Reference Model WfMC Reference Model Components The WfMC Reference Model shown in Figure 2 defines five components Process Definition Builder Tools Tools used to capture business process logic in a high level notation Workflow Server The nerve center of the workflow system It is responsible for process management activity distribution worklist management staffing directory services and limited application invocation Workflow Client Applications A GUI application used to view and manage the contents of a user s worklist on the server and interact with assigned work items on the server Invoked Applications Applications invoked by the workflow server to perform automated activities Administration Monitoring Tools Tools used to administer the execution and monitor the status of work flowing through the workflow system WfMC Interfaces Next the WfMC Reference Model defines interfaces between the components Interface 1 builder server interface Defines a common format for the interchange of static process specifications between a Process Definition Tool and a Workflow Server Interface 2 client server interface Provides a complete range of interactions between a Workflow Client Application and a Workflow Server These include worklist interaction query and control of workflow processes and their activities and administrative functions This allows a Workflow Client Application from one vendor to interact with a Workflow Server from another vendor Interface 3 application invocation interface This interface is not currently available but is intended to describe how applications are invoked Interface 4 server server interface Describes the interactions between two Workflow Servers Interactions include initiation query and control of workflow processes and their activities and administrative functions Interface 5 monitor server interface A set of functions for administrating and monitoring a Workflow Server Key limitations of the Workflow Reference Model While the WfMC standard represents a necessary step in the direction of workflow system interoperability the current version of the standard has significant weaknesses that limit its value in a heterogeneous distributed environment Most of the weaknesses in the standard stem from the monolithic nature of the workflow server which impedes the flexibility and scalability of workflow systems In this section we describe the shortcomings of the WfMC architecture Monolithic Workflow Server The Workflow Server in the WfMC Reference Model is responsible for all of the following functions Figure 3 Process execution Management of the Staff Directory Binding of activities to participants and distribution of work items to appropriate workflow participants performing role and group resolution as necessary Worklist management for all workflow participants who receive work items from the Server Application invocation Figure 3 Monolithic Workflow Server Centralizing all of these functions in a single logical entity results in a system architecture that is inflexible and unscalable A few examples serve to illustrate the point Worklists cannot be shared by heterogeneous workflow backends Since user worklists are hidden within the workflow server and are not externally addressable processes are only able to send work items to worklists that reside in the same workflow server Thus in order for a participant to participate in multiple workflows running on heterogeneous servers she must have an identity and a worklist maintained separately inside each workflow server she wishes to receive work from In addition the workflow client application must now manage multiple client connections to each of these workflow servers in order to receive work Figure 4 This is not a scaleable solution since it overloads the client application with unnecessary functionality whenever a participant wishes to participate in a large number of workflow applications from different servers Because of the complexity in the client this architecture is not suitable for workflow participation using thin clients and tier 0 devices personal digital assistants In effect this architecture is analogous to a hypothetical electronic mail delivery architecture where recipients must explicitly connect to sender machines to collect their e mail Figure 4 A dedicated connection to each Workflow Server Disconnected operation is difficult Even though work items are logically owned by the workflow participants the WfMC architecture assigns the task of managing work items to the workflow server Consequently the participant interacts with a remotely located work item and each interaction between the participant and an associated work item results in a remote access usually an RPC While this design has potential benefits when work items must implement some server side functionality it imposes severe constraints on disconnected workflow participation since the network must be constantly available

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

  • A "light" distributed OO Workflow Management System for the creation of Enterprise Architectures in BPR environments
    the best case scenario these applications provide the marginal means to accomplish a given task In the worst case scenario they represent a bottleneck in process efficiency often compromising the bottom line A perfect example of this situation is in trading systems where the number of transactions per unit of time is directly proportional to profits Solution Create enabling applications that follow the business processes The applications not only should display data that is important to the users but they need to walk them through the process instances Enabling applications are created through the BusinessEngineering life cycle which includes Business Requirements Business Design Business Evolution and Business Evolution It is best if these applications are created from a common base an Enterprise System Architecture That way the business logic is reused in creating multiple applications It is best to choose a technology that directly supports reuse in order to facilitate the delivery of applications such as object oriented languages and architectures In creating the enabling applications it important to identify the hot spots places where the business process may change in order to provide for appropriate hooks for later extensions This pattern naturally lead to ReifyTheProcess Example Bell Atlantic implemented enabling applications that allow them to reduce cycle time in their CAS process by several orders of magnitude Other Known Uses IBM Credit Hallmark Bank of America ReifyTheProcess Problem What is the best way to architect enabling applications in a reengineered environment Solution Create an application that contains a reified version of the process within the software That way the process can be managed from within the software offering the possibility of running multiple versions of it creating variations on the domain objects that run with it or saving it s state to be completed at a later time or by a different person or group The reification of processes means literally creating an object that represents the process that way the process steps can also be reified to offer the possibility of applying polymorphic interfaces and design patterns to them This adaptability is key in the rapid adaptation of the organization to the business environment and therefore is of critical competitive advantage to use this technique whenever possible This pattern sets up the context for the OO workflow manager Examples Hewitt Associates Action Workflow American Airlines reservation systems Shared Business Objects Problem Lack of conceptual integrity in the System Architecture across business processes For a system to work smoothly all of its parts need to be coherent Very often a process in a company claims to be reengineered because it uses traditional BPR patterns such as a Case Worker but the application that supports the Case Worker is not integrated with other applications in the organization A typical example of this situation is large insurance or credit organizations that claim that they reengineered their claims processing process but that can t give you a report across different insurance types such as property casualty and life for a single company

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

  • Fitting the Workflow Management Facility into the Object Management Architecture
    Transaction Service may provide atomic updates of sets of meta objects within workflow schemas as well as runtime support for transactional activities during workflow enactment For a comprehensive examination of the applicability of CORBAservices and CORBAfacilities see OMG97c Schu97a WorCOS A Prototypical Implementation Two years before the OMG started thinking about concrete requirements for workflow management within the OMA the WorCOS project Wor kflow Management based on C omponents and O bject S ervices has been established Right from the start our goal was to design and implement an OMA compliant workflow management service which complies with the design goals given by the OMG see OMG95b Many things that we have learned through this experience have been carried into the final RFP document Related work There are a number of projects that make use of CORBA technology for the implementation of workflow management systems in one way or another In most cases the ORB is just the means to an end It is employed in its role as a generic middleware see e g Bern96a to overcome heterogeneity of hardware and operating systems and to provide an easy way to interconnect components on different nodes using RPC style communication Very few researchers have realized the potential of CORBAservices and there is only a small number of projects actually implementing workflow management functionality with them VORTEL see Böhm95a Bapa96a is a typical example of the first category where DEC s ObjectBroker was used to create interoperability between the following workflow management products each running on a different platform FlowMark IBM Linkworks DEC and CORMAN FhG DOPAS a CORBA wrapped ObjectStore Database was used to create a centralized registry for workflow schemas and workflow instances MENTOR Wodt95a uses an ORB to wrapper existing applications in order to execute them as workflow applications during workflow enactment However the main focus is on partitioning workflow schemas and supporting workflow enactment with the well known functionality of a TP Monitor Tuxedo Both the METEOR Krish94a and the METEOR 2 project Shet96a Mill97a focus on supporting wide area workflows having transactional behavior Their prototypes OrbWork and NeoWork see Das97a work out different styles of workflow runtime architectures But again CORBA is only treated as just one implementation alternative No special attention is given to the potential use of CORBAservices BPAFrame see Schi96a Mitt96a is a multi use agent based framework which has been applied to build a workflow management system Notably it makes use of an OMG compliant EventService OrbixTalk in order to synchronize worklists of different workflow participants and it exploits the CORBA Dynamic Invocation Interface DII to invoke operations on business objects during workflow enactment WorCOS architecture layer overview The architecture of our WorCOS prototype conforms to the layered approach introduced in the previous chapter all four layers are covered The following paragraph describes all layers beginning from the top level When we started out with the design there was no perspective for a specification of the Meta Object Facility so we decided to build our own lightweight Meta Object Facilty that fulfills some of our needs WorCOS Meta Object Facility MOF Compared to a full fledged MOF as provisionally proposed in OMG97b the services and the meta metamodel of the WorCOS MOF are both very limited The WorCOS MOF provides interfaces to create and manage meta metaobjects where each one describes one modeling construct of the WorCOS workflow metamodel The WorCOS MOF does not support management of multiple workflow metamodels This approach is justified since our aim was to provide only an explicit representation of the WorCOS workflow metamodel that supports long term evolution of the Workflow Metamodel The capabilities of the meta metaobjects are very ascetic they only provide a name and a brief description for their corresponding modelling construct with a set of descriptive terms In addition to that it is possible to define basic relationships between them Each meta metaobject retains a queryable list of all meta objects that use it For example a meta metaobject for the concept of an activity could be asked about all activities that are defined on the model layer workflow schema level WorCOS Workflow Type Repository WFTR The WorCOS WFTR provides interfaces for the creation and management of workflow schemas that comply with the WorCOS workflow metamodel Each workflow meta object must have a corresponding meta metaobject By default the WFTR supports a set of predefined concepts of the WorCOS workflow metamodel for example WorkflowMetaObjects Those WorkflowMetaObjects can be used to register WorkflowFactories that may be located anywhere in the network An implementation of the WorCOS WFTR see Weis96a has been realized successfully with SunSoft s CORBA implementation NEO and actually makes extensive use of NEO s rich set of implemented CORBAservices like Naming Relationship LifeCycle and Events In addition an OMG compliant implementation of the Collection Service OMG96a is used WorCOS Workflow Schema Implementation At the moment our prototype does not support to automatically generate implementations for workflow schemas as they are specified within the WorCOS WFTR Hence object servers that implement the WorkflowFactory interface for workflow objects of a given type have to be implemented manually Once deployed on an arbitrary network node they can be registered at the WFTR for future workflow enactment Each workflow schema may have an arbitrary number of factories that support the creation of workflow objects complying to the schema WorCOS Workflow Objects In WorCOS workflow instances are realized as workflow objects which are true distributed objects created and executed on different computer nodes within a network In contrast to other approaches there is no generic workflow engine that processes and enacts the workflow schema To a certain extent the workflow functionality is hardcoded into the workflow objects The predominant part of this functionality can be inherited from library functions while specialized functionality has to be implemented for every new workflow type The library part of the WorCOS workflow objects supports the basic interfaces that are described in Schu96a like Retrieval of schema related information type version

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



  •