Object Management Group Framingham Corporate Center 492 Old Connecticut Path Framingham, MA 01701-4568 Telephone: +1-508-820 4300 Facsimile: +1-508-820 4303 BUSINESS SYSTEM APPLICATION ARCHITECTURE REQUEST FOR PROPOSAL OMG Document: /YY-MM-NN Submissions due: , Objective of this RFP This RFP solicits proposals for a Business System Application Architecture which includes the following: ? Meta-Model extensions to the BOCA for System Business Object types which are necessary and sufficient for specifying an abstract business application. ? An Abstract Framework of these types which can be used as base classes for domain object classes delivered as a run-time library. ? Design patterns and examples for the use of the proposed framework. For further details see Chapter 6 of this document. Table of Contents 1. INTRODUCTION 5 1.1 GOALS OF OMG 6 1.2 ORGANIZATION OF THIS DOCUMENT 6 1.3 REFERENCES 6 2. ARCHITECTURAL CONTEXT 8 2.1 OBJECT MANAGEMENT ARCHITECTURE 8 2.2 CORBA 8 2.3 CORBA/INTEROPERABILITY 9 2.4 CORBASERVICES 9 2.5 CORBAFACILITIES 10 2.6 OBJECT FRAMEWORKS AND DOMAIN INTERFACES 10 3. ADOPTION PROCESS 11 3.1 INTRODUCTION 11 3.2 ROLE OF BOARD OF DIRECTORS 11 3.3 ROLE OF TECHNOLOGY COMMITTEES AND ARCHITECTURE BOARD 11 3.4 ROLE OF TASK FORCES 11 3.4.1 Voter Registration 11 3.4.2 Initial Submissions 11 3.4.3 Evaluation Phase 12 3.4.4 Revised Submissions 12 3.4.5 Selection Vote 12 3.5 GOALS OF THE EVALUATION 12 4. INSTRUCTIONS FOR SUBMITTERS 13 4.1 OMG MEMBERSHIP 13 4.2 SUBMISSION EFFORT 13 4.3 LETTER OF INTENT 13 4.4 BUSINESS COMMITTEE RFP ATTACHMENT 14 4.5 RESPONDING TO RFP ITEMS 15 4.5.1 Separate proposals 15 4.5.2 Complete proposals 16 4.5.3 Additional specifications 16 4.5.4 Alternative approaches 16 4.6 CONFIDENTIAL AND PROPRIETARY INFORMATION 16 4.7 COPYRIGHT WAIVER 16 4.8 PROOF OF CONCEPT 16 4.9 FORMAT OF RFP SUBMISSIONS 17 4.9.1 General 17 4.9.2 Suggested Outline 17 4.10 HOW TO SUBMIT 18 5. GENERAL REQUIREMENTS ON PROPOSALS 20 5.1 MANDATORY REQUIREMENTS 20 5.2 EVALUATION CRITERIA 21 5.2.1 Performance 21 5.2.2 Portability 21 5.2.3 Securability 22 5.2.4 Compliance: Inspectability and Testability 22 6. SPECIFIC REQUIREMENTS ON PROPOSALS 23 6.1 PROBLEM STATEMENT 23 6.2 SCOPE OF PROPOSALS SOUGHT 24 6.2.1 Initial Program Family 25 6.2.2 Concept of Minimalism 25 6.2.3 Impact to the BOF Interoperability Specification 25 6.2.4 Objectives 25 6.2.5 Closure 26 6.2.6 Mobility 26 6.3 QUESTION AND ANSWERS 26 6.4 SUBMISSION EXAMPLE 30 6.4.1 BocaBusinessObjects 33 6.4.2 BocaDependent 35 6.4.3 BocaValueTypes 37 6.5 RELATIONSHIP TO EXISTING OMG SPECIFICATIONS 39 6.6 RELATED DOCUMENTS AND STANDARDS 39 6.7 MANDATORY REQUIREMENTS 39 6.8 OPTIONAL REQUIREMENTS 40 6.9 ISSUES TO BE DISCUSSED 40 6.10 EVALUATION CRITERIA 41 6.11 OTHER INFORMATION UNIQUE TO THIS RFP 41 6.11.1 Additional References 42 6.12 RFP TIMETABLE 42 7. APPENDIX A: HISTORIC PERSPECTIVE 44 7.1.1 Personal Computers 44 7.1.2 Software 45 1. Introduction Measures of success for OMG technology include a count of people who’s future is dependent upon the proliferation of its use, and the capital investment companies make in developing and delivering application software that uses it. According to these measurements, the OMG lags behind competing technologies. However, steps to address this situation are being taken which include: 1. the adoption of a Business Object Component Architecture (BOCA) and delivery of conforming Business Object Facilities, and 2. the definition of UML extensions which surface BOCA concepts, 3. and delivery of conforming training, analysis, design and development tools. A major objective of BOCA is to enable the rapid specification and development of business applications assembled from sharable, medium grained software components obtained from different business units and companies. This RFP seeks to further this work through the definition of a business system application architecture (BSAA) as an extension to the BOCA. The business value for end users are expected to be: 1. improved application development productivity through a) enhanced business system specification tools b) specifying standard ways (patterns) of dealing with standard application design problems c) providing support for these patterns natively in the BOF d) adding a greater selection of representation types for applications over the current BOCA Domain Types 2. improved software inventory re-use through a) a standard classification of medium grained application component types b) a standard set of system responsibilities for component types c) a standard set of interfaces for component types d) a standard set of system behavior for component types e) enhanced CDL for domain behavior specification 1.1 Goals of OMG The Object Management Group (OMG) is the world's largest software consortium with a membership of over 840 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 document@omg.org. Many OMG documents, including this document, are available electronically from OMG’s document server. Send a message containing the single line “help” to server@omg.org 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 responses@omg.org. 2. 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 customization 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 inter-operable 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 implementers 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. 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 Role 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 Role 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 Role 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: 3.4.1 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. 3.4.2 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. 3.4.3 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. 3.4.4 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. 3.4.5 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. Instructions for Submitters 4.1 OMG Membership Submissions to this RFP may only be made by Contributing or Domain Contributing members of the OMG. To submit to an RFP issued by the Platform Technology Committee an organization must be a Contributing member at the date of the submission deadline, while for Domain Technology RFPs the submitter or submitters must be either Contributing or Domain Contributing members. Submitters sometimes choose to name other organizations 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 organizations 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/97-10-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/97-10-01, was approved by the OMG Board in September 1997. __________________________________________ 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 commercial 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 organizations. Pre-product implementations are acceptable. Since use of OMG specifications should not be dependent 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 organizations 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 Unencumbered technology The submitter must certify that it is not aware of any claim that the specification infringes any patent, copyright, or other intellectual property right (collectively referred to in this policy statement as “IPR”). 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 BC that it will make a suitable license available to any implementer to permit development and commercialization of an implementation without violation of such IPR. The submitter shall also certify that this license will be made available on commercially reasonable, non-discriminatory terms. The submitter is responsible for disclosing in detail all known restrictions and fees, placed either by the submitter or 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. Note: Items in this RFP are not considered to be separable. 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 favor 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. 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 extensions 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 (rfp@omg.org) 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/96-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 hard copy 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. In addition, submitters are responsible for making available 100 paper copies to attendees of the TF meeting immediately following a submission deadline. There are normally two such presentation meetings, one for the initial and one for the revised submissions. 5. General Requirements on Proposals 5.1 Mandatory Requirements 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. 2. Proposals shall specify operation behavior, sequencing, and side-effects (if any). 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. 4. Proposals shall clearly distinguish mandatory interfaces and other specification elements that all implementations must support from those that may be optionally supported. 5. Proposals shall reuse existing OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions. 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. 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. 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. 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. 10. Proposals shall preserve maximum implementation flexibility. Implementation descriptions should not be included, however proposals may specify constraints on object behavior that implementations need to take into account over and above those defined by the interface semantics. 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. 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. 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: a) What, if any, are the security sensitive objects that are introduced by the proposal? b) Which accesses to security-sensitive objects must be subject to security policy control? c) Does the proposed service or facility need to be security aware? d) 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. e) What default policies should be applied to the security sensitive objects introduced by the proposal? f) Of what security considerations must the implementers of your proposal be aware? 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. 6. Specific Requirements on Proposals Architecture represents the earliest set of design decisions about a system. These early decisions are the most difficult to get right, are the hardest ones to change, and have the most far-reaching downstream effects. 6.1 Problem Statement Keynotes of the BODTF Common Business Objects and Business Object Facility vision are: ? interoperability of OMG Business Objects as both design-time and run-time constructs including the possibility of ad-hoc integration, and ? simplicity, so that design and implementation, configuration and deployment is viable for the average developer. While the CBO Working Group of the Business Object Domain Task Force is currently soliciting submissions for common business objects, only a minimal application architecture has been provided (the BOF Interoperability Specification) which specifies precisely what a system business object is, what its interfaces should be, or how it should behave as part of a business application solution. This approach leaves the consumer of these CBOs to with no option but to attempt to construct an application on a piecemeal basis, without an overall architecture. Specifically, the problems presented by the absence of this architecture are: ? an explosion of the number of interfaces one has to research in order to assemble a business application from an inventory of arbitrary component types, ? inventories of components that contain undiscovered voids and overlaps in responsibilities compounding reuse costs, ? increased design effort involved in the software developer’s understanding how assemble these components into business applications that work, ? undefined and ambiguous inter-operability between component types, ? a lack of effective abstractions that results in excessive system complexity, fragile, untested, unscalable and problematic application models, ? an inability to extend analysis and design tools to surface component types, an abstract application architecture and design patterns, thus constraining A&D productivity and artifact re-use, These problems result in component re-use costs that exceed the cost of development from scratch. This RFP solicits an Business System Application Architecture to address these problems. 6.2 Scope of Proposals Sought A reasonable definition of software architecture was adopted by David Garlan and Dewayne Perry for their guest editorial in the April 1995 IEEE Transactions on Software Engineering devoted to software architecture: The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. The bottom line is that software architecture is about structural properties of a system. Structural properties can be expressed in terms of components, interrelationships, principles and guidelines about their use. In this document the term application architecture is defined as a structural system of object types, interfaces, responsibilities, interactions, examples and design patterns which define how these types can (and should) be assembled to create business transactions and workflows. A long series of practical experiences working with systems in several highly populated domains, such as compilers has lead to practical advances in the understanding of software architectures. Throughout the 1970s and 1980s, compiler design evolved from a series of distinct efforts, each one innovative and unprecedented, into one with standard, codified pieces and interactions. Today, text-books about how to build a compiler abound, and the domain has matured to the point where no one today would think for a moment of building a compiler from scratch, without re-using and exploiting the codified experience of the hundreds of prior examples. What exactly is reused and exploited? Those structural necessities that are common to all compilers. Compiler writers can talk meaningfully with each other about lexical scanners, parsers, syntax trees, attribute grammars, target code generators, optimizers, and call graphs even though the languages being compiled may look nothing at all alike. So, for instance, two compilers may have completely different parsers, but what is common is that both compilers have a component called a parser, which performs a function in both that (when viewed under at a high level) is exactly the same. Reusing the structural decisions and componentry for a system also allows reusing its work breakdown structures, estimates, team organization, test plans, integration plans, documentation, and many other labor-intensive assets. Many other domains now exist that, through practice and repetition and sharing among the many early members of the family, now exhibit common structure, inter-connection strategies, allocation of functionality to components, component interfaces, and an overall justifying rationale. The current study of software architecture can be viewed as an ex post facto effort to provide a structured storehouse for this type of reusable high level family-wide design information. Work in software architecture can be seen as attempting to codify the structural commonality among members of a program family, so that the high-level design decisions inherent in each member of a program family need not be re-invented, re-validated, and re-described. 6.2.1 Initial Program Family In order to limit the field of study to a manageable level, this RFP is limited to defining an application framework that can be used to construct a “traditional business system transaction” like Order Entry. This set of business applications is understood well enough to be abstracted. Future RFPs can be expected to build on this foundation and expand the scope to more exotic business application categories. 6.2.2 Concept of Minimalism The concept of minimalism does not apply to submissions to this RFP. The current BOCA contains a minimal set of component types as defined in section 2.2.2.4 Domain Meta- Types. The objective of this RFP is to arrive at a larger set of business application meta types that are general enough to provide the flexibility to construct a spectrum of typical business transactions and workflows, but are also sufficiently constrained in behavior to provide a firm structure and foundation for design patterns. Just as there was no “right” answer for how many component types should be defined for the construction of a PC, there is no right answer here. An arbitrary balance must be struck between to few types with too broad responsibilities, and too many types presenting the consumer with too many design decisions. 6.2.3 Impact to the BOF Interoperability Specification It is anticipated that adoptions which extend the BOCA in this way will cascade into RFP’s to extend the BOF Interoperability Specification. Rather than attempting to perform this in parallel, a preferred approach is to standardize changes to the BOCA first, then using that as a firm foundation for requesting changes to the Interoperability specification. 6.2.4 Objectives Given an inventory of reusable components, this architecture will: ? tightly constrain the number of interfaces one has to research in order to assemble a business transaction or workflow. ? eliminate voids in responsibilities between types. ? eliminate overlaps in responsibilities between types. ? eliminate the guesswork involved in the software developer’s understanding how the system works, and ? clarify and comprehensively define inter-operability between component types. ? provide a set of effective abstractions that results in the construction of minimally complex, durable, proven, and scalable application models, ? provide a foundation for the extension of analysis and design tools to surface component types, an abstract application architecture, and design patterns. 6.2.5 Closure The application architecture must be closed. All component interfaces must also be defined in terms of the defined component types, thus making both the types and their interfaces medium grained. 6.2.6 Mobility This application framework must provide for business transactions and workflows to operate as mobile agents. 6.3 Question and Answers * What is it you expect to receive in response to this document, exactly? Microsoft OLE is probably the best known and most successful application architectures today. It is targeted at the “electronic paper” family of applications and consists of a set of horizontal interfaces for desktop interoperability based upon the Component Object Model (COM). This RFP asks for such a framework for the “traditional business transaction” family of applications. The deliverable product is ? An Abstract Framework of these types which can be used as base classes for domain object classes. This abstract framework is a real run-time product. It contains both real and virtual methods for its classes. Real methods are provided, along with class and instance variables to provide the infrastructure necessary to assemble applications according to the patterns. For example, if there is a component called an Entity and entity types are a container for a list of “attributes”, then the abstract Entity type would provide a list for these attributes. Further, it would provide methods for assignment and equivalence of entity instances. Further, if there is a component type called a “Form” or an “Interface” and that type also is a container for “attributes”, then the abstract framework could provide methods for copying attribute state from Form to Form, Form to Entity, Entity to Form, etc. * Do you have some response in mind yourself? Over the past decade, we have developed such a framework, patterns, etc. In the early 90’s we worked with IBM Rochester to transfer this knowledge, at least partially resulting in the San Francisco project several years later. * Do you have any other likely respondents? IBM’s San Francisco project contains such a framework. EDS and Data Access are also interested in responding. * Who else do you think will do so? Companies that do not provide a BOF could also submit a product which plugs into any of the BOFs being developed. One does not need to be a BOF builder to respond to this. * Are you asking for any and all domain models built on BOCA? I believe that OMG Domain standards should be specified in CDL. The new types resulting from this RFP will add keywords to CDL which will make the specification even richer. Individual domains may choose to require CDL or not as a general practice or on an RFP by RFP basis. * Or are you simply asking for some standard architectural patterns to be used in modeling any BOCA based domain systems? It would be highly beneficial for future CBO’s to be specified in CDL as extended by the results of this RFP. * Are you actually asking for a Domain Reference model of the Business Administration domain (it sounded like that at one point)? Or some other reasonably well-bounded domain? This RFP asks for BOCA extensions and a run time framework. It does not request any Domain model. The RFP is narrowly scoped, just like the compiler example, to the “family” of traditional online business transactions. This narrow scope is proposed because it is a well understood category of business applications which we should be able to create design patterns and an architecture for. * Or are you asking for simply any collection of CBOs people want to present as a group? No. This RFP is asking for an application architecture. It is free of any domain content and only presumes the “traditional online business transaction” family. It is not a set of CBOs, but an architecture that provides structure for their definition. * Does the scope of this cover RFP cover all potential CBOs? Once adopted, its impact on RFP submissions would only be through CDL. * What sort of form do the responses take? This RFP solicits proposals for a Business System Application Architecture which includes the following: ? Meta-Model extensions to the BOCA for System Business Object types which are necessary and sufficient for specifying an abstract business application. ? An Abstract Framework of these types which can be used as base classes for domain object classes delivered as a run-time library. ? Design patterns and examples for the use of the proposed framework. * What would actually be delivered to OMG? Submissions must include: ? definition of new types in MODL as necessary ? a UML model of the architecture as necessary ? an IDL and CDL specification of the framework * What would the submitters promise to offer commercially? The run-time framework that complies with the BOCA. I would say that I am having trouble understanding what you want and exactly what you hope to gain by it. Nothing less than COTS components. Why ask for both a Meta-Model and an Abstract Framework? How should a submitter choose between the two? The BOCA currently has both a Domain meta-model and abstract framework. The meta- model defines the types, and the abstract framework creates abstract (only some methods are pure virtual) instances of the types plus all the infrastructure. When a business type is defined in CDL, it can thus be generated as a subclass of the abstract type, and inherit all the infrastructure provided by the abstract framework. It seems to me that the CBO WG is still working out some basis for an abstract framework. For example, how does the same conceptual object map into system business objects in multiple domains-- the "object slicing" discussion that we had at one CBO meeting in SLC. I think we have reached the understanding that business object modeling is only "elastically" coupled with business system object modeling. While the application architecture should attempt to make the transition from business modeling to system modeling as straight forward as possible, for the foreseeable future it will be an engineering effort. I agree that overlaps and voids in components responsibilities is a problem, but I don't know how either meta-model extensions or an abstract framework would address it. Think about OLE. It provides a framework that precisely defines how paper components inter-operate. We can the same thing with business applications. If we say, a business application is composed of these components, this is the responsibilities of each type, this is how they can be containerized, and this is how they interact with each other as types, then I can develop an "algorithm" that you completely understand HOW to use and plug into your "process". All you have to discover is what its business behavior of the algorithm is (from the CDL). I believe this is the biggest benefit of what I believe you are proposing -- extensions to the Domain meta-model like algorithm, form, etc. with support in the BOF could greatly simplify development by generating standard ways (patterns) of dealing with standard problems, while simultaneously adding a greater selection of representation types for applications. Yes. This is the objective. How does this affect A&D tools-- I'd assume there would be a mapping from UML to the BOCA extensions. Think about how integrated circuit designers work today. Their CAD/CAM tools understand the responsibilities, interfaces, constraints, etc. of each standard IC type on the pallet. The engineer just drags and drops types onto the canvas. If the design is wrong, the tool can tell the engineer that he/she has "logic" error in the design. Without this application architecture and its rules, the tool would not have this capability. But since each business system object is of a standardized type, then it can become very smart and helpful. Once a standard set of types are defined, along with their legal interactions, containerization, etc. then the tool can become much smarter. For example, if one attempted to design an application with a "workflow" within an "algorithm" then it could tell the engineer that was not legal. It could expose things like a copy of a certain form to a certain entity did not make sense because they did not share any common attributes... etc. I don't see how voids and overlaps between types can be eliminated by either meta-model extensions or an abstract framework. The Application Architecture eliminates voids and overlaps in system responsibilities. You are right that it can not do this for business responsibilities. For example, a form is responsible for all interfaces to external communications technology. Business forms must not interact directly with persistent storage. Entity types are responsible for persistent state. Thus a CBO could not be proposed that combined both sets of responsibilities into one business type. Also, a CBO could not be proposed that only supported part of the functionality that a "form" or an "entity" type should provide. I'm not much of a fan of this "mobility" requirement. In my environment, I need to exert control over where business transactions occur-- maybe not where they are initiated from, but definitely where they occur. I really like Fred's Business System Domain concepts which are very restrictive in terms of mobility (and in my opinion, need to be that way). Ultimately we need to minimize the physical distance between logic and the resources it needs to interact with to complete some part of a task. To date we have been good at getting word processor applications close to both its files and the user. However, as we all know, this is not a good design for business systems that must share data among users. The first component type to make mobile is a form. A form created anywhere should be able to move itself close to the operator. The next item is a process which should be able to move itself close to either its data or its operator depending upon which set of interactions are most frequent. Then there are transactions and work- flows. While hesitant to embrace this concept because it is new, it is rapidly becoming essential to managing overall system performance. 6.4 Submission Example Below is a copy of the BOCA Business Type model which is required by this RFP to contain the base types for submissions. The following are a set of diagrams that are provided as an indication of one part of the kind of responses this RFP seeks. It is grossly incomplete but is included here to provide a more concrete example of the what submissions might look like. It was constructed from a combination of the work done by various participants in the OMG, submitters of responses to BODTF RFPs and work done at HBO & Company. 6.4.1 BocaBusinessObjects The BOCA Business Object is the super type for all objects with identity that directly represent business concepts. Subtypes of business object include: entity, process and subsystem. 6.4.1.1 BOCAENTITY A BocaEntity represents a identifiable business concept such as a person, place or thing, or activity (recording information about the activity itself). 6.4.1.2 BOCAWORKFLOW A BocaWorkflow is responsible for completing a directed graph of BocaTransactions. It encapsulates business logic regarding node transitions where each node represents the receipt of one or more BocaEvents. BocaTransactions and BocaSubroutines are responsible for creating BocaEvents with sufficient business information to support these nodes. (The modeler is responsible for assuring that these BocaEvents are defined.) Note: The nodes themselves are probably a CBO component type and need to be defined here. This would make them re-usable across BocaWorkflows and enable BocaWorkflows to be implemented across business system domains by obtaining incorporating nodes from other domains. The Workflow class has read-only access to the state of other identifiable CBO components within the business system domain. It can use BocaRules components to test for the existence of specific business system domain sub-spaces. The Workflow class also uses a trader service to interact with one or more business resource allocation services. It uses this trader service to determine the availability of resources to which transactions can be assigned. This, in combination with state information, is used to make node transition decisions. Instances of BocaWorkflows are agents. They can be mobile agents, moving themselves across business system domains to accomplish their goal. 6.4.1.3 BOCATRANSACTION A BocaTransaction represents domain logic and is solely responsible for the ACID properties of the unit of work (completing or rolling it back). BocaTransactions can contain any other component type except BocaWorkflows and BocaTransactions. The following design pattern may be adopted: Verbose BocaTransactions (those that require interaction with people) manage state transactions between BocaSubroutines to accomplish the unit of work. BocaSubroutines manage transitions between states of user dialog. This principal encourages the development and reuse of user dialog logic. 6.4.1.4 BOCABUSINESSEVENT BocaEvents provide the mechanism for BocaTransactions and BocaSubroutines to asynchronously communicate business information to other BocaWorkflows, BocaTransactions and BocaSubroutines. The provider of information is known as the publisher. Consumers of that information are known as subscribers. Events are committed to persistent storage when the unit of work is committed. If the commit fails, or the unit of work is rolled-back, the event will not be persisted. BocaEvents are constrained to only contain attributes and only have constructors (no methods, states or relations). This capability is useful to: ? maintain the integrity of a BocaTransaction’s responsibilities by isolating side-effect logic to subscribers, ? maintain BocaTransaction performance by having side-effect logic run asynchronously to the BocaTransaction, and ? assure communication between CBO components has well defined business meaning. 6.4.1.5 BOCARULE BocaRules regulate state changes in CBO component types. BocaRule instances are singletons and are immutable. Preferably, it is both modeled and implemented using a distinct language such as OCL. The language must assume an underlying meta-model such as defined here. The objectives of this component type are: 1. To enable modelers to specify constraints on state changes and domain experts to read and understand them. This reduces the cost of implementing “business rules” and increases the accessibility of this information to those who need to know and change them. 2. To provide a uniform high-level language to specify all state change constraints ranging from “referential integrity” up through application- domain integrity constraints. 3. To isolate state change constraint logic so that it can be managed independently of business process mechanization and algorithmic logic. This enables the enterprise to inventory its domain integrity constraints and manage them as an asset outside of the “procedural code”. It enables the enterprise to uniformly apply and rapidly change its integrity rules as its environment changes. Through unification, state change constraints can rationalized to insure a consistent enterprise operation. 4. To facilitate update sharing of distributed objects across political boundaries. Conflicting rules can be more easily identified and potentially resolved by the sharing parties. State changes can be enforced by the system through the union of the constraint rules imposed by the sharing parties. This language is purposefully restricted to regulating state changes. This restriction isolates the scope of its application and eliminates the possibility of side effects.. The language can not be used to cause state changes to occur. If it did so, it could and would be used as a programming language which would defeat its primary objectives. The language must contain the ability to define and test for the existence of a specific business system domain sub-space based upon the state of identifiable business component instances. The language must be closed in that it must be able to test for the existence of sub-spaces of instances within sub-spaces. 6.4.1.6 BOCAVALUETYPE BocaValueTypes encapsulate business value type information and operations. BocaValueTypes represent primitive immutable business value types such text, weight, length, currency, time, durations, etc. They handle arithmetic and relational operations, value type validation and rendering operations. Measurement subclasses provide unit of measure conversions. All BocaValueType instances are singletons and are immutable. They do not encapsulate state. 6.4.1.7 BOCASYSTEMSERVICE Some business logic does not participate in changing the state of the business system domain object space. It provides a service to other business components. Nor is it purely technology logic. An example in the Healthcare industry is the “Patient Identification Service”. The Calendar service CBO is another. This service employs sophisticated technology to a subset of people demographic information to identify probable matches between entered characteristics and characteristics on file. I call this type of business component a BocaSystemService. It is identifiable but is not a transaction. It operates outside the scope of any logical unit of work. 6.4.2 BocaDependent Unidentifiable components represent business concepts that are part of identified components. They must be contained within (directly or indirectly) an identifiable component. They do not have their own persistent lifetime independent of their container. 6.4.2.1 BOCAALGORITHM BocaAlgorithms encapsulate calculations. The following behaviors define an algorithm: 1. BocaAlgorithms perform calculations and return results. 2. BocaAlgorithms do not maintain state. Each time the run method is called, the algorithm is in state 0. 3. BocaAlgorithms do not communicate with the outside world. They are always mute. 6.4.2.2 BOCASUBROUTINE A BocaSubroutine represents re-usable domain logic that is part of a BocaTransaction. A BocaSubroutine is instanciated within a BocaTransaction or another BocaSubroutine. BocaSubroutine may contain any other component type except BocaTransactions and BocaWorkflows. A BocaSubroutine component is unidentifiable, reusable within Business transactions, does not have responsibility for commit / rollback (thus is reusable), and is generally either mute or enters into conversations with people to accomplish some set of domain logic. BocaSubroutines are considered superior to creating methods on BocaEntities and BocaRoles for modeling domain behavior for the following reasons: ? Properties BocaSubroutines have properties as defined by their type. Component properties provide some of the “glue” that enables component integration. Also, method names cannot be used as property values in other component types. ? Visible state BocaSubroutines may have visible states that can be queried and modified as the BocaSubroutine continues, thus supporting BusienssWorkflow and BocaTransaction status checking. ? Relationships BocaSubroutines may have well-defined relationships to other components, including other BocaSubroutines. ? Supported by Rules State changes in BocaSubroutines may be regulated by BocaRules. ? Concurrent BocaSubroutines may execute concurrently. ? Visible and traceable lifetime 6.4.2.3 BOCAATTRIBUTE BocaAttributes encapsulate values (state). BocaEntities and BocaForms are essentially defined by the list of attributes they contain. There is a relationship between each attribute and the BocaValueType of the value it encapsulates. It delegates validation, arithmatic and relational operations, unit of measure conversions, etc. to this related domain. 6.4.2.4 BOCAFORM BocaForms are responsible for exchanging data with the non-standard CBO Component world. BocaForms can only contain BocaAttributes and BocaForms. Implementations would support ISO Level 7 (application) message protocols. Examples include streaming of data to and from dumb terminals, WWW Browsers, and other applications through industry EDI protocols. 6.4.3 BocaValueTypes All business value types are singletons. A set of common types should be defined at the top of the hierarchy from which specific business types may be properly sub-classed as necessary. 6.5 Relationship to Existing OMG Specifications 1. Once adopted as an OMG standard, it is expected that CBOs will be specified as BSAA types. Operations on CBOs are to be completely defined by BSAA types. No additional public interfaces would be supported for any CBO. 2. BSAA types must be subclasses of BOCA types or request modifications or additions to BOCA types. New or modified types must be expressed in MODL?? 3. The BSAA types must be specified in CORBA IDL, UML, and CDL 4. The BSAA must provide scenarios, examples and design patterns. 5. The BSAA provide scenarios, examples and design patterns for the creation of transactions and workflows operating as mobile agents and must support or request modifications to the Mobile Agent Facility as necessary. 6. The BSAA must provide scenarios, examples and design patterns for state based security decisions and support or request modifications to the CORBA Security Architecture as necessary. 6.6 Related Documents and Standards List documents, URLs, standards, etc. that are relevant to the problem and the proposals being sought. ? CORBA 2.1 ? Mobile Agent System Interoperabilty Facilities Specification ? Portable Object Adapter (POA) ? CORBA Security ? BOCA ? Meta Object Facility ? UML 6.7 Mandatory Requirements Items in this RFP are not considered separable. Submissions must represent one unified, application architecture. 1. In this document the term application architecture is defined as a system of object types, interfaces, responsibilities, interactions, examples and design patterns which define how these types can (and should) be put together to create business transactions and workflows. Submissions must include: a) Extensions to the BOCA Domain Meta-Model for System Business Object types which are necessary and sufficient for specifying an abstract business application for the traditional online business transaction application family. b) An Abstract Framework of these types which can be used as base classes for domain object classes. c) Design patterns and examples for the use of the proposed framework. 2. For each type, the architecture must define: a) type names, b) interfaces, c) responsibilities, behaviors and interactions, and d) provide design patterns for creating business transactions and workflows from them. “Design patterns are the most effective form of software guidance available. They offer a concise, efficient way to convey expert software concepts, particularly architectural concepts. Design patterns also provide a terminology that can help practitioners become more effective and sophisticated in developing systems.” 3. It is essential that error handling be part of an object oriented architecture, as applications cannot be relied upon to provide adequate information about their state in the event of an application failure. 4. BSAA interfaces must be defined in terms of BSAA types, not object or IDL type based, thus making both the components and their interfaces medium grained. 5. Components must be reflective and introspective thus enabling the seamless exchange of BSAA types as well as BSAA instances. 6. All BSAA types must be extensions of the BOCA domain types. 7. textual descriptions of type responsibilities and intended use, 8. scenarios illuminating how types interact and their potential uses, 9. scenarios illuminating how BSAA types become and act as mobile agents. 1. 6.8 Optional Requirements None. 6.9 Issues to be Discussed 1. Packaging a) How will the product be packaged and distributed. 2. Change Management a) How will changes to the architecture be managed without impacting applications developed to earlier versions. 3. ??? 6.10 Evaluation Criteria An architecture comprises the set of rules, guidelines, interfaces, and conventions used to define how applications communicate and inter-operate with one another. Inter-operability is all about how multiple software modules collaborate to provide functionality. The overall goal is to provide a maintainable, scalable, reliable environment where application components can inter-operate and be responsive to the needs of users throughout the evolution of the system. A good architecture deals with several other key areas of concern, including reducing costs, managing performance, providing flexibility in component implementation, minimizing independence between modules, and providing for vendor and product independence to enable technological migration of software components. Furthermore, such architectures are seldom, if ever, born overnight. Rather, good architectures take a great deal of time and a significant amount of prototyping experience to mature. A good architecture provides useful abstractions which lead to simpler interfaces, uniform architectures, and improved object models. It is important to note that the quality of the abstraction dictates the reusability of the software component. It is the lack of effective abstractions that results in excessive system complexity. Developing abstractions that simplify individual interfaces provides cost savings across the system design. The flow of control is an essential consideration of the object oriented architecture as it can prevent common problems in the final system, such as bottlenecks and lack of system extensibility. Some knowledge of the expected usage patterns of the system must be factored into the architectural design. This can be accomplished by identifying potential hot spots of activity and providing the flexibility for implementation and run-time flexibility. It is essential that error handling be part of an object oriented architecture, as applications cannot be relied upon to provide adequate information about their state in the event of an application failure. Architectures are seldom, if ever, born overnight. Rather, good architectures take a great deal of time and a significant amount of prototyping experience to mature. The demonstrated maturity of a submission is essential to a positive evaluation. 6.11 Other information unique to this RFP ? While submissions may include additional specifications for items not covered by the RFP which they believe to be necessary and integral to their proposal, these items must be specifically germane to the delivery of an application framework meeting the stated requirements. ? Items in this RFP are not considered to be separable. Submissions which partially address these requirements will be considered incomplete. ? Submitters may provide alternative RFP item definitions, categorizations, and groupings so long as the rationale for doing so is clearly stated and do not contradict a stated requirement. 6.11.1 Additional References ? CORBA Design Patterns, Thomas J. Mowbray, Raphael C. Malveau, John Wiley & Sons, Inc. 1997, ISBN 0-471-15882-8 ? Pattern Oriented Software Architecture: A System of Patterns, Buschmann, Meunier, Sommerlad, Stal, John Wiley & Sons, Inc. 1996 ? Technical Report CMU/SEI-96-TR-025 ESC-TR-96-025 Recommended Best Industrial Practice for Software Architecture Evaluation, Gregory Abowd, Georgia Institute of Technology; Len Bass, SEI Paul Clements, SEI; Rick Kazman, SEI; Linda Northrop, SEI; Amy Zaremski, SEI January 13, 1997 ? Technical Report CMU/SEI-96-TR-003 ESC-TR-96-003 Software Architecture: An Executive Overview Paul C. Clements, Linda M. Northrop February 1996 6.12 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 60 LOI to submit to RFP due January , 120 Initial submissions due January , 134 Voter registration closes January , 141 Initial submission presentations January , Preliminary evaluation by TF 240 Revised submissions due January , 261 Revised submission presentations January , 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 360 BOD votes to adopt specifications 7. Appendix A: Historic Perspective The electronics industry was the dominant industry from 1970 to early 1990’s. The Audio / Video segment dominated until 1990’s and evolved from the delivery of integrated systems to the delivery of large grained, plug compatible components. The industry changed because it could deliver new technology at a rate that exceeded the market’s capacity to acquire it in integrated system chunks. Customers could not afford replace entire integrated systems every year just because amplifier technology improved, or someone invented cassette tape recorders or CD players. If this problem could be solved, the industry could generate significantly more revenue by delivering new technologies which made existing ones obsolete. The industry had to increase the granularity of its deliverables. It formed international standards organizations and standardized on the names, responsibilities, and interfaces of these large grained components. The interface standards were defined by plug, wire, and electrical specifications. While this increased competitive pressures on manufacturers by forcing them to specialize on a few component types, it expanded the overall market considerably. Each vendor gained a smaller piece of a much larger pie. 7.1.1 Personal Computers Personal computers became the dominant segment of the electronics industry in the late 1980’s and early 1990’s. The rate of technology change was even greater than that experienced by the Audio / Video industry. New technologies were being invented and delivered every day. Also, the complexity of the interactions between components was considerably higher than for A/V components. The personal computer segment learned from the A/V segment and took component based development and delivery to a new level. It had to. The complexity and variety of components and the complexity of the interactions between components was considerably higher than for A/V components. Wire level interfacing would not be sufficient to keep pace with the rate and types of new technology and their interactions. I frequently tell the story of Susan and Larry. They both want to assemble a computer in their garage. Susan picks up a copy of Computer Shopper and orders a chassis, mother board, disk controller card, memory SIMMs, Video Driver card, Monitor, etc. She has a Pentium 266 up and running within 4 hours of the components arriving at her door. Larry lives in another world where each manufacture has a different opinion about what LSI components should be placed together on a specific circuit card. One manufacturer thinks that the serial port belongs as part of the video driver since video monitors are logically the same as serial ASCII displays. Another feels that memory should be placed on the same circuit as the disk controller logic since data needs to be moved between disk and RAM rapidly. To compound the problem, each has chosen a different bus design for how the cards plug together. Needless to say, Larry is not very successful. He must study a very large number of designs at a detailed engineering level to understand whether component A will work with component B and provide all the functionality needed. Larry needs to be an engineer. He will spend a considerable about of time figuring it all out, and will end up using a soldering gun, resistors, capacitors, etc. to make it all work. In fact, Larry will not be able to assemble even a calculator for the same cost and in the same time as Susan assembled her Pentium 333. Object Technology is to computer software as LSI (chip) technology is to computer hardware. It is necessary for the rapid delivery of new solutions, but is not sufficient. Until IBM came along, there was no standard definitions for personal computer components. There were only wire and electrical standards for large grained component interfacing. There were several competing designs. Each manufacturer had its own idea of how to group PC functionality into chips and onto circuit boards. There was also several competing bus designs for how components were to be plugged together. It was just like the early days of the Automobile industry. IBM’s success created a defacto definition for the componentization of personal computers and the early interfaces between these components. It standardized their names, their responsibilities, and their interfaces. Gradually, third party manufactures saw an opportunity to sell components into the IBM market. Gradually, a market emerged that was comfortable with taking the cover off of their PC and plugging non-IBM components into it. This evolved into the commodity market we have today for inexpensive, component based personal computers. Note: This phenomenon has not occurred in any other market I have experience with. If you want to assemble a TV for example, you can not buy a chassis and set of cards and put it together. The key ingredients for the computer industry was industry wide standardization of generic medium grained component names, responsibilities, behavior, and interfaces. 7.1.2 Software Software is the dominant manufacturing industry today. Unfortunately it uses a cottage industry production model and the A/V component model. We have not learned from and extended the work that proceeded us. However, we have recognized that the development (notice that we do not yet use the word “manufacturing”) and delivery and ownership cost structure of software is grossly inadequate to keep up with demand for new software solutions. While PC hardware technology has consistently sustained an annual doubling of productivity and performance gains, similar significant productivity gains in software have not materialized. The software industry needs to capitalize on the proven concepts of specialized, application-independent, encapsulated, units of functionality - components. What is our deliverable? If it is sufficient to deliver large grained application systems which have relatively simple, low volume interactions, then all we need is a message based infrastructure analogous to the wires used in the A/V electronics industry segment. The Healthcare Software Industry has already gone down this road with HL/7 version 2 (as have many others with their industry specific EDI protocols) and have found that it is no longer sufficient to meet today’s challenges. Today’s pressures demand the delivery of medium grained components that have a high degree of complex interactions. We now recognize the need to deliver medium grained components that inter-operate with each other in high performance, complex ways. Business System Application Architecture RFP RFP