this site is individual site for ueh students of information management faculty this site provides some students resources of it courses such as computer network data structure and algorithm enterprise resource planning

In a well-structured application, information flows between three different layers: The presentation layer (often called the View): presents information to the user and collects infor[r]

Welcome to:

Issues in Electronic Information

Exchange

Unit Objectives

After completing this unit, you should be able to:

Describe the types of information exchange that occur in modern computer systems

Describe information exchange issues that exist in modern

computer systems

Describe what is needed to address many of the issues that exist in information exchange

Electronic Information Exchange (1 of 2)

Electronic information exchange is a simple concept:

Electronically encoded information of one sort or another moves among software units during the execution of some domain- (business) related function

There are several contexts for information exchange:

Intra-application - information movement among the parts of an application

Inter-application - information movement between applications in the same company system

Intercompany - information movement between companies

Inter-system - information movement between systems in the same company

There are problem dimensions in each context that shape the way information is exchanged Some of the problems are common but each context also has unique issues to deal with

Electronic Information Exchange (2 of 2)

Company 1

System 1 (Sales)

Company 2

Company 3

Application (Ordering)

Application (CRM)

System 2 (Accounting)

Intercompany Inter-System

Inter-Application

Intra-Application

Company n

Intra-Application Information Exchange

In a well-structured application, information flows between three different layers: The presentation layer (often called the View): presents information to the user and collects information from the user This layer is often coupled to a particular presentation technology, for example, Presentation Manager, X-Windows, and

so forth Therefore, it often must change significantly when the presentation mode changes.

The processing layer (often called the Controller): operates on the information

in accordance with the functional requirements of the application.

The business layer (often called the Model or Business Model): maintains the operational constraints that govern the business as a whole It ensures that no individual application contradicts those rules by performing an operation that is inconsistent with those constraints.

Presentation Layer (View)

Process Layer (Controller)

Business Layer (Model)

In this context, the biggest Information Exchange issues occur with the View

Agile Views - Multiple Client/Device Support

Prior to the arrival of the World Wide Web, applications were largely presented via workstations or dumb terminals, and required (relatively) infrequent modification of their presentation layer The World Wide Web has changed this.

Now, the addition of the mobile work force and use of handheld devices presents new opportunities for business and new challenges for application developers.

Applications must be presented via:

Cell phones and Handhelds, Wireless Markup Language (WML)

Web Browsers (HTML, Style Sheets, JavaScript)

PDF

And so forth

Many Web applications suffer from coupling issues where applications habitually

generate output that combines Presentation information (font, color, and so forth) with business information (bank balance, product information, and so forth) making it difficult

to reuse the data stream.

Ideally, the presentation layer would emit/consume a generic, structured information stream that can be filtered for the target device.

An external rendering engine worries about how it looks, while the application worries

about what should be viewed.

Enables speedy, low-cost support for new client devices.

Need a View-independent, structured

information stream

Inter-Application Information Exchange

Ideally, the design of a system takes into account all the operations that it will perform and the applications that will perform them.

It is rare that enough information exists to perform such an analysis and rarer still that the design remains stable as the applications that compose the system are constructed (typically at disparate points in time).

Technology does not stand still; it is common to see applications built late in the life of a system using technology that is completely different from that used by the initial ones, for example, COBOL versus Java.

Experience has shown that it is best to focus on the application at hand and allow the plans for a system to evolve as further applications are built based on new knowledge of the problem and new technologies.

The way that applications communicate should not make assumptions about implementation technology or how information will be used

Context-free Communication

As much as possible, eliminate assumptions from the way in which information is exchanged

This means that the information that flows between applications should not be coupled to a particular technology or to an assumption about how it will be used When possible, send an application domain entity, for example, a Purchase Order rather than the individual pieces, for example, a total, an item description, and so forth.

Don't use a message that is bound to an implementation technology, for

example, a Serialized Java Object (a Java-specific bit stream).

Ideally, the communication medium would be based on simple, ubiquitous

technology, for example, straight text.

Should be structured and self-describing to eliminate the need for context

awareness in the receiver.

Requires a structured information (text) format that supports the expression of semantics

B2B Intercompany Information Exchange

In this case, the presentation is focussed on the Business to Business (B2B) relationships that exist in e-business.

In such cases, the systems involved often talk to multiple business partners; sometimes for the same service where selection is based on price, availability, and so forth, for example, Credit Transaction Validation.

Scenario 2

Communicate with business partners through an intermediate 'Marketplace' vendor.

Forced to evolve at the rate of the intermediary

C1

C2 C3

Cn M

Scenario 1

Communicate directly with

business partners, potential

for 'n' communication protocols

C2 C3

Cn C1

Technology issues aside, it is clear that successful, unfettered B2B information exchange depends greatly on the creation of

implementation-independent, vendor-neutral languages in which to conduct business

Markup languages have existed as a means to embed semantics in electronic documents (for example, SGML)

SGML was created as a language for describing documents B2B communication may benefit from a similar solution, that is, use a markup language to describe information

Such a language could be used to describe documents that whole industries agree on as a means to exchange the information they need to conduct business

Need to Establish Common

Ground for Communication

Requires an implementation-independent, vendor-neutral markup language for describing information; enabling the creation of domain-specific business languages.

Inter-system Information Exchange

The exchange of information between systems is subject to most of the problems discussed so far except, perhaps, view coupling Typically, this sort of

communication does not involve a presentation layer.

When laying out the infrastructure in which systems will reside, it is wise to

establish a means of insulating systems from one another with a layer that is devoid of implementation and process coupling let's call this the Interface Layer (it's also known as an Abstraction of the System).

The role of the interface layer is to capture the semantics of a system as seen from an external point of view, and to represent it as a dialog, with messages providing the units of communication in the dialog.

As long as the definition of the system doesn't change, the dialog (the interface to the system) should remain stable The implementation may change significantly.

Need a way to exchange messages in an implementation-independent way

Exchanging Messages

Exchanging messages between systems has a lot in common with exchanging messages between B2B business partners

The exception is that though inter-system information exchange requires an established protocol (the interface), the system does not necessarily benefit from that protocol being an accepted standard for B2B communication

There are other differences, for example, the likely use of Message Oriented Middleware in system integration (MOM), but this presentation is focused on

the information being exchanged not on the exchange mechanism.

So, in common with B2B communication:

Requires an implementation-independent, vendor-neutral

markup language for describing information.

The Semantic Web

Requires self-describing information decoupled from View details

An extension of the WWW

The Web becomes an active (rather than passive) information space

Separation of content from presentation is necessary

That is, Model-View separation

HTML doesn't have this

Look at the browser compatibility problem as evidence for the need for this

In order for the Web to reason, it must be possible to identify the units that are going to be reasoned about

HTML doesn't help with this

Need self-describing data

A Common Solution?

Collecting all the observations together, an information solution addressing each of these issues would be:

a A view-independent, structured information stream

b A structured information (text) format that supports the

expression of semantics

c An implementation-independent, vendor-neutral markup

language for describing information, enabling the creation of domain-specific business languages

d Self-describing, decoupled from view details

In short:

"A text-based, vendor-neutral markup language that supports the expression of semantics."

Such a language would address many information exchange issues

if it gained significant industry acceptance

Checkpoint Questions (1 of 2)

1 Which of the following will reduce the coupling related to Electronic Information Exchange?

(Select all that apply)

a Create messages that are context-free

b Use system interfaces to hide implementation details

c Combine view information and data in each message

d Use messages that are vendor-neutral and

implementation-independent

e All of the above

2 Text-based messages are preferred because:

(Select all that apply)

a They are implementation-neutral

b All software technologies can read/write them

c It's easier to debug messaging problems

d They can be spell checked

e All of the above

Checkpoint Questions (2 of 2)

3 In general, the properties a message should exhibit are: (Select all that apply)

a Self-describing

b Predictable structure

c Conformance to one, industry-wide standard

d All of the above

Unit Summary

Having completed this unit, you should be able to:

Describe the types of information exchange that occur in modern computer systems

Describe the information exchange issues that exist in modern computer systems

Describe what is needed to address many of the issues that exist in information exchange