31. Implementing Models in Applications
DE + IA (INFO 243) - 2 May 2007
Bob Glushko
Plan for Today's Lecture
- Model-Based Applications
- Integration Patterns
- Composite Applications
- JustSystems XFY
Model-Based Applications
- Creating information and process models is a significant investment in capturing context-specific (or application-specific) requirements in a technology-neutral and robust way
- The abstraction in a good model makes it simpler and easier to work with than the specific technologies of implementation
- A Model-Based Application explicitly uses a model as a specification for generating code or configuring an application
Example: Models in MRP/ERP Cycles
- MRP systems (which evolved into ERPs) plan production, procurement, and distribution for an enterprise and you can view them as embodying a generic model of a manufacturing enterprise that is configured for a specific firm
- For each of the products a company manufactures there is a "recipe" or "parts list" or "bill of materials" that lists the parts or components that go into it (and how many of each).
- "Shopping lists" for each production cycle are then sent to suppliers as EDI or XML documents
How Else Could You Do It?
- I can't imagine why you'd design and implement an application without making the information and process models "first class citizens" but...
- Why did they call it "spaghetti" code?
- There is little separation of information models and the code that handles them in most scripting languages
- Many programs "flatten" and "deconstruct" a hierarchical document model into a set of "attribute-value" pairs
- The iterative, heuristic, and non-deterministic techniques by which most people design user interfaces don't emphasize the information and process models
Benefits of Model-Based Applications
- Easier to understand the software architecture
- Generated code is of higher quality than hand-crafted code
- Easier to maintain (regeneration when model changes)
Platforms for Model-Based Applications
- A software platform solves some class of generic problems so that application developers can focus on the context-specific parts
- Operating systems, programming languages and their runtime libraries, databases, software frameworks, and web browsers are platforms...
- But ideally, the context-specific parts of the application that are based on the model(s) remain distinct and inspectable apart from the generic functionality provided by the platform
- In this case, the platform interprets the model to determine how the software behaves -- the model configures or customizes the platform
A2A Integration
- The "old" way to integrate two applications within an enterprise (or the same application between two companies) was to write a
custom program that fit only between the two of them
- This method has traditionally been called A2A (Application to Application) integration
- The technical approach is usually file transfer or remote procedure call mechanisms; in the latter, the calling or receiving program basically stops and waits for the called application to return the desired information
- When everything works, A2A integration enables a tightly-coupled and real-time connection between applications
- But the low-level granularity of APIs means this isn't model-based
B2B Integration
- In contrast to traditional A2A integration, where neither application interface is visible outside the company, B2B integration
is concerned with automating the exchange of information between enterprises
- Loose coupling is a fundamental design principle for the Web, and today almost all B2B integration software uses Internet and Web standards with XML documents as the message format and
provides "bridges" to and from legacy formats
- Much B2B integration software has moved to a "hub" or "bus" architecture to replace point-to-point A2A integration with a more
scalable approach
Architectures for Transformation: Connectors
- It is the sender's responsibility to transform the message (the envelope and its contents) into the model needed by
the receiver
- Modern connector software may include predefined data translation solutions (adaptors) for common ERP systems, enterprise databases and enterprise messaging software
"Foreign Protocol Integration" via Connectors
Architectures for Transformation: Gateways
- The receiving application accepts whatever message the sender wants to produce and does the transformation. This is
the "be liberal in what you accept" strategy.
- This strategy captures existing "transaction flows" by making it easy for
legacy systems to join the marketplace or networks
"Foreign Protocol Integration" via Gateways
Architectures for Transformation: Services
- The transformation can be carried out by a third-party service provider - a transformation intermediary.
- This is often the most efficient architecture if there is a "hub" or "interoperability" message format (such as xCBL or UBL) because it minimizes the number of transformations that will be required
"Foreign Protocol Integration" via Service
Model-Based User Interfaces
- User interface design started as a distinct activity in the 1980s, and has been dominated by iterative and heuristic techniques ever since
- In the 1990s the goal of model-based UIs emerged with the hope that automatic generation of window and menu layouts from information already present in the application data model can relieve the application designer of unnecessary work while providing an opportunity to automatically apply style rules to the interface design
- Some people starting calling this the search for the Big Red Button, and in many cases it involved user interface modeling languages (expressed in XML) from which UI code would be generated
Many Small Red Buttons?
- An alternative to the search for the BRB is the goal of partial automation for user interface generation:
- Tools that generate prototype from specifications
- Tools that synthesize use cases into sequence diagrams
- Tools that merge sequence diagrams to hide states that have no UI implications
- Tools that generate UI skeletons or scaffolds while enforcing layout constraints
- Tools that generate a family of UIs via "graceful degradation"
- UI Design Patterns
Model-Based Applications and the Document Type Spectrum
- Most platforms for model-based applications are form-based and targeted toward transactional document types
- "E-book" readers are a notable exception, designed as platforms for narrative document types to provide "book-like" display and interactive functionality
"E-Books" and Platforms for Structured Publications
- The simplest case of structured publication is publishing a single document in a way that lets the user interact with it by exploiting its (content) component structure
- Many e-book platforms exist, and many have adopted XML formats (native or interchange) with Open eBook (but not all of them)
- E-book readers differ in how much structural and presentation fidelity they enable and in functionality that "goes beyond the printed book"
Composite Applications
- Create a single interactive user experience by combining multiple business functions or information sources
- Reuse the application logic from these existing applications / sources
- Do not change the constituent services/sources, which can still function independently in their original contexts
Swivel-Chair "Application Integration"
Motivations for "Internal" Composite Applications
- Business strategy perspective - can provide improved and new services to customers by combining customer information, order management, product information, etc.
- Business operation perspective - Reduce errors and time for information to flow from one "stovepipe" system or process to another by replacing manual methods of information sharing like re-typing or phone with automated interchange
- Technology perspective - reuse of legacy applications extends their useful lives and can be technically easier than reimplementing their functionality in a new application
Motivations for "External" Composite Applications
- Business strategy perspective - can focus on core competencies by using services provided by other firms in "plug and play" business models
- Business operation perspective - can improve collaboration and information exchange with suppliers and other partners
- Technology perspective - composite application platform can exploit "on demand" services and reuse the models and techniques needed to integrate (and interoperate) applications and services
Pre-requisites for Composite Applications
- Business Architecture -- Looking at business models and processes in more granular terms so that business functions are visible and reusable
- Service Architecture -- Platform-neutral and standard specifications for service interfaces
- Document Engineering -- Methods for analyzing and modeling service interfaces and the documents that they produce and consume
JustSystems XFY
- A platform for building composite applications with model-based user interfaces
- Can "plug in" and "mash-up" any information source described by a model (not just XML)
- Presentation by Hideki Hiura, JustSystems CTO
