New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
Course Title: Application Servers Course
Number: g22.3033-011
Instructor: Jean-Claude Franchitti Session: 12
This document focuses on XML and application modeling. Most of the suggested approaches in this document are applicable to various programming or scripting languages for which XML tools are available. Examples of such languages are Java, C++, and Perl.
Application modeling technology has evolved over the years until the most prominently used methodologies in the industry merged into a single standard known as the Unified Modeling Language (UML). UML is the result of combined work by three modeling experts referred to as the “three amigos” (i.e., Grady Booch, Ivar Jacobson, and Jim Rumbaugh). UML standardizes modeling language and notation, not a particular method. UML has been adopted as an industry standard modeling language by the OMG. UML provides a set of notations to capture the representation of various application model views. As you will discover throughout the session, the XML family of technologies complements UML and provides a portable representation of application models that brings us a step forward towards model-based computing.
The latest XML technologies that relate to application modeling include the XML Metadata Interchange (XMI), which brings together XML, OMG’s Meta Object Facility (MOF), and UML. XMI provides a portable representation of application models that supports the interchange of modeling data between modeling tools. More than focusing on the relationship between XML and modern modeling approaches and technologies such as UML, this session also presents the relationship between XML and model-based computing. As modeling technologies becomes more and more powerful and able to capture represent a broad spectrum of application design aspects, the automated generation of complete application based on models is becoming possible. While traditional modeling technology did not capture implementation detail, and did not specify interoperability semantics, and information interchange formats, modern modeling technology based on XML strives to provide complete application definitions that include operational semantics, constraints, and information exchange formats. It is now clear that XML will play an important role in the next generation of Model Based Architectures (MDAs), which are currently championed via the OMG.
In a nutshell, this document covers the following subtopics:
·
Understand
the "web object model" and its associated "binding" to Java
·
Understand
SOAP
·
Understand
UML based component modeling and related XML standards
·
Survey
XML "model-based" computing applications
The first sub-topic presents the “web object model” vision as set forth in 1998 by OBJS, Inc. This vision should be compared to the current vision of web application architectures, including J2EE, CORBA 3, and Web Services. The (dated) vision should also be aligned with OMG’s Model Driven Architecture approach. An example of a SOAP application is briefly presented as part of the first sub-topic. The second sub-topic focuses on UML-based component modeling, and its relationship to XML standards. The section starts with a detailed practical overview of UML-based component modeling, and focuses on the most recent XML technologies used to support UML modeling. The last sub-topic takes a deep look at XML as a vehicle for supporting model-based computing applications, and upcoming generations of application server technologies that will be based on OMG’s MDA.
Sub-Topic 1 –
The Web Object Model
Sub-Topic 1.1 – Web Object Model
Overview
Students should refer to the paper by Frank Manola (OBJS, Inc.) at http://www.objs.com/OSA/wom.htm. The paper is a snapshot of a “web object model” vision that goes back to 1998. At that time, it was already established that what was needed to progress towards a “Web Object Model” was:
·
A
representation language richer than HTML that could better represent “object
state”. That new language was to tackle such aspects as the semantic
identification of fields, and was to go beyond data presentation capabilities
·
An
API that would enable access to object state, so that programs could readily
access it
·
The
ability to relate object state to pieces of code that would serve as object
methods
The paper does a very good job at presenting
examples that contribute ideas and technology toward providing the components
of a Web object model compatible with the above observations. By analyzing the
principles underlying the various ideas and technology, the paper actually
suggested a first step towards a framework that would extend web applications
to encompass the various requirements set forth earlier. You will find that the
vision presented is not far from where we are today with modern application
server technologies, XML, and Web Services.
Sub-Topic 1.2 – A Soap Example
The example below is an excerpt of the SOAP tutorial
available at http://www.w3schools.com/soap.
The example demonstrates the SOAP specification of a simple GetStockPrice
request that is being sent to a server. The request has a StockName parameter,
and a StockPrice is returned in the response. The SOAP Envelope element is the
top element of the XML document representing the SOAP message. The namespace
for the functions (m) is defined at an example (http://www.stock.org) address.
The SOAP request embedded in an HTTP Request is as
follows:
<SOAP-ENV:Envelope> <SOAP-ENV:Body> <xmlns:m="http://www.stock.org/stock" /> <m:GetStockPrice> <StockName>IBM</StockName> </m:GetStockPrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> |
The SOAP response embedded
in an HTTP Response is as follows:
<SOAP-ENV:Envelope> <SOAP-ENV:Body> <xmlns:m="http://www.stock.org/stock" /> <m:GetStockPriceResponse> <Price>34.5</Price> </m:GetStockPriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> |
For detailed practical
examples of Web Services technologies involving WSDL, UDDI, and SOAP, students
are referred to the August/September 2001 issue of XML Magazine (http://www.xmlmag.com).
Sub-Topic 2 – XML and UML Based Component Modeling
Sub-Topic 2.1 – Business
Architecture Modeling
Business architecture modeling helps extract the overall business model of an organization, which includes the set of underlying processes necessary to operate the various functions of the organization. The business model includes the organization, location and process model as described below.
The organization model provides role definitions and a process/role matrix. Role Definitions are groups of functional capabilities, which must be present in a single person in order for that person to carry out one or more specific business processes. A single person may perform more than one role. The process/role matrix indicates the business roles responsible for executing specific business processes. It is usually built at the Elementary Business Process (EBP) level but may also be completed at higher levels if useful.
1. Clients: Existing
institutional customers presently managed by a salesperson. Clients have full
trading privileges only in the instruments for which they are authorized.
2. Salespeople
and Sales/Traders: Salespeople report to the sales
desk manager. Salespeople are responsible for managing client’s needs with
regard to a particular product / products or asset class. Salespeople and sales
trading desks have trading privileges on behalf of a subset of clients, e.g.
the clients covered by a particular sales person or that sales person’s
group. They interact with the various
trading desks on behalf of clients in order to:
- Obtain quote requests
- Enter orders
- Discuss market commentaries
- Help resolve issues (trade detail inquiries)
- Change status of client orders
Salespeople
also help customers understand research and suggest trade ideas.
3. Execution
Desk (Traders): Traders report to a trading
desk manager. Traders are responsible for making markets in a particular
product / products, within an asset class. They also manage the risk associated
with a particular trading book/s. Traders are a special type of client
(internal clients). Like clients, they
have full trading privileges only in the instruments for which they are authorized.
Some trading responsibilities include:
- Provide prices being published to clients
- Provide pricing for quote requests
- Approve / reject / counter-offer orders
sent to the trading desk by clients
- Determine axis to be offered to clients
- Offer a market commentary
4. Support –
Back-Office Operations: Often referred to as
“back-office personnel, support people ensure the timely processing, settlement
and delivery of transactions among other things. Support has access to all
windows accessible to clients. They
have no trading privileges but they can modify the status of an order on behalf
of a client. Support people staff the following areas:
- Trades processing
- Settlements
- Margin
- Stock loan
- Sales Support
- Others
Assumption: There may need to be a distinction made
between back-office and front-office personnel’s functionality. Support – Front-Office Operations: Typically work along-side Traders and
Salespeople. They facilitate telephone calls, process trades and resolve
trading and sales/customer issues. Front–Office personnel would consist of:
- Assistant traders
- Assistant salespeople
5. Client
Mid-Office:
These would be the client’s support staff.
6.
Administrators: Administrators do not have
trading privileges. Administrators alone
have access to administrator windows. Administrators would provide the
following support:
- Account set-up
- Account maintenance
- Modify client access
- Modify client trading privileges
7. Client
Administrators: Administrators do not have
trading privileges. Administrators
alone have access to administrator windows. Client administrators can only to
modify account holder privileges, within the limits of that client’s trading
and access privilege.
8. Marketing
Desk:
Provide marketing support to salespeople.
Interact with traders on behalf of regional
salesforce, performing similar functions as a salesperson would. However, they
may have limited client contact.
- Assist in educating the salesforce with regard to
financial products.
- Apprise the salesforce of new issues and other market related information received by the trading
desks and other sources
Assumption:
There exist such a desk performing the above listed duties..
9. Trading
Desk Managers: Supervise traders on
individual trading desks. Responsible for the overall profitability of their
trading desk.
10. Sales Desk
Managers: Supervise salespeople on
individual salesdesks. Responsible for the overall profitability of their sales
desk.
11. Upper
Management: Key managers that oversee
several business units, operations departments and other areas. These would
include:
- Division Managers
- Group Managers
- Risk managers
Assumption: CIO, CFO and CEO level of
management may want certain functionality.
12. Systems
Management: Key technical people responsible
for the daily operation of the
trading system, including:
- Site Manager
- Systems Maintenance Manager
- Content Manager
- Help Desk
- Others
The Conceptual Location Model shows how business processes will be distributed geographically. In the location model, location type definitions identify locations in terms of location type and general geographical area. A process/location matrix is also provided to indicate location types at which each process is performed. This matrix is used at the level of elementary business processes (EBPs). In our sample trading business model the location type definitions could be:
· Boston branch sales office
· Midwest district service center
· London regional distribution center
· New York Headquarters
· Singapore Headquarters
· London Headquarters
· U.S. Sales Offices
· Asian Sales Offices
· European Sales Offices
· Other Sales Offices
· Clients
· Inter-Dealer Broker Locations
· Electronic Communication Networks (ECN’s)
The business process model can be summarized in business process hierarchies. A business process hierarchy is a schematic representation of the results of process decomposition. Decomposition is taken down to the level of the elementary business process (EBP). An EBP is the smallest unit of business activity that:
· is worth examining;
· is performed by or in support of a single user;
· may include both manual and automated activities;
· has user involvement occur at one time;
· preserves important business distinctions between processes;
· leaves the Conceptual Entity Model in a consistent state.
Business process flow can be captured within a process map. Business process maps show the sequence of selected processes from the Process Hierarchies as they relate to the role that performs them.
A
high-level business process hierarchy for our sample trading business model is
given below:
Trading Business Process Hierarchy
EBPs can be further
decomposed in sub-hierarchies as illustrated below in the case of the Enter
Order process of our sample trading business model:
Enter Order Business
Process
EBP definitions contain a brief description of what occurs in each process. The definitions, combined with the relevant process flows, provide the basis to move forward into detailed design and support continued development of functional specifications. They also identify any assumptions made during the creation of the architecture, any rules for manual decisions that need to be made, and cross reference information, where applicable, to match the functional requirements of the application being designed.
The numbering of the EBPs corresponds to the layout on the hierarchies, and is used to cross-reference all of the other work products in the Business, Organization, and Location domains.
In the case of our sample trading business model,
EBP definitions are as follows:
1. Subscribe Prices
1.1 Receive Prices. Receive the updated prices from all pricing
sources. Show the relevant
information required to identify an instrument (e.g. ticker symbol, coupon,
maturity, price, yield for bonds). This needs to be as robust and frequent as
the Reuters update. Manage instruments
(add, change, delete) through backend systems.
1.2 Create Market Windows
1.2.1 Configure Market Windows. Set up screens and layout of windows and
workspace.
2.1.2 Enter Search Criteria. Locate instrument/groups/portfolios for
windows. Will need a request to
publish if user is the first one to request this instrument’s price feed. Check Price Subscription Entitlements.
1.2.2 Select Instrument for Market
Windows. Select and delete
instrument/group/portfolios to be represented on the Market Watch window.
1.2.3 Populate Market Windows. Populate market watch view to show prices to users for their selected instruments. Create market depth view of an instrument. Accessed after selecting an instrument (description) from the market watch window. Allows users to view price sources for a given instrument from multiple sources.
2.0 Process Order
2.1 Quote Request. Look up instrument via search functionality starting at asset class, checking view permissions. Select instrument to move into order/quote request process. Client uses to access price not generally available or not on their Market Watch (in which case, user could just search, add instrument to their Market Watch.
2.1.1 Select Quote Request Function. Select a Request for Quote (RFQ) button, menu item, or Market Watch window.
2.1.2 Enter Search Criteria. Fill in as much info as possible for the search window to narrow the possible options: instrument, group, and portfolio. Selected results may be added to Market Watch. Check entitlements for viewing.
2.1.3 Select Instrument to Populate
Ticket. Check trading entitlements.
Opportunity to go back to search criteria and get another instrument/group/portfolio
to add to ticket.
2.1.4 Review Ticket (RFQ, Order). View pre-populated RFQ or Order Ticket. Default fields are filled in based on Ticket type and asset class.
2.1.5 Enter Additional
Information on Ticket (RFQ, Order).
Enter quantity, and provide capability to override default settlement
and other fields. Enter order types - Fill or Kill, GTC, Day Order. Enter account number. User has option to
enter an order status change such as suspend order. User has option here to
cancel or return to select another instrument (e.g. clicked on wrong market
price or instrument or wants to add more.)
2.1.6 Submit Ticket (RFQ, Order).
Submit RFQ or Order to Trading Desk. If Execution Desk does not respond to RFQ
in 30 seconds.
· Validate ticket and/or entitlement Details – Make sure all relevant information has been entered on the ticket. User can edit and cancel. If info is missing or incorrect, send error message.
· Send ticket. Send acknowledgement to audit trail or user. Order state = ‘waiting’
· Route ticket to specific back-end system – The order will be routed to the appropriate back-end system for the given instrument based on order routing criteria.
· Send acknowledgement – An acknowledgement will be sent once the order has been received by the back-end systems.
2.1.7. Fill RFQ . Trader provides price, and any other required information, such as quantity, settlement for Quote Request and sends back to User.
2.2 Enter Order
2.2.1 Enter Order From Menu. Presumes price is missing and user must populate this in the Order Ticket.
2.2.1.1. Select Enter Order Function. Access menu item.
See EBPs 2.1.2. through 2.1.6.
2.2.2 Enter Order from Market Windows
2.2.2.1 Select
Instrument from Market Watch. Choose the instrument for which an order is to be
entered. This should open the Market
Depth window and display multiple prices, and price sources.
2.2.2.2 Select Price of Instrument. Click on the desired price. If the offer price is selected, a buy order ticket will be displayed. Should the bid price be selected, a sell order ticket will appear.
See EBPs 2.1.4.
through 2.1.6
2.2.3 Respond to filled RFQ
2.2.3.1 Select RFQ. Select from Order queue or from asynchronous pop-up window? Client can retrieve RFQ’s sent to the Execution Desk in order to cancel or modify the order. User has 5 seconds to respond once RFQ is received back with price. If time limit ends up being more than 5 seconds, may want to have Order queue functionality.
See EBP 2.1.4
2.2.3.2 Transform RFQ into Order. Continue order with information received
back from Trading Desk within the specified time limit. If RFQ times out, user
can still resubmit as order, but cannot expect it to be filled at that price.
See EBP 2.1.6
2.3 Execute Trade
2.3.1 Review Client Order Ticket. Trader reviews information on order ticket received from Client. Trader will decide if and how he will fill this order ticket. Order status changes to ‘confirm’ to note that Execution Desk has received it, and order queue reflects this.
2.3.2 Fill Order. Trading Desk person accepts or denies order. This part is manual. To provide process speed, parts of this should be automated based on some criteria (e.g. price limits, quantity limits). If order is approved, update order status (approved) and send return message that order is approved. If order is denied, updates order status (denied) and return message with denial, alternate price and/or quantities (can’t fill). Provide Alternate Price and/or Quantities.
2.3.2.1. Completely Fill Order. The user is notified by the status update of their order on their order queue that their order has been filled.
2.3.2.2 Partially Fill Order. System will send updates to order until completely filled or balance rejected/cancelled. User may change or cancel the unfilled portion of the order.
2.3.3 Confirm Fills. After receiving acknowledgement that order was filled, user will confirm fill.
2.4 Change/Cancel RFQ, Order. Change, Cancel, Change status
(suspend). Depending on instrument
type, user may need to cancel and add and order instead of change. Based on SEC regulations. Change and cancel orders may only be done if
current Order State is ‘pending’.
2.4.1 Select Order from Order Blotter. Status must be pending or partially filled
See EBP 2.2.3.1 and
2.1.4
2.4.2. Cancel
2.4.2.1 Cancel Order. Cancel directly in order blotter or optionally review ticket then cancel from ticket itself.
2.4.2.2 Cancel RFQ
2.4.3 Modify Information on Ticket
(RFQ, Order). Change information on
previously submitted ticket
See EBP 2.1.6
2.5 Process Unfilled Orders
2.5.1 Reject Order. A message will be sent to the user that
their order cannot be filled. User may
change order.
2.5.2 Terminate Order, End of Day. At the end of the business day, users will
be advised that all day orders that have not been filled are considered dead.
Order will have an ‘expired’ status. If the user wishes to re-enter their
order, they may do so, on the next business day.
3.0 Perform Management Functions
3.1 Set up Entitlements & Security
3.1.1 Provide Client Security Access
3.1.2 Determine Entitlements. Based on view and business functions allowed to do, role, asset class , account.
3.1.3 Administer Entitlements. Set up user on system, which drives their views and allows them to perform functions.
3.2 Provide Management Reporting. Periodic reporting, reconcile trades at end of day.
3.3 Perform Queries. Ad hoc or static on line queries. For trading/sales managers to get an overview of the business being done.
3.4 Manage Content. User news and other ‘push’ information, personalization.
3.5 Manage Site
3.6 Configure User Preferences. Provide user set up functionality to configure content and layout of views such as market watch and depth, Order queue and trade history. Access to data is based on user entitlements.
3.7 Maintain Accounts, Customers and Instruments. Add, change, and delete.
4.0 Maintain Systems
4.1 Perform Backup and Recovery
4.2 Monitor Systems. Monitor routing and workflow, audit trail.
4.3 Do Performance Tuning
4.4 Perform System Administration. Archiving to support deletion of data and maintenance of databases.
4.5 Provide Help Desk. Customer Support such as hot line, problems,
issues, etc.
Process Map Diagrams show the sequence of selected processes from the Process Hierarchies as they relate to the role that performs them. Only significant processes of special business interest appear in the following Process Maps. While any process appearing on a Process Map should also appear on the Business Process Hierarchy, the reverse is not true. Process Flow Diagrams may show:
· Business events that initiate a process
· Business results from completing a process
· Processes
· Process flow, also called process sequence
· Process flow breaks
· Iteration, optionality, and exclusivity
· Supporting comments.
In the case of our sample trading business model, a process map diagram for the Enter Order is as follows:
Sub-Topic 2.2 – Process Design
and Process Decomposition
While process design and decomposition was illustrated in the previous section, this sub-topic focuses on the interrelationship of the Elementary Business Processes to the Derived Logical Processes (DLPs) that link the business processes to a new software application. DLPs are not considered a further decomposition of the Business Process Hierarchy.
An Elementary Business Process is a unit of business activity, executable by one person at one time and in one place. They are depicted as elementary steps/tasks in the Process Hierarchies. The EBP’s that support the user requirements, combined with EBP’s that support the general and system management processes, comprise a majority of the Functional Specifications.
Derived logical processes (DLPs) describe what the computer system will do to automate a business process. DLPs provide shorthand for enumerating required system capabilities. In the Development Phase, specifications will be written to describe the DLP in enough detail for it to be developed.
An EBP/DLP matrix is usually developed concurrently
with the Logical Process Hierarchy to connect the systems to the business by
mapping the derived logical processes to the elementary business processes they
support or automate. One EBP may use several DLPs, and several EBPs may reuse
one DLP. This supports validation
linking from Architecture Phase user requirements to Development Phase
functional specifications and design specifications. A sample EBP/DLP matrix
for our trading business model is shown below:
EBP no. |
EBP name |
DLP name |
Implementation |
1. |
Subscribe Prices |
|
|
1.1 |
Receive Prices |
Add price Change price |
|
1.2 |
Create Market Windows |
|
|
1.2.1 |
Configure Market Windows |
Add Workspace Change Workspace Delete Workspace Save Workspace Add Window Change Window Delete Window Save Window? |
|
2.1.3 |
Enter Search Criteria |
Find instrument Check entitlements |
|
1.2.2 |
Select Instruments for Market Windows |
Add price subscription Delete price subscription Find price Find User Preferences |
|
Sub-Topic 2.3 – Business Model
Execution Engines
The ideal software development environment would be one where the business model could be provided as an input to a “business model execution engine” that would take care of converting the business model into an executable software application. In that process, the execution engine would select the best combination of frameworks and reusable components based on the requirements set forth by the business model. The environment could also provide business model engineering tools that would semi-automate the process of gathering business requirements via a graphical user interface. The business requirements would then be compiled into a business model that could be provided as an input to our hypothetical “business model execution engine”. Although the current state of software environments is not as advanced, today’s technology is clearly moving in that direction. Today’s data modeling CASE tools automate the generation of logical database design from a conceptual database design. The proposed environment would be an extension of the capabilities provided in these case tools, where the tool would be able to encompass other models than the data model such as the process, event, and persistence models. Technology has clearly made a step in that direction with the advent of Enterprise Java Beans (EJB) application servers, which can automate the management of messaging, transaction, persistence and so on. Some tools (such as the mapping tools provided by Persistence Software Inc.) are dedicated to the generation of object-relational mappings. Clearly, the level of automation provided in today’s technology is still limited.
Sub-Topic 2.4 – Frameworks and
Reusable Components
Most of today’s application architectures are
being modeled using Object Oriented Analysis and Design techniques. The
architecture object model is comprised of sub-models focused on the
application, application infrastructure, and technology infrastructure. The
application architecture object model combines information from the business
model, data model, and content model. The business model includes the organization,
location, and process models. The organization model captures the functional
roles of the different types of business users. The location model identifies
how business processes will be distributed geographically. The process model
sets forth a set of business rules tailored to the application’s functional
requirements. The data model formalizes the application’s underlying business
entities and their inter-relationships. The content model focuses on the
interface of the application, and encompasses navigation, presentation, and the
underlying publishing mechanisms. The content model closely follows the look
and feel and navigation guidelines imposed by the corporation implementing the
application. The architecture object model for the application infrastructure
is subsumed in a layered framework (i.e., an assembly of design patterns) that
drives the grouping of application components into logical packages that
provide added operational functionality. These logical packages enable the
mapping of the application components onto the application infrastructure. The
design of the application infrastructure framework is influenced by the
business constraints imposed on the overall system design. Finally, the
technology infrastructure model is subsumed in one or more instances of
physical architectures that map the aforementioned logical packages onto the
underlying hardware and operating system platform. The technology
infrastructure model takes into account the company’s operating standards and
constraints. The physical architectures implement the technology infrastructure
model and satisfy the operational requirements of the application, and
application infrastructure implementations. Altogether, the application,
application infrastructure, and technology infrastructure models capture the
preliminary analysis and design information required to move on to detailed
design, and implementation of the first release of the application.
As mentioned in the above, the resulting system is
architected in three layers as depicted in Figure 2.1. The top layer hosts the
application suite, which implements the various business functions. The middle layer hosts the application
infrastructure, which provides operational support for the application suite.
Finally, the bottom layer hosts the technology infrastructure, which includes
hardware and operating system software. The architecture offers a global vision
of the application. It describes the strategic capability choices that
determine the application’s overall software quality from a business and
technical standpoint. The application's software "quality" results
from meeting specific business and technical constraints. Business constraints
include the support for business specific requirements (e.g., guaranteed delivery
of order and order status messages in our sample trading business model).
Technical constraints include accuracy, correctness, performance/latency,
scalability, extensibility / adaptability, continuity / availability /
reliability / robustness, security, testability, and usability. These
capability choices, which provide a measure of the application's overall
software quality, directly result from an attempt at fulfilling business and
technical requirements. Such requirements are usually collected by various
workstreams during the vision and strategy phase. At that stage, typical
workstreams focus on customer facing interviews, competitive analysis, and a
detailed analysis of current state technology and business processes. It is
important to note that the assessment of an application’s required
architectural capabilities is currently based on a limited set of requirements.
Other design factors that will drive the implementation of a good application
architecture are simplicity, elegance, intelligibility, well-defined levels of
abstraction, and a clear separation between the interface and the
implementation of each level.
Figure 2.1 The Three-Layer Architecture
Within the context of object-oriented analysis and design, modeling is often used as a synonym of analysis and it decomposes systems into collaborating objects. The Unified Modeling Language (UML) defines several models for representing systems: the class, state, use case, interaction, implementation, and deployment models. The class model captures the static structure. The state model expresses the dynamic behavior of objects. The use case model describes the requirements of the user. The interaction model represents the scenarios and messages flows. The implementation model shows the work units. The deployment model provides details that pertain to process allocation. Models are browsed and manipulated by users by means of graphical representations, which are projections of the elements contained in one or more models. Many different perspectives can be constructed for a base model - each can show all or part of the model, and each has one or more corresponding diagram. UML defines nine different types of diagrams: class, sequence, collaboration, object, statechart, activity, use case, component, and deployment diagrams. Class diagrams represent the static structure in terms of classes and relationships as model elements. Sequence diagrams are a temporal representation of objects and their interactions; they involve actors, objects, and messages. Collaboration diagrams are a spatial representation of actors, objects, links, and messages. Object diagrams represent objects and their relationships, and correspond to simplified collaboration diagrams that do not represent message broadcasts; they use classes, objects, and links. Statechart diagrams represent the behavior of a class in terms of states and transitions. Activity diagrams represent the behavior of an operation as a set of activities; they involve transitions, and actors. Use case diagrams represent the functions of a system from the user's point of view; they rely on actors, and use cases. Component diagrams represent the physical components of an application, and deployment diagrams use nodes and links to represent the deployment of components on particular pieces of hardware.
From an architecture standpoint, putting a
well-adapted architecture in place is the key to successful development.
Software architecture are often characterized using the following formula:
Software Architecture =
Elements + Patterns + Motivations
In this equation, elements correspond to UML model elements such as classes, and objects. Patterns refer to recurring combinations of objects and classes. Patterns can be grouped in larger representations called frameworks. Frameworks are truly reusable infrastructures dedicated to the implementation of targeted applications. In the case of our sample trading application, we could envision an application infrastructure web framework to support the various application layers. Finally, the "Motivations" variable set forth in the above equation correspond to the driving forces behind the architecture implementation. In the case of our sample trading application, we would identify a set of business, and technical constraints on the application as well as a set of guidelines for designing a "good" application architecture.
As an architecture is being designed, there is more than one way to represent a system. Multiple perspectives are required. Moreover, in order to satisfy many parties, each UML diagram type only gives a partial image of a system. As a result, the architectural model, which describes the architectural vision, must be well adapted to the representation of various constraints that the architect must take into account. A possible architectural model is the "4 + 1 view model", which relies on a combination of logical, implementation, process, deployment, and use case views as illustrated in Figure 2.2. The logical view describes the static and dynamic aspects of the system in terms of classes and objects. It involves a combination of class, object, sequence, collaboration, statechart, and activity diagrams. The implementation view relies on component diagrams, and is concerned with the organization of modules within the development environment. The process view represents the decomposition, in terms of execution flows (processes, threads, tasks, etc.), the synchronization between flows, and the allocation of objects and classes within the various flows. It relies on sequence, collaboration, statechart, activity, and component diagrams. The deployment view describes the various hardware resources and deployment of software within these resources. The deployment view uses component and deployment diagrams. Finally, the use case view constitutes the glue that unifies the four previous views. Use cases motivate and justify the architectural choices. They facilitate the identification of critical interfaces, they force designers to focus on the concrete problems, and they demonstrate and validate the other architectural views. The use case view involves use case, object, sequence, collaboration, statechart, and activity diagrams.
Figure 2.2 The "4 + 1" Architectural View Model
Sub-topic 1.4 fully illustrates our sample trading
application architecture. The documentation is limited to the "core"
functionality, which excludes the details of the presentation layer. The
proposed application architecture documentation includes:
·
A
textual description of the features of the architecture (i.e., the views) and
the key system requirements.
·
The
compromises reached and the alternatives explored.
·
A
high-level representation of the logical view.
·
Scenarios
specific to the architecture.
·
Description
of key mechanisms.
As the actual sample trading
application is too complex to be understood, designed or implemented in one
shot, it is better to implement it iteratively. Each iteration can focus on
functionality increments. The object-oriented approach provides a comfortable
framework to develop in an evolutionary fashion using such an iterative approach. We therefore suggest an
iterative and incremental project lifecycle for our sample trading application,
and we will use UML to model the system as it provides a comprehensive notation
for the full lifecycle of object-oriented development.
Sub-Topic 2.5 – Process/Entity
Matrix
Meshing business processes and data entities can be done in various ways. When using the object model approach (i.e., UML, or EER data model), business processes can be represented as the methods of classes, which are used to represent the typical entities. If the data model of the language used to implement the conceptual database design is not as expressive as an object model (e.g., E-R data model), it may be necessary to use process/entity matrices to associate relevant business processes to the entities they act upon. A simple alternative to a process/entity matrix is that of a Logical Process Hierarchy. A Logical Process Hierarchy is a structure for organizing DLPs using object-based principles. It starts with the Logical Entity Model and identifies business objects to correspond to the major data entities. Each DLP/object that is used by an EBP, is noted here. The Logical Process Hierarchy is used as a reference tool to identify development components and to promote reusability.
A Logical Process Hierarchy for our sample trading application is illustrated below:
Sub-Topic 2.6 – Conceptual
Database Design
This section illustrates the database design steps
for our sample trading application. It first shows how to derive a logical data
model from a traditional E-R data model. It then relates the mapping of the
resulting logical data model to the object model of the overall trading application.
This logical data model has been constructed based
on data requirements derived from sample functional requirements. The mapping of entities to the functional
requirements that they support is listed as part of the data dictionary. Where possible, the model has been validated
by business people from the appropriate subject areas, but as requirements are
still being defined, some areas will need revision as these requirements are
completed. It is also important to note
that the primary intent of this model is to present the logical entities and
their relationships. The attributes
listed as belonging to these entities are just samples of what may be required
and will have to be modified and expanded upon as business requirements are
completed.
The logical data model is broken up into five
subject areas based on the functions the entities contained in each
support. These subject areas are: Orders and Quote Requests, Price
Subscriptions, User Preferences, Privileges, and Instruments. A description of the purpose of each subject
area follows, and a definition of each entity can be found in the data
dictionary. Entities that appear in
gray are not required for phase one.
The Entity-Relationship (ER) diagrams for the five
subject areas, and the associated data dictionary are illustrated below:
The model below supports both quote requests and
orders. Quote requests will contain
most of the same information as an order, so logically they can be stored
within the same entity. Since an order
or quote request can consist of orders/requests for multiple instruments, two
entities are used to represent this.
The order entity links all of the individual lines together and describes
their dependencies, while the order line consists of all of the details needed
for an order or quote request for a single instrument. The execution entity contains the results of
a trade whether that is a fill or partial fill, while the quote entity contains
responses to price requests. Each
change in the status of an order or quote request, including rejections and
cancellations, is maintained in the order status entity.
A user can define price subscriptions in two ways. An individual instrument can be assigned to a
market window, or a group of instruments may be assigned. These groups or lists can be user defined
and do not imply that the instruments have anything in common; rather, it
allows the instruments to be more easily manipulated as a group. The assignment of instruments to windows
defines a subscription. Included in
gray are some entities that will support parametric prices in a later
phase. These entities allow for the
fact that there can be many prices for an instrument if different conditions or
parameters are applied, such as conditions for delivery or settlement. Entitlements to view prices are controlled
through their assignment to price groups and price tiers.
This model defines four sets of user preferences. The first, through the user entity, identifies the user and specifies a collection of default settings that apply throughout the trading application. The next is the set of default settings that depends on the asset class that the user is working with. The default order parameters entity allows the user to specify default values that will be used unless overridden when placing an order or making a quote request. Finally, there are the entities that represent the configuration of the user’s work area. A user can create multiple workspaces, each containing a set of windows (order queue market watch, market depth). Each of these windows can in turn be configured to display a selected set of columns and their positions, sort orders, and filters.
The proposed data model would need revision as
business requirements in this area become better defined. There are three main groups of
privileges: price entitlements, trading
permissions, and administrative privileges. In this model, all three groups are represented through the
privileges entity. This entity
associates an action, such as ‘place order’, with a target object, such as
‘product X’. Access will be controlled
to objects such as price tiers, price groups, order books, accounts, and
products. These privileges can be
assigned directly to a user, or can be assigned first to roles for easier
administration. Users can then be
assigned to these roles. In addition
there is a set of roles and privileges that are associated with a client
(firm). Client users must then be
assigned a subset of the privileges and roles available to the client. It is also possible that where a client is a
subsidiary of another client, the subsidiary can inherit the privileges of its
parent. Alternately, it can be given
its own set of privileges.
The
instrument model is needed to support searching for instruments as well as for
identifying an instrument to a back end system in an order. This model will
need to evolve as new requirements are
being added. A couple of different instrument groupings are represented
here. The first is through product and
asset class. These are used in
determining defaults and for controlling access within the application. They also support classifying and searching
for instruments. The other grouping
method allows a hierarchy of groups that can be defined either by the company
developing the trading application or by the users themselves. These custom groups are not used to classify
instruments or imply any similarities between instruments in the group; rather,
they are used to allow users to easy find and manipulate commonly used sets of
instruments. A structure also exists
for representing multiple identifiers by which an instrument may be known.
·
All
data that needs to be persisted will be stored within a database.
·
The
logical model needs to conform to naming and abbreviation conventions.
·
The
application needs to maintain audit logs for auditing, reporting, and recovery
purposes.
·
All
persistent data must be backed up regularly.
·
Lost
sessions and failed messages can be reconstructed from persistent data.
·
Access
to data within the application will be controlled according to the company’s
security standards for data stores.
·
Database
replication:
ü
For
locations that handle same client base, databases may need to be shared and or
synchronized.
ü
Databases
for servers that are in different countries will not replicate each other’s
data.
·
The
back end system is responsible for mapping a trading account to an account
within the back end system.
·
The
trading application will receive instrument data from back end systems and
maintain a version locally.
·
Backends
will maintain client credit data.
·
The
following estimations are given:
Item |
Quantity |
Update
Rate |
Users |
10K |
100/day |
Accounts |
5K |
10/day |
Firms |
5K |
10/day |
Entitlements |
500K |
5K/day |
Price requests |
50K/day |
2/second |
Orders |
20K/day |
1/second |
Peak Hour |
15% of daily global volume |
|
Avg. price subscriptions/user |
30 |
|
Price update rate |
|
1/second/product |
Total price update rate |
|
300K/sec |
Price update size |
50 bytes = ~500 bits (no compression) |
|
Total price update data volume |
|
150 Mbits/second |
Client distribution: North America 40%, Europe 40%, Asia 20%
·
Due
to the high volume up price updates, price data will need to be stored in an
in-memory database.
·
Similarly,
the high number of references to entitlements means that a copy of these
entitlements needs to be stored in an in-memory database, while a permanent
copy is persisted in a relational database.
·
If
Tibco products are used, we may need to use a Sybase database as DB2 is not
fully supported.
·
The
system must be fault tolerant.
·
Currently,
some business requirements are still being developed. As a result, data requirement in the following areas are
incomplete:
·
Entitlements
·
Instruments
·
Attribute
level information for most entities, including orders, price requests,
executions, and quotes.
Sub-Topic 2.7 – Object Model for
the Sample Trading Application
As mentioned earlier, the architectural model chosen
for the sample trading application is the "4 + 1 view model", which
relies on a combination of logical, implementation, process, deployment, and
use case views. The logical, use case and process views are handled as part of
the application modeling phase. The implementation view is addressed as part of
the application infrastructure modeling phase, and the deployment view is
addressed as part of the technology infrastructure modeling phase.
The use case view constitutes the glue that unifies the logical, process, implementation, and deployment views. Use cases motivate and justify the architectural choices. The process model and associated process maps described earlier give a conceptual representation of the use case view of the sample trading application object model. In the UML notation, the use case view involves use case, object, sequence, collaboration, statechart, and activity diagrams. These diagrams should be developed incrementally as needed as part of the detailed design.
The logical view describes the static and dynamic
aspects of the system in terms of classes and objects. The logical view
overlaps the class and state models, as the class model is focused on the
static structure, and the state model focuses on the dynamic behavior of
objects. In the UML notation, the logical view involves a combination of class,
object, sequence, collaboration, statechart, and activity diagrams.
The UML notation supports model elements and visual
elements (a.k.a., diagram). The visual elements provide textual or graphical projections
that facilitate the manipulation and representation of model elements. Classes
and objects are examples of common model elements used to represent
abstractions of a system being modeled. Packages are common model elements that
provide a general mechanism for partitioning models and grouping model
elements. The sample trading application architecture can be expressed as a
hierarchy of inter-dependent packages. The package hierarchy is follows:
Enterprise Applications Suite
Channels
Web Portal
Web Interface
Web View
Web Controller
Enterprise Services
Trading Enterprise Services
Business Controller
Client Interface
Client Handler
Component Manager
Business Object Model
Infrastructure
Services
Common Facilities
Domain Specific Facilities
The following class diagram illustrates some of the
classes would populate the above packages. More diagrams would need to be
developed incrementally as part of the detailed design.
Business
Object Model
Component Manager Package
The process view details execution flows (processes, threads, tasks, etc.), synchronization between flows, and allocation of objects and classes within the various flows. The process view overlaps the state model and the interaction model, as the state model focuses on the dynamic behavior of objects, and the interaction model focuses on scenarios and message flows. The process model and associated process maps described earlier give a very high-level conceptual representation of process view of the sample trading application object model. In the UML notation, the process view relies on sequence, collaboration, statechart, activity, and component diagrams. These diagrams should be developed incrementally as needed as part of the detailed design, which would take place early on in the detailed design phase. The detailed design phase would also focus on the specification of events, exits, errors, and detailed sequence diagrams including preconditions, triggers, and responses. At this stage of the analysis and design phase, we would focused on the interaction model and would develop a high-level message specification, and a preliminary message hierarchy. We would also put together a conceptual representation of message flows within the system. Additional work products would need to be developed incrementally as part of the detailed design phase.
The implementation view is concerned with the
organization of modules within the development environment. In the UML
notation, the implementation view relies on component diagrams. These diagrams
will be developed as part of the detailed design. At this stage of the Analysis
and Design Phase, a Logical Architecture Diagram would be provided. It would
act as a conceptual illustration of the implementation view that would serve as
a starting point for the detailed design of the architecture implementation
view. The diagram would illustrates the proposed logical components of the
sample trading application, and their
mapping to an application framework that would meet the business and technical
constraints imposed on the overall application design.
The deployment view describes the various hardware
resources and deployment of software within these resources. In the UML
notation, the deployment view uses component and deployment diagrams. These
diagrams would be developed as part of the detailed design. A Physical
Architecture Diagram would provide a conceptual illustration of the deployment
view that would act a starting point for the detailed design of the architecture deployment view.
Sub-Topic 2.8 – XML Support for
UML Modeling
OMG is championing a Model Driven Architecture (MDA)
that relies on the use of generic tools to generate platform-specific software
components from platform independent metamodels. To support its MDA, OMG has
adopted several metadata standards including the Meta Object Facility (MOF, http://cgi.omg.org/cgi-bin/doc?ad/99-09-05)
and XML Metadata Interchange (XMI, http://cgi.omg.org/cgi-bin/doc?ad/9910-02,
http://cgi.omg.org/cgi-bin/doc?ad/99-10-03,
and www.oasis-open.org/cover/xml.html).
XMI integrates XML with MOF and UML.
The MOF is the meta-metamodel that can be used to describe the whole
software development architecture as well as the MOF itself. Additionally, the MOF contains a set of rules that
specify the interoperability semantics and information interchange format for
any of its metamodels. Among these rules, the MOF to IDL (Interface Definition
Language) transformation rules can be applied to any metamodel to produce a
well-defined API. This API can be used to manipulate instance data
corresponding to the respective metamodel. This API also provides introspection
(a.k.a. reflection) - the ability to discover information contained in the
respective metamodel. In addition to the API, the MOF rules also define the DTD
corresponding to the metamodel. Any instance data of a metamodel can be
represented by an XML Metadata Interchange (XMI) stream that conforms to the
corresponding DTD. This results in the MDA development approach suggested in
Figure 2.3 below:
Figure 2.3 MDA
Development Approach
The MOF Core is a subset of UML (http://cgi.omg.org/cgi-bin/doc?ad/99-06-08) that is sufficient to model metadata (i.e.,
classes, associations, subtyping, etc.). Normative Java interfaces to the MOF
are being defined as part of JSR-40 - the Java Community Process (JCP) Metadata
API Specification.
To use the MDA paradigm, you would first describe a software system using a MOF-compliant modeling language such as UML. You would then refine the resulting design other models that further describe implementation and runtime semantics. The aforementioned MOF rules would then be applied to the initial model to define interoperability semantics and interchange format. Based on this paradigm, the MDA architecture provides a framework that supports the full description of software systems.
To illustrate the use of MOF, you can consider the very simple MOF model of a relational database illustrated in Figure 2.4 below. In that example, the metadata corresponds to the table, and column constructs that make up a relational database. Note that the Table and Column constructs set forth as the basic constructs of the relational database model may in turn be used to specify an actual database schema.
Figure 2.4 A
MOF Metamodel Expressing a Simplified Relational Database Model
The corresponding MOF Core elements used to describe the relational database model are MOF::Class and MOF::Association as shown in Figure 2.5.
Figure 2.5 MOF
Elements Used to Express the Relational Database Metamodel
The MOF core is technology neutral, and any of the MOF Core’s constructs may be mapped to CORBA IDL, Java, XML, or any other technology. In fact OMG has adopted the XML Metadata Interchange standard to encompass the rules for generating an XML DTD from a MOF metamodel. Figure 2.6 below illustrates further how instances of MOF::Class and MOF::Associations would be mapped to DTD elements in a typical MOF to XML mapping.
Figure 2.6
MOF to XML Mapping
The following is a listing of a corresponding
simplified XMI DTD generated using the IBM's AlphaWorks XMI Toolkit (http://www.alphaworks.ibm.com/tech/xmitoolkit ).
<!ELEMENT Table.column
(Column)* >
<!ELEMENT Table.name (#PCDATA |
XMI.reference)* >
<!ELEMENT Table (Table.name?, XMI.extension*,
Table.column*)? >
<!ATTLIST Table
%XMI.element.att;
%XMI.link.att;
>
<!ELEMENT Column.name
(#PCDATA | XMI.reference)* >
<!ELEMENT Column.type (#PCDATA |
XMI.reference)* >
<!ELEMENT Column (Column.name?, Column.type?,
XMI.extension*)? >
<!ATTLIST Column
%XMI.element.att;
%XMI.link.att;
>
<!ELEMENT RDB ((Table |
Column)*) >
<!ATTLIST RDB
%XMI.element.att;
%XMI.link.att;
>
Note that, in the model represented in Figure 2.4, both the Table and Column relational database elements use a name:string attribute. As an alternative, the model could abstract that attribute into a supertype named ModelElement. This would lead to the refined model illustrated in Figure 2.7.
Figure 2.7 A Refined Relational Database
Model
The following illustrates how XMI may use ENTITY declarations in the generated DTD to handle the representation of subtyping relationships in a more compact form. XMI DTD generators may be told to use alternate rule sets to generate DTDs. One of the rule set controls the generation of ENTITY declarations.
<!-- =========
RDB:ModelElement ========= -->
<!ELEMENT RDB:ModelElement.name (#PCDATA|XMI.reference)*>
<!ENTITY % RDB:ModelElementFeatures
'XMI.extension | RDB:ModelElement.name'>
<!ENTITY % RDB:ModelElementAtts
'%XMI.element.att; %XMI.link.att;
name CDATA #IMPLIED'>
<!ELEMENT RDB:ModelElement
(%RDB:ModelElementFeatures;)*>
<!ATTLIST RDB:ModelElement
%RDB:ModelElementAtts;>
<!-- ========= RDB:Table
========= -->
<!ENTITY % RDB:TableFeatures
'%RDB:ModelElementFeatures;'>
<!ENTITY % RDB:TableAtts
'%RDB:ModelElementAtts;'>
<!ELEMENT RDB:Table
(%RDB:TableFeatures;)*>
<!ATTLIST RDB:Table %RDB:TableAtts;>
<!-- =========
RDB:Column ========= -->
<!ELEMENT RDB:Column.type
(#PCDATA|XMI.reference)*>
<!ENTITY % RDB:ColumnFeatures
'%RDB:ModelElementFeatures; | RDB:Column.type'>
<!ENTITY % RDB:ColumnAtts
'%RDB:ModelElementAtts;
type CDATA #IMPLIED'>
<!ELEMENT RDB:Column
(%RDB:ColumnFeatures;)*>
<!ATTLIST RDB:Column %RDB:ColumnAtts;>
Very complex models can be represented in XMI form. In fact, the OMG started standardizing several XMI DTDs for the technologies and tools which are the basis of its Object Management Architecture (OMA). OMG’s OMA is a basic framework for organizing reusable components on top of a CORBA-enabled distributed architecture. OMA’s are based on OMG’s CORBAServices and CORBAFacilities reusable component categories. The XMI DTDs corresponding to OMA services or facilities can be generated from a corresponding MOF-compliant metamodel. For example, UML has a MOF-compliant metamodel and a corresponding XMI DTD as shown (simplified) in Figure 2.8.
Figure 2.8 A Simplified Representation of
the UML XMI DTD
Similarly, the CORBA Component Model (CCM) includes a metamodel of the new version of CORBA IDL, and a packaging and deployment descriptor metamodel. The CORBA IDL metamodel is used to represent CORBA object models that may be mapped to CORBA IDL. The packaging and deployment descriptor metamodel is used to generate an XMI DTD that defines the structure of XML documents that contain deployment descriptors. CCM components are deployed with descriptors that are expressed in XML documents that comply with that structure. The EJB Component Model also has an associated MOF metamodel.
The Common Warehouse Metamodel (CWM), which has been
adopted by the OMG (see specifications at http://cgi.omg.org/cgi-bin/doc?ad/00-01-01
and
http://cgi.omg.org/cgi-bin/doc?ad/00-01-02),
also follows the MOF architecture. CWM is as a standard metamodel for relational,
record-oriented and hierarchical databases and for other aspects of data
warehousing. As a result, XMI DTDs, generated from that metamodel, may be used
to exchange warehouse models.
Sub-Topic 3 – XML and Model Based Computing
Sub-Topic 3.1 – Developing Applications Using XMI
The OMG MDA described in the previous sub-topic is organized in various layers as illustrated in Figure 3.1 below. The MOF technology is expressive enough to represent complex software systems, and OMG has used it to provide concise models of most of the OMG’s OMA supporting CORBAServices, and CORBAFacilities. Corresponding models describe technologies, services and business models such as UML, CCM, the Common Warehouse Model (CWM), the EJB model, etc. As the various technologies and services are used by tools and applications, the MDA ensures a precise definition of a whole application implementation.
Figure 3.1 The Various Layers of OMG’s MDA
As application models and their implementation details are being captured, the intermediate technology layer provides the necessary implementation details. For example, you may have an application whose business logic is captured in a UML model. MDA handles the application model as an instance of the UML metamodel. As the application is being targeted toward a specific implementation environments, its implementation details are being provided by the respective technology metamodels (e.g., EJB or CCM metamodels). The application may also reuse available components, including services or facilities available in the target environment. Again, the corresponding information may be captured using the respective technology metamodels. Based on this approach, OMG’s MDA can capture both the business logic and implementation details of a complex software application.
In the case of the Relational Database Metamodel described in Sub-topic 2.8, the MDA development approach would be used to produce an API based on the MOF to IDL transformation rules. The corresponding interfaces shown below, provide methods to get (name()) and set (set_name()) the name of a table as well as methods to add modify and delete columns from a table. These generated interfaces can be used by programs to manipulate the instance data of the relational database metamodel.
interface Table : TableClass
{
string name ()
raises (Reflective::MofError);
void set_name (in string new_value)
raises (Reflective::MofError);
ColumnSet column ()
raises (Reflective::MofError);
void set_column (in ColumnSet new_value)
raises (Reflective::MofError);
void add_column (in SimpleRDB::Column new_element)
raises (Reflective::MofError);
void modify_column (
in SimpleRDB::Column old_element,
in SimpleRDB::Column new_element)
raises (Reflective::NotFound, Reflective::MofError);
void remove_column (in SimpleRDB::Column old_element)
raises (Reflective::NotFound);
}; // end of interface Table
The instance data associated to the relational
database metamodel can be represented by an XML Metadata Interchange (XMI)
stream that conforms to the corresponding MOF DTD listed in sub-topic 2.8. As
an example, the XMI stream could represents a simple table named “PERSON”,
consisting of two columns. One column would correspond to the “name" of
type "String" used to store the name of a person, and the second
column would correspond to the socialSecurityNumber" of type
"CHAR(9)" used to store a person's social security number as a
nine-character string. The corresponding XMI stream is illustrated below:
<?xml version="1.0" encoding="UTF-8" ?>
<XMI xmi.version='1.1'>
<XMI.header>
<XMI.metamodel xmi.name='SimpleRDB' xmi.version='1.0'/>
</XMI.header>
<XMI.content>
<RDB:Table name='PERSON'>
<RDB:Table.column>
<RDB:Column name='name' type='String'\>
<RDB:Column name='socialSecurityNumber' type='CHAR(9)'\>
<RDB:Table.column>
</RDB:Table>
</XMI.content>
</XMI>
Sub-Topic 3.2 – Using XMI with Instance Data
It is important to realize that, in the overall MDA approach, XMI can be used
to handle metadata exchange as well as to exchange instance data. As an
example, the UML model shown in Figure 3.2 is not a metamodel, Instead, it is
an example of a model expressed via the UML metamodel. In this case, instances
of classes which are part of the model constitute real user objects, and not
models. As any other MOF model, the application model is platform-independent
(i.e., it is not specific to CORBA, EJB, XML or any other target platform or
support technology.
Figure 3.2 Expressing
Application Models via the UML Metamodel
As the MOF Core is very close to UML, MOF’s XMI to DTD transformation rules can be applied directly to a UML model representing a user application. Assuming the UML model is that of a bank application, the result produced by feeding the model into an XMI DTD generator is that of producing a DTD that spells out how to encode the state of instances of banking entities (e.g., Accounts, and Customers) in an XMI stream. The corresponding DTD shown below can be used as a reference for exchanging instance data.
<!--------------------
Customer ----------------------------->
<!ELEMENT Bank.Customer.SocialSecurityNum
(#PCDATA | XMI.reference)*>
<!ELEMENT Bank.Customer.name (#PCDATA |
XMI.reference)* >
<!ELEMENT Bank.Customer.Address (#PCDATA |
XMI.reference)* >
<!ELEMENT
Bank.Customer.account (Bank.Account |
Bank.SavingsAccount |
Bank.CheckingAccount |
Bank.PrefferedChecking |
Bank.RegularChecking)*
>
<!ELEMENT Bank.Customer
(Bank.Customer.SocialSecurityNum?,
Bank.Customer.name?,
Bank.Customer.Address?,
XMI.extension*,
Bank.Customer.account*)?
>
<!ATTLIST Bank.Customer
%XMI.element.att;
%XMI.link.att;
>
<!----------------------
Account ---------------------------->
<!ELEMENT Bank.Account.number (#PCDATA |
XMI.reference)* >
<!ELEMENT Bank.Account.balance (#PCDATA | XMI.reference)* >
<!ELEMENT Bank.Account.customer (Bank.Customer)? >
<!ELEMENT Bank.Account
(Bank.Account.number?,
Bank.Account.balance?,
XMI.extension*,
= Bank.Account.customer?)?
>
<!ATTLIST Bank.Account
%XMI.element.att;
%XMI.link.att;
>
Sub-Topic 3.3 – Information Modeling with XML
There are at least three information modeling approaches to pick from today. These include XML, Object-Role Modeling (ORM), and Unified Modeling Language (UML). UML and ORM are obviously modeling technologies, which share concepts such as an object-centric methodology and conceptual modeling. However, ORM is a tool for designing databases, not application classes. XML is more than a data and document markup language, it is a solution for content modeling and creating standards for content. The various types of modeling techniques offered via UML, XML, and ORM cater respectively to object modeling, content modeling, and data modeling. To build Web applications, you might use two or three modeling techniques. For example, the design of distributed applications may be based on UML for middle-tier components and ORM for database design.
First generations of modeling tools and technologies
centered on process (e.g., system-level flow charts) and data modeling (e.g.,
Natural Language Information Analysis Method (NIAM), and data flow diagrams
(DFD)). Data modeling is the process of creating models when designing
databases. This process is based on a progression from conceptual modeling to
logical modeling that leads to the specification of a physical schema. Most
data-modeling products support entity-relationship diagrams (ERD), object-role
modeling (ORM), and Integration Definition for Information Modeling (IDEF1X)
models. More recent modeling technologies, such as UML, support object-oriented
analysis and design (OOAD).
UML is an object-oriented methodology that standardizes modeling language and notation, not a particular method. UML supports several different views of a system -- class diagrams, behavior diagrams, use-case diagrams, and implementation diagrams. Use-case diagrams let UML users define how actors participate in an interaction with the system. UML users can capture a system's dynamic behavior by using activity diagrams, collaboration diagrams, sequence diagrams, and state diagrams. To document the lower-level details of a system, UML users can develop component diagrams and deployment diagrams. The UML is also extensible and supports the addition of new modeling concepts via the use of stereotypes and patterns. UML is a powerful solution for application object modeling, but developers doing real-time and database applications find that it does not address all of their needs. For those purposes, developers often turn to data modeling and ORM. An example of a mainstream tool that supports ORM (As well as UML) is Visio Enterprise’s VisioModeler. The following chart represents an ORM conceptual model for a memo-style document. This ORM model can be used to generate a database schema for storing documents.
Figure 3.3 A Sample
ORM Model
While developers today can use object models, database models, and
standard components, XML DTDs are gaining momentum as the content model for
standard inputs and outputs. XML, in general, may be used for both data and
object modeling. XML supports the modeling of widely disparate types of content
that range from book-oriented document types to commercial transactions. XML is
an enabling technology for business-to-business integration, data interchange,
e-commerce, and the creation of application-specific vocabularies. Database
developers are particularly interested in XML as a building block for creating
middle-tier servers that integrate data from disparate databases. XML is also
used for purposes such as exchanging data warehouse metadata and UML models.
Organizations such as IBM, Oracle, Rational, Sybase, and Unisys are promoting
XML, UML, and the Meta Object Facility (MOF) as solutions for collaborative MDA
development using an open information interchange model. While a visual
designer thinks of XML in terms of client-side issues such as presentation and
style sheets, a database developer is mostly concerned with middle-tier data
integration and schemas. To effectively use XML, a database developer needs to
understand XML document structures and be able to store, parse, and manipulate
such documents. Additionally database designers need to be able to generate XML
output from database queries.
The XML document shown below is the counterpart to the ORM model shown in Figure 3.3:
<?xml version="1.0"?>
<MESGMEMO STATUS="PUBLIC">
<DATESENT>27 March 1999</DATESENT>
<RECIPIENT>To Whom it May Concern</RECIPIENT>
<SENDER>XYZ</SENDER>
<TOPIC>Recommended Reading List: Web Farming for the
Data Warehouse</TOPIC>
<SECTION>
<P>
Web Farming for the Data Warehouse (Morgan Kaufmann) is a
compendium of information that is best-described as systematically making
intelligent use of the Web.
...
</P>
<P>
The book contains a wealth of
information about content-providers, protocols, standards, tools, discovery
services, knowledge management, Web agents, and data mining software.
...
</P>
</SECTION>
<CLOSE>XYZ</CLOSE>
</MESGMEMO>
Several initiatives are related to W3C’s recent XML Schema
recommendation that provides an integrated set of document structuring and data
typing capabilities. These initiatives include the Resource Description
Framework (RDF), the Document Content Description (DCD), and XML-Data. RDF
provides the ability to describe Web resources. An RDF schema is similar to a
database schema. It defines types and document semantics, which makes it
possible to do type checking of XML documents. DCD enables the definition of
rules that describe the content and structure of XML documents. DCDs supplement
DTD semantics by describing constraints in XML and defining document elements
as types. DCD constraints include subclassing and inheritance, data types, and
SQL-style constraints (key fields, unique values, referential integrity).
XML-Data is an XML vocabulary for defining and documenting object classes. It
can be used to define the characteristics of syntactic classes, or for
conceptual schemas that are similar to relational schemas. XML-Data schemas
include element type declarations. They support subtypes, groups (ordered
sequences of elements), defaults, aliases, class hierarchies, multipart keys,
and one-to-many relations. We refer students to the W3C Metadata project at http://www.w3.org/Metadata/Activity
for additional information on W3C’s work in the area of metadata handling.
XML schemas facilitates the development and use of tools for querying
XML data stores. Although XPATH provides sophisticated pattern-matching
functions available via XSLT, it doesn't provide create, update, and delete
operations that are analogous to SQL queries. That particular functionality is
part of XML Query, which was covered in an ealier session of this course.
In summary, database developers are likely to be involved with XML for
several reasons:
1. Develop applications
that query databases and format the query results as XML documents.
2. Develop databases and
write code to support business-to-business integration or other forms of
electronic data interchange (EDI).
3. Store XML documents in
a database.
Database developers are well supported by current database products
when it comes to using XML capabilities for persistent applications. Oracle,
IBM, and Microsoft fully support XML in their application server and database server
offerings. Oracle has built-in support for XML into products such as Oracle
Application Server and Oracle 8i (O8i), an object-relational DBMS capable of
storing rich data types. O8i includes an XML parser, an Internet File System
(iFS) that provides automatic parsing of XML documents, and Java classes that
support XML. Oracle's parser supports the Document Object Model and the
event-based SAX interface. Oracle's interMedia text search engine provides
section searching of XML documents. XML support has been further integrated
into Oracle9i’s application server and database.
IBM provides an XML toolkit for its WebSphere (application server)
studio product and its DB2 Universal Database (UDB) is XML-enabled. IBM has
developed an XML Extender for DB2 UDB and has added features for storing and
querying XML documents. It can store XML documents as a single column, or
decompose the document and treat it as a collection of fields that are standard
or user-defined types (UDTs). IBM revised the DB2 text search engine so it
understands the structure of an XML document, thereby providing capabilities
such as section searches. By storing XML elements and attributes as SQL types,
DB2 users are able to index documents for more powerful search optimizations.
IBM also added functions to extract XML elements, attributes, or entire
documents, to reconstruct decomposed documents, and to link to XML documents
stored in external files.
Microsoft Office 2000 saves files as native HTML and includes embedded
XML within Office documents. Internet Explorer can read XML tags embedded in a
Web page and perform semantic validation using DTDs. Microsoft implements the
W3C DOM over a Component Object Model (COM) component. Developers can use the
XML COM component for client- or server-side programming. The XML component
calls the XML parser to check a file for validity, builds the document tree in
memory, and then builds the object model over the tree. This programmatic
interface enables VBScript, JScript, ActiveX Data Objects (ADO), and Active
Server Pages (ASP) to operate with XML. A script can, for example, create an
XML data source object (XMLDSO) and then use DOM objects to walk an XML tree.
ADO has been extended to work with XML as shaped or hierarchical recordsets.
Users can bind data islands to Web pages and then use XML objects or ADO
methods to navigate through the data.