Object Management Group
First Needham Place 250 First Avenue, Suite 201
Needham, MA 02494 Telephone: +1-781-444-0404
Facsimile: +1-781-444-0320
in cooperation with
Business Process Management Initative
1155 S. Havana Street, #11-311 Aurora, CO 80012
Telephone: +1-303-364-8595
and
Workflow Management Coalition
2436 N. Federal Highway #374 Lighthouse Point FL 33064
Tel: +1-954-782-3376 Fax: +1-954-782-6365
UML
TMExtensions for Business Process Definition Request For Proposal
under the OMG process
OMG Document: bei/2002-03-01
Submissions due:
Objective of this RFP
This Request For Proposal solicits submissions that specify extensions to UML™ for expressing Business Process Definitions that may be enacted by execution environments that implements the existing OMG Workflow Management Facility specification.
This RFP solicits proposals for the following:
• An metamodel and/or profile which extends extension to UML™ for defining business processes.
• A standard for exporting and importing a Workflow Process Definition from tools and repositories, and for exchanging a Workflow Process Definition with other enactment domains.
A standard for process definition will provide modelers with a common notation, interoperation between modeling tools, and between tools and execution environments. This will increase communication between modelers, including between business and software modelers, provide flexibile selection of tools and engines, and promote the development of more specialized tools for the analysis and design of processes. Basing business process definition on UML will leverage the existing users, tools, and execution engines for UML.
For more details, see section 6 of this document.
1.0 Introduction
1.1 Goals of OMG
The Object Management Group (OMG) is the world's largest software consortium with a membership of over 800 vendors, developers, and end users. Established in 1989, its mission is to promote the theory and practice of Object Technology (OT) for the development of distributed computing systems.
A key goal of OMG is create a standardized object-oriented architectural framework for distributed applications based on specifications that enable and support distributed objects. Objectives include the reusability, portability, and interoperability of object-oriented software components in heterogeneous environments.To this end, the OMG adopts interface and protocol specifications, based on commercially available object
technology, that together define an Object Management Architecture (OMA).
1.2 Organization of this document
The remainder of this document is organized as follows:
Chapter 2 - Architectural Context - background information on OMG’s Object Management Architecture.
Chapter 3 - Adoption Process - background information on the OMG specification adoption process.
Chapter 4 - Instructions for Submitters - explanation of how to make a submission to this RFP.
Chapter 5 - General Requirements on Proposals - requirements and evaluation criteria that apply to all proposals submitted to OMG.
Chapter 6 - Specific Requirements on Proposals - problem statement, scope of proposals sought, mandatory and optional requirements, issues to be discussed, evaluation criteria, and timetable that apply specifically to this RFP.
Additional RFP-specific chapters may also be included following Chapter 6.
1.3 References
The following documents are referenced in this document:
Richard Soley (ed.), Object Management Architecture Guide, Third Edition, Wiley, June 1995. OMG Document ab/97-05-05, or successor.
The Common Object Request Broker: Architecture and Specification, Revision 2.1, August 1997. OMG Document formal/97-09-01, or successor.
CORBAservices: Common Object Services Specification, Revised Edition, July 1997. OMG Document formal/97-07-04, or successor.
CORBAfacilities Architecture, Revision 4.0, November 1995.
Business Committee RFP Attachment, OMG Document omg/97-10-01.
Policies and Procedures of the OMG Technical Process, OMG Document pp/97-06-01 or successor.
These documents can be obtained by contacting OMG at
[email protected]. Many OMG documents, including this document, are available electronically from OMG’s document server. Send a message containing the single line “help” to [email protected] for more information, or visit the OMG Web page (URL http://www.omg.org/), which also has more information about OMG in general. If you have general questions about this RFP send email to [email protected].
2.0 Architectural Context
2.1 Object Management Architecture
The Object Management Architecture Guide (OMAG) describes OMG’s technical objectives and terminology and provides the conceptual infrastructure upon which supporting specifications are based. The guide includes the OMG Object Model, which defines common semantics for specifying the externally visible characteristics of objects in a
standard implementation-independent way, and the OMA Reference Model.
The Reference Model identifies and characterizes the components, interfaces, and protocols that compose the OMA. This includes the Object Request Broker (ORB) component that enables clients and objects to communicate in a distributed environment, and four categories of object interfaces:
• Object Services are interfaces for general services that are likely to be used in any program based on distributed objects.
• Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains.
• Domain Interfaces are application domain-specific interfaces.
• Application Interfaces are non-standardized application-specific interfaces.
A second part of the Reference Model introduces the notion of domain- specific Object Frameworks. An Object Framework component is a collection of cooperating objects that provide an integrated solution within an application or technology domain and which is intended for customisation by the developer or user.
Through a series of RFPs, OMG is populating the OMA with detailed specifications for each component and interface category in the
Reference Model. Adopted specifications include the Common Object Request Broker Architecture (CORBA), CORBAservices, and
CORBAfacilities.
The wide-scale industry adoption of OMG's OMA provides application developers and users with the means to build interoperable software systems distributed across all major hardware, operating system, and programming language environments.
2.2 CORBA
The Common Object Request Broker Architecture defines the programming interfaces to the OMA ORB component. An ORB is the basic mechanism by which objects transparently make requests to - and receive responses from - each other on the same machine or across a network. A client need not be aware of the mechanisms used to communicate with or activate an object, how the object is implemented, nor where the object is located. The ORB thus forms the foundation for building applications constructed from distributed objects and for interoperability between applications in both homogeneous and heterogeneous environments.
The OMG Interface Definition Language (IDL) provides a standardized way to define the interfaces to CORBA objects. The IDL definition is the contract between the implementor of an object and the client. IDL is a strongly typed declarative language that is programming language- independent. Language mappings enable objects to be implemented and sent requests in the developer's programming language of choice in a style that is natural to that language.
CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2 specification. CORBA 2.0 is a family of specifications consisting of the following components:
• Core (including IDL syntax and semantics)
• Interoperability
• An expanding set of language mappings, including:
C
C++
SmallTalk Ada95 COBOL
Each component is a separate compliance point. The minimum required for a CORBA-compliant implementation is adherence to the core and one language mapping.
2.3 CORBA/Interoperability
Interoperability between CORBA-compliant ORBs is provided by OMG's Internet Inter-ORB Protocol (IIOP). Adopted in December 1994 as the mandatory CORBA 2.0 protocol for “out of the box” interoperability, IIOP is the TCP/IP transport mapping of a General Inter-ORB Protocol
(GIOP). IIOP enables requests to be sent to networked objects managed by other ORBs in other domains.
The OMG interoperability architecture also accommodates
communication using optional Environment-Specific IOPs (ESIOPs), the first of which is the DCE-CIOP.
2.4 CORBAservices
Object Services are general purpose services that are either fundamental for developing useful CORBA-based applications composed of
distributed objects, or that provide a universal - application domain- independent - basis for application interoperability.
Object Services are the basic building blocks for distributed object
applications. Compliant objects can be combined in many different ways and put to many different uses in applications. They can be used to construct higher level facilities and object frameworks that can interoperate across multiple platform environments.
Adopted OMG Object Services are collectively called CORBAservices and include Naming, Events, LifeCycle, Persistent Object, Relationships, Externalization, Transactions, Concurrency Control, Licensing, Query, Properties, Security, Time, Collections, and Trading Services.
2.5 CORBAfacilities
Common Facilities are interfaces for horizontal end-user-oriented
facilities applicable to most domains. Adopted OMG Common Facilities are collectively called CORBAfacilities and include an OpenDoc-based Distributed Document Component Facility.
A specification of a Common Facility or Object Service typically includes the set of interface definitions - expressed in OMG IDL - that objects in various roles must support in order to provide, use, or participate in the facility or service. As with all specifications adopted by OMG, facilities and services are defined in terms of interfaces and their semantics, and not a particular implementation.
2.6 Object Frameworks and Domain Interfaces
Unlike the interfaces to individual parts of the OMA “plumbing”
infrastructure, Object Frameworks are complete higher level components that provide functionality of direct interest to end-users in particular
application or technology domains. They are vertical slices down the OMG “interface stack”.
Object Frameworks are collections of cooperating objects categorized into Application, Domain, Facility, and Service Objects. Each object in a framework supports (through interface inheritance) or makes use of (via client requests) some combination of Application, Domain,
CORBAfacilities, and CORBAservices interfaces.
A specification of an Object Framework defines such things as the structure, interfaces, types, operation sequencing, and qualities of service of the objects that make up the framework. This includes requirements on implementations in order to guarantee application portability and interoperability across different platforms.
Domain Task Force RFPs are likely to focus on Object Framework specifications that include new Domain Interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation.
3.0 Adoption Process
3.1 Introduction
OMG adopts specifications for interfaces and protocols by explicit vote on a technology-by-technology basis. The specifications selected each fill in a portion of the OMA Reference Model. OMG bases its decisions on both business and technical considerations. Once a specification is adopted by OMG, it is made available for use by both OMG members and non-members.
For more detailed information on the adoption process see the Policies and Procedures of the OMG Technical Process.
3.2 Rôle of Board of Directors
The OMG Board of Directors votes to formally adopt specifications on behalf of OMG. The OMG Technology Committees (Domain and
Platform TCs) and Architecture Board (AB) provide technical guidance to the Board of Directors. In addition, the Business Committee of the Board provides guidance to ensure that implementations of adopted specifications are made commercially available.
3.3 Rôle of Technology Committees and Architecture Board Submissions to RFPs are evaluated by the TC Task Force (TF) that initiated the RFP. Selected specifications are recommended to the parent TC after being reviewed by the Architecture Board for consistency with the OMA. The full TC then votes to recommend adoption to the OMG Board.
3.4 Rôle of Task Forces
The role of the initiating TF is to technically evaluate submissions and select one or more specifications that satisfy the requirements of the RFP.
The process typically takes the following form:
• Voter Registration
Interested TF members may register to participate in specification selection votes for an RFP. Registration ends on a specified date 6 or more weeks after the announcement of the registration period. The registration closure date is typically around the time of initial
submissions. Companies who have submitted an LOI are automatically registered to vote.
• Initial Submissions
Initial submissions are due by a specified deadline. Submitters
normally present their proposals at the next following meeting of the TF. Initial submissions are expected to be full and complete proposals and working implementations of the proposed specifications are expected to exist at the time of submission.
• Evaluation Phase
A period of approximately 120 days follows during which the TF evaluates the submissions. During this time submitting companies have the opportunity to revise and/or merge their initial submissions, if they so choose.
• Revised Submissions
Final revised submissions are due by a specified deadline. Submitters again normally present their proposals at the next following meeting of the TF. Finalists may be requested to demonstrate implementations of their proposal.
• Selection Vote
When the registered voters of the TF believe that they sufficiently understand the relative merits of the revised submissions, a specification selection vote is taken.
3.5 Goals of the evaluation
The primary goals of the TF evaluation process are to:
• Provide a fair and open process
• Force a critical review of the submissions and discussion by all members of the TF
• Give feedback to allow submitters to address concerns in their revised submissions
• Build consensus on acceptable solutions
• Enable voting members to make an informed selection decision Submitters are expected actively to contribute to the evaluation process.
4.0 Instructions for Submitters
4.1 OMG Membership
Submissions to this RFP may only be made by Platform, Domain or Contributing members of the OMG. To submit to an RFP issued by the Platform Technology Committee an organisation must be a Platform or Contributing member at the date of the submission deadline, while for Domain Technology RFPs the submitter or submitters must be either Contributing or Domain members. Submitters sometimes choose to name other organisations that support a submission in some way;
however, this has no formal status within the OMG process, and for OMG’s purposes confers neither duties nor privileges on the
organisations concerned.
4.2 Submission Effort
Unlike a submission to an OMG Request For Information (RFI), an RFP submission may require significant effort in terms of document
preparation, presentations to the initiating TF, and participation in the TF evaluation process. Several staff months of effort might be necessary.
OMG is unable to reimburse submitters for any costs in conjunction with their submissions to this RFP.
4.3 Letter of Intent
A Letter of Intent (LOI) must be submitted to the OMG Business Committee signed by an officer of your organization signifying your intent to respond to the RFP and confirming your organization’s willingness to comply with OMG’s terms and conditions, and commercial availability requirements. These terms, conditions, and requirements are defined in the Business Committee RFP Attachment and are reproduced verbatim in section 4.4 below.
The LOI should designate a single contact point within your
organization for receipt of all subsequent information regarding this RFP and your submission. The name of this contact will be made available to all OMG members. The LOI is typically due 60 days before the deadline for initial submissions. LOIs must be sent by fax or paper mail to the
“RFP Submissions Desk” at the main OMG address shown on the first page of this RFP.
Here is a suggested template for the Letter of Intent:
This letter confirms the intent of <___organisation required___> (the
organisation) to submit a response to the OMG <___RFP name required___>
RFP. We will grant OMG and its members the right to copy our response for review purposes as specified in section 4.7 of the RFP. Should our response be adopted by OMG we will comply with the OMG Business Committee terms set out in section 4.4 of the RFP and in document omg/98-03-01.
<____contact name and details required____> will be responsible for liaison with OMG regarding this RFP response.
The signatory below is an officer of the organisation and has the approval and authority to make this commitment on behalf of the organisation.
<___signature required____>
4.4 Business Committee RFP Attachment
This section contains the text of the Business Committee RFP attachment concerning commercial availability requirements placed on submissions.
This attachment, available separately as document omg/98-03-01, was approved by the OMG Board in February 1998.
__________________________________________
Commercial considerations in OMG technology adoption A1 Introduction
OMG wishes to encourage rapid commercial adoption of the specifications it publishes. To this end, there must be neither technical, legal nor commercia l obstacles to their implementation. Freedom from the first is largely judged through technical review by the relevant OMG Technology Committee; the second two are the responsibility of the OMG Business Committee. The BC also looks for evidence of a commitment by a submitter to the commercial success of products based on the submission.
A2 Business Committee evaluation criteria A2.1 Viable to implement across platforms
While it is understood that final candidate OMG submissions often combine technologies before they have all been implemented in one system, the Business Committee nevertheless wishes to see evidence that each major feature has been implemented, preferably more than once, and by separate organisations. Pre- product implementations are acceptable. Since use of OMG specifications should
not be dependant on any one platform, cross-platform availability and interoperability of implementations should be also be demonstrated.
A2.2 Commercial availability
In addition to demonstrating the existence of implementations of the specification, the submitter must also show that products based on the
specification are commercially available, or will be within 12 months of the date when the specification was recommended for adoption by the appropriate Task Force. Proof of intent to ship product within 12 months might include:
• A public product announcement with a shipping date within the time limit.
• Demonstration of a prototype implementation and accompanying draft user documentation.
Alternatively, and at the Business Committee's discretion, submissions may be adopted where the submitter is not a commercial software provider, and therefore will not make implementations commercially available. However, in this case the BC will require concrete evidence of two or more independent implementations of the specification being used by end-user organisations as part of their
businesses.
Regardless of which requirement is in use, the submitter must inform the OMG of completion of the implementations when commercially available.
A2.3 Access to Intellectual Property Rights
OMG will not adopt a specification if OMG is aware of any submitter, member or third party which holds a patent, copyright or other intellectual property right (collectively referred to in this policy statement as "IPR") which might be infringed by implementation of such specification, unless OMG believes that such IPR owner will grant a license to implementers (whether OMG members or not) on non-discriminatory and commercially reasonable terms which wish to implement the specification. Accordingly, the submitter must certify that it is not aware of any claim that the specification infringes any IPR of a third party or that it is aware and believes that an appropriate non -discriminatory license is available from that third party. Except for this certification, the submitter will not be required to make any other warranty, and specifications will be offered by OMG for implementation "as is". If the submitter owns IPR to which an implementation of a specification based upon its submission would necessarily be subject, it must certify to the Business Committee that it will make a suitable license available to any implementer on non-discriminatory and commercially reasonable terms, to permit development and commercialisation of an
implementation that includes such IPR.
It is the goal of the OMG to make all of its specifications available with as few impediments and disincentives to adoption as possible, and therefore OMG strongly encourages the submission of technology as to which royalty-free licenses will be available. However, in all events, the submitter shall also certify that any necessary license will be made available on commercially reasonable, non-discriminatory terms. The submitter is responsible for disclosing in detail all known restrictions, placed either by the submitter or, if known, others, on technology necessary for implementation of the specification.
A2.4 Publication of the specification
Should the submission be adopted, the submitter must grant OMG (and its sublicensees) a world-wide, royalty-free licence to edit, store, duplicate and distribute both the specification and works derived from it (such as revisions and teaching materials). This requirement applies only to the written specification, not to any implementation of it.
A2.5 Continuing support
The submitter must show a commitment to continue supporting the technology underlying the specification after OMG adoption, for instance by showing the BC development plans for future revisions, enhancement or maintenance.
__________________________________________
4.5 Responding to RFP items 4.5.1 Separate proposals
Unless otherwise indicated in Chapter 6, independent proposals are solicited for each separate item in the RFP. Each item is considered a separate architectural entity for which a proposal may be made. A submitter may respond to any or all items. Each item will be evaluated independently by the initiating TF. Submissions that do not present clearly separable proposals for multiple items may therefore be at a disadvantage.
It should be noted that a given technology (e.g. software product) may support two or more RFP items. So long as the interfaces for each item are separable, this is not precluded.
4.5.2 Complete proposals
Proposals for each separate RFP item must be complete. A submission must propose full specifications for each item and address all the relevant general and specific requirements detailed in this RFP.
4.5.3 Additional specifications
Submissions may include additional specifications for items not covered by the RFP which they believe to be necessary and integral to their proposal. Information on these additional items should be clearly distinguished.
Submitters must give a detailed rationale as to why these specifications should also be considered for adoption. However submitters should note that a TF is unlikely to consider additional items that are already on the roadmap of an OMG TF, since this would pre-empt the normal adoption process.
4.5.4 Alternative approaches
Submitters may provide alternative RFP item definitions,
categorizations, and groupings so long as the rationale for doing so is clearly stated. Equally, submitters may provide alternative models for how items are provided within the OMA if there are compelling technological reasons for a different approach.
4.6 Confidential and Proprietary Information
The OMG specification adoption process is an open process. Responses to this RFP become public documents of the OMG and are available to members and non-members alike for perusal. No confidentiality or proprietary information of any kind will be accepted in a submission to this RFP.
4.7 Copyright Waiver
If a submitted document is copyrighted, a waiver of copyright for unlimited duplication by the OMG is required to be stated in the document. In addition, a limited waiver of copyright is required that allows each OMG member to make up to fifty (50) copies of the document for review purposes only.
4.8 Proof of Concept
Submissions must include a “proof of concept” statement, explaining how the submitted specifications have been demonstrated to be technically viable. The technical viability has to do with the state of development and maturity of the technology on which a submission is based. This is not the same as commercial availability. Proof of concept statements can contain any information deemed relevant by the
submitter, for example:
“This specification has completed the design phase and is the process of being prototyped.”
“An implementation of this specification has been in beta-test for 4 months.”
“A named product (with a specified customer base) is a realization of this specification.”
It is incumbent upon submitters to demonstrate to the satisfaction of the TF the technical viability of their proposal. OMG will favour proposals based on technology for which sufficient relevant experience has been gained in CORBA-based or comparable environments.
4.9 Format of RFP Submissions
This section provides guidance on how to structure your RFP submission.
4.9.1 General
• Submissions that are concise and easy to read will inevitably receive more consideration.
• Submitted documentation should be confined to that directly relevant to the items requested in the RFP. If this is not practical, submitters must make clear what portion of the documentation pertains directly to the RFP and what portion does not.
• The models and terminology in the Object Management Architecture Guide and CORBA should be used in your submission. Where you believe this is not appropriate, describe and provide a rationale for the models and terminology you believe OMG should use. Submitters are encouraged to document their object models and designs using OMG UML where appropriate, and to supply an OMG XMI
representation of the design (including a machine-readable copy) for
the convenience of those wishing to import the UML model into design tools.
4.9.2 Suggested Outline
A three part structure for submissions is suggested:
PART I
• Copyright Waiver (see 4.5)
• Submission contact point (see 4.2)
• Overview or guide to the material in the submission
• Overall design rationale (if appropriate)
• Statement of proof of concept (see 4.6)
• Resolution of RFP mandatory and optional requirements Explain how your proposal satisfies the mandatory and (if applicable)
optional requirements stated in Chapter 6. References to supporting material in Part II should be given.
In addition, if your proposal does not satisfy any of the general requirements stated in Chapter 5, provide a detailed rationale.
• Responses to RFP issues to be discussed
Discuss each of the “Issues To Be Discussed” identified in Chapter 6.
PART II
• Proposed specification PART III
• Summary of optional versus mandatory interfaces
Submissions must clearly distinguish interfaces that all implementations must support from those that may be optionally supported.
• Proposed compliance points
Submissions should propose appropriate compliance points for implementations.
• Changes or extensions required to adopted OMG specifications
Submissions must include a full specification of any changes or extensio ns required to existing OMG specifications. This should be in a form that enables “mechanical” section-by-section revision of the existing specification.
• Complete IDL definitions
For reference purposes and to facilitate electronic usage, submissions should reproduce in one place a complete listing in compilable form of the IDL definitions proposed for standardization.
4.10 How to Submit
Submitters should send an electronic version of their submission to the RFP Submissions Desk ([email protected]) at OMG by 5:00 PM U.S. Eastern Standard Time (22:00 GMT) on the day of the submission deadline.
Acceptable formats are Postscript, ASCII, PDF, FrameMaker, Word, and WordPerfect. However, it should be noted that a successful submission must be supplied to OMG’s technical editors in Framemaker source format, using the most recent available OMG submission template (document ab/97-06-02 at the time of writing). The AB will not endorse adoption of any submission for which appropriately-formatted
Framemaker sources are not available; it may therefore be convenient to prepare all stages of a submission using this template.
Submitters should make sure they receive electronic or voice
confirmation of the successful receipt of their submission. Submitters should also send, within three (3) working days after the submission deadline, a single hardcopy version of their submission to the attention of the “RFP Submissions Desk” at the main OMG address shown on the first page of this RFP.
5.0 General Requirements on Proposals
5.1 Mandatory Requirements
5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow accepted OMG IDL and CORBA programming style. The correctness of the IDL shall be verified using at least one IDL compiler (and preferably more then one). In addition to IDL quoted in the text of the submission, all the IDL associated with the proposal shall be supplied to OMG in compiler-readable form.
5.1.2 Proposals shall specify operation behaviour, sequencing, and side-effects (if any).
5.1.3 Proposals shall be precise and functionally complete. There should be no implied or hidden interfaces, operations, or functions required to enable an implementation of the proposed specification.
5.1.4 Proposals shall clearly distinguish mandatory interfaces and other
specification elements that all implementations must support from those that may be optionally supported.
5.1.5 Proposals shall reuse existing OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions.
5.1.6 Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. This includes changes and extensions to CORBA inter-ORB protocols necessary to support
interoperability. In general, OMG favours upwards compatible proposals that minimize changes and extensions to existing OMG specifications.
5.1.7 Proposals shall factor out functions that could be used in different contexts and specify their interfaces separately. Such minimality fosters re-use and avoids functional duplication.
5.1.8 Proposals shall use or depend on other interface specifications only where it is actually necessary. While re-use of existing interfaces to avoid duplication will be encouraged, proposals should avoid gratuitous use.
5.1.9 Proposals shall specify interfaces that are compatible and can be used with existing OMG specifications. Separate functions doing separate jobs should be capable of being used together where it makes sense for them to do so.
5.1.10 Proposals shall preserve maximum implementation flexibility.
Implementation descriptions should not be included, however proposals may specify constraints on object behaviour that implementations need to take into account over and above those defined by the interface semantics.
5.1.11 Proposals shall allow independent implementations that are substitutable and interoperable. An implementation should be replaceable by an alternative implementation without requiring changes to any client.
5.1.12 Proposals shall be compatible with the architecture for system distribution defined in ISO/IEC 10746, Reference Model of Open
Distributed Processing (ODP). Where such compatibility is not achieved, the response to the RFP must include reasons why compatibility is not appropriate and an outline of any plans to achieve such compatibility in the future.
5.1.13 In order to demonstrate that the service or facility proposed in response to this RFP, can be made secure in environments requiring security, answers to the following questions shall be provided:
• What, if any, are the security sensitive objects that are introduced by the proposal?
• Which accesses to security-sensitive objects must be subject to security policy control?
• Does the proposed service or facility need to be security aware?
• What CORBAsecurity level and options are required to protect an implementation of the proposal? In answer to this question, a
reasonably complete description of how the facilities provided by the level and options (e.g. authentication, audit, authorization, message protection etc.) are used to protect access to the sensitive objects introduced by the proposal shall be provided.
• What default policies should be applied to the security sensitive objects introduced by the proposal?
• Of what security considerations must the implementers of your proposal be aware?
5.1.14 Proposals shall specify the degree of internationalization support that they provide. The degrees of support are as follows:
a) Uncategorized: Internationalization has not been considered.
b) Specific to <region name>: The proposal supports the customs of the specified region only, and is not guaranteed to support the customs of any other region. Any fault or error caused by requesting the services outside of a context in which the customs of the specified region are being consistently followed is the responsibility of the requester.
c) Specific to <multiple region names>: The proposal supports the customs of the specified regions only, and is not guaranteed to support the customs of any other regions. Any fault or error caused by requesting the services outside of a context in which the customs of at least one of the specified regions are being consistently followed is the responsibility of the requester.
5.2 Evaluation criteria
Although the OMG adopts interface specifications, the technical viability of implementations will be taken into account during the evaluation process. The following criteria will be used:
5.2.1 Performance
Potential implementation trade-offs for performance will be considered.
5.2.2 Portability
The ease of implementation on a variety of ORB systems and software platforms will be considered.
5.2.3 Securability
The answer to questions in section 5.1.13 shall be taken into
consideration to ascertain that an implementation of the proposal is securable in an environment requiring security.
5.2.4 Compliance: Inspectability and Testability
The adequacy of proposed specifications for the purposes of compliance inspection and testing will be considered. Specifications should provide sufficient constraints on interfaces and implementation characteristics to
ensure that compliance can be unambiguously assessed through both manual inspection and automated testing.
5.2.5 Standardised Metadata
Where proposals incorporate metadata specifications, usage of OMG standard XMI metadata representations will be considered, since this allows specifications to be easily interchanged between XMI compliant tools and applications. Since use of XML (including XMI, XML/Value) is evolving rapidly, the use of industry specific XML vocabularies (which may not be XMI compliant) is acceptable where justified.
6.0 Specific Requirements on Proposals
6.1 Problem Statement
A standard for process definition will provide modelers with a common notation, interoperation between modeling tools, and between tools and execution environments. This will increase the communication between modelers, including between business and software modelers, provide flexibile selection of tools and engines, and promote the development of more specialized tools for the analysis and design of processes. Basing business process definition on UML will leverage existing users, tools, and execution engines for UML.
Process definitions in UML and its extensions will be translatable to various interchange languages and API’s. Definitions should express the intent a modeler has for runtime behavior, rather than the means by which that behavior is realized. However, an intermediate layer of specification based on message passing between entities may be provided to constrain the centralization or decentralization of the implementation.
For example, a decentralized model might be an industry process that emerges from the interaction of multiple companies. A centralized model might a virtual company that coordinates other business entities that interact with each other only under the direction of the virtual company. The intermediate layer specifies a message-passing pattern for realization, determining the degree of centralization of the process.
An astract process definition specifies only the order and conditions for steps in the process, independently of how the process is realized in messages.
The above issue is recursive. A process described in terms of message passing can expand to finer-grained processes on each entity that are decribed abstractly, but show when messages are sent between entities.
For example, a decentralized industry model may show messages passing between businesses, while the processes inside the business are described abstractly. These in turn, may be implemented by message passing between departments in the business, and so on.
Process definitions will provide information to be executed by
enactment engines, including resource specifications. However, they will also support incomplete specifications that are not executable without additional modeling. It is expected that some modelers may sketch a process that is filled out by others for execution.
Interoperability between these engines at runtime is not in the scope of this RFP. Enactment engines have their own interfaces for managing processes based on the definitions of this RFP, for example starting and stopping them, and querying and auditing the state of execution.
Engine interfaces and process definition are expected to touch at a very small number of points, for example, to specify the process definition when starting a process, to assign resources, and to find out which steps in a process are currently executing.
6.1.1 Examples of Business Processes
The intent of the following examples is to give a sense of the scope of process definitions that submission should be able to support. The list is by no means complete or exhaustive. All of the processes represented are based on real production processes. For the purposes of this RFP the essential or unique characteristics of each process is presented, rather than the full description.
6.1.1.1 Employee Expense Reimbursement (EER) Process
This process, implemented as a workflow, provides for reimbursement of expenses incurred by employees for the company. For example buying a technical book, office supplies or software. In a normal day there are several hundreds of instances of this process created.
The main rules of the process are
• Amounts under $200 are automatically approved.
• Amounts equal to or over $200 need approval of the supervisor.
• The reimbursement goes to the employee’s direct deposit bank account.
• In case of rejection, the employee must receive a rejection email.
• If no action has happened in 7 days, then the employee must receive an approval in progress email.
• If the request is not finished within 38 days, then the request is cancelled and the employee receives an email and must re- submit.
Below is a graphical representation of the EER process. There are 3 types of nodes shown in the graphic: work nodes (person at computer icon), routing nodes (3 arrow icon), and timer node (clock icon). A work node represents a task performed by a human or application. A routing node indicates where the flow branches or combines. A timer node represents a waiting period or an absolute date. The process flow is indicated by arrows. There are many aspects of the process definition that do not appear in the graphical image. One important example of this is the rules that control the flow of the process at routing nodes.
Another is the process data involved and used by the workers, applications and rules.
Figure 2 – EER Process Graph
There are two important characteristics in this example. The first is the time check path running in parallel to the basic approval path.
Whichever path finishes first wins. This is the same as the test process in
$9,79 ((5 /RDG
3UHDSSURYDO
'HFLVLRQ 6XEPLW IRU $SSURYDO
$SSURYDO 'HFLVLRQ
6HUYLFH
$SSURYDO
5HMHFW
1RWLI\ 5HMHFW 1R DFWLRQ WLPHU
1RWLI\ $SSURYHU
&DQFHO 7UDQVDFWLRQ 7LPHU
&DQFHO 6HUYLFH
3/
school; the test is done when the student has answered all the questions or when the test time is finished. The second is the branching with multiple outflows of which only some might be taken and multiple inflows of which only some might be necessary to trigger the following step.
More detail about this process can be found in bom/00-01-06.
6.1.1.2 Airplane Design (AD) Process
This example centers on the design of an airplane. Design of an airplane means the selection of standard parts to assemble the interior of the airplane, not the aerodynamic aspects of the body and wings. There are two groups of people involved, the airplane designers and the standard part engineers. Each group has its own system.
The airplane designer works within the context of a process. In his work he discovers the need for a standard part with a step in his process. That need is translated into a search process instance within the system of the standard part engineer group. A successful search returns the part to the plane design engineer step.
An unsuccessful search results in a modification to a standard part process being started in the standard part group system. Part of the modification process is to check the search conditions. The airplane designer might not have formulated the correct search because of the large number of parts and part categories. If no part is found with the reformulated search, then the process leads the standard parts group through an assessment of whether to modify an existing part or to create a new standard part.
Whether a part is to be modified or a new part created, a process instance is started for that process. The process needs to take into
account that not every standard part engineer can work on any standard part. To a certain extent this process definition is finished from a
template at process instantiation time. The availability of a qualified engineer to create or modify the part is critical to the scheduling and enactment of the process instance. This schedule information is given back to the airplane designer for approval. If the new standard part cannot be done in time then an alternate design is followed.
One of the unique characteristics of this example is the messages or interactions that occur between process instances. There are processes that define or complete the definition of other processes. There are complex resource qualification and assignment rules. The rules must
take into account not only the skills and qualifications needed, but also the availability of the engineer in relation to the airplane schedule.
More detail about this example can be found in bom/98-02-14.
6.1.1.3 Trouble Ticket (TT) Process
The Trouble Ticket process covers quality assurance teams or customer support teams. A "bug" or "problem" is identified; it must be recorded;
the record must be checked for accuracy; from a single instance of a problem, the underlying cause is identified; a resolution is identified, which must be communicated back to the original party with the problem.
This process contains a potential loop. If the resolution cannot be
verified as successful, then the problem goes back to the resolution step.
Rework is quite common in processes, because the ability to verify if work was properly done might only be possible several steps later, More detail about this example can be found in bom/98-02-09 and bom/98-07-13
6.1.1.4 Common Business Process Patterns
One common pattern is multiple entrances into a process. That is a process which starts with 2 or more steps in parallel. The reasons for this are reuse of process segments and access control to information.
Another common pattern is the execution of more than one following step. For example (see figure below) a review step might result (in the
Add New Document
Select
Document
Mod case) in asking for a modification of a document (rework back to edit) and sending a notification of the modification result via email.
Passing the review step (the Accept case) would activate only the publish step. Rejecting the document (the Reject case) would activate only the rejection notification step. Just as in the EER example there are branches that do not join before the end of the process, but unlike the EER example there are no “races” to completion. An important attribute of this example is that a new resource may be assigned to the Mo dify Proposal step if and when the review sends the document back for rework (Mod case).
More detail about this example can be found in bom/00-01-05.
6.1.1.5 Resource Specification Examples
A process definition will need to specify the resources it needs at var ious levels of abstraction. The specification of the resources can be viewed as an expression.
The resource specification will (in the most general case) have two aspects. The first aspect of the specification consists of constraints associated with the instance enactment history such as a preference for
Modify Proposal
Review Proposal
Publish Proposal
Stop
Stop
Notify of Rejection Notify of Modification
Reject
Accept Mod
the same person that worked on an earlier step. The evaluation of these constraints will add to the second aspect of the resource expression. The second aspect consists of the characteristics of the resource needed. This part will be handed to resource manager for evaluation.
The resources will usually be referenced as roles. In this situation the term role is used in multiple ways. The first way is the role the resource plays via the assignment. Is the resource a performer or an artifact? A second way role is used is as an abstraction for a set of characteristics or capabilities. This might be a set of skills, an availability, a capability, an authority level, a location, etc.
A few example resource specifications of the kind that would appear in process definitions are included below. See bom/00-01-03 for more discussion and examples.
A person in organization position Z – a typical reference to a position in the organization structure, officer of the company, R&D manager, leader of project A
The manager of X, where X is initiator of process or some other participant – a typical reference into an organization structure that satisfies a relationship
Joe Smith – a direct reference
A mechanical engineer with skills in structural analysis and who is a
registered Professional engineer in the state of Colorado – reference to a skill or capability set, often this information is not in the corporate organization structure
A master machinist and a 5 axis milling machine that can handle a part of 1m maximum dimension and 90 cm of stock (#12345A) and 5 diamond tipped bits (#45-678 – a reference to a set of resources that come from several different resource models
The gear XXX CAD model to be changed and CAD mode ls yyy, vvv and zzz as reference and context for the change – these references include roles that the information resources play during the process enactment
6.2 Scope of Proposals Sought
Process definitions should provide enough information for complete execution of processes, while still supporting incomplete models.
6.2.1 Business Process Definition Model and Notation
The metamodel for process definition should be completely consistent with UML semantics and reuse as much of it as possible, activity
modeling and collaboration/sequence modeling in particular. The same applies to notation, but more leeway is available to accommodate
business modeler perferences. The metamodel should avoid adding to generic modeling techniques, but rather be limited to extensions that are needed in the domain of business modeling. OCL is part of UML d shall be treated the same way as the rest of UML.
6.2.2 Abstractness of Process Models
Some process definitions emphasize the order and conditions for their steps, and abstract away from implementation. Others focus on the messages that pass between objects to realize an abstract process.
Proposals need to address both of these and how they relate.
6.2.26.2.3 Step Types
The process definition needs to provide for the specification of step types. There are many possible types of steps: those done by a person, automatic ones done by a program, those accomplished by a subprocess, etc.
6.2.36.2.4 Representation of the Flow of Work
a) The proposals need to provide for a representation of the flow of work from one task to the next. These flows need to support sequential and parallel concurrent, and ordered or unordered execution of tasks. Additionally, the flows need to support looping back to previous portions of the flow of work.
b) The definition will need to be able to express parallel join conditions where the completion of n of m parallel branches (where n <= m) results in progression to the next step in the flow.
c) The definition should be able to accommodate graph or rule based representations of the flow of the work from one task to the next.
d) The definition should be able to accommodate nested flows where a step in a process may start another process.
e) The definition should provide for specification receiving and sending events, including receptions that initiate a step or flow of work as the result of notification of an event.
f) It would be useful to be able to specify processes where certain process flow parameters are determined at execution time. The number of parallel flows leaving a split is an example of a p arameter that a process designer might want to depend on factors only
determinable at execution time.
6.2.46.2.5 Relation to Existing Enactment Specifications
Listed below are some of the interactions between process definitions and processes execution engines.
6.2.4.16.2.5.1 Creating process instances
Process instances are controlled by process definitions. Process definitions are objects supporting the creation of process instances.
Typically these objects would be registered with a Naming or a Trader service. Some or all of the process definition information is available from the process instance. Process definitions may control whether process instances can be created from them at any given time.
6.2.4.26.2.5.2 Control of execution behavior
a) The process definition should contain the conditions that need to be satisfied for the start and/or the completion of a process and steps in a process. For example certain process context data may need to exist or have values within certain limits.
b) It could also contain actions that need to be accomplished before the start of a process or step in a process and/or upon completion of the process or step. A typical action is to destroy any temporary data or objects created during process enactment.
c) The process definition could specify the propagation scope and reaction method of state change, such whether pausing a process pauses the current step being executed or whether the current step is allowed to finish.
d) Process definitions might have additional execution constraints or characteristics like maximum duration, predicted start time, the inability to pause or interrupt a process, or the ability to rollback
execution to an earlier step in the flow. The modeling of these constraints and the violation of them are of interest.
6.2.56.2.6 Audit Event Generation and Reaction
This is for monitoring a process, in particular defining business- meaningful events to be generated from execution objects.
a) The process definition should be able to specify which audit events are produced and logged. The event log may be different from public notification. The public events produced and events log can differ from process definition to process definition.
b) The process definition should be able to specify the events to which a WfProcess or a WfActivity will react and the method of reaction.
6.2.5 Process Definition AuditingVersioning
Recording changes to the process definition is desired in order to track evolution of a process definition. These changes might result in a new version of the process. It should be possible to review the changes made to a process definition.
A more detailed state model for process definitions might be offered, controlling when instances can be made from it.
6.2.6 Resource Specification
A part of the process definition is the specification of the r esources required for execution. These resources will be known at process definition time with different degrees of specificity. This specificity might range from a particular person, to an organizational group, or merely a list of required skills. The process definition needs to be able to represent, in an abstract or concrete manner, the resources that can be involved in the process.
The specification of a resource might include process execution relative terms. For example, the second review action in a process might involve the same skills as the first review step, but must be a different person.
The process definition could specify the scope of use of a resource. Is the resource allocated for the entire process, just-in-time for the steps or by some other policy?
6.2.7 Artifacts
Business processes generally involve artifacts, records or subject matter of the process. The process definition must include references to
artifacts and access to the attributes and methods on objects that represent them as well as related objects.
Artifacts may be passed to a process at initiation, obtained by a process from other system services or applications during execution, or created by the process. The process definition may determine the lifecycle of certain artifacts.
6.2.7 Access Control[CB14]
a) A process might have data, artifact objects, event audit data or steps that require access restrictions. It should be possible to model and represent these restrictions in a process definition. For example, a process to review employee salaries would restrict viewing or changing the salary.
b) There may be a need to describe access control characteristics that change as the execution of a process progresses.
c) There may also be restrictions in the definition on who may create an instance of a WfProcess. A complete solution would provide for modeling these restrictions.
6.2.8 Simulation Data Representation
Proposals may address the representation of data useful for simulations of the process enactment. Some examples of data that might exist for the purposes of simulation are expected task duration, maximum task
duration, expected process duration, maximum process duration, expected branch activation probability, etc.
6.3 Relationship to Existing OMG Specifications
• OMG Workflow Management Facility - Original Specification : bom/98- 06-07 plus Errata bom/98-07-15. RTF 1.2 report : dtc/99-07-04 and IDL dtc/99-07-06. Convenience document : dtc/99-07-05
• Unified Modeling Language (UML) Specification version TBD, especially the sections on activity modeling.
• UML 1.4 with Action Semantics - ptc/02-01-09
• Meta Object Facility Specification version 1.3 - ad/99-09-05
• XML Metadata Interchange (XMI) Specification version 1.1 - ad/99-10-02 and ad/99-10-03
• Party Management Facility - finance/98-12-09
• PDM Enablers formal/2000-11-11 especially PdmResponsibility, PdmFoundation, and PdmChangeManagement
• Additional Structures for OTS – orbos/00-06-19
• Organizational Structure Facility - draft adoped specification: dtc/01- 09-01. This may provide constructs which could be reused for expressions identifying human resources in process definitions.
• UML Profile for Event-based Architectures in Enterprise Application Integration (EAI) - doc??? Enterprise Application Integration (EAI) involves the flow of information between applications and the event driven flow of business processes. Submitters may find parts of the EAI Profile reusable for supporting event driven flow behaviors in process definitions.
• UML Profile for Enterprise Distributed Object Computing (EDOC) – doc?
The UML Profile for EDOC may include representation of business process objects or components and the relationships between these and associated system elements. The Business Process Definition specification may extend or reuse model elements of t he EDOC Profile.
6.4 Related Documents and Standards
6.4.1 The Workflow Management Coalition (www.wfmc.org) has published the following specifications related to this RFP:
• Workflow Reference Model : WfMC-TC-1003
• Terminology & Glossary : WfMC-TC-1011
• Workflow Process Definition Interchange : WfMC-TC-1016
• Resource Model : WfMC-TC-1020
• Process Definition Attributes List : WfMC-TC-1024
6.4.2 The following OMG technology processes which are currently underway, address related concerns to this RFP (more details can be found via
http://www.omg.org/techprocess/meetings/schedule/index.html).
Submissions should address their relationship to these efforts:
• Document Repository Integration
Business processes are often used to manage documents. Document Repository Integration can provide for the storage, transfer and tracking of documents, information or tasks managed by process definitions.
• UML 2.0 Infrastructure and Superstructure
Submitters should be aware that the architecture for the UML metamodel may change in UML 2.0, in particular the relation between State Machines and Activity Modeling.
• UML 2.0 Object Constraint Language (OCL)
Submitters should be aware that a metamodel for OCL will be defined in UML 2.0 and that this may relate to conditional expressions for process definitions.
6.5 Mandatory Requirements
Background for many of the following mandatory requirements can be found in section 6.2.
6.5.1 Business Process Definition Model and Notation
Proposals shall define an extension to UML that is completely
consistent with UML semantics, and as consistent with UML notation as possible. Proposals shall not define models that have semantics already available in UML and shall reuse as much of UML as possible, activity modeling in particular. OCL is part of UML and shall be treated in the same way. Proposals shall avoid extensions for generic modeling and focus on extensions for the business domain.
6.5.2 Abstract and Message-based Process Models
Proposals shall provide for process definitions that emphasize sequence and order of steps, and process definitions that emphasize message- passing between objects, and ways of relating the two kinds of definition.
6.5.3 Step Types
Proposals shall provide for the definition of types for steps of a process.
6.5.4 Representation of the Flow of the Work
Proposals shall provide for the representation of the flow of work from one step to the next.
a) These flows shall support sequential and parallel concurrent, and ordered or unordered execution of steps.
b) Parallel join conditions shall be supported where the completion of n of m parallel branches (where n <= m) results in progression to the next step in the flow.
c) Nested processes where a step may start another process shall be supported.
d) The flow representation shall support receiving and sending events, including receptions that intiate a process as the result of
notification of an event.
6.5.5 WfProcessMgr Metadata
Proposals shall provide for the representation of metadata for process definitions needed by the WfProcessMgr interface of the WFM
specification.
6.5.6 Control of execution behavior
Proposal shall provide modeling constructs for specifying pre or post conditions for steps and processes. Proposals shall also provide a means for specifying completion actions for steps and processes. Proposals shall provide means for specifying the propagation scope of operations.
6.5.7 Audit Event Generation and Reaction
Proposals shall provide means for specifying events that process and step instances generate to publish changes in process state.
6.5.8 Resource Specification
Proposals shall provide means of specifying the resources needed to do the work represented by the steps in a process.
6.5.9 Distributed Enactment
Proposals shall ensure that the form of definition does not preclude distributed enactment.
6.5.10 Process Definition import and export
Proposals shall specify a standard XMI based encoding form for process definition import and export.
6.6 Optional Requirements 6.6.1 Additional Execution Constraints
Proposals may provide for the ability to model additional execution constraints, like maximum duration of a WfExecutionObject. For these additional constraints the behavior of constraint violation should be modeled and its affect on the process enactment described.
6.6.2 Simulation Data Representation
Proposals may provide for the representation of data needed for the support of simulation of process definitions.
6.6.3 Process Definition Auditing
Proposals may provide a means of tracking changes to the process definition so that versions may be differentiated.
6.6.4 Access Control
Proposals may provide a means of modeling requirements for access controls for process data, artifacts, steps in process, and process enactment.
6.6.5 Runtime Parameters
Proposals may provide for the specification of flow control and
synchronization parameter values that will be determined at execution time
6.7 Issues to be discussed
6.7.1 Relationship to existing UML metamodel
Proposals shall discuss the relationship of model elements used for business process modeling to the existing UML metamodel, activity modeling and collaboration/sequence diagrams in particular.
6.7.2 Relationship to UML Notation
Proposals shall discuss the relationship of process modeling notations to existing UML notation such as activity diagrams and
collaboration/sequence diagrams.
6.8 Evaluation Criteria
Proposals will be evaluated against the mandatory and optional
requirements, above, and the extent to which they address the business needs as described in sections 6.1 and the scope as described in section 6.2.
6.9 Other information unique to this RFP
<Include here any further information pertinent to this RFP that does not fit into the sections above, or which is intended to override statements in the Chapters 1 to 5.
For example, in the case of RFPs relating to the CORBA Core, it would be stated that interfaces to entities that are properly not CORBA objects shall be expressed in Pseudo IDL (PIDL) and that mappings for all languages for which OMG IDL mappings exist should, in this case, be specified.>
6.10 RFP Timetable
The timetable for this RFP is given below. Note that the TF may, in certain circumstances, extend deadlines while the RFP is running, or may elect to have more than one revised submission step. The latest timetable can always be found in the Member Services section of OMG’s Web page (URL http://www.omg.org/)
Approx Day
Event or Activity Actual Date
Preparation of RFP by TF
Approval of RFP by Architecture Board Review by TC (“Three week rule”)
0 TC votes to issue RFP <approximate month>
60 LOI to submit to RFP due January <day>, <year>
120 Initial submissions due January <day>, <year>
134 Voter registration closes January <day>, <year>
141 Initial submission presentations January <day>, <year>
Preliminary evaluation by TF
240 Revised submissions due January <day>, <year>
261 Revised submission presentations January <day>, <year>
Final evaluation and selection by TF Recommendation to AB and TC
Approval by Architecture Board Review by TC (“Three week rule”)
330 TC votes to recommend specifications <approximate month>
360 BOD votes to adopt specifications <approximate month>
