Architecture Centered Publishing Systems

Architecture Centered
Publishing Systems
Publishing Platforms Symposium – IFRA
Zurich Switzerland
November 4, 2000
Copyright ©, 2000 Niwotridge Consulting 1
Niwot Ridge Consulting, Copyright © 2000
Architecture Centered Publishing
Systems
Architecture bridges the semantic gap
between the requirements and software
IFRA Publishing Platforms Symposium
Zurich Switzerland, December 4th 2000
The use of an architecture–centered development process for delivering
information technology began with the introduction of client / server
based systems. Early client/server and legacy mainframe applications
did not provide the architectural flexibility needed to meet the changing
business requirements of the modern manufacturing organization. With
the introduction of Object Oriented systems, the need for an
architecture–centered process became a critical success factor. Object
reuse, layered system components, data abstraction, web based user
interfaces, CORBA, and rapid development and deployment processes
all provide economic incentives for object technologies. However,
adopting the latest object oriented technology, without an adequate
understanding of how this technology fits a specific architecture, risks
the creation of an instant legacy system.
Publishing software systems must be architected in order to deal with
the current and future needs of the business organization. Managing
software projects using architecture–centered methodologies must be
an intentional step in the process of deploying information systems –
not an accidental by–product of the software acquisition and integration
process.

Publishing Systems
Zurich Switzerland
November 4, 2000
What’s Happening in the Industry
Enterprise integration should be viewed as a
strategic initiative for every large enterprise. The
complexity of and the demands on modern
computing environments requires a systematic,
centralized approach to integration requirements
to achieve optimal value for the totality of
enterprise information assets. Message brokers
are an emerging class of products that can be
increasingly applied at the enterprise level.
— Patricia Seybold Group
It’s the value of the technology assets that drives business decisions.
How can the value of these assets be increased in the presence of
changing standards, increasing complexity, increasing competition, and
the Internet? One answer is the better use of commercial off the shelf
components and reuse of these components once they have been
integrated into a system.

Publishing Systems
Zurich Switzerland
November 4, 2000
The System Integration Problem
♦ The problem in automating the
publishing enterprise is not the
technology, it is controlling the
complexity of the resulting system.
This complexity is directly related to
system cost
[†] “Increasing Returns and the New World of Business, W. Brian Arthur,
Harvard Business Review, 74(4) Jul-Aug, 1996, pp. 100–110.
♦ Traditional methods create systems with n2
connections. Each connection creates a
maintenance expense over the life of the
system.
♦ Removing these connection points through
“component based” technologies is a
“bookable” benefit to the organizaiton.
In today’s news and information publishing environment, content resides on
many platforms distributed throughout the organization. Gaining access to the
right information at the right time is a daunting task. Integrating these diverse
information sources and the processes that manipulate them in a seamless manner
is called Enterprise Application Integration (EAI).

Publishing Systems
Zurich Switzerland
November 4, 2000
Macro Economics and Software
♦ In an Increasing Return
environment, adaptation requires:
– Agility
– Flexibility
– Incrementalism
– Rapid development
– Loosely defined interfaces
– Operations within chaotic environments
– Managing work–state rather than workflow
♦ All of these attributes can be found in
component based software systems
The Increasing Returns economy requires adaptability rather than
optimization. Adaptability means agility, flexibility, incrementalism, rapid
development, interfaces that are not formally defined, chaotic business
and product environments, managing the state of the business rather
than the flow of the business. Component software systems provide the
tools and architecture to meet these requirements. Traditional software
tools and architecture do not.

Publishing Systems
Zurich Switzerland
November 4, 2000
Components are IT Plumbing
Object Request Brokers
Models
Inheritance
Polymorphism
EncapsulationObjects
n-Tier
3-Tier
2-Tier
Architecture
Java the Language
IDL
IIOP
DCOM
OMG
Java Beans
Components
Java the OS
Client Server
The Web
Fault Tolerance
Load Balancing
Remote Access
XML
eXtreme
Programming
SmallTalk
UML
RAD
In information systems, business components are like plumbing, they
connect all the important pieces of the system, provide the flow of
important resources, and keeps everything going in the right direction at
the right time, for the right reason.
One plumbing model is the interchangeability of parts in the North
American Standard plumbing fixtures. Parts and pieces can be
assembled into a final system by simply connecting each component in
the proper manner to form the completed system.
This may not be the experience of the home repair person, after the 3rd
trip to the hardware store for that “special” part, but it is the norm in the
commercial plumbing world.

Publishing Systems
Zurich Switzerland
November 4, 2000
One Approach to Components
♦ CORBA is one approach, there are others:
– MQ Series from IBM
– MSQ from Microsoft
– Emerging XML connectivity standards
♦ All these approaches isolate the components by
creating “interfaces” that are independent from
the underlying system.
♦ This implies
– Data transformations are hidden from the user
– System functionality is “neutralized” through shared
semantics.
• When I say “this” I mean “that,” is a very difficult problem to solve
in an open and integrated domain.
There is a major difference between standards and guidelines. A
standard is a rule that must be followed. A guideline is a
recommendation that should be followed in most cases. If an
organization fails to follow a standard, a negative outcome should
occur. If the organization fails to follow a guideline, there is usually little
risk to the outcome. Most organizations allow deviations to standards
only through a formal review and approval process. Usually a deviation
requires some form of a sign–off by a manager that understands the
consequences.
In addition to the system integration standards there are numerous
standards for content interchange. When combined with the hardware,
software, messaging, database, distributed computing, and data and
metadata standards, the simple approach of picking a set of
applications and assembling them into a system may seem hopeless.

Publishing Systems
Zurich Switzerland
November 4, 2000
CORBA Enables…
♦ Best of Breed Application Components to
Interoperate
♦ Distributed Heterogeneous Systems Integration
to take place in a transparent manner
♦ Legacy System Integration Strategies to be
implemented in the same manner as new
development
♦ Rapid Development Strategies using standard
interfaces
♦ Internet Based Strategies using Java
♦ Platform and Language Independent Strategies
CORBA is an enabler of business components. It is not the only way,
but it is one that has several advantages, and some disadvantages,
over the alternatives. It is platform independent, it provides the services
for:
•fault tolerance
•load balancing
•Scaling
•quality of service
•replication
These features come with a price, like anything worthwhile, but they are
provided in a standard package. Like any modern system, the price is
the technical competence and skills needed to assemble the system
into a product. In the current business environment these skills are in
short supply.

Publishing Systems
Zurich Switzerland
November 4, 2000
Component Based Systems
To succeed in the era, software development
organizations must come to terms with the
realities of the market.
What are component based systems? Why are they different and better
than traditional integrated systems? How can the user understand the
differences and make an informed decision about the technology
strategies needed to move into the next generation of publishing
systems?

Publishing Systems
Zurich Switzerland
November 4, 2000
What is the Problem?
Best of Breed
Services
and Databases
In the traditional approach to assembling a system from components,
the individual API’s, data formats, protocols, languages, operating
systems, and application locales create many barriers to the “seamless”
construction of the system. Once these connections have been made,
any changes in any component in the system will have some impacts
on other components.
In the past, these brick walls have been overcome with brute force,
either through the efforts of programming or the use of intermediate
database or format translation software. This approach resulted in client
server architectures that were “fixed” in their construction, just like the
brick wall.

Publishing Systems
Zurich Switzerland
November 4, 2000
A Solution
CORBACORBA
With the introduction of “middleware” interface, locality, programming
languages, and operating systems issues become the responsibility of
CORBA. Using component technologies, the application domain and
the services domain can be connected with very little impact on the
other domains. This is done through standard distributed object
architectures
1. Starting with the interfaces, a standard interface definition
language is used to describe the “public” capabilities of the
various components
2. In many systems a layered approach is taken to hide the
idiosyncrasies of each component’s domain. The result is a
standard mechanism for connecting any specific class of
component to the system. For example asset managers have a
general set of capabilities. These capabilities are expressed using
the IDL of the interface component.
3. The interface component itself contains layers the progressively
isolate the specific application domain from the general CORBA
architecture.
In this way each participating component presents a “neutral” interface
to CORBA, while providing the necessary business processing
capabilities needed to construct a complete system.

Publishing Systems
Zurich Switzerland
November 4, 2000
Component Market Imperatives
I’ve got a Great Idea!
Here’s how
this will help
everyone
Define the components
in terms of the existing
architecture.
We can add
this to the next
release and
everyone will
be happy
The system has new
features
and all the old features
still work
The power of components can be seen in a example of system
development. The developers have built a component based
infrastructure on which commercial applications can be assembled into
a product. Someone (who will remain a nameless marketing executive)
discovers a new requirement for a new component or subsystem that
must be added to the system without disrupting the other application
components. In the component environment the interfaces between the
components provides the necessary isolation to allow a new application
to be added with minimal impact. The business rules and software
protocols shared by all components form the foundation of this process.
The fundamental concept here is the market place drives this process.
The marketing department will have significant input to the outcome, but
the application domain and the system behaviors are controlled by
external forces, not the traditional product marketing forces.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Market Drives Architecture
♦ Systems developers must
accommodate marketplace
instabilities.
♦ Component come and go and often
do not integrate well with each
other, even from the same supplier.
♦ If integration is achieved at all, it often breaks
down when new version of a component is
introduced.
♦ The traditional, tightly coupled, systems also
have an n2–n connections, versus n
connections for a component based system
with bus connectivity, like CORBA.
Many of today’s technology decisions are driven by the market, not the
vendor. The internet, CORBA, communications networks, programming
languages, databases, system architectures, are all defined external to
the business needs of the user. Adapting to these standards requires
an architectural vision, not just a product plan. This vision must include
the evolving standards as well as the evolving component technologies
provided by external suppliers. Building “purpose built” applications
moves away from this vision and must be considered carefully.

Publishing Systems
Zurich Switzerland
November 4, 2000
Systems Must Accommodate Change
♦ New components are desirable for
their innovative features
♦ New components necessary in
response to market pressures
♦ The downside is that new components may
not be compatible with each other or with
older components
♦ Some means of integrating the new
components, while maintaining the old is
needed
♦ This method is based on managing the
interfaces between components rather the
content of the components
Change is constant. Change is disruptive. Change is the engine that
drives innovation, increasing returns, market share, product
displacement, product obsolescence.
In order the survive in the presence of change the underlying system
architecture must not only support change, but must thrive on change –
that is the cost of change is not related to the size or complexity of the
application domain, but is a function of the change. This is a linear
change cost model, rather than a non-linear (exponential or greater)
models found in API based implementations.

Publishing Systems
Zurich Switzerland
November 4, 2000
Compressed Processes Are The Norm
♦ Requirements, analysis,
design, and implementation
cycles must be compressed
and commingled.
♦ Often the only way to know a component
works is to try it.
♦ Previously discrete activities are often
indistinguishable.
♦ This may appear as chaos but it is “Just in
Time Competency,” though highly focused
prototyping.
♦ In the end it is all about “Time to Market.”
The traditional processes of analysis, design, development, and
deployment have difficulty dealing with rapid change, adaptive markets,
and changing market requirements. Component based systems provide
the means to develop product in the presence of these forces.

Publishing Systems
Zurich Switzerland
November 4, 2000
Component Suppliers
♦ Systems depend on component
suppliers, not just components.
These suppliers provide parts and
building blocks, as well as tools.
♦ This regime is new and is similar to traditional
manufacturing supply chain management.
– Suppliers of parts linked to suppliers of subassemblies
– Subassemblies assembled into assemblies
♦ Unlike manufacturing, the standards are set by the
market place, not the final assembler
– CORBA
– Java and Swing
– Database technologies
In the Best of Breed market, the suppliers not only provide a product,
they also provide a collection of products and the environment in which
they operate. These collections of components may include items from
other suppliers. This situation adds to the complexity of integrating
components and increases the importance of system architecture,
component isolation, and industry standards in assembling the final
product.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Bottom Line on Components
♦ The difference between components and
traditional systems may appear complex, but…
♦ The bottom line is components provide:
– Interchangeable parts
– Scalable systems
– Architectures that are adaptable to changing market needs
and new product releases
♦ All of this translates into
– Faster time to market
– Lower sunk cost for the development process
– Higher flexibility in a changing business and technical
marketplace
The difference between component based systems and more traditional
system integration approaches lies not in the techniques but in the
results of the process. The outcome of the integration in the component
architecture is distinctly different than an integrated system based on
traditional API’s. Flexibility, isolation, separation of concerns, portability
across languages, platforms, operating systems, and locales is
provided “for free” with the CORBA architecture.
All of these attributes must be built from scratch in the non CORBA
implementation.

Publishing Systems
Zurich Switzerland
November 4, 2000
The World of Publishing Systems
In the Publishing World, there are
fundamental applications that are needed to
get the paper out.
In the publishing domain, change is coming somewhat late compared to
other businesses. This is an advantage that can be used to avoid many
of the past difficulties.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Component Domain
Advertising
Output
WorkflowGraphicsPictures
Pagination
Wire Service Editorial
Using a Best of Breed approach has several consequences. It is
unlikely that the Best of Breed application has been built as an OEM
product, that is intentionally built to be used “within” another application.
Many BoB products have API’s but these API’s make the assumption
that the application is the center of the process. This is called “Inversion
of Control” and takes place when one application is integrated with
others, and all the applications assume they are in control.

Publishing Systems
Zurich Switzerland
November 4, 2000
Best of Breed Components
♦ Integrating Commercial Off The Shelf (COTS)
software is now the norm
– Using purpose built software has very little economic appeal for a
vendor or end user
– Interchangeability of the software, people, and formats provides
the agility needed to deal with change
– software becomes the enabler of the economic outcome
♦ Putting these components together allows
– Focus on the “business” of business
– Open systems, that mean “plug and play” software components
– Re-capitalizing of the investment in software and hardware
♦ This means gaining and holding a competitive edge
Overcoming this Inversion of Control issue as well as other control
integration issues requires an architecture designed to isolate the
applications while also providing state, status, and data integration.

Publishing Systems
Zurich Switzerland
November 4, 2000
Components Build Systems
Using a component strategy, systems are
constructed in the same way other
“component based” products are built.
Once a component strategy has been selected, the assembly of these
components into a system is driven by the business architecture not the
technical architecture.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Manufacturing Paradigm
Digital
Asset
Manager
Pagination Layout
System
Object
Store
Editorial and
Advertising
Systems
Story
Page
Image
Content
Management
Reporters
Graphics
Artist
Paginators
Content
Procurement
Creation of
Content
Assignment of
Content to the
Publication
Content
Assembly
Content
Delivery
Output
Management
Publishing the
Paper to
Specific Media
Here’s a simple picture of the business processes involved in publishing
a newspaper. The content creation and management within each
domain can be provided by a best of breed application. The connectivity
between the domains is provided through a layered set of objects which
reside in a central clearing house. The state and status of the content in
each domain is communicated other to domains using this meta object.
The content remains in the application domain until it is assembled on
the published page for output.

Publishing Systems
Zurich Switzerland
November 4, 2000
Enterprise Application Integration
♦ Enterprise Application Integration (EAI) is …
“the integration of applications across the
enterprise in a rational and centralized manner.”
♦ EAI focuses on:
– Integrating publishing enterprise applications, not the data
used by these applications.
– Reusing publishing applications in a variety of ways, some
way that may not have been originally considered
– Integrating these applications at the “process” and “business
practice” level, rather than the Application Interface (API)
level.
– Making the underlying middleware transparent to the user,
through the use of Integration Standards.
The process of building an integrated system starts with the underlying
architecture. This architecture provides the foundation for connecting
the individual system components, without impacting their native
capabilities. The data is manipulated by these applications remains in
the application domain. This data is not shared among the various
applications but is federated between the domains.
This may not seem like a large distinction, but it is a critical factor in the
deployment of integrated applications. If the data is integrated, then the
semantics (the meaning) of the data must also be integrated. This
integration of the data is done in a static manner, with the semantics
defined in advance. If the data is federated then the semantics of the
data is determined at the point of use – usually by the consumer of the
data.
In the integrated architecture the federation process hides the
underlying connections between the domains, so each application
thinks it is the center of the process. The result is a bridge that is
formed between each domain. Information, state, and status travels
across the bridge. On each side of the bridge the application domain
remains intact.

Publishing Systems
Zurich Switzerland
November 4, 2000
System Architecture
The architecture of a system consists of the
structure(s) of its parts, the nature and
relevant externally visible properties of those
parts, and the relationships and constraints
between them.

Publishing Systems
Zurich Switzerland
November 4, 2000
♦ Architecture is the generation of plans for
information systems.
– Architecture is the view of the “whole” rather than a collection
of components.
– Architecture becomes the planning process that defines the
foundation for the information system
♦ System architecture is intimately related to life
cycle cost.
– A well–designed system represents a valuable investment
that yields adaptability to new requirements and technologies
over the system life.
♦ Architecture is the set of decisions about any
system that keeps its implementers and
maintainers from exercising needless creativity.
What is Software Architecture?
The term architecture is so overused in the software business, that it
has become a cliché.
Software architecture is defined as the generation of the plans for
information systems, analogous to the plans for an urban dwelling
space. Software architecture is different from software design. Software
architecture is a view of the system as a whole rather than a collection
of components assembled into a system. This holistic view forms the
basis of the architecture–centered approach to information systems.
Architecture becomes the planning process that defines the foundation
for the information system.

Publishing Systems
Zurich Switzerland
November 4, 2000
Architecture Strategies
♦ Define the goals of the business in a clear and
concise manner, using a notation that is
readable by both humans and machines.
♦ Identify the Information Technology already in
place that meets these goals
♦ Identify gaps in the levels of Information
Technology that fail to meet these goals
♦ Identify the organizational structure needed to
support the implementation of the strategy
♦ Define a layered framework for connecting the
system components
Publishing systems possess a unique set of requirements, which are
continuously increasing in complexity. In the past, it was acceptable to
assemble a set of application that functioned in a serial manner, making
format transformations across application boundaries, and performing the
workflow processes by hand. In the current publishing environment, the
timeliness, seamless workflow and, multi–purpose nature of content has
become a critical success factor in the overall business process.
In the past, publishing information was usually provided through a monolithic
set of applications (standalone applications integrated through file systems on
a network). This critical data was trapped inside the applications, which were
originally designed to liberate the workforce from mundane tasks.
However, without flexibility and adaptability, the users were forced to adapt
their behaviors to the behaviors of the system. The result was a recurring
non–recoverable cost burden on the organization. What was originally the
responsibility of the software became the burden of the user.
An effective publishing system architecture must combine content creation,
content management, content publishing, and information systems.
In order to address these needs, the system architecture must perform the
tasks describe here.

Publishing Systems
Zurich Switzerland
November 4, 2000
EAI Deployment Strategies
Application
to
Application
Integration
EventExchangeDatabaseExchange
Purpose of The EAI
Update another domain Read another domain
Messaging
Systems
Publish and
Subscribe
Systems
Transaction
Process Monitor
Systems
Warehousing
And Datamart
Systems
This simple matrix isolates both the problem domain and the solutions
for integrating the publishing domain.
There are distinctly different problem areas in publishing systems
integration:
• The purpose of the integration – which can be to update the
information in the integrated systems in order to maintain cross–
system consistency, or simply to read data from one system from
another in order to provide a unified view of the distributed data.
• The level at which the integration can be performed – which can
through messages at the application level or through the
exchange of data through a shared database

Publishing Systems
Zurich Switzerland
November 4, 2000
Why is EAI Important to Publishing?
♦ Integration issues transcend the boundaries of
point solutions.
– Single vendor solutions are no longer acceptable
– New classes of applications now dominate the market
• Sales force automation
• Web based customer interaction
• Process driven environments – workflow
• External content acquisition
• Re–purposing of output to non–traditional markets and devices
♦ “Processware” is a class of software that sits
between different applications and allows those
applications to interoperate in a transparent
manner.
In the publishing business the content of the publication is usually
located in a variety of systems. The days of a single monolithic system
that does everything for everyone are over. Today’s systems are in fact
systems of applications, each with a special capability. The users of this
system want each of these specialized systems to work together
seamlessly without requiring any changes to the underlying data or
processes in each domain.
This transparent interoperation of COTS products is what distinguishes
the EAI solution from the integrated solution. This is what separates
Insiight™ from any other product that tightly couples COTS into a
system.
It is the loose coupling of components along with the data and process
neutral architecture that defines EAI Federation.

Publishing Systems
Zurich Switzerland
November 4, 2000
CORBA is an Integration Enabler
EAI is a broad architectural solution space.
CORBA is one paradigm to build EAI
systems. CORBA is well suited to the
publishing industry, as well be shown next.
The middleware market is an enabling technology market. This is
different than an integration technology using API’s, or a technology
that allows items to be connected (RMI for example). This software is
independent of the applications and at the same time is the glue that
holds them together.

Publishing Systems
Zurich Switzerland
November 4, 2000
The CORBA Sales Pitch
♦ CORBA supports many languages (C++ and
Java dominate) in a single distributed application
♦ CORBA supports both distributed and
Component computing models
♦ CORBA is platform and language independent
and an industry standard
♦ CORBA provides interoperability to insure
objects communicate in a heterogeneous
environment
♦ CORBA provide locality isolation for the
components. All components are accessible not
matter where they physically reside
You may hear some sales pitches today for CORBA, if not here’s mine.
This pitch is meant to inform you about a specific technology rather than
try to sell you on a specific product of concept.
What I do want to sell you on is the concept that integrating a bunch of
applications to form a system is actually much harder that it looks.
CORBA provides many of the tools needed to perform this integration.
Other middleware system provides more or less the same tools, but
CORBA is platform and language independent, which is a big
advantage in today’s world.

Publishing Systems
Zurich Switzerland
November 4, 2000
What Is CORBA Really?
♦ CORBA is a standard for distributed objects
♦ CORBA allows an application to request an
operation to be performed by a distributed object
and for the results of that operation to be
returned, independent of the object’s location
♦ CORBA is the mechanism for assembling
components into systems that:
– Scale
– Provide fault tolerance
– Are interoperable on a variety of platforms
CORBA is a technology for integrating business components in a
platform and programming language independent manner.
CORBA is an international standard.
CORBA is an accepted technology for integration system in a variety of
business domains - telecommunications, banking, insurance.
CORBA is NOT a silver bullet, it is an industrially robust way of
managing the integration problem.

Publishing Systems
Zurich Switzerland
November 4, 2000
What Are The EAI Alternatives?
♦ MQ Series
– Windows, AIX and Mainframe based implementations
– Message Oriented
♦ Microsoft Message Queuing Systems
– Similar to MQ Series but Microsoft-centric
♦ Third Party Products
– NEON
– Vitria
– Saga Soft
♦ All are EAI oriented but there are other Critical
Success Factors to consider
There are always alternatives to every technology, here are some
alternatives to CORBA.

Publishing Systems
Zurich Switzerland
November 4, 2000
Critical Success Factors
♦ Adaptive platforms
– Unix and NT dominate here, but there are multiple flavors of
UNIX as well as databases and there is always the Mac
♦ Agile application selection
– The “Best of Breed” list changes with every generation of
product
♦ Scalable resources
– Scalable in terms of performance, capacity, users, locations
♦ Robust (fault tolerant) architectures
– Tandem like behaviors are the benchmark
♦ Natural transition to the Internet
– CORBA and Java “are the net,” anything less will become an
“Instant Legacy” system
These Critical Success Factors could be applied to any system
integration architecture. So what makes CORBA unique here? CORBA
provides these in one package, external from the business applications.
It provides them through a set of standard interfaces, a standard
processing model, and a standard set of platforms and programming
languages.

Publishing Systems
Zurich Switzerland
November 4, 2000
Staying Focused on the Outcome
♦ The bottom line is Business Issues usually
dominate Technical Issues
– So the choice of a technology must be
based on a business analysis
– What is the cost of providing a feature set
using a specific architecture?
♦ Buy or build a monolithic set of applications
– How will these be integrated?
– How will the scale to the internet?
– How will these applications adapt to changes in the Best of
Breed product list?
♦ Adopt the CORBA (or other middleware)
paradigm
All technical decisions need to start with the business process. By
focusing on the business requirements the technical aspects of the
decision can be put in the proper perspective.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Good, The Bad, and the Ugly
Monolithic Approach
♦These systems are
composed of Application
Programming Interfaces
(APIs) that are connected
with other applications, one
connection times the
number of components (bi–
direction).
♦The APIs are usually
provided by the vendor of
the application, so
consistency, uniformity and
standards are not assured.
Component Approach
♦ These system are
composed of Objects that
interact through a
standard interface
protocol.
♦ The interface between
these components is
provided by a
standardized language.
There is no such thing as a free lunch, so let’s look at the costs of both
a CORBA based system and a system that makes use of Best of Breed
applications, but integrates them using API’s. I’ll call the API system
monolithic, since the result is a tightly coupled set of applications, all
working together to produce a result. This is a biased view I know. In
the monolithic system the various components are connected to each
other using the integration tools of the application, in other words, there
is usually not a middleware component, whose only job is to isolate the
applications from each other. The resulting monolithic system is
optimized using the applications, but gives up the features of a loosely
coupled system.

Publishing Systems
Zurich Switzerland
November 4, 2000
The Basic Capabilities of Components [†]
♦ Environmental independence – components interoperate
across languages, operating systems, networks,
development and production environments
♦ Location transparency – components can be accessed
from a variety of locations
♦ Interface is separate from the implementation – separation
of concerns is a core object concept
♦ Platform Binary Independence – the ability to install and
use a component out of the box on any platform
♦ Self describing interface – using IDL the interface to the
component is described independently from the
implementation
♦ Universal Application Component Framework – a
component must be able to integrate with one or more
components to form a new well–behaved and well–defined
application
[†] “Component Software for the Enterprise,” Bruce Cottman, I–Kinetics, www.I-kinetics.com
In the loosely coupled system, the connections between the
applications is “mediated” by CORBA. Each application presents an
interface to CORBA, which is then used by other applications. This
interface is defined within the rules of CORBA (the Interface Definition
Language, or the Java Interface) and shared by all other applications.
The result is a set of connecting points that are “neutral” in that they do
not impose the application specific behaviors on the other domains. The
CORBA middleware becomes a “mediator” between the applications.
Applications can come and go from the system without impacting other
applications, since the coupling and cohesion between each application
is minimal.

Architecture Centered Publishing Systems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Architecture Centered Publishing Systems

Similar to Architecture Centered Publishing Systems (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Architecture Centered Publishing Systems