The XML Files

The XML Files:
Using XML for Business-to-Business

and Business-to-Consumer Applications
XML in IBMs Application Framework

for e-business
Patterns for B2B and B2C
Applications
Learn about TPA-Trading
Partner Agreements
Luis Ennser
Pietro Leo
Tamas Meszaros
Eric Valade
ibm.com/redbooks
SG24-6104-00
International Technical Support Organization

The XML Files:
and Business-to-Consumer Applications
September 2000
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix C, Special notices on page 297.
First Edition (September 2000)

This edition does not apply to any specific operating system or application other than those described
within this document.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 2000. All rights reserved.
Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Part 1. Introduction to e-business and XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. XML and e-business applications . . . . . . . . . . . . . . . . . .
1.1 About e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Business transformation and innovation . . . . . . . . . . . . . . . . .
1.1.2 Which is the e-business value? . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 A simplified classification schema for e-business applications
1.2 The Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . .
1.2.1 World Wide Web document standards . . . . . . . . . . . . . . . . . .
1.2.2 A brief history of XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 XML a universal data format . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 A short comparison of XML and HTML . . . . . . . . . . . . . . . . . .
1.2.5 XML linking and addressing . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6 Advanced type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7 Metadata (RDF and PICS) . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.8 Domain-specific document definitions. . . . . . . . . . . . . . . . . . .
1.2.9 XML in wireless applications. . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.10 XML styling and transcoding . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.11 XML query languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.12 Processing XML documents . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.13 Organizations concerned with XML. . . . . . . . . . . . . . . . . . . .
1.2.14 Typical applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 XML and e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .3
. .3
. .5
. .7
. .8
. 15
. 16
. 16
. 18
. 19
. 20
. 21
. 21
. 22
. 23
. 24
. 25
. 25
. 29
. 30
. 31
. 34
Chapter 2. Introduction to IBM e-business solutions.

2.1 IBM e-business cycle . . . . . . . . . . . . . . . . . . . . . . . .
2.2 IBM Application Framework for e-business . . . . . . . .
2.2.1 Using an asset-based approach . . . . . . . . . . . .
2.2.2 Overview of the IBM Application Framework. . .
2.2.3 Patterns for e-business. . . . . . . . . . . . . . . . . . .
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
. 35
. 35
. 37
. 38
. 42
. 51
. 57
Copyright IBM Corp. 2000
.
.
.
.
.
.
.
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
Chapter 3. XML in the IBM Application Framework for e-business .

3.1 e-business application with XML . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 IBM XML development tools and utilities . . . . . . . . . . . . . . . . . . . .
3.2.1 Open source initiative: the xml.apache.org project . . . . . . . . .
3.2.2 Parsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 XML open frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 OASIS consortium, XML.ORG . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Electronic Business XML initiative (ebXML) . . . . . . . . . . . . . .
3.3.3 WebSphere B2B Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 XML extensions to IBM products . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 WebSphere Application Servers . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 VisualAge for Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 MQSeries Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.4 DB2 XML Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.5 Lotus with XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.6 Tivoli Cross-Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 59
. . 59
. . 63
. . 65
. . 68
. . 68
. . 74
. . 77
. . 82
. . 82
. . 84
. . 85
. . 89
. . 89
. . 96
. . 97
. . 97
. 100
. 102
. 104
Part 2. Designing B2C and B2B e-business applications using XML . . . . . . . . . . . . 105
Chapter 4. Patterns for B2C and B2B applications . . . . . . . .
4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Logical and physical patterns . . . . . . . . . . . . . . . . . . . .
4.1.2 Runtime topology nodes . . . . . . . . . . . . . . . . . . . . . . . .
4.2 e-business patterns for B2C applications . . . . . . . . . . . . . . .
4.2.1 B2C logical patterns for e-business . . . . . . . . . . . . . . .
4.3 e-business patterns for B2B applications . . . . . . . . . . . . . . .
4.3.1 B2B logical patterns for e-business . . . . . . . . . . . . . . .
4.3.2 Physical patterns for B2C and B2B runtime topologies .
4.4 Implementation considerations for XML . . . . . . . . . . . . . . . .
4.4.1 Applications that benefit from using XML . . . . . . . . . . .
4.4.2 Typical design for applications using XML . . . . . . . . . .
4.4.3 A sample of an architecture for XML applications . . . . .
4.4.4 Composing Java object with XML . . . . . . . . . . . . . . . . .
4.4.5 XML filtering with Java servlets . . . . . . . . . . . . . . . . . .
4.4.6 XML/XSL as inputs for a Web application generator . . .
4.4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
The XML Files: Using XML for B2B and B2C Applications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 107
. 107
. 107
. 108
. 110
. 111
. 117
. 117
. 127
. 129
. 130
. 131
. 132
. 135
. 135
. 136
. 136
. 137
. 137
Chapter 5. B2C applications using XML . . . . . . . . . . . . . . .

5.1 The B2C application model . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 The field of business-customer interaction . . . . . . . .
5.1.2 Application models, architectures and components .
5.1.3 XML powers the B2C interaction. . . . . . . . . . . . . . . .
5.2 Enterprise portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Data and application integration . . . . . . . . . . . . . . . .
5.2.2 Content management . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Controlled access to structured information . . . . . . .
5.2.4 Customer relations, recognition, and personalization
5.2.5 Business intelligence and enterprise portals . . . . . . .
5.2.6 Connection to e-commerce . . . . . . . . . . . . . . . . . . . .
5.2.7 New presentation devices. . . . . . . . . . . . . . . . . . . . .
5.2.8 IBM portal examples . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 IBM products and tools in B2C applications . . . . . . . . . . .
5.3.1 Enterprise Information Portal . . . . . . . . . . . . . . . . . .
5.3.2 Lotus Raven suite. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3 IBM WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 IBM products and tools in portals . . . . . . . . . . . . . . .
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 139
. 139
. 139
. 140
. 143
. 144
. 146
. 148
. 151
. 152
. 156
. 157
. 160
. 162
. 165
. 166
. 168
. 171
. 174
. 175
Chapter 6. B2B applications using XML . . . . . . . . . . . . . . . . . . . . . . . 177

6.1 The B2B application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.1.1 B2B: a major business opportunity of business integration . . . . 177
6.1.2 General issues in business-to-business electronic interactions . 179
6.1.3 XML B2B frameworks and standards . . . . . . . . . . . . . . . . . . . . 180
6.2 IBM WebSphere B2B Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.2.1 Trading Partner Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2.2 The IBM Business-to-business Protocol Framework . . . . . . . . . 204
6.2.3 A sample application TPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.4 Using the IBM Visual XML Builder for a specific OBI TPA. . . . . 216
6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Part 3. B2B eMarketPlaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Chapter 7. B2B eMarketPlaces: a case study . . . . . . . . . . . . . . .
7.1 Why the B2B eMarketPlace application? . . . . . . . . . . . . . . . . . .
7.2 eMarketPlaces and online intermediaries . . . . . . . . . . . . . . . . . .
7.2.1 B2B online intermediary business trading models . . . . . . . .
7.3 The E-broker application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 E-broker business models . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Considerations on the impact of XML on the architecture . .
7.3.3 A building block architecture . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 241
. 241
. 242
. 244
. 246
. 247
. 257
. 261
7.3.4 E-broker application functional decomposition . . . . . . . .

7.4 Initial E-broker design activities . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 E-broker access service TPAs . . . . . . . . . . . . . . . . . . . .
7.4.2 The directory service data model in DB2 XML Extender .
7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
. 264
. 271
. 272
. 274
. 279
Appendix A. An example of a OBI TPA XML document . . . . . . . . . . . . 281

A.1 The OBI TPA between Large Co and Pens We Are . . . . . . . . . . . . . . . . 281
Appendix B. Using the additional material . . . . . . . .
B.1 Locating the additional material on the Internet . . . . .
B.2 Using the Web material. . . . . . . . . . . . . . . . . . . . . . . .
B.2.1 How to use the Web material . . . . . . . . . . . . . . .
.......
.......
.......
.......
......
......
......
......
.
.
.
.
295
295
295
296
Appendix C. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Appendix D. Related publications . . .
D.1 IBM Redbooks . . . . . . . . . . . . . . . . .
D.2 IBM Redbooks collections . . . . . . . .
D.3 Referenced Web sites . . . . . . . . . . .
.......
.......
.......
.......
......
......
......
......
.......
.......
.......
.......
......
......
......
......
.
.
.
.
301
301
302
302
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
vi
Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
The e-business adoption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

The e-business applications classification schema . . . . . . . . . . . . . . . . . . . 9
Growth of the business-to-consumer sector . . . . . . . . . . . . . . . . . . . . . . . 12
Growth of the business-to-business sector . . . . . . . . . . . . . . . . . . . . . . . . 14
XML supports a number of other languages . . . . . . . . . . . . . . . . . . . . . . . 20
SAX application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
DOM interface hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
IBM e-business cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Three-tier computing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Application Framework for e-business architecture . . . . . . . . . . . . . . . . . . 44
WEB application topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Using Application Framework for e-business: a simple approach . . . . . . . 52
Leveraging the IBM Application Framework for e-business with XML. . . . 60
XML in a Web application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
IBM XML components in the e-business application architecture . . . . . . . 63
BPF as a business-to-business coordinator . . . . . . . . . . . . . . . . . . . . . . . 88
DB2 XML Extender overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Lotus Domino XML language opens Domino data . . . . . . . . . . . . . . . . . 101
Tivoli Cross-Site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Application topology: Web-up topology 1. . . . . . . . . . . . . . . . . . . . . . . . . 112
Runtime topology: Web-up topology 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Application topology: Web-up topology 2. . . . . . . . . . . . . . . . . . . . . . . . . 114
Runtime topology: Web-up topology 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Application topology: document exchange . . . . . . . . . . . . . . . . . . . . . . . 118
Runtime topology: VAN-document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Application topology: Direct exchange with adapter/bridge . . . . . . . . . . . 120
Runtime topology: Internet direct queue . . . . . . . . . . . . . . . . . . . . . . . . . 120
Application topology: message broker . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Runtime topology: Internet brokered . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Application topology: business protocol managed. . . . . . . . . . . . . . . . . . 123
Runtime topology: Internet managed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Application topology: jointly managed . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Runtime topology: Internet jointly managed. . . . . . . . . . . . . . . . . . . . . . . 127
Typical design for a Web application with XML . . . . . . . . . . . . . . . . . . . . 132
Architecture of XML application with Cocoon . . . . . . . . . . . . . . . . . . . . . 134
The main areas of business-to-customer systems . . . . . . . . . . . . . . . . . 141
Interfaces between the main areas of B2C systems . . . . . . . . . . . . . . . . 142
Enterprise portals connect data, applications and people together . . . . . 145
Integrating clients, applications, and portals . . . . . . . . . . . . . . . . . . . . . . 147
Content management general architecture . . . . . . . . . . . . . . . . . . . . . . . 149
vii
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
viii
Content management using XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Personalization in enterprise portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Transcoding XML documents on-the-fly . . . . . . . . . . . . . . . . . . . . . . . . . 161
Sample News DTD from ibm.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Prototype architecture for ibm.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
IBM product suites in business-to-customer integration . . . . . . . . . . . . . 166
IBM Enterprise Information Portal architecture . . . . . . . . . . . . . . . . . . . . 167
Lotus Raven knowledge portal architecture. . . . . . . . . . . . . . . . . . . . . . . 168
Integrating Lotus Raven and IBM Enterprise Information Portal . . . . . . . 169
A sample screenshot of a Lotus Raven portal . . . . . . . . . . . . . . . . . . . . . 170
WebSphere integrates users, data, applications; offers portal services . 171
WebSphere transcoding customization . . . . . . . . . . . . . . . . . . . . . . . . . . 173
TPAs within B2B XML frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
The TPA structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
The control point role of BPF in inter-enterprise business processes . . . 205
General process flow for BPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
BPF functional layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
BPF set up environment and runtime operations. . . . . . . . . . . . . . . . . . . 210
OBI Participants and flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
The OBI Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
TPA XML document building process within IBM Visual XML Builder. . . 218
Creating a TPA XML model for the OBI TPA contract . . . . . . . . . . . . . . . 219
Selecting the XML document root element . . . . . . . . . . . . . . . . . . . . . . . 220
TPA document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
TPAInfo section of the TPA XML model for the two companies . . . . . . . 224
Transport section of the TPA XML model for the two companies . . . . . . 226
Document Exchange of TPA XML model for the two companies . . . . . . 228
Service Interface section of TPA XML model for the two companies . . . 230
Associating meta-data to a TPA field . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Using the user-exit function in IBM XML Visual Builder environment . . . 233
Group editing facility of the IBM XML Visual Builder environment. . . . . . 234
Calendar editing facility of the IBM XML Visual Builder environment . . . 235
TPA XML document source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
The eMarketPlace and the online intermediary business models . . . . . . 244
The E-broker eMarketPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Interactions between Traders and the E-broker Directory Service . . . . . 250
TPA online building process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
The bulletin board auction information flow . . . . . . . . . . . . . . . . . . . . . . . 253
The reverse auction information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
The regular auction information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
The multiple Request For Quotation aggregation service . . . . . . . . . . . . 256
E-broker functional layers and main applications components . . . . . . . . 262
Directory service: application topology . . . . . . . . . . . . . . . . . . . . . . . . . . 265
84.
85.
86.
87.
88.
89.
Auction service: application topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Aggregation service: application topology . . . . . . . . . . . . . . . . . . . . . . . . 267
Customer support service: application topology . . . . . . . . . . . . . . . . . . . 268
The application topology of E-broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Runtime topology of E-broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Simple database model of a company. . . . . . . . . . . . . . . . . . . . . . . . . . . 277
ix
Tables
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Relationship between XML Features and e-business applications . . . . . . 33

Standard protocols and APIs: Network infrastructure . . . . . . . . . . . . . . . . 48
Standard protocols and APIs: Application server software . . . . . . . . . . . . 48
Standard protocols and APIs: Web application environment. . . . . . . . . . . 49
Standard protocols and APIs: System management . . . . . . . . . . . . . . . . . 49
Standard protocols and APIs: Development tools . . . . . . . . . . . . . . . . . . . 49
Standard protocols and APIs: e-business application services . . . . . . . . . 49
A pattern for each e-business solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Standard protocols and APIs: Network infrastructure . . . . . . . . . . . . . . . . 61
Standard protocols and APIs: Application server software . . . . . . . . . . . . 62
Standard protocols and APIs: Web application environment. . . . . . . . . . . 62
Standard protocols and APIs: Development tools . . . . . . . . . . . . . . . . . . . 62
Standard protocols and APIs: e-business application services . . . . . . . . . 62
List of tools and utilities by category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Product mappings for AIX and Windows NT . . . . . . . . . . . . . . . . . . . . . . 128
IBM products and tools in building enterprise portals . . . . . . . . . . . . . . . 174
XML B2B framework initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
The TPA Preamble section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Product mappings for the E-broker runtime topology . . . . . . . . . . . . . . . 270
xi
xii
Preface
When you get right down to it, e-business is a simple concept. An e-business
is an organization that connects critical business systems directly to key
actors such as customers, employees, suppliers, and distributors, by using
Internet technology. But this simple concept quickly becomes powerful. As
customers, employees, suppliers and distributors are all connected to the
business systems and information they need, e-business actually transforms
key business processes. This book intends to present the emergence, and
the impacts of the Extensible Markup Language (XML) in e-business world.
By reading this book, customers, IBM sales people, IT architects, and IT
specialists will have the opportunity to understand how the marriage
between XML technology and the IBM Application Framework for e-business
can help to leverage e-business applications, particularly those based on
business-to-business (B2B), and business-to-consumer (B2C) models.
In writing this book, residents had many discussions with IBM people involved
in e-business, XML, and related technologies. They also surfed the net (IBM
and non-IBM) to gather information about the e-business world in general, the
IBM e-business vision and solution, and the XML technology applied to the
e-business applications.
This book is designed to expand your knowledge on the following topics:
The e-business market: what is going on, trends, and directions.
The added value of XML technology to help to solve issues, and some
challenges that arise through e-business applications such as data
exchange, portal services, and pervasive device support.
How IBM cuts XML and related technologies down to size in its application
Framework for e-business, including details of the IBM offering in terms of
architecture and tools to design, develop, deploy, and run complex B2B
models (applications sharing services among different trading partners),
and B2C models (applications providing end-users with various services).
This book also depicts a case study in the eMarketPlace field that
demonstrates the ability of XML technology combined with the IBM
Application Framework for e-business to implement both B2B and B2C
models.
xiii
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization San Jose Center.
Luis Ennser is a consultant at the International Technical Support
Organization, San Jose Center. He holds a Bachelor degree in Mechanical
Engineering from IME-Instituto Militar de Engenharia, Rio de Janeiro, Brazil.
Luis has 15 years of experience in Application Development and Networking.
He writes extensively and teaches IBM classes worldwide on all areas of
XML, WebSphere, and Java. Before joining the ITSO, he worked as an
e-business Solution Architect in Brazil.
Pietro Leo is an IBM IT specialist in the IBM SEMEA Sud - Java Technology
Center, Bari (Italy), organized under the IBM Global Services division. He has
eight years of experience in Knowledge Management and Artificial
Intelligence. This includes five years of experience in IBM on Web
applications and object-oriented programming. He holds a degree in
Computing Science from University of Bari (Italy), a Master of Science by
Research in Applied Artificial Intelligence from University of Aberdeen (UK,
and a higher artistic degree in Music (a Diploma in OBOE) from the Music
Conservatoir of Lecce (Italy). His expertise on customer projects includes
areas of Knowledge Management, XML, Project Financing, Knowledge
Based Systems, Intelligent Agents, and Internet Personal Assistants.
Tams Mszros is a research associate at the Budapest University of
Technology and Economics (BUTE) in Budapest, Hungary. He received his
M.Sc. degree in electrical engineering from BUTE. He has seven years of
experience in networking technologies and artificial intelligence, and four
years of experience in intelligent agents and Web application development.
His areas of expertise include intelligent agents, Web application design and
development, operating systems, and artificial intelligence. He has written
extensively on intelligent agents, artificial intelligence methods, and
intelligent product manuals.
Eric Valade is an IBM IT specialist in France. He has 10 years of experience
in EMEA technical pre-sale support for the application development area. He
holds a degree in Computer sciences from Pierre and Marie Curie University
of Paris (France). His areas of expertise include software configuration
management, software development process, and programming. He has
written extensively on IBM CMVC and IBM VisualAge TeamConnection.
xiv
Thanks to the following people for their invaluable contributions to this

project:
Joaquin Picon
International Technical Support Organization, San Jose Center
Indran Naick
International Technical Support Organization, Austin Center
Jonathan Adams
IBM UK
Joel Farrell
IBM US
Martin Sachs
IBM US
Fernando Lopez
IBM US
Christina Lau
IBM Canada
John Ibbotson
IBM UK
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Please send us your
comments about this or other Redbooks in one of the following ways:
Fax the evaluation form found in IBM Redbooks review on page 313 to
the fax number shown on the form.
Use the online evaluation form found at ibm.com/redbooks
Send your comments in an Internet note to redbook@us.ibm.com
xv
xvi
Part 1. Introduction to e-business and XML

This part of the book introduces the main issues concerning the
emerging models of e-business applications on Internet and the
importance of XML in setting up these applications. It also shows what
products IBM offers to help customers in deploying e-business
applications. We provide an overview of these areas for people who
would like to know more about these technologies from the customer
and sales perspectives.
Chapter 1, XML and e-business applications on page 3) gives an
overview of e-business applications and XML. It includes a general
model of e-business applications, and identifies the main types
(business-to-business, business-to-consumer, business-to-employee
and intra-company applications). It briefly introduces XML and related
technologies, standards, organizations, and typical applications. The
last part of this chapter summarizes how XML and related technologies
can be used in building e-business applications.
Chapter 2, Introduction to IBM e-business solutions on page 35
introduces the IBM Application Framework for e-business. It describes
the architecture, programming model, design approach, and
e-business cycle within the framework. It also shows how XML
technologies can fit into the e-business Application Framework on both
the client and server sides.
Chapter 3, XML in the IBM Application Framework for e-business on
page 59 presents the IBM XML initiatives and offerings related to
business applications, such as XML components; B2B frameworks,
such as the announced WebSphere B2B Integrator; and extensions to
other IBM products, such as the WebSphere family, DB2, VisualAge for
Java, and MQ.
Chapter 1. XML and e-business applications

The purpose of this chapter is to provide you an overview of e-business
applications and XML technology. First, we describe a general model of
e-business applications, and identify the main types: inter-business
applications (business-to-business and business-to-consumer applications)
and intra-business applications .
Next, we introduce the Extensible Markup Language (XML) and related
technologies, standards and organizations, and we show some typical
applications.
Finally, we summarize how XML and related technologies can be used in
building e-business applications.
1.1 About e-business

At the beginning of the Internet era, IBM invented the term e-business to give
a proper name to a new class of powerful software applications and services
that, in its vision, should be developed in the following years. These
applications derive their power from combining the universal access and
standards of the Internet with the reliability, security, and availability of
existing content, core business processes, and applications.
In very simplified terms, e-business refers to the use of Internet technologies
to improve and transform key enterprise processes. Most organizations
understand this, and have begun the transformation from traditional
applications to their e-business counterparts. This transformation has begun
to Web-enable core processes to strengthen customer service operations,
streamline supply chains, and reach existing and new customers.
Probably one of the best-known applications of e-business is e-commerce,
which refers to buying and selling activities over a digital medium. However,
as we will soon clarify, e-business embraces e-commerce and includes
intranet applications. e-business is the overall strategy, although e-commerce
is an extremely important subset of e-business.
In what way is e-business different than the old order? Some characteristics
of the e-business model that set it apart from legacy business systems are
these:
The e-business model facilitates transactions with a much wider group of
respondents.
Communication and other transactions are instantaneous.

Customers are empowered.
Competition is fierce.
Customer communities will emerge.
Examples of companies implementing e-business applications can be easily
found as simply as you can browse the Web. But to be much more concrete,
and to give you a better idea what e-business applications are, we
recommend that you see the case studies discussed at the IBM Web site
http://www.ibm.com/e-business.
Following are some typical case studies:
A commercial insurer developed an online billing inquiry system for agents
that saves upwards of $5000 a month in call center expenses and acts as
a platform for a wide range of agent communications needs.
A retail bank offers Internet banking as a successor to direct-dial home
banking by supplying enhanced home banking features and services
through the Internet. This application enables the retail bank to acquire
new accounts, transition existing customers to home banking, reduce
operating costs, and free up customer service personnel to provide
value-added services.
A retailer implements an e-business supply chain solution to increase
collaboration with suppliers. In particular, the e-business solution provides
the retailer's suppliers with real-time sales and supply information along
the entire supply chain. The solution has resulted in significant
improvements in shelf-availability of key products (from 87% to 98%) and
time required for product introductions and promotions.
A government Motor Vehicles Registration Division improved service and
reduced cost by creating a Web-based driver's license renewal process
that increases renewal alternatives, decreases transaction time, and cuts
direct transaction costs while helping the division maintain the same level
of operating budget.
These are only a few examples of the value that companies are creating
when they implement e-business. But, realizing this value is not simply a
matter of establishing a Web site or a single, discrete, online application. It
arises from an e-business vision and an e-business roadmap that begins with
an initial solution that is extendable into other high-value areas of the
business. e-business is not just about e-commerce transactions; it's about
redefining old business models with the aid of technology.
In summary, an e-business is an organization that connects critical business

systems directly to their customers, employees, partners, and suppliers, via
intranet, extranet, and over the Web. As customers, employees, suppliers,
and distributors are all connected to the business systems and information
they need, e-business actually transforms, innovates, and integrates key
business processes.
1.1.1 Business transformation and innovation

The convergence of Internet technologies, IT systems, and business
processes creates new business models: e-business models. Thus,
e-business poses the most significant challenge to the traditional business
model. Computers have increased business speed by automating tasks, but
have not fundamentally altered the business foundation; e-business does
this. If any entity in the value chain begins to do business electronically,
similar companies must follow suit or risk being eliminated. Rethinking and
redesigning the business model is not an option, but a necessary step to
surviving in the information era.
Companies have found that success in e-business is typically based on
building efficient value-added relationships with their customers. Those
companies exhibiting the highest degree of satisfaction and success with
e-business consistently focus their strategy on improving their performance
for their customers. Whether simply making it efficient for a customer to place
an order for a product or service, Web-linking and customizing access for a
supplier network, or integrating a real-time collaborative product
design/development process, the goal is to serve customers better.
Regardless of size or industry, companies follow a similar pattern of
e-business adoption. Figure 1 illustrates the typical e-business adoption
roadmap.
Awareness Presence
Use the Establish

Internet a Web site
internally
Pilot
Adoption
Allow
Allow
access transactions
to key
on key
systems
systems
Process
Investment
CrossProcess
Integration
Improve key
business
process(es)
Redefine
key
process(es)
(read only)
Figure 1. The e-business adoption process
The first two steps are typically a companys introduction to using Web
technologies deploying intranet applications to communicate with
employees and establishing external Web presence with information about
the company and its offerings.
This experience has led companies to take the first steps toward real
e-business the establishment of pilots that give customers and suppliers
access to the information contained in key business systems for example,
opening up the customer database that a service representative views and
providing this information to customers directly.
The next step in the cycle extends legacy transaction capability to customers.
The travel industry, for example, offered online bookings, while retail banking
offered online banking.
The final two steps in the process offer the greatest opportunity for return, as
companies transform their business processes by integrating multiple
back-end systems to create a common user experience. As an example, an
airline has integrated all travel systems and customer processes for
bookings, upgrades, seat and meal selection, awards redemption, and
frequent flyer account management.
During these last two steps, not only can a customer buy or process
transactions online whenever they wish, but the company gains valuable
insight and knowledge about the specific needs and behaviors of its
customers. They can also segment customers from a behavioral perspective
as well as from a value perspective. However, without an initial effort to make
the data customer-ready, value for both the customer and the enterprise,
though real, would be minimal. Many companies have begun offering online
transactions to reduce their costs without considering the value for their
customers and, therefore, have not achieved sustained customer
commitment to the system.
In the process investment phase, armed with this customer knowledge and
with the integration of business intelligence tools, analyses, and insights,
companies can improve the customer relationship process by personalizing
customer interactions online and integrating the customer view for their entire
enterprise. Through these personalized interactions, customer retention and
loyalty analysis can be applied to serving the customer more effectively at the
point of need, rather than integrating this information after the fact.
Cross-process integration, the final phase in e-business evolution, focuses on
integrating across all the processes in an enterprise as well as across
customer processes. For the enterprise, this means integrating all the
customer touch points across all operational systems from supply to demand
fulfillment, and through customer satisfaction. For the customer, it means
linking the systems of all the suppliers involved in their process. Airlines, for
example, have integrated their booking systems with their frequent traveler
services internally and have linked into their travel partner systems to begin
offering passengers a single convenient point of fulfillment; retail banks are
integrating their services into a much broader single service access point for
their online customers.
1.1.2 Which is the e-business value?

There are several trends that are shaping the e-business necessity, and at
the same time, its value:
Businesses of all sizes are impacted by globalization and deregulation,
which lowers barriers to entry and dramatically reshapes the competitive
landscape.
Customers now have a broader array of choices and, therefore, are
becoming more sophisticated and more demanding both in what they
want from a supplier and how they choose to acquire goods and services.
As a consequence of the fact that markets are becoming increasingly

fragmented (see the first two points above), mass marketing is fading in
importance as mass customization becomes the path to serving
discriminating customers.
Technology continues to evolve rapidly to support this environment. The
global reach of the World Wide Web enables companies to reach
customers anywhere and to connect to employees, suppliers and trading
partners wherever they are. This will create an expanding amount of data,
which now can be mined for insight leading to better decisions creating
ways to know and serve your customers better and more profitably as well
as ways to gain a competitive advantage.
Thus, e-business can dramatically improve competitiveness and create new
paths to customer loyalty.
1.1.3 A simplified classification schema for e-business applications

There are a number of ways to classify e-business activities. In this section,
these are divided based on the scope of the applications, and on the players
at each end of the transaction.
Concerning the application scope, we have two main categories:
Intra-business applications
Inter-business applications
The first category, intra-business applications, includes all e-business
applications that have a company/organization internal scope. These
applications lie in the company/organization boundary and they are
connected to internal business activities. For example, this class includes the
realization of an Intranet Information Web Site for company employees.
The second category, inter-business applications, includes all applications
that require some kind of interaction between the company/organization and
some other external entities, such as a customer, a company trading partner,
or a financial institution. For example, as we will see better in the following
sections, an e-commerce application which models a buying/selling activity
between a company and its customers over Internet is an inter-business
application as well as a Web-bank application, where, by using the Web, the
bank customers can view their account balances, their recent transactions,
and other financial data.
Note
One could argue that sometimes the boundary between an intra-business

application and an inter-enterprise application cannot easily defined.
However, just for the purpose of this classification, we are referring to
intra-business applications as all applications that are interfaced/used
directly by company employees and/or other systems belonging to the
company and are isolated from the external world. Complementary,
inter-business applications are all those applications that can be interfaced
by external end-users (for example, a customer) and/or external
applications (trading partner applications).
Classification of e-business activities, or business processes, is described in

more detail in the following sections. It is important to note that, although the
following sections make a distinction between intra-business applications and
inter-business applications, from the infrastructure solutions point of view,
this distinction can disappear.
In fact, IBM has defined another convenient way to describe the architectural
nature of the e-business solutions that can be applied both to intra-enterprise
and inter-enterprise models. As the next chapter explains, recently IBM has
introduced Patterns for e-business which will allow IT architects in 80% of
cases to quickly develop 80% of their required infrastructure by reuse of
proven architecture patterns, design patterns, and runtime patterns, as well
as offering design, development, and deployment guidelines and code.
Figure 2 illustrates the e-business application classification schema.
Company
e-business applications
intra
Trading Partners
inter
Redesigned
applications
Business To
Business
Business To
Employee
Business To
Consumer
Legacy
Customers
Figure 2. The e-business applications classification schema
1.1.3.1 Intra-business applications

Most intra-enterprise solutions are based on an intranet infrastructure where
the purpose of an intranet is to share company information and computing
resources among employees usually, this class of applications are known
as business-to-employee (B2E). An intranet can also be used to facilitate
working in groups and for teleconferences.
Content can be acquired from:
Existing internal databases
Existing internal publications
External databases and publications
New content from employees
There are four general categories of intra-business applications:
Internal communication: This creates an involved and communicative
environment by making information accessible to an
company/organizations employees/members.
Knowledge management: This is the identification and analysis of
available and required knowledge assets and knowledge asset related
processes. Knowledge assets are the knowledge regarding markets,
products, technologies, and organizations that a business owns or needs
to own, and which enable its business processes to generate profits and
provide value.
Knowledge management means facilitating an environment where
knowledge, such as standards, common processes, and best practices,
is shared and exploited by any group, department, or division in an
organization. This involves the process of capturing and leveraging a
companys intellectual capital, which is a valuable commodity in many
companies.
Knowledge management includes collaboration which exploits the Web
technology to create team-oriented work environments that are more
productive, higher quality, and enjoyable.
Business intelligence: This means the development of applications able
to individuate information that are conclusive, fact-based and actionable.
Typically, business intelligence solutions combine consulting and services,
applications, and technologies to gather, manage and analyze data,
transform it into usable information to develop the insight and
understanding needed to make informed decisions.
10
Using the latest e-business technologies, this intelligence can then be

distributed around your company or around the world helping to make
crucial and profitable decisions.
Business process redesign: This means transforming inefficient
practices and processes inside the organization, from supply chain
management to internal procurement or expense reports.
1.1.3.2 Inter-business applications
Inter-business applications are all applications that require some kind of
interaction between a company/organization and some other external entities
such as a customer, a company trading partner, a financial institution, or
public administration departments. Inter-business applications can be divided
into two main subclasses: business-to-consumer (B2C) and
business-to-business (B2B).
Inter-business application is the class of e-business application on which this
book focuses and, as it will be better clarified in the following, it is also the
class of application to which XML has its main impact.
Business-to-consumer applications (B2C)

This is, by far, the most common type of e-business. Activities are driven by
the consumer and, usually, are based around the Internet. The consumer is
outside of the organization using the service. This service could take the form
of goods or information. It is also widely known as Enterprise Portals, to refer
to the set of Web-based applications that enable companies to connect
customers to their information systems, and that provide a single gateway to
the personalized information needed to make business decisions.
Some of the services provided by a business-to-consumer solution may also
hold true for intra-company solutions. The following are some of the most
common processes that are contained within this activity:
One-way marketing is the electronic presentation of goods and services,
such as:
- Site Information
- Press releases and announcements
- Forming part of a marketing strategy based on a brand or corporation
a form a Web-selling, but the commodity is brand or corporate
information
11
Customer self-service includes queries from customers (consumers or

businesses), for example:
- Account inquiries
- Customer service
- Help desk
Online ordering (Transaction/Dynamic) includes online order taking and
bill presentation for any of the following:
-
Electronic Catalogs
Web stores
Web selling
Web auctions
Bill Payment (Transaction/Dynamic) includes online payment and

transaction handling.
Figure 3 shows how fast the business-to-consumer sector is growing.
Software
Other
Groceries
Books
Computers/CE
Travel
1998
1999
2000
Billions
$300
High Estimate
$180
2001
2002
2003
Source: Forrester, Morgan Stanley Dean Witter, Giga, IBM Analysis
Figure 3. Growth of the business-to-consumer sector
12
Business-to-business applications (B2B)

These types of applications focus on using the Internet and/or extranet to
improve business-to-business partnerships and transform
inter-organizational relationships. Companies can cut the cost of operations
and production, improve business processes, and deliver more value to
market by leveraging e-business enhanced partnerships.
e-business feeds new kinds of relationships between organizations. Some of
the newest types of relationships are:
Automation, automating the exchange of information between businesses
Collaboration, sharing information and knowledge between businesses for
mutual benefit
The most common process that is contained within this activity is supply
chain integration. The supply chain integration refers to Web-enabling legacy
systems to provide visibility to select partners, suppliers, and customers, and
to integrate the supply chain into other corporate processes using customized
extranets. An organization may have already had some or all of its supply
chain integrated using earlier technologies, such as Electronic Data
Interchange (EDI).
The following are a few processes related to supply chain integration and how
they might be improved using the Internet:
Supplier management
Reduce the number of suppliers, and get them to become partners in
business in a win/win relationship.
Inventory management
Shorten the order-ship-bill cycle by electronically linking them, thus,
allowing the reduction of inventory levels, improved inventory turns, and
eliminating out-of-stock occurrences.
Distribution management
Move documents related to shipping, such as bills of landing, purchase
orders, advanced ship notices, and manifest claims, into an electronic
mode, thus, allowing improved resource planning.
Channel management
Quickly disseminate information about changing operational conditions to
trading partners. Technical, product, and pricing information can now be
posted to electronic bulletin boards, allowing instant access.
13
Payment management
Link the company, supplier, and distributors so that payments can be sent
and received electronically, thus, eliminating thousands of labor hours per
week.
Financial management
Enable global companies to manage their money in various foreign
exchange accounts.
Sales force productivity
Improve the communication and flow of information among sales,
customer, and production functions, thus, creating greater access to
market intelligence and competitor information.
Figure 4 shows how fast the business-to-business sector is growing.
$3.2
Trillions
Other
Utilities
Petrochemicals
Motor Vehicles
Computing/Electronics
High Estimate
$1.8
1998
1999
2000
2001
2002
2003
Source: Forrester, Morgan Stanley Dean Witter, Giga, IBM Analysis
Figure 4. Growth of the business-to-business sector
14
During recent months, the traditional B2B model, centered around the
buyer-seller transaction paradigm, is showing its limitations: it is definite in
scale and displays only partial efficiency in terms of market economics. To
overcome these limitations, a new internet business model appeared which
supports B2M2B and leverages existing B2B applications and technology.
The M represents the eMarketPlace or online trading communities which
assist multiple buyers and suppliers in exchanging information and
transactions.
Trading communities are internet based hubs that focus on specific industry
verticals (see, for example, the recent hub, Component Knowledge, launched
by IBM Global Services for the electronic components market) or specific
industry processes that use various market making mechanisms (auctions,
exchanges, aggregation) to mediate any-to-any transactions among
businesses.
Through the trading communities (hubs), buyers and sellers can trade
electronically with established partners and, at the same time, get access to
new markets and new parts of the supply chain. These eMarketPlaces can be
public, where all members participate in an open, interactive buying and
selling community; or private, which are invitation-only communities whose
members participate in special pricing arrangements and/or product and
service offerings. Online trading communities have the potential to create
excellent and efficient markets.
A much more detailed description of the B2B online trading communities and
their related issues is provided in Chapter 7, B2B eMarketPlaces: a case
study on page 241, which proposes a case study in this interesting field.
1.2 The Extensible Markup Language (XML)

This section introduces the Extensible Markup Language (XML) and related
standards, the organizations behind this technology, and the current trends.
This introduction does not cover the technical details of these standards. For
a detailed technical description of these technologies, read The XML Files:
Using XML and XSL with WebSphere 3.0 by Luis Ennser, Christophe Chuvan,
Paul Fremantle, Ramani Routray, and Jouko Ruuskanen (IBM Redbook
SG24-5479-00).
15
1.2.1 World Wide Web document standards

The World Wide Web (WWW) became very popular and widespread in the
past 5 years. Trends in communication networks, personal computers, and
operating systems, as well as the underlying technology of the WWW, made it
easy to access and use. The Web relies on two main standards, the
HyperText Markup Language (HTML) and the HyperText Transfer Protocol
(HTTP). Implementations of these standards can be found on all major
platforms of todays computing systems, from personal computers to
mainframes, regardless the operating system used on them.
Web browsers implement the HTTP protocol to receive content from the Web
and display the received HTML documents to the user. They became
available on every platform and provide universal access and user interface
to the http://www. On the other hand, Web servers were designed to deliver
HTML files to browsers using the HTTP protocol. Due to the licensing policy
of the first server and browser implementations (they were practically free to
use, and the source code was also available), they soon became widespread.
HTML was designed to describe the presentational format of a document. It is
text-based, therefore, a simple text editor is enough to create and edit HTML
documents. Internet Service Providers (ISPs) introduced Web services to
their customers to store and publish HTML files, and the WWW became a fast
growing supply of information for the Internet community.
As more and more users published their Web documents on the Internet, and
software vendors introduced new features to their browsers, the HTML
standard was extended by new, de facto components and features. However,
it remained a limited standard in a way, because it concentrates on the
presentation, and not on the content.
The growing amount of data stored in HTML format, and increasing problems
of handling this data, led to a proposal of a new document standard for the
World Wide Web, the Extensible Markup Language (XML).
1.2.2 A brief history of XML

In 1969, an IBM team developed a document description language (the
Generalized Markup Language, GML) to solve the problem of different
document formats of various systems. GML formed the basis of many IBM
documentation systems, including Script and Bookmaster. In the following
years, the language evolved into the Standard Generalized Markup
Language, which became an international standard (ISO 8879) in 1986 for
the format of text and documents.
16
SGML is the document standard for big industries like airplane construction,
automobile, and military. Its strengths are being an implementationindependent, generalized, structured, and extensible language. These
features made it popular for companies that create, handle, and distribute
large amounts of text data.
In 1989, researchers at the CERN European Nuclear Research Facility
developed a hypertext version of the SGML standard, called Hypertext
Markup Language (HTML) to solve information sharing tasks within the
organization. HTML inherited important features from SGML (such as being
structured, implementation-independent, and descriptive), but it was also
limited in many areas (it used a fixed set of element types, and it
concentrated on the presentation). These limitations were necessary to make
the language more simple for easy software implementation and editing.
However, the growing amount of data stored in Web systems put these
limitations into focus. The World Wide Web Consortium (W3C, the
organization behind the Web standards) introduced several extensions to the
HTML standard to solve its interoperability and scalability problems, but
finally it decided to develop a new subset of the SGML standard, XML, for
Web use.
The Extensible Markup Language (XML) was developed to overcome the
limitations of the HTML standard. It retains most of the features of the SGML
standard, but makes it easier to implement and use in the World Wide Web
environment. It became W3C standard in 1998.
The initial draft of this new standard included ten key design goals, which are
worth listing here:
XML shall be straightforwardly usable over the Internet.

XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute
minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness is of minimal importance.
17
1.2.3 XML a universal data format

XML is practically almost indistinguishable from SGML. It has almost all of the
capabilities of SGML that are widely supported by implementations, but it also
lacks some important capabilities of SGML that primarily affect document
creation, not document delivery. That is because XML was not designed to
replace SGML in every respect, but only on the Web.
While HTML is a single markup language, designed for a particular
application, XML is really a family of markup languages: in fact, you can
define any number of markup languages in XML. This means that almost any
type of data can be easily defined in XML. So, in addition to a universal
communications medium (the Internet), a universal user interface (the
browser), we now have a universal data format XML.
XML is universal, not only by its range of applications, but also by its ease of
use: its text-based nature makes it easy to create tools, and it is also an
open, license-free, cross-platform standard, which means anyone can create,
develop, and use tools for XML. What also makes XML universal is its data
description power. Data is transmitted and stored in computers in many
different ways: originally it was stored in flat-files, with fixed-length or
delimited formats, and then it moved into databases, and often into complex
binary formats. XML is a structured data format, which allows it to store
complex data, whether it is originally textual, binary, or object-oriented. To
this day, very few data-driven technologies have managed to address all
these different aspects in one package except XML.
In markup languages, like XML, SGML, and HTML, the information pieces in
a document are marked with beginning and ending tags. These markings
identify the pieces according to the creators intentions (within the frame of
the language). For example, in HTML, these tags instruct the browser as to
how it should present the data between the marks to the viewer. In SGML and
XML, these tags can do more: they can describe the information content held
by the data between the marks. To define what is the meaning of the tags
used in a document, these languages use the document type definition (DTD)
description. Document creators can select or create a DTD they want to use
to specify the meaning of tags.
The DTD defines all elements used in a set of documents, and it also
specifies the relation of these tags to each-other in a tree format. Each
element has an element type name (tag name) and a set of attributes. Each
attribute consists of a name and a value. In XML 1.0, element type names
and attribute names are strings of (a restricted set of) characters, similar to
identifiers in programming languages.
18
1.2.4 A short comparison of XML and HTML

The problem with data available in HTML format is that it is formatted for
people to view, and not for computers to use. HTML consists of a pre-defined
set of tags, primary for viewing purpose. This makes it a language that is
easy to learn and accessible, but since it only concentrates on the
presentation, it is hard to reuse the data in HTML format.
This is where XML enters the picture. As its name indicates, XML is
extensible, which means that you can define your own set of tags and make it
possible for other parties (people or programs) to know and understand these
tags. This makes XML much more flexible than HTML. In fact, because XML
tags represent the logical structure of the data, they can be interpreted and
used in various ways by different applications. See Figure 5.
Much of the value of the Web comes from re-using data. For example, one of
the great success stories of the Web are the search engines. They work on
the basis of a universal communications method (HTTP), and a universal
markup language (HTML), to catalog Web pages. However, search engines
work on very limited information, because only a tiny part of an HTML
document is designed to be used by a search engine (new XML based
initiatives such as Resource Description Framework will make search engines
more powerful; see 1.2.7, Metadata (RDF and PICS) on page 21). Imagine
how much more powerful search engines could be if the data that they search
was stored in a simple, structured, re-usable format, that concentrates on
describing the data, and not on the presentation.
A number of standards and specifications make XML more usable for the
World Wide Web. The XML standard itself does not contain information about
linking documents together, referencing to each other, using stylesheets,
defining document access interfaces, and so on. The W3C is working on
related specifications that make this technology more complete.
There are also related specifications that target particular application areas,
and solve different tasks. XML, as a low level syntax for representing
structured data, provides a solid basis for defining a wide variety of
application-specific languages and standards. A number of XML-based
specifications are now under development at W3C and other industrial
organizations.
19
domain specific standards
SMIL
tpaML
SVG
XHTML
resource description standards
PICS
...
P3P
...
RDF
XML
Figure 5. XML supports a number of other languages
In general, these specifications are work-in-progress. This means that most

of these specifications have not reached the standard level; they are
candidates for standards, working drafts, or proposals for new
standardization. For more information about their current status, visit the
W3C Technical Reports and Publications Web site at:
http://www.w3.org/TR/
Also see the OASIS XML Cover Pages at:

http://www.oasis-open.org/cover/sgml-xml.html
The following sections introduce several new proposals in different areas like
styling, enhanced type definitions, and accessing XML documents from
computer programs.
1.2.5 XML linking and addressing

There are specifications for linking and addressing XML documents. Linking
means establishing relationships between objects; addressing means
describing how to find linked objects.The XLink (XML Linking Language)
specification describes constructs that may be inserted into XML resources to
describe links between objects. It can describe simple links like those in
HTML, as well as more sophisticated multi-ended, typed links. The basic form
of address is a Uniform Resource Identifier (URI, RFC 2396), which is a more
general form of resource location than the Webs URL (Uniform Resource
Locator, RFC 1738).
20
The XPath (XML Path Language) is a language for addressing parts of an

XML document. It operates on the abstract, logical structure of an XML
document. The XPointer (XML Pointer Language) specification supports
addressing into the internal structures of XML documents. It is an extension
XPath to address points, ranges, and nodes; to locate information by string
matching; and to use addressing expressions in URI-references as fragment
identifiers.
1.2.6 Advanced type definitions

There have been several proposals to enhance the applicability of Document
Type Definitions. In a situation where different types of DTDs can exist within
the same application (or document), a simple character string may not be
enough to specify tags used in a document. The XML Namespaces
recommendation extends the data model to allow element type names and
attribute names to be qualified with a URI.
Since the XML Document Type Definition is a restricted format (more
restricted than the SGML DTD), there are limitations when it comes to
defining complex relationships between data elements and their usage,
especially when XML documents also use namespaces which might define
elements conflicting with DTD declarations. To resolve these limitations, a
new standard was proposed: XML Schema.
The purpose of a schema is to describe a set of document constructs to
constrain and document the meaning, usage, and relationships of their
constituent parts: datatypes, elements with their content, and attributes with
their values. Schemas specify richer models for data typing and inheritance.
Schemas strengthen the document modelling and validating capability of
XML, and make it possible to express structural relationships between
document types.
1.2.7 Metadata (RDF and PICS)

Metadata, or data about data, provides information about data objects. This
information can be used to label and catalog data. Metadata helps in
organizing, locating, and understanding data. It provides a means to improve
the productivity of the data management process.
W3C's metadata activity is concerned with ways to model and encode
metadata developing RDF and PICS, two metadata standards.
21
Resource Description Framework (RDF, http://www.w3.org/RDF) integrates

a variety of Web-based metadata activities, including site maps, content
ratings, stream channel definitions, search engine data collection, digital
library collections, and distributed authoring. It is a declarative language
and provides a standard way for using XML to represent metadata in the
form of statements about properties and relationships of Web resources.
RDF also provides a framework in which independent communities can
develop vocabularies that suit their specific needs. The descriptions of
these vocabulary sets are called RDF Schemas. A schema defines the
meaning, characteristics, and relationships of a set of properties, and this
may include constraints on potential values and the inheritance of
properties from other schemas. A well-known RDF Schema is the Dublin
Core, developed by the library community. RDF uses the idea of XML
Namespaces to allow RDF statements to refer to a particular RDF
vocabulary.
Platform for Internet Content Selection (PICS, http://www.w3.org/PICS)
consists of a set of specifications which allows people to assign labels to
digital information for describing metadata. Labels contain information
about the content in simple, computer-readable form. This information can
be used according to users settings for filtering out undesirable material
or directing users to sites that may be of special interest to them. While
PICS has general applicability to labelling pages for a variety of metadata
purposes, the PICS specification was originally designed to allow parents
and teachers to screen out materials unsuitable for children using the
Internet.
1.2.8 Domain-specific document definitions

There are specialized vocabularies (DTDs) for different application fields.
These pre-defined DTDs define a common document structure for the given
application field to ensure that different application vendors use the same
element definitions for same purposes.
There are DTD repositories where you can find definition files for your
application field. There are only a few standardized document definitions at
the time of writing this book, but it is expected that the number of these
standardized DTDs will increase greatly as the industry leaders and standard
bodies agree on them in various applications fields.
Horizontal XML specifications, which are not tied to a single application field,
contain information about several fields, for example, measurements, date
and time, country codes, basic business forms, and descriptions of
businesses and individuals.
22
Vertical XML specifications describe a specific application area like electronic

payment, mathematics, or chemistry. For example, a specialized language for
trading is the Trading Partner Agreement markup language (tpaML) proposed
by IBM, which will be described in detail in 6.2.1, Trading Partner
Agreements on page 185.
There are also collections of vocabularies like Open Buying on the Internet
(OBI, http://www.openbuy.org), Open Applications Group
( http://www.openapplications.org), Open Travel Alliance (OTA,
http://www.opentravel.com), and RosettaNet ( http://www.rosettanet.org).
The World Wide Web Consortium also redefines the HTML standard based
on XML. This new document standard is called XHTML (Extensible HyperText
Markup Language, http://www.w3.org/TR/xhtml1), that is now a W3C
Recommendation. The XHTML 1.0 specification describes XHTML, a
reformulation of HTML 4.0 as an XML 1.0 application. This aims to move
HTML into the XML area while retaining its processing ability in standard Web
applications. XHTML is intended to be used as a language for content that is
both XML-conform and operates in HTML 4 conforming user agents.
1.2.9 XML in wireless applications

Wireless application environments are domains where XML has already been
playing an important role. These applications have special requirements for
document formats and rendering due to their limited bandwidth and display
capabilities. There are several XML-related proposals to fit mobile devices
into the World Wide Web.
The W3C User Interface domain contains a Mobile Access Activity
( http://www.w3.org/Mobile/Activity), that is working on protocols and data
formats to ensure that provide an effective way to access the Web from
mobile devices. They are working on presentation languages as well as on
resource description formats that can represent the capabilities of these
devices.
The Composite Capability/Preference Profiles (CC/PP) specification is
currently a W3C Note. It is a user side framework based on XML and RDF
that describes the capabilities, hardware, system software, applications, and
user preferences used by someone to access the Web. These information
might include the preferred language, sound on/off, images on/off, class of
device (phone, PC, printer, or other), screen size, available bandwidth,
version of HTML supported, and so on.
23
The Wireless Application Environment (WAE, http://www.wapforum.org)

specification contains several documents that describe the application
environment. It includes the WML, WBXML, WMLScript and its standard
libraries, and finally, the Wireless Telephony Application Specification and its
application interface specifications.
WML (Wireless Markup Language) is a markup language based on XML, and
is intended for use in specifying content and user interface for narrowband
devices, including cellular phones and pagers. WML includes four major
functional areas:
It includes support for text and image, formatting and layout commands.
Deck/card organizational metaphor structures information in a collection of
cards and decks.
The inter-card navigation and linking supports the navigation between
cards and decks.
String parameterization and state management is possible in WML decks,
using a state model.
WAP Binary XML Content Format (WBXML, http://www.w3.org/TR/wbxml/)
proposed by Ericsson, IBM, Motorola, and Phone.com, defines a compact
binary representation of the Extensible Markup Language. It is designed to
reduce the transmission size of XML documents without loosing functionality
or semantic information.
1.2.10 XML styling and transcoding

The Extensible Style Language (XSL) is a specification by the World Wide
Web Consortium for applying formatting to XML documents in a standard
way. XSL is based on the Document Style Semantics and Specification
Language (DSSSL, ISO/IEC 10179), but it is simplified and designed for Web
use, and also has document manipulation capabilities beyond styling.
Actually, the XSL specification is divided into two main documents. The XSL
Transformations (XSLT) specification describes how to transform one XML
document into another, and an XML vocabulary specifies formatting
semantics. An XSL stylesheet specifies the presentation of a class of XML
documents by describing how an instance of the class is transformed into an
XML document that uses the formatting vocabulary.
There are also ways of transcoding XML documents into another document
formats. Todays typical application scenario for this type of document
transformation is the server-based transcoding. For example, a Web server
can be extended to process XML files on the fly, and present HTML files for
24
its clients. This can also be tailored according to the clients needs, for
example, a WAP client from a wireless phone would prefer different document
formats, than another from a home PC. The IBM WebSphere product family
offers such document transformation using WebSphere Transcoding.
1.2.11 XML query languages

Query languages and tools help accessing information in XML documents in
an efficient way. While XSL allows information access by filtering the required
elements, it is very limited tool for this purpose. There are several proposals
on extending the XSL standard with more powerful query and search
capabilities.
At the time writing this book there was no standard technology for building
and processing XML queries. The W3C created a draft recommendation on
XML Query Requirements (W3C Working Draft, 31 January 2000, available at
http://www.w3.org/TR/xmlquery-req), and there are several initiatives to
formulate a standardized language.
The XML Query Requirements document identifies what properties an XML
Query Language must, should and may have. It includes general
requirements, like language syntax, declarability, protocol independence, and
error conditions. The document also describes requirements for the XML
Query Data Model, that relies on the XML Information Set. Finally, it
discusses the details of query functionality, like operations, quantifiers,
document part combination, aggregation, and handling document structures.
Two example initiatives of describing an XML query language are XML-QL
( http://www.w3.org/TR/NOTE-xml-ql/), and XQL
( http://www.w3.org/Style/XSL/Group/1998/09/XQL-proposal.html). The XML-QL
proposal draws from database technology traditions. It is more concerned
with large repositories, integration, creation of new views of existing data, and
transforming data into common data-exchange formats. The XQL standard
(from the document community) is more concerned with integrating full-text
and structured queries, describing the structured search, and creating
multiple presentations from a single document.
1.2.12 Processing XML documents

At the heart of every XML application is an XML parser that processes an
XML document, so that the document elements can be retrieved and
transformed into data that can be understood by the application and task in
hand. The other responsibility of the parser is to check the syntax and
structure (validity and well-formedness) of the document.
25
Anyone has the freedom to implement a parser that can read and print an
XML document. The XML 1.0 Recommendation defines how an XML
processor should behave when reading and printing a document. There are
several parser implementations, for example the IBM XML Parser for Java
(now donated to the Apache Group, and continued under the name Xerces).
The parser can be used as part of an application, which wants to extract data
from or put its own data into XML format. To provide this functionality parsers
specify an application programming interface (API). The XML
Recommendation does not specify this API, therefore it is up to the parsers
designer to specify and implement this interface.
Currently, the following two APIs are widely used:
Simple API for XML
Document Object Model
Simple API for XML (SAX) was developed by David Megginson and a number
of people on the xml-dev mailing list on the Web, because a need was
recognized for simple, common way of processing XML documents. As such,
SAX 1.0 is not a W3C recommendation, but it is the de-facto standard for
interfacing with an XML parser, with many commonly available Java parsers
supporting it.
SAX is an event-driven lightweight API for accessing XML documents and
extracting information from them. It cannot be used to manipulate the internal
structures of XML documents. As the document is parsed, the application
using SAX receives information about the various parsing events. The logical
structure of an application using SAX API with the parser is shown in
Figure 6.
26
X M L A P P L IC A T IO N
SAX API
XM L PARSER
XM L DO CUM ENT
Figure 6. SAX application components
The SAX driver can be implemented by the XML parser vendor, or as an

add-on to the parser. That makes the application using the parser via SAX
independent of the parser.
The Document Object Model (DOM) API is a set of interfaces that must be
implemented by a DOM implementation such as IBMs XML Parser for Java.
The interfaces, being originally described in the interface definition language
(IDL), form a hierarchy (see Figure 7).
The root of the inheritance tree is Node, that defines the necessary methods
to navigate and manipulate the tree-structure of XML documents. The
methods include getting, deleting, and modifying the children of a node, as
well as inserting new children to it. Document represents the whole
documents, and the interface define methods for creating elements,
attributes, comments, and so on. Attributes of a Node are manipulated using
the methods of the Element interface. DocumentFragment allows extracting
parts of a document. It should be noticed that while a DOM application reads
an XML document and an object representation if formed, that representation
remains only in memory. Changing a DOM object in memory does not
automatically modify the original file. That is something an application
program has to do for itself.
27
N ode
A ttr
N o d e L is t
C h a ra c te rD a ta
Com m ent
N am edN odeM ap
D o c u m e n tT y p e
Te x t
D O M Im p le m e n ta tio n
C D A T A S e c tio n
D o c u m e n tF ra g m e n t
Docu m ent
D O M E xc e p tio n
(c la s s )
E le m e n t
E n tity
E n tity R e fe re n c e
N o ta tio n
P ro c e s s in g In s tru c tio n
Figure 7. DOM interface hierarchy
Some important facilities that are missing from the DOM Level1
Recommendation are being defined in DOM Level 2, which is currently a
W3C Candidate Recommendation (10 December, 1999). The added
functionality in Level 2 contains interfaces for creating a document, importing
a node from one document to another, supporting XML Namespaces,
associating stylesheets with a document, the Cascading Style Sheets object
model, the Range object model, filters and iterators, and the Events object
model.
There are certainly applications that could use either SAX or DOM to get the
necessary functionality needed when processing XML documents. However,
these two approaches to XML processing each have their strengths and
weaknesses.
SAX provides a standardized and commonly used interface to XML parsers. It
is ideal for processing large documents whose content and structure does not
need to be changed. Because the parser only tells about the events that the
application is interested in, the application is typically small, and has a small
memory footprint. This also means that SAX is fast and efficient, and a good
choice for application areas such as filtering and searching, where only
certain elements are extracted from a possibly very large document.
28
Because the events must be handled as they occur, it is impossible for a SAX
application, for example, to traverse backwards in the document that is under
processing. It is also beyond SAXs capabilities to create or modify the
contents and internal structure of an XML document.
Because every element of an XML document is represented as a DOM object
to the application using the DOM API, it is possible to make modifications to
the original XML document. Deleting a DOM node means deleting the
corresponding XML element and so on. This makes DOM a good choice for
XML applications that want to manipulate XML documents, or to create new
ones.
DOM is not originally an event driven API like SAX, even though the DOM
Level 2 draft specifies events. To extract even a small piece of data from an
XML document, the whole DOM tree has to be created. There is no way of
creating lightweight applications using DOM. If the original XML document is
large, the DOM application that manipulates the document requires a lot of
memory. In practice, DOM is mostly used only when creating or manipulating
XML documents is a requirement.
There are other initiatives to specify application interfaces to XML documents
in various environments. There are native APIs for different programming
platforms, like Pyxie for Python (http://www.pyxie.org), or the Java API for
XML Parsing (JAXP, java.sun.com/xml), and XML components for various
applications like DB2 XML Extender.
For more information about XML support in IBM products see Chapter 3,
XML in the IBM Application Framework for e-business on page 59. For a
more detailed description about DOM and SAX, and application examples,
read The XML Files: Using XML and XSL with WebSphere 3.0 by Luis
Ennser, Christophe Chuvan, Paul Fremantle, Ramani Routray and Jouko
Ruuskanen (IBM Redbook SG24-5479-00).
1.2.13 Organizations concerned with XML

There are standard bodies, civil organizations, and industrial groups and
companies behind the specification of XML and related standards.
The ISO (International Standards Organization) handles several related
standards, like the SGML ( http://www.oasis-open.org/cover/sgml-xml.html),
the HyTime ( http://www.hytime.org), DSSSL ( http://www.jclark.com/dsssl)
and Unicode ( http://www.unicode.org).
The World Wide Web Consortium (W3C, http://www.w3.org), founded in 1994,
is an international industry consortium, that issues Recommendations (as
29
they call their standards) on XML, XSL, XPath, Namespaces, MathML, and
other related technologies. It also issues Proposed Recommendations
(Recommendations before the W3C Advisory Committee reviews them),
Candidate Recommendations (published for external review), and Working
Drafts (submitted for review by W3C members).
The largest industrial consortium to promote the structured document
management technology (SGML and XML) is the Organization for the
Advancement of Structured Information Standards (OASIS,
http://www.oasis-open.org). It is a non-profit, international consortium of users
and suppliers (including IBM) whose products and services support SGML
and XML. OASIS operates XML.ORG, the a global XML industry Web site
featuring an XML registry and repository that offers automated public access
to XML schemas for electronic commerce, business-to-business transactions,
and tools and application interoperability. The annual SGML/XML 'XX
Conference and the corresponding SGML/XML Europe Conference are
co-sponsored by OASIS (together with the Graphic Communications
Association), as are other major SGML/XML events.
CommerceNet ( http://www.commercenet.com) is a non-profit global
membership organization whose mission is to promote and advance
interoperable electronic commerce to support emerging communities of
commerce. It runs several research projects about XML topics.
BizTalk ( http://www.biztalk.org) is a Microsoft initiative whose goal is driving
the rapid, consistent adoption of XML to enable electronic commerce and
application integration. It defines the BizTalk Framework, a set of
guidelines for how to publish schemas in XML and how to use XML messages
to easily integrate software programs. It runs independently from other
industrial organizations like OASIS and CommerceNet.
1.2.14 Typical applications

In this section we present three examples of how XML is being used in
real-life to bring benefits to people, businesses, and organizations. For more
examples, see the XML section in the IBM developerWorks site at:
http://www.ibm.com/developer/xml
XMLSolutions extends EDI applications to non-EDI partners

XMLSolutions XEDI Translator integrates existing electronic data interchange
(EDI) systems to XML-based system, providing both X12 and EDIFACT
translations to XML. This technology can dramatically reduce the overall cost
of electronic commerce systems. This technology enables non-EDI trading
partners to participate in EDI transactions, thus reducing trading costs. A
30
majority of the Global 2000 companies have between 10,000 and 40,000
trading suppliers, 80% of those have not implemented EDI trading. By using
XMLSolutions XEDI Translator this majority of the trading partners can also
participate in electronic transactions. IBM WebSphere, WebSphere Studio,
and VisualAge for Java are used to implement XMLSolutions products.
Navant Corporation develops Web of Knowledge using XML

The Web of Knowledge e-business platform has built-in capabilities for
building enterprise portals, online communities, performing online education,
and webcasting. It addresses several business challenges including business
integration, employee education and collaboration, Intranet management,
online commerce, and online Internet content. Web of Knowledge uses XML
for its business object persistence, site content markup, message exchange,
template-driven customizable interfaces, client-side data islands, and
configuration. It uses XSL for server-side data transformation and filtering,
and for client-side filtering. Using the XML standard guarantees that the data
will be interoperable between business applications. Web of Knowledge is
based on IBMs WebSphere solution and DB2 database system as the
preferred infrastructure to be used in support of the product.
SABRE and Wireless Markup Language
The SABRE Group is one of the major distributors of international travel
services, offering electronic travel bookings through travel agents and on the
Web worldwide. They are transforming their travel information into XML using
a Java application, and then allowing mobile phone users worldwide to look
up, reserve, and purchase travel from a mobile phone. The XML is
automatically translated from XML into Wireless Markup Language, which is
a standard for building applications on mobile phones. The benefits of XML to
this application are its extensibility, the speed of development, and the ability
to build a standard repository in XML, and translate as needed into a
particular environment, in this case the mobile phone.
1.3 XML and e-business

XML opens up data so that you can share it among your organization,
partners, customers, and suppliers without sharing or integrating your
critical business systems.
From the development teams point of view, this means they no longer have
to use proprietary mechanisms for formatting data passed between
applications or stored in files or databases. From the vendors and business
partners points of view, this means they can easily exchange information.
31
Finally, for the e-business, XML provides an open, cross-platform way to

transact, manage, and share information.
Businesses can leverage data currently residing in hard-to-reach or
non-integrated legacy systems and share information across the
heterogeneous environment of the Web. XML helps improve
business-to-business transactions by combining the power of electronic data
interchange (EDI) with the simplicity of the Web. This combination of
technologies fuses Web data interchange based on XML with existing
EDI business methods and structures.
For example, using an XML-based solution, the health care industry can
create vocabularies for medical patient information that can be easily shared
among doctors, insurance companies and patients. This capability enables
medical professionals to access common information without worrying
about the hardware and software that they use to run their respective
businesses. In this way, patients will benefit of a more efficient processing of
medical claims between doctors and insurance companies, tighter integration
of patient history, and better customer service.
Following is a list of the main advantages that XML provides in e-business.
XML is:
Simple
It is a text-based tag language that people and computers can easily
understand.
Extensible
Diverse data with specific meaning for a given community can be freely
exchanged. You can invent custom tags and vocabularies for any purpose
and share them across interest groups.
Interoperable
Data sharing does not depend on any particular software or hardware
platform.
Mature
Although the specification was announced in February 1998, it is a
simplification of the proven SGML technology that originated from IBM
research in the 1960s.
International
Built-in support for Unicode, an international language encoding standard
that supports any script in the world today. This makes transnational data
accessible to the programmer.
32
Table 1 summarizes the relationship between main XML feature and

Table 1. Relationship between XML Features and e-business applications
XML Feature
Relationship in the inter-business

applications
Sharing data across platforms and

applications
Data tagged with XML in one application

can be understood in another. The XML
tags permit content sharing across the
company/organization Intranet as well as
Extranet.
Reusing information efficiently
Company information created in XML and

stored in a document management
system has a longer life span helping to
ensure future readability as well as reuse
today and tomorrow.
Improving customer satisfaction
The XML metadata capabilities help

software to personalize end-user
experiences without complex
programming. You can modify data
presentation for different client devices.
Using XML in an open, standard

environment
XML is a critical component to completing

the technology foundation necessary for
e-business, removing direct
dependencies between data and the
software that uses it.
XML has the potential to be the standard language of inter-enterprise

business integration: if company information systems, applications, and so on
are XML-compliant, then data can be easily exchanged between them.
However, XML alone cannot be the solution to the business integration
problem. XML itself is not a business data description language; rather, it is a
specification language that can be used to build the former. As we will see in
the second part of this book, companies, industrial consortiums and
organizations are still working to formulate XML schemas to be used in doing
B2B transactions.
33
1.4 Summary
In this chapter we summarized the two key areas this book focuses on:
e-business applications and the XML technology.
E-business systems are defined as applications that use Internet technology
to improve business processes. We categorized e-business applications as
being intra-business or inter-business systems, and we gave detailed
descriptions of these categories. As a key example in intra-business
applications, business-to-employee (B2B) systems, which facilitate
information sharing within the company, were briefly introduced. The two
main areas of inter-business cooperation are business-to-business (B2B) and
business-to-consumer (B2C).
B2B applications help companies in establishing electronic transactions and
partnership over the Internet. They enhance business process automation,
collaboration with other companies, and establish virtual markets and
communities. B2C applications help companies to automate and enhance
their customer relations. Using B2C solutions, companies can create and
maintain information sites, automated customer service, help desks,
electronic catalogs, and Web stores. These solutions help in marketing, sales
and support.
The Extensible Markup Language is a key technology to build e-business
applications, since it is a platform and vendor independent document
standard for describing structured data. As a universal data format, it enables
the seamless connection to business partner systems. It is based on an ISO
industry standard (SGML), and it is created for Web use. In the second
section of this chapter we introduced this technology, showing its key features
and areas. We have also shown application examples, where XML was used
to enhance business applications.
Finally, in the last part of the chapter, we summarized the impact of XML on
e-business. We gave a list of advantages that XML provides in e-business,
and we analyzed the relationships between the main XML features and the
34
Chapter 2. Introduction to IBM e-business solutions

It seems as if nearly every country in the world is captivated by the Internet.
A half-billion users worldwide are expected online by the year 2003. The
Internet is not only providing a communication medium for the masses it is
also enabling business-to-business relationships to soar to new heights. The
underlying technologies enabling this fundamental revolution have opened
the door for the development of the next generation of business applications.
If you are involved in that revolution, you have certainly heard about the IBM
e-business cycle and the IBM Application Framework for e-business. If you
already know about the Framework, you may wish to skip this chapter. If not,
or you need more information about some points, such as how to transform
businesses into e-business, the application architecture, the programming
model, then this chapter aims to give you some basics.
2.1 IBM e-business cycle

Most companies have begun the transition from traditional business to
e-business. They have established Web sites and have started to
Web-enable such core processes as self-service applications to strengthen
customer service operations, to better connect with their supply chains and
reach new and existing customers. However, the next step is integrating
business processes. IBM finds that its not just Web-enabling that counts, but
linking a myriad of business-critical processes.
IBM has determined that e-business is more than a technology discussion.
The move requires a clear vision of what needs to be done and an equally
clear picture of how to make that vision a reality. The e-business cycle shown
in Figure 8 is the IBM model for how customers can transform and innovate
their businesses into e-businesses.
35
Leverage
Transform
knowledge and
information
Run
a scalable,
available, safe
environment
core business
process
Build
new
applications
Figure 8. IBM e-business cycle
Transforming core business processes

Transforming core business processes is about doing business in new
ways by applying Internet technologies to create maximum value for your
business. It's about how e-business (and not just technology) changes the
rules for Customer Relationship Management, Supply Chain
Management, and Electronic Commerce. IBMs key differentiator in the
networked world is business value. IBM can help you create the vision,
and supply the solutions and services that will help you achieve maximum
value as you make the transition from traditional business to e-business.
Building new and innovative applications
Transforming core business processes requires a new generation of
applications. They run on servers, leverage existing applications and data,
and scale to meet user demands. IBM can design, develop, and integrate
these applications or makes it easy for you to develop them yourself. The
IBM Application Framework for e-business is designed to help you build
and deploy a new generation of applications that are open, flexible and
easy to change. Thus, e-business continues to be about starting simple
and growing fast .
Runnings a scalable, available, safe environment
The infrastructure squeeze play is real. Businesses are looking for a better
return on investment. Users want systems that are easy to use, yet always
36
responsive. IBMs solution is to provide an environment with scalable

servers, flexible clients, and advanced storage devices all handled in a
secure, manageable way. IBM strategic advantage is in helping you Build
on what you have offering cross platform integration and a complete
range of services from in-house management to Web hosting to full
strategic outsourcing services.
Leveraging knowledge and information
This is about creating a responsive organization that makes intelligent use
of all types of data and organizational knowledge. By enabling profiling
and personalization, e-business allows you to use data as a weapon. IBM
has Business Intelligence and Learning services that can help you create
faster, smarter organizations. IBM Business Intelligence solutions
leverage the data within your company. IBM Knowledge Management
solutions help you capitalize on human experience to create a more
responsive culture.
2.2 IBM Application Framework for e-business

Application Framework for e-business is an IBM-defined model that improves
the customers chance of success. Research was conducted to better
understand the issues that application developers deal with as they build
Internet-based applications. Included in the research was participation from
corporate and commercial application developers, as well as both IBM and
non-IBM customers.
The customers involved in the research were developing sophisticated
Internet, intranet, and extranet applications in multi-platform environments.
They indicated that there was no road map for developing applications that
span multiple platforms and told IBM they would welcome a proven
approach that combined products as well methodology. IBM was viewed as
one of the few vendors who could provide such a road map due to our
commitment to standards and knowledge of multiple platforms. In response,
IBM has delivered a model to design, develop and deploy this new class of
The IBM Application Framework for e-business is a combination of:
A set of industry standards and technologies
Proven methodology
Leadership products
37
The Framework is based on what has been proven successfully over the last
three years as IBM has worked closely with customers to help them develop
and deploy the e-business applications that are transforming their
businesses. In this section, we will not be covering the IBM Application
Framework for e-business in detail. Rather, we will introduce the general
concepts and objectives of the Framework.
2.2.1 Using an asset-based approach

Todays approaches to solution development are still primarily based on
handcrafting and bear little relationship to the asset-based engineering
methods so successfully used in other disciplines. Handcrafting approaches
are obsolete, and a more disciplined and constrained method is needed for
solution development.
2.2.1.1 Traditional problems
Today, the most common model for solution development is based on an
approach that could be called heroic. A highly-skilled energetic team studies
and refines the stated requirements, defines the architecture for a solution to
meet those requirements, carries out a detailed design, and builds the
system. The primary assets brought to the table are the skills and experience
of the individuals who make up the team. In the 1970s and, to some extent,
the 1980s, the heroic approach seemed reasonably effective, but it is clear
that it is no longer adequate for todays enterprise-scale systems.
In 1996, surveys of twenty major enterprise solution development projects in
North America and Europe showed that solution development project risk
increased rapidly with project size. For projects requiring more than one
hundred person-years, the risk of project delay or failure was very high.
Moreover, for various reasons, the amount of project resources needed to
replace existing business systems is rising rapidly.
In the 1960s, utility billing systems could be developed in fifty person-years
using batch technology; in the 1970s, the first-generation online systems,
which provided the genesis for the IBM Customer Information Control System
(CICS) transaction monitor, needed about one hundred person-years; in the
1980s, the figure was up to one hundred fifty person-years with more
sophisticated personal computer (PC)-based interfaces.
However, by the mid-1990s, with the advent of object-oriented front ends and
distributed logic, client/server, and other technologies, several projects were
up to five hundred person-years with an elapsed time of four to five years. A
considerable part of this effort, perhaps one-third, was spent on integrating
new functions with existing (legacy) IT systems and handling data migration
38
to new database designs. These figures are not unique to the utilities
industry. The same trends are apparent in the insurance industry. Specifically,
the replacement of existing contract management systems in a large
insurance company in France was recently reported to have consumed five
hundred person-years over an elapsed time of six years or more.
It goes without saying that any project of five hundred person years is
exposed to considerable risk not only the risk of technical failure, but also
the risk that, upon final delivery, the business requirements will have changed
beyond recognition, and the delivered solution may no longer meet business
needs. These are known as instant legacy solutions.
Older or legacy systems frequently seem, to the end user, to be
disconnected, with independently-operating silos. For example, in an
insurance company, one IT system may deal with life insurance business and
another with general business, such as car insurance. More likely, the life
insurance business itself will run multiple systems to handle various products,
such as unit business, group products, and so on.
With today's focus on customer service, it is increasingly unacceptable for an
enterprise to communicate with its customers separately from each system.
To put it in a more positive way, a more coherent view of a customer that
considers all products held by that customer provides excellent marketing
opportunities and improved customer retention; so, the existence of silos,
typically manifested both through incompatible hardware and incompatible or
segregated software, is a serious issue.
Many development efforts start from scratch, and architectural components
are integrated to create a custom architecture without the use of a template
or blueprint. Frequently, the project creates extensive custom middle ware,
which might not have been needed if a blueprint-driven approach had been
taken. The selection of products from vendors is left to the skill of one or a
few key architects. As a consequence, the solution takes longer to develop
and deliver, and the costs and risks are higher. Along the way, opportunities
to leverage existing products, services, the prior integration of components,
and the opportunity to acquire knowledge for subsequent reuse have been
lost.
When combining this risk with the likely development costs of fifty million
dollars or more, it is apparent that our industry is facing a crisis. In these
circumstances, it is not surprising that enterprises are seeking to mitigate risk
by taking an asset-based approach.
39
2.2.1.2 Using a sound architecture

A sound architecture is an essential prerequisite for the successful
development of an enterprise-scale IT solution:
It aids communication among stakeholders. The architecture is a basis for
ensuring mutual understanding.
It represents the earliest design decisions about a system decisions
absolutely critical in terms of development, deployment, and future
maintenance costs. For example, in development, they play a crucial role
in team organization, and this is later reflected in the organization of the
company for which the solution is being developed. In maintenance, the
flexible qualities built into the architecture will be key to the ability of the
solution to respond to changes in business and technology.
It provides a compact and understandable abstraction of a system and,
thus, is a mandatory prerequisite for the reuse of software assets.
At the beginning of a specific solution development project, the architecture
team has the option of creating the architecture in a number of ways.
It can develop the architecture from scratch, it can pick from a library of
architectural styles, or it can reuse and build upon an existing Framework.
A Framework is a reusable design expressed as a set of abstract patterns
and the way their interfaces collaborate. It is a reusable design for all or part
of a software system; a User Interface Framework only provides a design for
the user interface of a system, while an Application Framework provides a
design for the entire application. Early Frameworks revolved around
programming languages, such as an object-oriented design. Application
Frameworks do not have to be implemented in an object-oriented (OO)
language, but they do have characteristics similar to OO design, in that
everything has defined interfaces and can be treated as a component
(or why not an XML document?).
An Application Framework provides a context for the software, servers, and
services necessary to create, deploy, and manage complex e-business
applications. The programming model, the architecture of technologies
(and tools), and e-business disciplines, such as customer relationship
management (CRM) and supply chain management (SCM) all overlay the
Application Framework.
2.2.1.3 Advantages of IBM Application Framework for e-business
The IBM Application Framework for e-business:
Provides you a programming model that puts you on the fast track.
40
Helps you work with multi-platform standards like Java and technologies
like CORBA and XML.
Explains the characteristics of application servers and how to connect with
clients of all types.
Guides you to more information on network, data, and infrastructure
standards.
IBM Application Framework helps you build and deploy, so you can write an
application on one platform and run it somewhere else without completely
rewriting the code. The Framework offers the fastest way to develop
e-business applications and integrated software, server, and services, when
you are faced with the unique development and deployment challenges
involved in building e-business applications that are scalable, work across
multiple platforms, and integrate with existing applications.
The benefits of developing applications using the IBM Application Framework
are illustrated by the key principles that have guided its development:
Maximize ease and speed of development and deployment. By adopting a
server-centric, Java based component model and toolset, your e-business
applications can be developed and deployed quickly with skills ranging
from non-technical graphic designers to programmers.
Accommodate any client device. Support of Internet standards and a
server centric model expands access to your e-business applications to a
broad range of client devices.
Ensure portability across a diverse server environment. Support of the
open, unifying Java platform makes it easy to deploy your e-business
applications on the systems that best meet your scalability and quality of
service requirements.
Leverage and extend existing assets. To improve time to market and
reduce cost of development, e-business applications must leverage and
extend the reach of secure, reliable, and scalable applications that are the
core of many business processes.
Flexible and extendable. Able to accommodate future technology, such as
pervasive computing, Internet2.
The IBM Application Framework for e-business programming model is used
as a basis for the design of e-business applications. This model has evolved
from the traditional client/server computing model. The key properties of
applications based on this model are as follows:
41
Universal connectivity based on HTML/Java-enabled thin clients, that is,

manageable clients that can be configured so they do not require local
software installation and data backup, such as the IBM WorkSpace
On-Demand Client solution.
Rapid development of write-once-run-anywhere applications with
just-in-time deployment.
Software reuse to minimize new code, promote quality, and maximize
productivity.
Universal access to data
Workload optimization across servers
Application deployment is independent of client and server operating
software and hardware.
Connections to external services where existing business applications and
data reside leveraging their value for customers, business partners, and
employees.
Moving applications to the e-business model also brings design problems that
many developers may never have faced before. Among the new factors
developers must now consider are the following:
Web Browser clients and other new technologies and paradigms such as
pervasive computing devices
The distributed multi-tier nature of e-business applications
Direct support of customers
To better understand the advantages we have just listed above, the next
section depicts the foundation of the IBM Application Framework for
e-business.
2.2.2 Overview of the IBM Application Framework

To transform traditional business processes in order to become an
e-business, you will need a foundation for developing new business
applications. IBM's answer is the Application Framework for e-business, a
comprehensive, scalable platform that supports all the services needed to
develop and deploy e-business solutions.
The IBM Application Framework for e-business provides a model for designing
e-business solutions. The Framework is based on an n-tier distributed
environment where any number of tiers of application logic and business
services are separated into components that communicate with each other
42
across a network. In its most basic form, as shown in Figure 9, the Framework
can be depicted as a logical three-tier computing model, meaning that there is a
logical, but not necessarily physical, separation of processes. This model is
designed to support clients with high-function Web application and enterprise
servers.
E xtern a l
S ervice s
N e tw o rk in fra s truc tu re th a t u se s
ind u s try sta n da rd A P Is a nd
p ro toco ls
C o nn e cto rs
Web
A p p lica tio n
S e rvers
Thin client
C o n te n t E nterprise
JavaB eans
Figure 9. Three-tier computing model
A prototypical three-tier architecture consists of the following:

A client tier containing logic related to the presentation of information
(that is, the graphical user interface) and requests to applications through
a browser, Java applet, or pervasive computing devices.
Web application servers containing the business logic and processes that
control the reading and writing of data.
Servers that provide the data storage and transactional applications used
by the Web application server processes.
The application elements residing in these three logical tiers are connected
through a set of industry-standard protocols, services, and software
connectors.
43
2.2.2.1 Application Framework Architecture

The IBM Application Framework for e-business architecture provides a full
range of services for developing and deploying e-business applications.
Because it is based on industry standards, the Framework has the ability to
plug-and-play components provided by almost any vendor.
The model identifies key elements for developing and deploying e-business
applications as shown in Figure 10. Each element is based on open,
vendor-neutral standards, allowing you to substitute components from any
vendor that supports those standards.
e - b u s in e s s A p p l ic a t io n
S e r v ic e s
W e b A p p lic a t io n P r o g r a m m in g
E n v iro n m e n t
A p p lic a t io n
S e rv e r
S o ft w a r e
E x te r n a l
S e r v ic e s
A p p lic a t io n
I n t e g r a t io n
N e tw o r k I n f r a s t r u c t u r e
S y s te m M a n a g e m e n t
T o o ls
W eb
A p p li c a t io n
S e rv e rs
c l ie n ts
Java
C o n te n t
E n t e r p r is e
JavaB eans
Figure 10. Application Framework for e-business architecture
The architecture is composed of the following key elements:

Clients based on a thin client, Web browser/Java applet model that
enables universal access to Framework applications, and on-demand
delivery of application components.
A network infrastructure that provides services such as TCP/IP, directory,
and security whose capabilities can be accessed via open, standard
interfaces and protocols.
44
Application server software that provides a platform for e-business

applications and includes an HTTP server, database and transaction
services, mail and groupware services, and messaging services.
Application integration that provides access to existing data and
applications.
A Web application programming environment that provides the server-side
servlet and Enterprise Java programming environment for creating
dynamic and robust e-business applications.
e-business application services that provide higher level application
specific functionality to facilitate the creation of e-business solutions.
Systems management functions that accommodate the unique
management requirements of network computing across all elements of
the system, including users, applications, services, infrastructure, and
hardware.
Development tools to create, assemble, deploy, and manage applications.
Clients
Clients supported by the Framework are thin clients, meaning that little or
no application logic is executed on the client and therefore relatively little
software is required to be installed on the client. In this model, applications
are managed on the server and dynamically downloaded on-demand to
requesting clients. As such, the client portions of new applications should be
implemented in HTML, Dynamic HTML, XML, and Java applets. The
Framework supports a broad range of fixed, mobile, and Tier 0" clients such
as personal digital assistants (PDAs), smart cards, and digital cell phones,
from IBM and other industry leaders, based on industry initiatives such as the
Network Computer Profile, and the Mobile Network Computer Reference
Specification.
Network infrastructure
The network infrastructure provides a platform for the entire architecture. It
includes the following services, all based on open standards:
TCP/IP and network services like DHCP that dynamically assigns IP
addresses as devices enter and leave the network.
Security services based on public key technology that support user
identification and authentication, access control, confidentiality, data
integrity, and non-repudiation of transactions.
Directory services that locate users, services, and resources in the
network.
45
Mobile services that provide access to valuable corporate data to the

nomadic computing user.
Client management services that support the setup, customization, and
management of network computers, managed PCs, and in the future Tier
0 devices such as smart cards, digital cell phones.
File and print services that are accessed and managed via a standard
Web browser interface.
Application server software
The application server software layer provides the core functionality required
to develop and support the business logic of e-business applications running
on the Web application server. It includes the following services:
An HTTP server that coordinates, collects, and assembles Web pages
composed from static and dynamic content and delivers them to
Framework clients.
Mail and community services that provide e-mail messaging, calendaring
and group scheduling, chat, and news group discussions.
Groupware services that provide a rich shared virtual work space and
support the coordination of business workflow processes.
Database services that integrate the features and functions of an
object-relational database with those of the Web application server.
Transaction services that extend the Web application server by providing a
highly available, robust, expandable and secure transactional application
execution environment.
Messaging services that provide robust, asynchronous communication
and message brokering facilities that support a publish/subscribe model of
communication and message transformations.
Application integration
The application integration component of the Framework allows disparate
applications, potentially written in different programming languages and built
on different architectures, to communicate with each other. The bulk of
today's critical data and application (especially transactional) programs
reside on and use existing enterprise systems. Application integration allows
Web clients and servers to work together with this data and these application
programs, seamlessly linking the strength of the Internet with the strength of
the enterprise. Three methods of integration are supported:
Connectors are gateway software that provide linkage between the Web
server and services that are reached through the use of application
specific protocols.
46
Messaging services provide asynchronous communication and message

brokering facilities, including message transformations.
Managed object services enable object wrappering of existing application
logic written in any language. As a result, existing application logic is
extended to object-oriented environments.
Web application programming environment
The Web application programming environment, based on Java servlets,
Enterprise Java services and Enterprise JavaBean components, provides an
environment for writing dynamic, transactional, secure business applications
on Web application servers. Services are provided that promote separation of
business and presentation logic enabling applications to dynamically adapt
and tailor content based on user interests and client device.
e-business application services
The e-business application services are building blocks that facilitate the
creation of e-business solutions. They are higher level application oriented
components that conform to the Framework's programming model. They build
on and extend the underlying application server software and network
infrastructure with functions required for specific types of applications, for
example, e-commerce applications. As a result, e-business solutions can be
developed faster with higher quality. Examples of e-business application
services include payment services, catalog services, and order management
services.
System management
Within an enterprise, systems management services provide the core
functionality that supports end to end management across networks,
systems, middle ware and applications. The Framework provides the tools
and services that support management of the complete life cycle of an
application from installation and configuration, to the monitoring of its
operational characteristics such as availability and security, to the controlled
update of changes. Across multiple enterprises, the Framework provides a
collaborative management approach for establishing and following
procedures to share information and coordinate problem resolution with
business partners. This collaborative approach includes policy management,
data repository, scheduling and report generation.
Development tools
The Framework provides a broad range of tools to enable creation,
deployment and management of e-business applications for Internet, extranet
and intranet environments. It also supports integrating third party tools into
the development process. The Framework supports the different skill sets
47
involved in developing Web applications, providing tools that target specific

skill sets, and facilitates collaboration among members of the development
team.
API and protocols support
Table 2 through Table 7 summarize the standard protocols and APIs
supported by each component of the Application Framework for e-business.
While IBM will provide a complete and competitive set of products that
implement the Framework, other implementations can also work within it.
Thus, customers can choose from providers that support these open
standards. Likewise, solution providers can build their solutions using a
variety of differently sourced software products. We deliberately omitted to
include XML and related technologies in these tables, section 3.1,
e-business application with XML on page 59 will do.
Table 2. Standard protocols and APIs: Network infrastructure
Service
Protocol standard
API
Directory
LDAP
JNDI
Security
CDSA, SSL, IPsec,

x.509v3 certificates
JSSL, JCE
Network
TCP/IP
JDK java.net
File
AFS/DFS
JDK java.io
Print
IPP, LPR/LPD
JDK java.2d, JNPAPI
Pervasive computing
MNCRP, WAP,
Transcoding
non applicable
Table 3. Standard protocols and APIs: Application server software
48
Service
Protocol standard
API
Mail and community
SMTP, POP3, IMAP4, IRC,

NNTP, FTP, iCalendar
Java Notes API
Groupware
non applicable
Java Notes API
Data
ODBC, DRDA
JDBC, SQL-J,EJB
Transaction
CORBA, OTS/IIOP
EJB, JTS
Message queuing
not applicable
JMS
Message routing,
transformation
EDI (ANSI X.12, EDIFACT)
(OAG), AMI-J, MQSeries,

CMI-J
Service
Protocol standard
API
Workflow
CORBA, WfM/IIOP, WfMC
non applicable
Table 4. Standard protocols and APIs: Web application environment
Service
Protocol standard
API
Web server
HTTP, HTML
Servlets,
Server-side-includes
Web browser
HTTP, HTML
Applets
Component model
CORBA IIOP
Java beans
Business component
model
CORBA IIOP
JB, RMI
Scripting
ECMAScript
JSP
Table 5. Standard protocols and APIs: System management
Service
Protocol standard
API
Distribution (Install/Config)
DMTF-CIM
AMS
Operations (Fix/Change)
DMTF-CIM
AMS
Performance (Monitor)
SNMP
ARM
Events (Alarms)
SNMP
TEC
Table 6. Standard protocols and APIs: Development tools
Service
Protocol standard
API
Authoring and versioning
WebDAV
non applicable
Table 7. Standard protocols and APIs: e-business application services
Service
Protocol standard
API
Commerce
EDI, OBI,SET
non applicable
2.2.2.2 The programming model

Web applications are applications that leverage Web clients (such as Web
browsers), Web application servers, and standard Internet protocols. They
also typically leverage existing applications and data from external non-Web
services. Figure 11 illustrates the major elements of the Web application
topology supported by the Framework. It is important to note that the Web
application server and external services are logical tiers capable of running
49
Firewall
on the same physical machine. In addition, functionality on the Web

application server can be spread across multiple physical machines.
Frequently, the front-end and business logic parts of a Web application are
run on separate server machines.
c lie n ts
W e b A p p lic a tio n
S e rv e rs
c lie n ts
E x te rn a l S e rv ic e s
- in te r e n tre p ris e s
- b u s in e s s p a rt n e rs
Figure 11. WEB application topology
The application programming model defines application topologies and

solutions using the services defined by the Framework as described in
section 2.2.2.1, Application Framework Architecture on page 44. For the
most part, your work deals mostly with the application programming model.
The Web application topology consists of:
Internet and intranet clients
These clients, through the users, communicate with Web application
servers (using Internet standards, such as TCP/IP, HTTP, and HTML) to
access business logic and data. The primary role of the client is to accept
and validate user input, and to present results received from the Web
application server to the user.
Infrastructure services
These provide the Web application server and its business logic
components with directory and security services. Included in these
services are firewalls that shield an organization's network from exposure
when connecting to the Internet and prevent hackers and others from
gaining unauthorized access to internal data and computing resources.
Web application servers
These are the hubs of the Web application topology processing requests
from clients by orchestrating access to business logic and data on the
server and returning Web pages composed of static and dynamic content
50
back to the client. The Web application server provides a wide range of
programming, data access, and application integration services for writing
the business logic part of a Web application.
External services
These consist of existing mission-critical applications and data within the
enterprise as well as external partner services, such as payment services,
financial services, and external information services. Most often, these
existing applications and services control the company's core business
processes.
Most often, these existing applications and services control the company's
core business processes.
2.2.3 Patterns for e-business

Patterns for e-business are a group of proven, reusable assets that can help
speed the process of developing applications.The patterns are targeted to
meet 80% of the most common customer requirements. If you use the
patterns within a structured development methodology, you can extend their
scope to meet 100% of your requirements.
The patterns are a group of reusable assets, such as:
Business patterns that identify the interaction between users and
businesses.
Logical patterns or topologies to define the existing customer environment
and lead to a common solution environment.
Physical patterns providing product mappings to populate the solution.
The product mappings are based on previous walkthroughs and testing.
A technical sales team, customer system architect, solution provider, or other
I/T architect presented with a customer problem can use this approach as an
aid in helping the customer design and build an e-business solution. Using
the patterns saves the architect from starting with a blank sheet of paper and
allows guidance in reusing e-business assets. This approach makes the use
of Application Framework for e-business products and technologies truly
simple and prescriptive, as shown in Figure 12.
51
Customer expectation:
- Business problem
- Business procedures/rules
- Existing environment
Customized customer solutions:

= e-buisness solutions
(CRM,SCM,KM,BI, e-commerce)
tion
om
iza
Logical patterns:
- Application topologies
- Runtime topologies
Cu
st
ogy
dol
tho
Me
Business patterns:
- based on scenarii
Physical pattern:
- runtime product map
BUILD
Development tools
and Components
RUN
Server and
integration software
MANAGE
Secure network and

management software
Open standard, technologies

Windows 2000 Linux AIX Solaris OS/2 HP-UX OS/400 OS/390
e-business
Application Framework
for e-business
Figure 12. Using Application Framework for e-business: a simple approach
Patterns for e-business describe the interaction between the participants in

an e-business solution. The important patterns are:
User-to-business: Users interact with enterprise transactions and data.
Encompasses all user-to-business interactions except user-to-online
buying (where packaged goods are sold through a catalog using a
shopping cart, a wallet, and so forth).
User-to-online buying: Packaged goods are sold through a catalog using
a shopping cart, electronic wallet, or similar software tools. The
purchasers may be consumers obtaining products or online buyers
purchasing goods from a supplier.
52
Business-to-business: Programmatic links for inter-business to

business, for example, electronic invoicing.
User-to-data: Users need to take large volumes of data, text, images,
video, and so forth. They use tools to extract useful information. This
includes Business Intelligence and Knowledge Management. Example:
evaluation of user purchasing preferences.
User-to-user: Users collaborate with one another through e-mail, shared
documents, and so forth. Example: collaboration across teams on
document development.
Application integration is required to speed the flow of data between
existing heterogeneous applications. It also programmatic links for
intra-business to business.
Table 8 shows the relationship between some e-business solution areas and
the patterns for e-business introduced above.
Table 8. A pattern for each e-business solution
e-business solution area
Business patterns
Customer Relationship Management
User-to-business
e-commerce
User-to-online buying
Supply Chain Management
Business-to-business
Collaboration
User-to-user
Business Intelligence; Knowledge Management
User-to-data
Business Application Integration
The inter- or intra-connection of patterns for e-business enables two or more

applications to solve a business problem for example, integrating
user-to-business with user-to-data to improve the personalization of a
customer self-help Web site.
There are two sets of logical patterns associated with each e-business
pattern:
Application topology: The application topologies illustrate various ways
that the interaction between users, applications, and data can be
configured.
Runtime topology: The runtime topology uses nodes to group functional
requirements. The nodes are interconnected to solve the business
53
problem. Your choice of application topology will typically take you to the
underpinning runtime topology. The runtime topologies are based on the
Enterprise Solution Structure (ESS) patterns. Some recent ESS work
involved looking at patterns for complete end-to-end System Architectures
(refer to the IBM Systems Journal, Volume 38, No. 1, 1999. Enterprise
Solutions Structure at http://www.research.ibm.com/journal/sj38-1.html).
ESS is now part of SIMeth (or IBM Global Services Method), the work
product based methodology used by IBM Global Services.
The physical patterns provide runtime product mappings together with
guidelines for design, development and management of the application.
The rest of this section focuses on the business patterns. The logical and
physical patterns will be covered in more detail in Chapter 4, Patterns for
B2C and B2B applications on page 107.
2.2.3.1 User-to-business pattern
The user-to-business pattern refers to the general case of users (internal to
the enterprise or external) interacting with enterprise transactions and data.
In particular, it is relevant to those enterprises that deal with goods and
services not normally listed in and sold from a catalog. Basically, it covers all
user-to-business interactions that are not in the user-to-online buying pattern.
This business pattern also covers the more complex case in which there is a
need to access back-end applications and data such as Customer
Relationship Management.
Here are some examples of the user-to-business pattern:
Convenience banking
-
View account balances

View recent transactions
Pay bills or transfer funds
Stop payments
Manage bank cards
Discount brokerage
-
54
Portfolio summary
Detailed holdings
Transaction history
Quotes and news
Buy and sell stocks
2.2.3.2 User-to-online buying pattern

The user-to-online buying pattern describes a special case (a subset of the
user-to-business pattern) where packaged goods, for example, are sold
through a catalog using a shopping cart, a wallet, and so on. This includes
both consumers purchasing goods or online buyers purchasing goods from a
single supplier. It can also links to back end systems to allow for inventory
updates and credit checking.
All e-commerce applications can be built on this model. Here are two
examples of the user-to-online buying pattern: Consumers purchasing goods
online; and buyers purchasing goods online from a supplier.
2.2.3.3 Business-to-business pattern
The business-to-business pattern includes two styles of inter-business to
business. Intra-business to business is covered under the application
integration pattern.
The first style covers the programmatic link between arms-length business,
where potentially a trading partner agreement may be appropriate. A good
example of this would be the supply chain management (SCM) application.
The second style covers the eMarketPlace, where the model supports
B2M2B. The M represents the eMarketPlace, which supports multiple buyers
and suppliers. The buying function may be performed online or
programmatically.
2.2.3.4 User-to-data pattern
The user-to-data pattern encompasses the provision of Business Intelligence
(BI) capabilities to an organization. The user is someone connected to the
data through one of four paths:
Internet: the user is external to the company, or an agent of the company.
Note the possibility of a chaining effect: the external user can trigger the
user-to-data scenario, while the user actually connected to the data is an
internal staff member or agent. For example, a customer phones a query
into an organization and a staff member connects to a data store to
respond to the query. In this scenario, the user is defined as the staff
member, not the customer.
Intranet: a staff (internal) user
Extranet or privileged Internet: an associate of the clients organization
who acts as a business agent on the companys behalf.
Fat client, connected as in a client-server system: applies to internal users
only.
55
The data can be held in any of the following:

Web-content store: holding Web pages and cached information. The data
may include copies of operational detailed records, such as consolidated
account information for a customer reference. The data is read-only; if an
update of the data is required, the pattern is user-to-business, not
user-to-data.
Data mart: the data may be read-write with local scope-of-effect only.
Data warehouse: the data is read-only for applications.
Tool-specific store (proprietary): some tools, such as Essbase, require
specialized data stores for efficiency.
This pattern has several distinguishing characteristics:
The user is not connecting to a traditional transactional system performing
an operational business process.
The user perceives themselves to be interacting directly with the data
rather than with a system.
Normally, the user has significant freedom and flexibility in her access of
available data. The data sets are often specially prepared in advance to
suit the user or the tool being used.
The data sets being accessed:
- Are not the companys prime operational data.
- Include a copy of relevant operational data and other data as
necessary.
- Include a historical set of data.
Linking applications together within a business, like enterprise resource
planning (ERP) with existing applications, is represented by the application
integration pattern. In particular, it is crucial to enable customers to install
packages which integrate with their existing systems. It is also required to
support those applications which need to combine functionality from more
than one technology pattern, for example, a pharmaceutical company that
needs stock transactions using WebSphere combined with access to patient
records on Domino. This can be used within a business pattern or between
business patterns.
56
2.3 Summary
This chapter has provided a general overview of the IBM solution for
e-business. This solution is built on a model that helps customers to
transform and innovate their businesses to e-businesses using the IBM
Application Framework, a model that helps customers to design, develop,
and deploy their e-business applications.
The next chapter describes the place of XML in the overall picture of the IBM
e-business world.
57
58
Chapter 3. XML in the IBM Application Framework for e-business

IBMs goal is to be established as the leading provider of XML solutions to
help solidify IBM's leadership position in e-business: XML is an e-business
accelerator. This chapter describes the engagement and initiatives of IBM to
promote XML up to its Application Framework for e-business. It lists, in a
non-exhaustive manner, some tools and utilities IBM provides to developers
on its AlphaWorks Web site. You will also find a short description of the
commitment of IBM toward standard frameworks, and overviews of XML
extensions of some IBM products.
3.1 e-business application with XML

IBM has joined open organizations such as OASIS, and XML.ORG (see
3.3.1, OASIS consortium, XML.ORG on page 82) to accelerate the adoption
of e-business by establishing XML and associated industry specific grammars
as de facto industry standards. IBM also drives activities in W3C and other
trade organizations to leverage IBM product's integration of the standard
such as DOM, and XSL.
IBM reinforces its Application Framework for e-business, as shown in Figure
13, by extending its line of products with features which help customers and
business partners to build, deploy and manage e-business applications which
interchange data via XML:
Build: Enable tools for creation and use of XML.
Deploy:
- Enable middleware products: WebSphere, DB2, IBM MQSeries.
- Enable IBM hardware platforms with native support.
- Develop cross platform solutions using XML products.
Manage: Create repositories for managing & sharing DTDs (catalog, and
versioning).
59
BUILD
RUN
Development tools
and Components
Server and
integration software
MANAGE
Secure network and

management software
Open standard, technologies

Windows 2000 Linux AIX Solaris OS/2 HP-UX OS/400 OS/390
Application Framework
for e-business
e-business
XML
Figure 13. Leveraging the IBM Application Framework for e-business with XML
Figure 14 shows how the diverse tiers of the architecture of an e-business

application developed inside the Application Framework for e-business
employ XML in these different purposes:
Messaging
XML easily (compared to EDI) allows to use the same message format to
exchange between organizations, or between application systems within
an organization. So with XML, the threshold for participating in a
message-exchanging community can be quite low.
Rich document
With XML it is expected that richer document markup languages can be
defined. With a properly designed stylesheet, it should be relatively easy
to design a personal markup language.
Database
Many three-tier applications extract data from back-end database
systems. Usually the results are transformed into the <table> tag of HTML
and displayed on the screen. If data is delivered as an XML document that
preserves the original information, such as column names and data types,
the data can be used by the client for purposes other than just displaying
on the screen.
Meta content
Because of its extensibility, flexibility, and readability, XML is considered to
be the best formalism to define a meta content syntax.
60
Clients
Web application servers
Servlets
EJBs
JSPs
Back-end
XSL/XSLT
XML:
- data
- meta data
- messages
AppletsBeans
ActiveX components
XML/XSL
HTML/CSS
XML/XSL
Browsers
and
Pervasive computing
XML data
XML meta data
DTD/Schema
Data modeling
Meta content
Rich document
Messaging
Database
Storage
Figure 14. XML in a Web application architecture
Table 9 through Table 13 are intended to place XML in the standard protocols
and APIs supported by each component of the Application Framework for
e-business, as defined in API and protocols support on page 48.
Table 9. Standard protocols and APIs: Network infrastructure
Service
Protocol standard
API
XML-DSig
IBM XML Security Suite
WAP/WML, VoiceXML
Not applicable
Directory
Security
Network
File
Print
Pervasive computing
61
Table 10. Standard protocols and APIs: Application server software
Service
Protocol standard
API
XML, XQL, XPATH, SMIL
DOM, JAXP
XML, XEDI
MQSeries integrator
Mail and community

Groupware
Data
Transaction
Message queuing
Message routing,
transformation
Workflow
Table 11. Standard protocols and APIs: Web application environment
Service
Protocol standard
API
Web server
XML, XHTML, XSL/XSLT,

XLink
Servlets,
Server-side-includes
JSP (XML data island)
SAX, Xalan
Web browser
XML,XHTML, XSL/XSLT,
DOM level 1
Applets, directDOM,
Xerces, Xalan
Component model
XML
Java Bean (JAXP)
Business component
model
XML
EJB
Scripting
Table 12. Standard protocols and APIs: Development tools
Service
Protocol standard
API
Authoring and versioning
XML, XMI
Not applicable
Table 13. Standard protocols and APIs: e-business application services
Service
Protocol standard
API
Commerce
XML, TPA/BPF,
RosanettaNet, ebXML
Not applicable
The next section provides additional information about IBMs strategy to put
XML in its Application Framework for e-business.
62
3.2 IBM XML development tools and utilities

To develop an application, programmers need some tools to be more efficient
so they can avoid tedious tasks such as entering XML begin tags and end
tags. They can find a plethora of useful tools and utilities on the IBM
AlphaWorks Web site. These components are parcelled out in the IBM
e-business application architecture, as depicted in Figure 15.
do m D irect
X a lan
Clie nts
X M L en ab ler
Lo tusX S L /X a la n
FO P
X erces/S A X
X M L Is lan d
S VG
W e bS ph ere Tran sco din g P ub lish er
W e b a pplica tion se rve rs
Se rvlets
EJB s
JSP s
A pp letsB ea ns
A ctive X com pone nts
M Q S eries
In te gra tor
D B 2 X M L E xte nd er
B a ck -end
X S L/X S LT
X M L:
- d ata
- m e ta d ata
- m e s sa ge s
X M L/XS L
H TM L/C S S
X M L /XS L
B row sers
and
P ervasive com pu ting
R ic h d o c u m en t
X M L da ta
X M L m eta d ata
D TD /Sch em a
D a ta m o d elin g
M e ta co n te n t
M e ss ag in g
D a tab a se
Sto ra g e
Figure 15. IBM XML components in the e-business application architecture
All the components to be described in this section are available from the IBM
AlphaWorks site http://www.alphaworks.ibm.com or xml.apache.org. This list is
not exhaustive; there are other components on those sites, but we only
describe those which we thought were the most relevant.
63
Note
Any software that is made available through AlphaWorks project is not

generally available software. It has not undergone complete testing it
may contain errors, or it may not function properly, and it is subject to
change or withdrawal at any time. No support or maintenance is provided
with the software. Do not install this software if you are not accustomed to
using experimental software. The AlphaWorks software is made available
without charge in the experimental stage in order to allow you to evaluate
the software in its development stage.
Table 14 lists the components by category, and gives the URLs from which
you can get further information and download the desired components.
Table 14. List of tools and utilities by category
Components
Category
Relative URL
http://xml.apache.org
Cocoon
Web publishing
/cocoon/index.html
FOP
Formatting
/fop/inedx.html
Xalan
Formatting
/xalan/overview.html
Xerces-C
Parsing
/xerces-c/index.html
Xerces-J
Parsing
/xerces-j/index.html
Xerces-P
Parsing
/xerces-p/index.html
http://www.alphaworks.ibm.com
64
XML4J
Parsing
/tech/xml4j
XML4C
Parsing
/tech/xml4c
Data Description by
Example
Editing
/tech/DDbE
TaskGuide Viewer
Editing
/tech/taskguideviewer
Visual XML tools
Editing
/tech/visualxmltools
Xeena
Editing
/tech/xeena
X-It
Editing
/tech/xit
XML Diff & Merge
Editing
/tech/xdiffmerge
Components
Category
Relative URL
XML Master
Editing/
programming
/tech/xmas
XSL Editor
Editing/testing
/tech/xsleditor
XSL Trace
Editing/testing
/tech/xsltrace
directDOM
Formatting
/tech/directdom
lotusXSL
Formatting
/tech/lotusxsl
SVGView
Formatting
/tech/svgview
XML Enabler
Formatting
/tech/xmlenabler
Bean Markup Language
Programming
/tech/bml
TSpaces
Programming
/tech/tspaces
VoiceXML
Programming
/tech/voicexml
XMI Tool Kit
Programming
/tech/xmitoolkit
XML Generator
Programming/
testing
/tech/xmlgenerator
XML Lightweight Extractor
Programming
/tech/xle
XML Security Suite
Programming
/tech/xmlsecuritysuite
3.2.1 Open source initiative: the xml.apache.org project

The xml.apache.org project is an effort of the Apache Software Foundation.
The mission of the xml.apache.org project is to provide:
Commercial-quality standards-based XML solutions that are developed in
an open and cooperative fashion.
Feedback to standards bodies (such as IETF and W3C) from an
implementation perspective.
A focus for XML-related activities within Apache projects.
The Apache Software Foundation ( http://www.apache.org) exists to provide
organizational, legal, and financial support for the Apache open-source
software projects. Formerly known as the Apache Group, the Foundation has
been incorporated as a membership-based, not-for-profit corporation in order
65
to ensure that the Apache projects continue to exist beyond the participation
of individual volunteers, to enable contributions of intellectual property and
funds on a sound basis, and to provide a vehicle for limiting legal exposure
while participating in open-source software projects.
The xml.apache.org project began with a sizeable collection of open source
software to offer, donated by Sun and various other companies and individual
developers besides IBM. In fact, IBM is an Apache devotee, and has a
proprietary version of Apache, a secure server called the IBM HTTP Server
powered by Apache. IBM provided the initial code base for Xerces (Java,
C++, and Perl versions), as well as ongoing support for this and other Apache
projects such as the Apache HTTP server. Lotus provided the initial code
base for Xalan (Java and C++ versions).
The xml.apache.org project currently consists of four sub-projects, each
focused on a different aspect of XML:
Cocoon: A powerful framework, for XML Web publishing
FOP: The world's first print formatting utility driven by XSL formatting
objects
Xalan: XSL stylesheet processors
Xerces: World-class XML parsers
Each of these sub-projects is described in more detail in the following
sections.
3.2.1.1 Cocoon XML-based Web publishing
Cocoon is a powerful framework for XML Web publishing, written in Java,
which brings a whole new world of abstraction and ease to consolidated Web
site creation and management based on the XML paradigm and related
technologies.
The Cocoon model supports the creation of Web sites that are highly
structured and well-designed, reducing duplication of efforts and site
management costs by allowing different presentations of the same data,
depending on the requesting client (HTML clients, PDF clients, WML clients),
and separating different requirements, skills, and capacities within different
contexts. Cocoon facilitates better human resource management by giving
each individual a unique job, and reducing to a minimum the cross-talk
between different working contexts.
To do this, the Cocoon model divides the development of Web content into
three separate levels:
66
XML creation: The XML file is created by content owners with no specific
knowledge of how the XML content is further processed, other than the
particular DTD/namespace chosen. This level is always performed by
humans directly through normal text editors or XML-aware tools/editors.
XML processing: The requested XML file is processed and the logic
contained in its logic sheet is applied. Unlike other dynamic content
generators, the logic is separated from the content file.
XSL rendering: The created document is then rendered by applying an
XSL stylesheet to it and formatting it to the specified resource type (HTML,
PDF, XML, WML, XHTML).
3.2.1.2 FOP XSL formatting objects
FOP, the world's first print formatting utility driven by XSL formatting objects,
is a Java 1.1 application that reads a formatting object tree and then turns it
into a PDF document. The formatting object tree can be in the form of an XML
document (output by an XSLT engine like Xalan), or it can be passed in
memory as a DOM Document or (in the case of Xalan) as SAX events.
3.2.1.3 Xalan XSL stylesheet processors
Xalan (named after a rare musical instrument) is available for both Java and
C++, fully implementing the W3C Recommendation 16 November 1999 XSL
Transformations (XSLT) Version 1.0 and the XML Path Language (XPath)
Version 1.0. XSLT is the first part of the XSL stylesheet language for XML. It
includes the XSL Transformation vocabulary and XPath, a language for
addressing parts of XML documents.
3.2.1.4 Xerces XML parsers
Xerces (named after the Xerces Blue butterfly) provides world-class XML
parsing and generation. Fully-validating parsers are available for both Java
(Xerces-J) and C++ (Xerces-C), implementing the W3C XML and DOM (Level
1 and 2) standards, as well as the de facto SAX (version 2) standard. The
parsers are highly modular and configurable. Initial support for XML Schema
(draft W3C standard) is also provided.
A Perl wrapper is provided for the C++ version of Xerces, which allows
access to a fully validating DOM XML parser from Perl. It also provides for full
access to Unicode strings, since Unicode is a key part of the XML standard.
Xerces-J is available on all Java platforms. Xerces-C is available on AIX,
Linux, HP-UX, Solaris, and Windows.
67
3.2.2 Parsers
IBM is a pioneer in XML technologies, with parsers that have been
consistently highly rated since XML4J version 1.0 was released in 1998. IBM
is a major contributor to Apache's Xerces-J code base, which is the basis for
XML4J version 3.
3.2.2.1 XML parser for Java
XML Parser for Java Early Access release (XML4J-EA) is based on the
Apache Xerces XML Parser which is a validating XML parser written in 100%
pure Java.
XML4J consists of a single package ( com.ibm.xml.parser) containing classes
and methods for parsing, generating, manipulating, and validating XML
documents. XML Parser for Java is believed to be the most robust XML
processor currently available and conforms most closely to the XML 1.0
Recommendation.
XML4J includes support for DOM Level 2, SAX2 (alpha), and parts of W3C
Schema.
XML4J is available on all Java platforms.
3.2.2.2 XML parser for C++
XML parser for C++ (XML4C) is based on Apache's Xerces-C XML parser,
which is a validating XML parser written in a portable subset of C++.
XML4C integrates the Xerces-C parser with IBM's International Components
for Unicoded (ICU) and extends the number of encodings supported to over
150.
It consists of three shared libraries (2 code and 1 data) which provide classes
for parsing, generating, manipulating, and validating XML documents.
XML4C is faithful to the XML 1.0 Recommendation and associated standards
(DOM 1.0, SAX 1.0, DOM 2.0). Source code, samples and API
documentation are provided with the parser.
XML4C is available on AIX, Linux, Solaris, Windows NT, Windows 98, HP-UX
11, HP-UX 10.2, AS/400.
3.2.3 Editing
An XML document must be well-formed (tag balancing) and valid (respect
DTD grammar). When creating a DTD file, or an XML document, it is quite
68
easy to make mistake on the tag name, or on the structure of the document.
IBM proposes some editing tools to facilitate the tedious creation of XML
documents, and DTDs.
3.2.3.1 Data Descriptions by Example
Data Descriptions by Example (DDbE) is a Java component library for
inferring an XML DTD or Schema from a set of well-formed XML instances.
DDbE offers parameters which permit the user to control the structure of the
content models and the types used for attribute declarations. The goal of
DDbE is to give users a good start at creating DTDs for their own
applications.
DDbE is available on all Java platforms.
3.2.3.2 TaskGuide Viewer
TaskGuide Viewer is an XML-based tool for creating wizards. This
wizard-creation tool makes computer tasks easier by breaking complicated
tasks into sequential, simple steps that can be performed using a graphical,
user-friendly interface.
TaskGuide Viewer is a step above other wizard systems, which require you
build the graphical user interface and manage data using traditional
programming languages. Building and displaying wizards with the TaskGuide
Viewer is as easy as creating and viewing HTML files.
The companion documentation, IBM's TaskGuide: An XML-Based System for
Building Wizards, has all the information you need to develop wizards. Once
you've coded your wizard script, the TaskGuide Viewer displays your panels
and follows the instructions in your script. Best of all, the TaskGuide Viewer
provides usability-tested screen layout and navigation options, allowing you
to focus on task content rather than design elements. The main headaches of
building wizards like screen layout, navigation, and data management are
eliminated.
TaskGuide is available on Java platforms.
3.2.3.3 Visual XML tools
The IBM XML Tools package is an early technology release for providing XML
tooling in the Application Framework for e-business. It is not intended for
production use. The IBM XML Tools can be enhanced via a series of ongoing
updates.
This package contains the following four Visual technologies:
69
1. Visual XML Query

Visual XML Query is a tool for helping you construct an XML query
expression. Using Visual XML Query, you can do the following:
- Open an XML document.
- Visually construct an XPath expression for the XML document.
- Execute the XPath expression using the Lotus XSLT-based XML Query
engine.
- Save the XPath expression to a file.
2. Visual XML Builder
Visual XML Builder is a tool for constructing a valid XML document from a
DTD. In particular, Visual XML Builder can be used to construct a Trading
Partner Agreement (TPA). Using Visual XML Builder, you can:
- Create an XML model that conforms to a DTD.
- Customize the XML model to add in additional semantic information
such as data types and constraints.
- Define user-exit for specifying application specific processing logic.
- Support re-use of other XML models.
- Validate an XML document.
- Generate the final XML document.
3. Visual XML Creation
Visual XML Creation is a tool for creating XML documents from an SQL
query. Using Visual XML Creation, you can do the following:
- Connect to a DB2 database, and retrieve a list of tables.
- Visually generate SQL select, insert, update, and delete statements.
- Execute an SQL query statement and display the result set.
- Generate an XML document and a corresponding DTD for the query
result. You can choose from a number of different patterns for mapping
your relational data to an XML format.
- Generate a default XSL stylesheet for formatting your XML document.
- Save the query statement into a configuration file. A servlet that
processes this configuration file is included. You can deploy this servlet
to the WebSphere Application Server and use it to create XML
documents from an SQL query at run-time.
- Store a model using XMI.
70
4. Visual DTD
Visual DTD is a tool for creating and viewing DTDs. Using Visual DTD, you
can do the following:
- Create DTD elements, attributes, entities, and notations.
- Import existing DTDs for structured viewing.
- Create DTDs from existing XML documents.
- Generate DTDs.
- Generate XML Schemas. Note that this is only preliminary support for
the W3C XML Schema Language. IBM intends to provide complete
support in subsequent updates.
- Generate Java classes for creating XML instances of an XML Schema.
- Generate a sample XML document from a DTD.
- Generate a default HTML form from a DTD.
- Search elements and attributes in the DTD.
5. Visual XML Transformation
Visual XML Transformation is a tool that can help you create a new XML
document from existing XML documents. Transforming XML to XML can
be very useful if you want to take an existing XML format and transform it
into a format that fits a particular need. Using Visual XML Transformation,
you can do the following:
- Input one or more DTDs describing the source XML documents, and
visually construct the DTD describing the target XML document.
- Generate the resulting DTD.
- Generate the XSLT script that will transform the source XML
documents into the target XML document.
- Unit test the XSLT script.
Visual XML tools are available on Windows NT, and all Java platforms.
3.2.3.4 Xeena
When using Xeena, the editor takes as input a given Document Type
Definition (DTD), and automatically builds a palette containing the elements
defined in the DTD. Users can thus create/edit/expand any document derived
from that DTD, by using a visual tree-directed paradigm. The visual paradigm
71
requires a minimum learning curve, as only valid constructs/elements are

presented to the user in a context-sensitive palette.
A Key feature of Xeena is its syntax directed editing ability. Xeena is aware
of the DTD grammar, and by making only authorized elements icons
sensitive, automatically ensures that all documents generated are valid
according to the given DTD.
Other Xeena features include:
Intuitive viewing and editing of XML documents in a tree control view.
Editing of multiple XML documents.
Use of an XML source viewer.
Restricts adding and editing of features according to the DTD, and checks
validity of documents produced.
Easy customization of display.
Xeena is available on Windows 95, Windows NT, Windows 98, UNIX, and
MacOS.
3.2.3.5 XML Diff and Merge
The XML Diff and Merge Tool for XML is a Java program that can be used for
reconciling or understanding changes that a single user has made to their
XML document, or for reconciling or understanding changes that several
people have made to a single document.
When using this tool, you pick one XML document to be the base and another
one to compare it with. The tool points out each difference from the base by
use of symbols and color. You then walk through each difference and decide
whether to include the difference or not.
The XML merge tool is available on AIX and Windows NT.
3.2.3.6 X-It
X-It is a Java based application for batch processing of XML files. X-It takes a
batch of XML files and processes/ transforms them based on the operation
specified.
X-It supports the following operations:
Adding a PI/Comment to the XML files.
Deleting specific nodes from XML file.
Finding a given text and replacing with a new value.
72
Validating the XML file against the specified DTD.

Sorting the XML file.
X-It provides a wizard that will guide you through the processing of XML files.
The processing can be done in an interactive mode, that is, you can view the
results and save; or in a non-interactive mode, which automatically saves the
successfully processed files.
X-It is available on AIX, Linux, OS/390, Solaris, OS/2, Windows 95,
Windows NT, and Windows 98.
3.2.3.7 XML Master
XML Master (XMas) allows you to design and generate custom Java Beans
for working with a particular XML document. It consists of two parts:
1. The XMas application an editor for designing and generating custom
Java beans to work with XML documents that conform to a certain DTD
(Document Type Definition).
2. The XMas Bean Suite a collection of Java beans that can be used for
modeling XML structures and getting access to their parts via
XML-oriented GUI components.
The XMas application is used to design both visual and non-visual beans to
work with a particular XML document, for example, select the XML elements
that your application needs to work with and use the tool to design the layout
for an editor to work with those elements. When the design is complete, use
the XMas application option to generate code. XMas creates the necessary
Java code for the beans and places them in a jar file in the location specified.
Then you can just import the jar file into an IDE such as VisualAge for Java,
where they can be wired into applications.
XML Master is available on AIX, Linux, Solaris, OS/2, Windows 95,
Windows NT, Windows 98, HP-UX.
3.2.3.8 XSL Editor
This XSL stylesheet editor incorporates trace function and provides
assistance with writing select and match expressions. It integrates XSL Trace
with the Visual Transform tool, both available on AlphaWorks.
IBM's XSL Editor allows users to set and remove break points on the
stylesheet and source document. The XSL Editor user interface features an
XML source based collapsible tree view with dynamic font resizing for
Zooming in/out to handle small/large documents. Dynamic edit pads
provide a vehicle for stylesheet and source document editing, which are
73
automatically kept in synchronization with their corresponding tree views.

Stylesheet authoring is made convenient by the ability to automatically
generate XPath syntax from sample source documents.
The XSL Editor is available on all Java platforms.
3.2.3.9 XSL Trace
The IBM XSL Trace application reveals the mystery of XSL transforms! XSL
Trace allows a user to visually step through an XSL transformation script,
highlighting the transformation rules as they are fired. Additionally, an XSL
Trace user can view the XML source and the corresponding XML or HTML
result in real time. XSL Trace users can set and remove break points on
the stylesheet and source document as well as highlight all source nodes
processed by each style rule. The XSL Trace UI features an XML source
based collapsible tree view with dynamic font resizing for Zooming in/out
to handle small/large documents.
The XSL Trace application is for anyone who is developing XSL scripts for
either the client or server, and is a natural complement to LotusXSL. Indeed,
XSL Trace is built on the new LotusXSL trace API jointly developed by the
LotusXSL and Advanced Internet Publishing Teams. As a consequence, XSL
Trace adheres to the latest draft of the W3C XSL specification.
XSL can be a tough language for even experienced programmers to start
using. IBM's XSL Trace can speed up the creation of XSL scripts for
seasoned developers and serve as a great learning tool for those new to
XSL.
3.2.4 Formatting
In this section we describe some rendering technologies for displaying data
contained in XML documents through a Web browser.
3.2.4.1 DirectDOM Development Kit
The DirectDom technology allows a Java developer to manipulate the live
Document Object Model (W3C DOM) of a browser or Scalable Vector
Graphics plug-in to build rich graphical user interfaces.
In its simplest form, DirectDom is about writing Weblets. These are Java
client programs which use the client user interface facilities of a 5th
generation browser or other DOM viewer (such as SVG) to render and control
its interface via standard W3C interfaces found in DOM Level 1, DOM Level
2, and HTML 4.0. These DOM interface facilities include UI widgets, layout,
accessibility, sound, and printing functions. Therefore, the Weblet runtime
74
does not rely upon the Abstract Windowing Toolkit (AWT) nor the JFC. The
DirectDom runtime is used to build Java programs which run inside a browser
Web page, or as stand alone applications.
The Weblet environment shall be dynamically reconfigurable and extensible
by means of a framework. This shall apply both to the Java component as
well as any possible native component of the Weblet runtime. Given the
reliance of the Weblet runtime upon the underlying facilities of rapidly
changing browser technology, a Weblet environment provider must be able to
update the environment as quickly and as painlessly as possible for the user.
One way to write a Weblet in DirectDom is to write the user interface in HTML
and the logic in Java. In this case, one would embed a Weblet in an HTML
page to perform a role, much as Java Script is used today. The role of the
Weblet would be to set up event listeners to modifications of the HTML. When
such events occur, the Weblet could modify the HTML page accordingly.
A second way to write a Weblet is to embed it in an empty HTML page. When
the Weblet is started, it could dynamically add buttons, tables, text, and
graphics to the browser window via manipulating the DOM. As with the first
scenario, it could then add event listeners and respond to events accordingly.
A third way to write a Weblet is to combine the first two approaches, where at
times pre-constructed HTML is used for the user interface, while at other
times the Weblet adds new UI elements via manipulating the DOM.
In addition, one could simply write a Weblet that is run as an application.
Instead of navigating to a Web page that embeds the Weblet, a user could
simply run a Weblet directly by typing a command in a shell such as DOS or
CSHELL or by double-clicking on a Weblet icon. In this case, the Weblet
could then open a Weblet window to display a UI. A Weblet window is like any
other client OS window, and embeds a browser's engine inside it without the
accompanying browser chrome. The Weblet can then add UI elements to this
window by manipulating the DOM.
Of course, DirectDom Weblets can be used by non-Java programmers as
well. For example, an HTML author or Java Script developer could reuse
pre-existing Weblets to enhance a Web page or connect to a database.
The developer kit is available on Windows NT and 98 for Microsoft Internet
Explorer 5.0+ (not including the IE 5.5 beta) and the Adobe SVG plug-in. A
DevKit for Mozilla M14 (Windows NT, Windows 98, Mac OS 9, and Linux) will
soon be posted. The developer kit for DirectDom on Internet Explorer is
75
shipped in two forms, one that includes IBM's Java 1.2.2 JDK as well as
DirectDom and one that includes only DirectDom.
3.2.4.2 LotusXSL XSL Processor
XSL provides a mechanism for formatting and transforming XML, either at the
browser or on the server. It allows the developer to take the abstract data
semantics of an XML instance and transform it into a presentation language
such as HTML.
LotusXSL implements an XSL processor in Java, and can interface to APIs
that conform to the October 1 Document Object Model (DOM) Level 1
Specification. The processor can be used from the command line or from an
wrapper applet, or it can be used as a sub module of other programs, and
accessed via the API.
LotusXSL version 0.20.0 is an IBM gold candidate preparing for a 1.0
production-level release. It remains compatible with XML4J 2.x/1.x, as well as
with Xerces 1.0.2, and it is available on Java platforms.
3.2.4.3 SVGView
Scalable Vector Graphics (SVG) is a language for describing two-dimensional
graphics in XML. The language is a new standard being developed by the
World Wide Web Consortium (W3C).
SVGView is a Java program that uses Java 2D and the XML Parser for Java
to parse, process, and display SVG files on any XML-enabled Web browser.
The viewer enables Web professionals working with SVG files to preview
their forms or images. The viewer passes the document to the parser, which
creates the data tree structure. The parser then traverses the tree in Java 2D,
which calls the appropriate functions in the Java2 API. For example, if a
square needs to be drawn, the relevant Java2D function draws the square at
the appropriate location.
For a demonstration of on-line transcoding, including Advanced Function
Presentation (AFP) documents to SVG and Color Graphics Metafile (CGM)
documents to SVG, see the IBM On-Line Transcoding Demo package. You
can use SVGView to display the transcoded output.
SVGView is available on Windows 95, Windows NT, and Windows 98.
3.2.4.4 XML Enabler
The XML Enabler is a servlet that can successfully implement stylesheets
such as the LotusXSL technology. Using the XML Enabler, developers with
any kind of browser can now send requests to a servlet, and as the servlet
76
responds, it formats the data using different XSL stylesheets. The system
administrator can then configure which stylesheets go with which browser
types.
Therefore, the XML Enabler makes XML real by allowing any user of any
browser to view and use XML data. Most developers in the XML space are
concerned with the heavy client. In other words, you can use XML as soon
as you move to Internet Explorer 4.0 or higher. The XML Enabler technology
removes this impediment and allows the system administrator to focus on
using XML-tagged data intelligently without worrying about the types of
browsers that might be used to view that data.
The XML Enabler uses the XML and XSL technology mentioned above,
combined with the information in the HTTP header. The system administrator
defines the mapping between browser types and XSL stylesheets. Once that
mapping is defined, the servlet gets XML data from a data source, then
formats that data using an XSL stylesheet.
The XML Enabler works with the Lotus Extensible Stylesheet Language
(XSL) Processor to transform data using XSL stylesheets. When an HTTP
request comes in to the XML Enabler, it does three things:
1. Gets the XML document requested by the client (the URL of that
document is passed as a parameter on the URL).
2. Looks at the client type (using the user-agent field of the HTTP header),
and selects an XSL stylesheet. The stylesheet selected for each
user-agent type is defined by the Web master or Web mistress.
3. Once the XML document and the XSL stylesheet are selected, the two are
combined by the Lotus XSL Processor; the output from the XSL Processor
is returned to the client.
XML Enabler is available on all Java platforms.
3.2.5 Programming
When programming an application, the developer needs to manipulate and
access various types of data, and use pre-defined services such as
communication services. This section describes some useful items which
could help the developer.
3.2.5.1 Bean Markup Language
Bean Markup Language (BML) is an instance of an XML-based component
configuration or wiring language customized for the Java Bean component
model. The language is designed to be directly executable; that is,
77
processing a BML script will result in a running application configured as

described in the script. The BML language has elements that can be used to
describe the creation of new beans, accessing of existing beans,
configuration of beans by setting/getting their properties and/or fields, binding
of events from some beans to other beans as well as calling of arbitrary
methods in beans.
IBM provides two implementations of BML the first is an interpreter that
plays a BML script to create the desired bean hierarchy (which is then a
running application). This is implemented using reflection and is very small,
approximately a 70K jar file (without class compression).
The second implementation is a compiler that compiles any BML script into
reflection-free Java code. The advantage of this is that it allows one to
capture the inter-component structure of the application using a first-class
language designed for that purpose and yet be able to compile it into
"regular Java code with basically no performance loss.
BML is available on all Java platforms.
3.2.5.2 TSpaces
TSpaces is a set of network communication buffers called tuple spaces and
a set of APIs (and classes that implement the API) for accessing those
buffers. TSpaces allows heterogeneous, Java-enabled devices to exchange
data with little programming effort. The package includes server software that
implements the buffers and client software for accessing the buffers.
TSpaces provides group communication services, database services,
URL-based file transfer services, and event notification services. With its
small footprint, it is ideal for bringing network services to small and
embedded systems; for example, it brings the power of the network to palm
devices, making them full-fledged network computers capable of controlling
printers and other networked devices.
For the client, being connected to TSpaces is like having the perfect
assistant: TSpaces acts as a reminder service, carries out any tasks that you
assign to it, reports incoming messages and delivers outgoing messages,
and notifies you of any events in which you're interested. By adding additional
client applications, TSpaces can be used as a universal print service, E-mail
service, pager service, remote control service, and so on.
TSpaces has many advantages over other technologies, including the
following:
78
Data is de-coupled from programs. Data can outlive its producer (because
once it's produced, it lives in tuple space) and can be produced before the
receiver exists.
Communication is anonymous. The sender needn't know about the
receiver, and vice-versa. Sender and receiver only need to know about
tuple space, which mediates all communication.
Communication is asynchronous. The sender and receiver don't have to
rendezvous to communicate; the producer produces when it's ready, and
the consumer consumes when it's ready.
Since it is written in Java, TSpace client applications can be loaded
dynamically into any network-attached computer. The TSpaces package
comes with several useful applications that show how to build TSpace clients.
TSpaces is available on all Java platforms.
3.2.5.3 VoiceXML
VoiceXML is an XML-based markup language for distributed voice
applications, much as HTML is a language for distributed visual applications.
VoiceXML is designed for creating audio dialogs that feature synthesized
speech, digitized audio, recognition of spoken and dual tone multi-frequency
(DTMF) key input, recording of spoken input, telephony, and mixed-initiative
conversations. The goal is to provide voice access and interactive voice
response to Web-based content and applications, for example, by telephone,
PDA, or desktop.
VoiceXML is being defined by an industry forum, the VoiceXML Forum
founded by AT&T, IBM, Lucent, and Motorola which was established to
promote the Voice eXtensible Markup Language (VoiceXML).
VoiceXML brings the power of Web development and content delivery to
voice response applications, and frees the authors of such applications from
low-level programming and resource management. It enables integration of
voice services with data services using the familiar client-server paradigm,
and it gives users the power to seamlessly transition between applications.
The dialogs are provided by document servers, which may be external to the
browser implementation platform.
For further information on the VoiceXML Forum and to comment on the
specification, please refer to the VoiceXML Forum Web site
http://www.voicexml.org/.
79
3.2.5.4 XMI Tool Kit

XMI specifies an open information interchange model that gives developers
working with object technology the ability to exchange models and data over
the Internet in a standardized way, thus bringing consistency and
compatibility to applications created in collaborative environments. By
establishing an industry standard for storing and sharing object programming
information, development teams using various tools from multiple vendors
can collaborate on applications. The new XMI standard allows developers to
leverage the Web to exchange data among tools, applications, and
repositories, to create secure, distributed applications built in a team
development environment.
The Toolkit is a Java component that converts UML information between
Rational Rose Models and XMI-standard XML files. The Toolkit can also
generate DTDs directly from your models. A Reference Implementation of
XMI, with source code, is included. The new functionality includes the ability
to generate Java from Rational Rose and UML models and to convert Java to
Rational Rose and UML models.
XMI toolkit is available on Windows 95, Windows NT, and Windows 98.
3.2.5.5 XML Generator
Creating test cases for XML applications by hand from DTDs can be tedious
and may not cover all possible or required instances. IBM's XML Generator is
a Java program designed to automate this process by generating random
instances of valid XML from a single input DTD. The XML Generator engine
can create an XML file or can be accessed via the Document Object Model
(DOM) API.
By random we mean that the generator operates within a few user-definable
constraints, which lets the user limit the size and customize the appearance
of the output XML. Users can limit the depth of the generated tree, limit the
number of IDs an IDREFs attribute can contain, choose whether or not
implied attributes should appear, and more. Users can even indicate which
entities should appear within PCDATA using a configuration file.
With the proliferation of XML vocabularies and processors the generation of
constrained random input instances is essential for batch testing of XML
applications. DTD authors can also inspect randomly generated XML
instances to quickly reveal good and bad DTD writing practices.
XML Generator is available on all Java platforms.
80
3.2.5.6 XML Lightweight Extractor

Given a DTD, the XML Access Server Lightweight Extractor (XLE) allows a
user to annotate the DTD to associate its various components with underlying
data sources, and when requested, extracts data from the data sources and
assembles the data into XML documents conforming to that DTD.
In many applications, it is often necessary to generate XML documents from
existing data sources so that the documents conform to certain given DTDs.
XLE allows a user to complete this task in a simple and flexible way, without
requiring the user to write detailed access queries, for example SQL queries.
XLE has the following features:
XLE currently supports JDBC compliant data sources.
Given a DTD and a set of tables accessible through JDBC, the user first
annotates the DTD file to create a mapping file called a DTDSA file.
DTDSA annotation is done by inserting into the DTD file mapping
constructs that are syntactically simple yet flexible and powerful enough to
express a large number of ways a user may want to map underlying data
into XML documents.
When a particular XML document is requested, the user specifies the
DTDSA file and zero or more runtime parameters, and XLE will construct
the appropriate XML document from the underlying data sources and
return it to the user.
The mapping mechanisms of DTDSA allow XLE to assemble an XML
document from a relational table, a set of relational tables related by
foreign-key relationships, or more advanced relationships.
XLE is available on OS/390, Windows 95, Windows NT, Windows 98, UNIX,
AIX, AS/400.
3.2.5.7 XML Security Suite
XML is expected to facilitate Internet B2B messaging because of its simplicity
and flexibility. One big concern that the customer may have in doing Internet
B2B messaging is security. Internet is a public network, and there has been
no protection against attacks such as eavesdropping and forgery. If
messages are stolen or modified during transmission, B2B messaging could
become almost useless. Fortunately, the recent advancement of public-key
cryptography has remedied most of the security problems in communication.
Using modern cryptographic protocols such as SSL, the Internet became as
secure as any other networks, including VANs and intranets.
81
IBM XML Security Suite will push the security further by introducing new
security features such as digital signature, element-wise encryption, and
access control that are beyond the capability of the transport-level security
protocol such as SSL. Our goal is to contribute to the discussions of standard
bodies by providing sample implementations, as well as to supply our
advanced technologies to our partners and to hear what they think. In this
release of XML Security Suite, IBM provides reference implementations of
DOMHASH, a proposed canonicalized digest value for XML documents, and
its two sample applications. DOMHASH can be a basis for XML digital
signature that is being discussed in both IETF and W3C.
IBM XML Security Suite is available on Linux, Windows 95, Windows NT, and
Windows 98.
3.3 XML open frameworks

When interacting with business partners across open networks such as the
Internet, there are likely to be considerable variations in request/response
times. In these cases, a single business flow requiring responsive interaction
with multiple partners, such as in the travel industry, will need to employ
parallel concurrent conversations. During these types of conversations,
partners may detect unexpected conditions requiring specialized action by
the interaction or business logic software. An XML framework provides
services that map interaction events from message processing into business
events which can be meaningfully handled in the business applications.
These services enable the coupling of application processing to appropriate
interaction processing, with the ability to control how interaction events are
filtered and combined.
3.3.1 OASIS consortium, XML.ORG

OASIS ( http://www.oasis-open.org), the Organization for the Advancement of
Structured Information Standards, is a non-profit international consortium
founded in 1993 to advance the open interchange of documents and
structured information objects. OASIS aims to accelerate the adoption of
product-independent formats based on public standards. These standards
include SGML, XML, HTML, and CGM, as well as others that are related to
structured information processing. Members of OASIS are providers, users,
and specialists of the technologies that make these standards work in
practice.
XML.ORG ( ww.xml.org) is an industry Web portal operated by OASIS, the
Organization for the Advancement of Structured Information Standards.
82
Funded by a group of companies committed to establishing an open,

distributed system for enabling the use of XML in electronic commerce and
other industrial applications, XML.ORG is designed to provide a credible
source of accurate, timely information about the application of XML in
industrial and commercial settings and to serve as a reference repository for
XML specifications. The most important function of XML.ORG is to serve as a
trusted, secure, persistent repository and registry for document type
definitions (DTDs), namespaces, schemas, and other specifications that must
be globally accessible in order to make possible the use of XML for data
exchange within particular industries. This base functionality will evolve
through releases offering increased capabilities to OASIS members and the
general public.
The reference site is intended to jump-start the use of XML for electronic
commerce by providing a key piece of the necessary infrastructure and then
to serve as a model for an extensible, distributed system of registry/repository
sites based on the same architecture.
XML.ORG takes in an XML catalog which lists organizations known to be
producing industry-specific or cross-industry XML Specifications. The XML
Catalog is intended to evolve into the XML.ORG Registry and Repository for
XML Schemas, DTDs, and specifications. Here are some initiatives for
industry standard:
ebXML e-business XML Initiative
FpML Financial Products Markup Language
IFX Interactive Financial Exchange Banking
SVG Scalable Vector Graphics
RosettaNet IT Supply Chain
XMI XML Metadata Interchange
OTA Open Travel Alliance
HL7 Health Level Seven
OTP Open Trading Protocol
WML Wireless Markup Language
XML/EDI Electronic Data Interchange
XHTML XML HTML
83
3.3.2 Electronic Business XML initiative (ebXML)

Electronic Business Extensible Markup Language (ebXML,
http://www.ebxml.org) is an International initiative established by the United
Nations Centre for the Facilitation of Procedures and Practices for
Administration, Commerce and Transport (UN/CEFACT) and the
Organization for the Advancement of Structured Information Standards
(OASIS) with a mandate to undertake a 15-18 month program of work. The
purpose of ebXML initiative is to research and identify the technical basis
upon which the global implementation of XML can be standardized. The goal
is to provide an open technical framework to enable XML to be utilized in a
consistent and uniform manner for the exchange of Electronic Business (EB)
data in application-to-application, application-to-human, and
human-to-application environments, thus creating a single global market.
UN/CEFACT ( http://www.unece.org/cefact) is the United Nations body whose
mandate covers worldwide policy and technical development in the area of
trade facilitation and electronic business. Headquartered in Geneva, it has
developed and promoted many tools for the facilitation of global business
processes, including UN/EDIFACT, the international EDI standard. Its current
work program includes such topics as Simple-EDI and Object Oriented EDI,
and it strongly supports the development and implementation of open,
interoperable, global standards and specifications for electronic business.
Big companies such as IBM, Microsoft, Oracle, SUN are participants in
ebXML.
A primary objective of ebXML is to lower the barrier of entry to electronic
business in order to facilitate trade, particularly with respect to small- and
medium-sized enterprises (SMEs) and developing nations.
Following are some examples of ebXMLs value:
Provides the only globally developed open XML-based Standard built on a
rich heritage of electronic business experience.
Creates a Single Global Electronic Market Enables all parties irrespective
of size to engage in Internet-based electronic business.
Provides for plug-and-play shrink-wrapped solutions.
Enables parties to complement and extend current EC/EDI investment
expand electronic business to new and existing trading partners.
Facilitates convergence of current and emerging XML efforts.
Using the strengths of OASIS and UN/CEFACT to ensure a global open
process, ebXML delivers this value by:
84
Developing technical specifications for the open ebXML infrastructure

Creating the technical specifications with the worlds best experts
Collaborating with other initiatives and standards development
organizations
Building on the experience and strengths of existing EDI knowledge
Enlisting industry leaders to participate and to adopt ebXML infrastructure
Realizing the commitment by ebXML participants to implement the ebXML
technical specifications
3.3.3 WebSphere B2B Integrator

IBM has announced WebSphere B2B Integrator software, which combines
technologies from IBM's integration and transaction software, and which is
based on open XML technology.
WebSphere B2B Integrator is be built on IBM's WebSphere Application
Server, its industry-leading MQSeries messaging software and open XML
technology for e-contracts called tpaML (trading partner agreement markup
language).
The following sections supply a short overview of the fundamental building
blocks on which WebSphere B2B Integrator will be based: Trading Partner
Agreements (TPAs) and the IBM Business-to-business Protocol Framework
(BPF).
3.3.3.1 Trading Partner Agreements
When a business externalizes automated functions to make them available to
business partners several new issues must be addressed which were less
important or had simple solutions within a single enterprise. If the function
becomes accessible via a public network, how will it be reached, who will be
allowed to use it, and how will these users identify themselves? What do both
parties in the resulting long- running conversation commit to in terms of
behavior, responsiveness and recovery from error situations? What are the
rules of interaction.
The foundation of tpaML is the Trading Partner Agreement (TPA). A TPA is an
electronic contract that uses XML to stipulate the general contract terms and
conditions, participant roles (buyers and sellers), communication and security
protocols, and business processes such as valid actions and sequencing
rules.
85
tpaML is a complementary technology to business protocol standards

projects such as ebXML, the Electronic Business XML initiative, which is a
joint effort of the United Nations/CEFACT and OASIS to establish a global
framework for the exchange of electronic business data (see 3.3.2,
Electronic Business XML initiative (ebXML) on page 84).
The TPA simplifies the specification of a business-to-business interaction by
organizing the information into separate functional layers. Data flow through
the runtime layers is governed by specifications in the TPA. This layering
provides appropriate abstractions for business data flow and minimizes the
need for specialized coding.
The functional layers specified in a TPA and supported in the underlying
Business-to-business Protocol Framework runtime processing (see 3.3.3.2,
Business-to-business Protocol Framework (BPF) on page 87) are:
Transport, which handles the selected transport protocol, network
connection, and basic security
Document exchange, which provides document abstraction, including
message data mapping, non-repudiation, time-stamping, logging and audit
Business protocol rules and interface, which defines the requests that
each partner may make of the other; and provides message sequence and
responsiveness checks, as well as document type and trading partner
specific data handling.
These agreements are to be enforced by the customized integration software
that will be used to govern all transactions that are conducted over the
Internet between the trading partners' business systems. For example,
consider a small auto parts manufacturer that wants to sell to a major auto
maker. These two partners would take the following steps:
1. The auto maker creates the TPA using a TPA-aware authoring tool, then
sends the parts manufacturer a tpaXML template containing all the
necessary information about the automaker.
2. The parts manufacturer adds the essential information about itself to the
template and returns the completed TPA via the Internet to the automaker.
3. The TPA is then processed by a code generator at each trading partner's
site to customize the B2B integration software that will be installed on
each business system involved in transacting business.
4. At this point, the auto maker could issue purchase orders in the form of
XML documents transferred to the parts manufacturer under control of the
tpaML document.
86
Section 6.2.1, Trading Partner Agreements on page 185 describes TPAs in

detail.
3.3.3.2 Business-to-business Protocol Framework (BPF)
The Business-to-business Protocol Framework (BPF) provides a
comprehensive set of tools and enablers for ease of specification,
configuration, plug-in, customization, and execution of a set of TPAs between
business partners. It is the gateway, coordinator and control-point of choice
across intra-business and inter-business processes, for example, between
the buy/sell component of a local business, the remote businesses, and the
back-end systems.
The protocols are expressed as an electronic TPA in XML using a higher level
authoring tool and are registered to the BPF server along with the internal
business processes for setting up such B2B interactions.
BPF is architected as a general mechanism to support various business
protocols and B2B processes, such as the Open Buying on the internet (OBI),
Commerce XML (cXML), and so on.
In the BPF architecture, this is accomplished by creating a personality for a
business protocol, based on the specification of a protocol TPA. Typically
B2B processes, such as Request For Quote (RFQ), Request For Information
(RFI), and other processes, are similar across various B2B protocols and can
be implemented by the same framework. These other processes will be
implemented largely by changing the TPA. Tie-in to back-end systems is
provided by invoking an extensibility framework from the business logic
interface which is triggered by incoming requests.
A partner's use of BPF does not require that all partners to a given TPA must
also use BPF. This independence is essential for doing business over an
open medium such as the Internet. One should not dictate to others which
technology to use to send and receive messages. Because BPF is
technology neutral, it is ideal for setting up loosely-coupled trading
agreements in which, for example, a business is free to replace suppliers by
others without having to make a large IT investment to support the new
supplier. As long as the business protocol, and hence the TPA, does not
fundamentally change, replacing business partners by others is practical.
Figure 16 illustrates the role of BPF as the gateway, coordinator and
control-point of choice between intra-business and inter-business processes.
It is positioned between the buy/sell component of a local business, the
remote businesses, and the back-end systems. The applications spanning
87
multiple businesses (such as procurement or supply chain management) are

numerous and can be built using this framework.
B2
B1
B3
BPF
BPF
selling
purchasing
Backend
Systems
Backend
Systems
Figure 16. BPF as a business-to-business coordinator
A version of BPF is built on top of an Enterprise Java Beans (EJB) server and
employs a diverse set of technologies for providing various functions and
services. A business may communicate with its partners using one of the
several protocols HTTP, SMTP, FTP, VAN, IBM MQSeries. It may even use
different protocols for different sets of actions on a per-TPA basis. Security
technologies include transport security (SSL), authentication using digital
certificates, as well as digital signatures for non-repudiation (using MD5,
SHA-1). Various data formats include EDI, XML-EDI or other XML formats.
Appropriate message parsers or message generators are provided for
converting these documents into an internal format. Independent software
components providing many of these technologies can be plugged in to the
BPF framework via a vendor-neutral open API, thus allowing developers to
customize solutions of their choice.
88
BPF provides many different services to the business applications running on

this platform. In addition to the basic TPA service, BPF provides services like
time-stamped logging, recovery services, public-private key cryptography,
reliable document exchange, and document repository.
Section 6.2.2, The IBM Business-to-business Protocol Framework on page
204 gives you a detailed description of BPF.
3.4 XML extensions to IBM products

IBM and Lotus have a long-standing commitment to open standards and
cross-platform technologies, meaning that you can confidently adopt new
technologies such as XML, Java, and other component technologies that
enable you to move from business as usual to e-business.
IBM intends to XML-enable many middleware products to help customers and
business partners build, deploy and manage e-business applications. IBM is
the first to offer messaging products that support both XML and Java
technologies. This functionality makes it easy for companies to exchange
information internally as well as with business partners and customers.
format.
3.4.1 WebSphere Application Servers

IBM WebSphere Application Servers (WASs) are part of a family of IBM Web
application servers and complementary development and management tools
providing a complete solution for running, building, and managing e-business
applications. XML support and tools are key components of the server
environment, enabling widespread communication of business content.
3.4.1.1 WebSphere programming model with XML
WebSphere Standard Edition is capable of running servlets, Java Beans and
Java Server Pages, all of which can connect to back-end resources such as
databases. In addition to that, WebSphere Advanced Edition gives you the
ability to run Enterprise JavaBeans. Both editions provide a set of XML
related tools and utilities that are packaged into what is called XML Document
Structure Services. These services consist of document parsers, document
validators, and document generators for server-side XML. The Document
Structure Services support:
W3C Extensible Markup Language (XML) 1.0
W3C Namespaces in XML (Recommendation January 14, 1999)
89
W3C Level 1 Document Object Model Specification (DOM) 1.0

(Recommendation October 1, 1998)
XSL Transformations Version 1.0
XML Path Language Version 1.0
Microstar SAX 1.0
The XML Document Structure Services in WebSphere is a package of three
components:
XML for Java Parser
LotusXSL
DTD Catalogs
To make it easier to use industry standard DTDs and other grammars, local
copies are installed with the Application Server. Some of the grammars in the
library are:
Channel Definition Format (CDF), developed by Microsoft Corporation,
enables subscription to Web-based channels (a Web site or a portion of a
Web site). The subscription can be implemented to have the Web site
automatically send the subscriber updates to the channel (using push
technology) or transmit the updates at the request of the subscriber (using
pull technology). In either case, the subscriber must be able to link to a
CDF file on the channel site. The CDF file is an XML document that
conforms to the CDF DTD.
Mathematics Markup Language (MathML), developed by the W3C, is a
grammar for documents that contain math formulas, notations, and other
data.
Wireless Markup Language (WML) is a grammar for creating documents
so that they can be efficiently transmitted and displayed on narrowband
devices, such as cellular phones, personal digital assistants (PDAs), and
pagers.
XML is an excellent solution to separate data from its presentation, for
example, if you want to do any of the following:
Tailor data to different client or media types:
-
90
Pervasive computing, such as SpeechML, WirelessML (WML)

HTML-enabled browsers
XML-enabled browsers
CD
Paper
Tailor data to different user preferences or privileges:

- My Yahoo versus Your Yahoo
- Free versus paid versus premium content
XML can also be used when your applications need to share data with other
applications in an open data format:
Between server-based applications (business-to-business)
Both intra-enterprise and inter-enterprise
Enterprise information portal, collaboration, workflow, content managers,
EDI, proxies, and so forth
With XML-enabled clients that locally apply views
(business-to-consumer)
To improve network response
To reduce network traffic
To reduce server load
To increase sharing of legacy content stores (business-to-legacy)
To implement your needs in term of data representation, and data sharing,
you can use servlets, and Java Server Pages.
Servlets and XML
Servlets are Java objects which generate an output stream based on input
parameters. Generally, these are used to generate HTML, which is then sent
to a client browser over HTTP. However, servlets can generate any kind of
output stream, including XML. Servlets do not need to be called by a browser
other servers, Java programs, or Java Applets can call servlets over HTTP
and receive XML data in this way. Because XML is easy to parse, and can
form a publishable interface between systems, this is an easy mechanism for
system-to-system communications.
Java Server Pages and XML
Java Server Pages are textual documents that contain special dynamic
tags. These tags serve as templates for dynamic data which is inserted at
runtime by the server. JSPs are requested by the user from the Web server.
WebSphere evaluates them and converts them into a static output stream,
which is sent to the client. The actual implementation of JSPs is that they are
compiled into servlets before running. This means that programmatically they
are equivalent to servlets. However, syntactically they are like HTML or XML
documents. Generally, JSPs have been used to generate HTML. However,
91
the JSP 1.0 specification (see http://java.sun.com/products/jsp/index.html)

has been extended with an optional XML-compatible syntax to make it easier
to create XML documents with JSPs. WebSphere Application Server 3.0
supports this extension.
XSLT Islands are a new technology available inside WebSphere Application

Server version 3.0, which allows XSL to be used directly inside JSPs. In
effect, this technology allows JSPs to contain HTML, Java and XSL in one
file. The JSP can give the XSL an XML source which it applies the XSL to,
and the results are incorporated inside the resulting output.
To sum up this section, we could show a correspondence between XML
technology and the Model View Controller programming model:
Model: XML document
View: XSL stylesheet
Controller: Java, JSP
For more information, we recommend reading the IBM Redbook, The XML
Files: Using XML and XSL with IBM WebSphere 3. 0, SG24-5479-00.
3.4.1.2 XML in the administration of WAS
WASs, servlets, and JSPs require a large amount of configuration data in
order to work properly. WebSphere takes advantage of XML to enforce the
portability and the exchange of such data.
XML in EJBs
XML can be used to create deployment descriptor for Enterprise Java Beans
(EJBs). An XML file can be treated manually or by using a graphical user
interface (GUI) of the jetace tool. Once created, the XML file can be used to
generate an EJB JAR file from the command line by using the jetace tool.
The use of XML allows you to easily to deploy a collection of EJBs on servers
other than WAS, without having to manually enter the information by using
the WAS administration console.
Note
In the EJB server environment, use of the XML features described here is
not recommended.
Configuring servlets using XML files

When WAS receives a request for a servlet instance, it can obtain the servlet
configuration from an XML servlet configuration file. That file contains all
92
required information such as the servlet initialization parameters, and the

page list of URIs (universal resource identifiers) of the JavaServer Pages
(JSPs) that the servlet can call.
The added-value of using XML is to eliminate the need to hard-code URIs for
called JSPs. Moreover, if a referenced page has changed, you just update the
XML configuration file instead of updating servlet code and recompiling the
servlet.
Configuring WAS through XML

WAS includes an XML configuration management tool to import and export
configuration data to and from the WAS administration repository. That makes
effortless the cloning of WAS machines.
The XML documents must be coded to the WAS Configuration Markup
Language (WASCML) syntax.
The XML-based approach complements the administration tasks you can
perform through the WAS administration console.
Configuring standalone servlet redirector

A standalone servlet redirector can be configured from data contained in an
XML file. You need to customize the iiopredirector.xml file, which provides
what would otherwise be command line arguments for starting the standalone
redirector and generating the Web server plug-in.
3.4.1.3 WebSphere DAV for Java
The WebSphere DAV4J client API provides Java client applications with a
simple, rich interface for accessing resources managed by a WebDAV server.
Using this API, client applications are relieved from managing the details of
the low level HTTP communication protocol, constructing and parsing XML
request and response entity bodies, and the complexities of the WebDAV
semantics. DAV4J also provides:
A servlet that, with WebSphere application server, extends the Apache
Web server with the WebDAV Class 2 protocol.
Protocol independent (not just WebDAV) communication between client
and server applications, including support for http:, rmi:, and local access.
Support for iiop: may be provided in a future release. Local access is used
if the host name in the URL is the local host and no port is specified.
A high-level, object-oriented interface capturing the WebDAV Class 2
semantics that can interface with any WebDAV Class 2 compliant server.
93
A Java servlet that along with WebSphere application server enables DAV
Class 2 methods in the Apache Web server. The Apache Web server can
be configured so that some URLs can be handled either directly by the
Apache server without WebDAV methods while other URLs are handled
by the DAV4J servlet with WebDAV methods. This allows a single Apache
server to be both a production and authoring server on different partitions
of the URL namespace.
The ability to access multiple back end repository managers using a
single, common, standard, simple protocol: WebDAV. The DAV4J
architecture encapsulates low-level repository services required to
implement the WebDAV semantics into a number of simple Java
interfaces. All that is required to provide WebDAV access to a repository
manager is to implement these interfaces on the repository manager.
DAV4J includes a repository manager based on the local file system as a
reference implementation and example of how to integrate a repository
manager. There is also support for the NetObjects Authoring Server
available from NetObjects. Future releases may include support for the
repository managers such as ClearCase from Rational.
Platform independent, 100% pure Java portability.
DAV4J contains the IBM DAV4J client API, the DAV4J servlet, and the file
system repository manager. By changing a few simple properties, the
WebSphere application server can be configured to support the WebDAV
methods in the Apache Web server. WebDAV is described in the IETF draft
specification at http://www.ietf.org.
For further information, refer to http://www.alphaworks.ibm.com/tech/DAV4J.
3.4.1.4 WebSphere Transcoding Publisher
One key intermediary application is the transformation of information from
one form to another, a process called transcoding. Transcoding is already
commonly used in many applications to change data formats, for example to
convert a document from one word processor to another. The need for
transcoding is growing tremendously, as information on the Web becomes
more important and new ways are provided for people to access it.
For example, many Web pages contain large color images that cannot be
viewed on palmtop computers, and XML data on the Web often needs to be
transformed into other forms of XML or possibly into HTML before it can be
viewed. business-to-business communication often requires information to be
transcoded from the formats and structures specific to one company to
formats and structures understood by business partners, suppliers, and
94
customers. Transcoders are specialized programs for transforming

information into different forms.
IBM WebSphere Transcoding Publisher extends the reach of your data with
an easy-to-use, flexible solution to the complex problem of bridging existing
data and applications to new environments. Transcoding Publisher is
server-side software that adapts, reformats, and filters data so that it is
optimally formatted for the destination environment, whether it be a
business-to-business transaction, or an emerging pervasive computing
device. Transcoding Publisher can be extended to deliver custom transforms
in response to new breeds of devices, emerging XML variants, and
e-business trends. The flexible architecture keeps the business ahead of
trends and ensures that your data and applications continue to reach
customers in the environments of tomorrow.
IBM Transcoding Publisher provides the answer for:
Accessing your existing data and applications
Integrating your disparate data systems for smarter business-to-business
communications
Tailoring host data that is already Web-enabled for the new breed of
pervasive devices
Features of Transcoding Publisher include:
A set of basic content transformations or transcoders suitable for
modifying Web data, such as HTML pages, GIF or JPEG images, and XML
documents.
A robust framework that allows the Transcoding Technology to operate as
a network intermediary (proxy), or WebSphere Application Server Servlet.
Transcoders are also delivered as Java Beans, which can be utilized as an
element of a larger Web application development.
A pluggable framework so that custom transformations work with existing
ones and leverage the same core services.
Core services, such as:
- Access to device and network profiles
- Selection of transcoding preferences based on one or more profiles
that match a particular request
- Resolution of any conflicts between relevant profiles
- Selection of XSL stylesheets based on device and network type
95
- Configurations that allow preferences to be modified and plug-ins to be

enabled and disabled
A default configuration that is ready for use with Windows CE devices,
Palm Pilot devices, and traditional browsers
For further information, visit the site
www-4.ibm.com/software/webservers/transcoding.
3.4.2 VisualAge for Java

VisualAge for Java is an award-winning, integrated development environment
for creating Web-enabled enterprise applications. It delivers the industry's
most advanced support for building, testing and deploying 100% Pure Java
applications, JavaBeans components, servlets and applets. A key element of
IBM's Application Framework for e-business, VisualAge for Java allows
developers to build Java applications for today's most demanding e-business
environments.
VisualAge for Java is equipped with a powerful suite of WebSphere tools.
These tools enable you to use VisualAge for Java interactively with other
WebSphere products, such as WebSphere Studio and the WebSphere
Application Server.
The WebSphere tools in VisualAge for Java include:
WebSphere Test Environment
JSP/Servlet Development Environment
EJB Development Environment
XML goals for VisualAge for Java are:
To enable development of XML-based WebSphere applications.
To support key XML-based software development standards.
To exploit XML internally in tools and IDE.
XML data can be accessed through Enterprise JavaBeans or Java
Connectors, and can be emitted by using servlets, JavaServer Pages, or
XML4J DOM. See 3.4.1.1, WebSphere programming model with XML on
page 89 for more information.
VisualAge for Java includes XML parsers (validating and non-validating) in
the project IBM XML Parser for Java.
96
3.4.3 MQSeries Integrator

MQSeries Integrator V2 exploits and complies with industry standards such
as Structured Query Language (SQL) and eXtensible Markup Language
(XML), enabling different systems to share information and to directly support
emerging e-business standards. Integrator's ability to support XML, and
bridge it to non-XML users as they migrate to XML, can accelerate the
penetration of supply chain e-commerce by reliably carrying transactions
between customers, suppliers, manufacturers, and finance organizations.
MQSeries offers more for the administrator of distributed applications. With
enhanced visual tooling combined with XML system message sets and
assured delivery infrastructure, business systems can be deployed and
managed in a manner that mirrors how an organization evolves and reflects
how its trading relationships evolve.
The MQSeries family can act as an XML gateway to B2C e-commerce. This is
done by converting between XML and legacy messaging formats that already
exist within an enterprise. Application servers such as WebSphere provide
the gateway into the XML Internet world. This does not preclude the possible
application of MQSeries down to the client desktop, should it be required.
MQSeries allows the integration of XML B2C e-commerce into a complete
enterprise infrastructure which may be considerably more complex than
3-tier.
In B2B transactions, the MQSeries family can integrate and coordinate not
only XML based ED, but also existing formats and protocols. This can use
both the Internet and intranets. Existing EDI protocols will not disappear
overnight and be replaced with the brave new world of XML. Rather, there will
be different flavors of XML adopted by different industries. MQSeries allows
the evolution in EDI messaging standards to be managed.
3.4.4 DB2 XML Extender

The IBM DB2 Extender family provides data and metadata management
solutions to handle traditional and nontraditional data. The XML Extender
helps you integrate the power of IBM's DB2 Universal Database (DB2 UDB)
with the flexibility of XML.
With the content of your structured XML documents in a DB2 database, you
can combine structured XML information with your traditional relational data.
Based on the application, you can choose whether to store entire XML
documents in DB2 as a nontraditional user-defined data type, or you can map
the XML content as traditional data in relational tables. For nontraditional
XML data types, the XML Extender adds the power to search rich data types
97
of XML element or attribute values, in addition to the structural text search

that the DB2 UDB Text Extender provides. Figure 17 shows a general
overview of how the different components interact with each other.
Traditional SQL data is either decomposed from incoming XML documents or
used to compose outgoing XML documents. The XML Extender provides
application-specific mapping mechanisms to allow transformation between
XML documents and relational data. The transformation includes
decomposing an XML document into one or more pieces and storing them in
the form of relational data, as well as composing XML documents from the
data in existing relational tables.
You specify how structured XML documents are to be stored or created in a
document access definition (DAD). The DAD itself is an XML formatted
document. It associates XML documents to a DB2 database through two
major access and storage methods: XML columns and XML collections. An
XML column contains intact XML documents. An XML collection is a set of
relational tables containing data that is mapped to an XML document and that
can be composed into an XML document.
A pplication
XM L Ad m in.Tool
X M L R ep ository
D a ta Acce ss
D efin itio n
(D A D )
DB2 XML
E xtend er
DB2
Structural
Search Eng.
table
F ile S ystem
XM L do c
CL O B
D a ta Link
Figure 17. DB2 XML Extender overview
98
XM L
DO C
in d e x
The XML Extender provides several user-defined types (UDTs) for use with
XML columns. A UDT is a data type that is not native to the database
manager and is created by a user. All the XML Extender's UDTs have the
prefix db2xml, which is the schema name of the DB2 XML Extender UDTs.
These data types are used to identify the storage type of XML documents in
the application table. The XML Extender supports legacy flat files; you are not
required to store XML documents inside DB2. You can also store XML
documents as files on the local file system or remote file system, as specified
by a local file name.
The DB2 XML Extender provides powerful user-defined functions (UDFs) to
store and retrieve XML documents in XML columns, as well as to extract XML
element or attribute values. A UDF is a function that is defined to the
database management system and can be referenced thereafter in SQL
queries. All the XML Extender's UDFs have the prefix db2xml, which is the
schema name of the DB2 XML Extender UDFs. The UDFs are applied to XML
UDTs, and they are used primarily for XML columns.
With the XML Extender, your application can:
Store entire XML documents as column data in an application table, either
internally or externally as a local file, while extracting desired XML
element or attribute values into side tables for search.
Compose or decompose contents of XML documents from or into an XML
collection, which consists of one or more relational tables.
Perform fast search on XML elements or attributes of SQL general data
types by converting character strings in XML documents to SQL data
types for indexing.
Update the content of an XML element or the value of an XML attribute.
Extract XML elements or attributes dynamically in SQL query.
Validate XML documents during insertion and update.
Work with the Text Extender to perform structural-text search.
The XML Extender provides an XML DTD repository. When a database is
enabled for XML, a DTD reference table (DTD_REF) is created. Each row of
this table represents a DTD with additional metadata information. Users can
access this table to insert their own DTDs. The DTDs in the DTD_REF table
are used to validate XML documents and to help applications define a DAD.
99
For a Web publishing or Internet information portal solution, the application or

tool builder may want to store Extensible Markup Language (XML)
documents in DB2 and use SQL to do fast and powerful searches against
them.
For e-commerce and other application integration solutions using XML
documents as their interchange format, application builders may want to
decompose the XML document and map the data into relational tables or
retrieve relational data and compose it into XML documents. You can easily
do this using the XML Parser for Java (included with DB2). the XML Extender
provides wizards to help map XML Document Type Definitions (DTDs) to
relational tables. The XML Extender also let you generate XML documents
from DB2 tables.
3.4.5 Lotus with XML

Lotus recognized the value of XML very early, driving the development of XML
standards through its active participation in World Wide Web Consortium
activities, such as the XML Schemas and Extensible Stylesheet Language
working groups. Lotus has also supported the XML community through its
development of LotusXSL, an open source, Java implementation of XSL
Transforms.
3.4.5.1 Domino application server
The Domino application server takes advantage of and exploits the capabilities of
XML and its related technologies. The design center of both Domino and XML is
the separation of data from document structure, delivering maximum flexibility in
data manipulation and presentation.
Domino Java servlet and agent support make it easy to write business logic
that imports or produces XML. Domino forms and views provide a
non-programmatic way to create XML from Domino data, using Domino
Designer. Domino R5 includes a set of Java design elements (views, outlines
and actions) that are populated via XML.
Domino Java servlets or agents can invoke the LotusXSL processor. LotusSXL
processor provides the transformation functionality of Extensible Stylesheet
Language (XSL). XSL stylesheets are used to transform XML from one format to
another; or to transform XML to HTML for rendering in browsers and other
devices.
Lotus also defined Domino XML Language (DXL) to express Domino data in
XML. With DXL, user can export, import, or modify data as depicted in Figure
18.
100
NSF
DXL
X S LT
X M L or
HTML
T he W o rld
XSL
D
Do
om
m in
ino
o
M o dific a tio ns
Figure 18. Lotus Domino XML language opens Domino data
Lotus will continue to enhance the Domino Application Server to help

customer be more productive when working with XML. New features and
corresponding benefits will include the following:
Simplified development. New features will automatically retrieve Domino
view and document information in XML format, using standard HTTP
protocols.
Integration with standard XML Tools: Lotus will provide a standard XML
Document Type Definition (DTD) that describes the XML representation of
a Domino database, enabling automatic Domino import and export of both
design and data, using standard XML tools.
Native storage of XML. Domino will store XML natively, augmenting it
with proven security and replication. The Domino database will optimize
XML storage for fast, efficient access.
Runtime API support for Standard XML Libraries. Domino will include a
set of standard APIs for XML, based on the DOM (Document Object
Model) Level 1 and SAX (Simple API to XML), enhancing our current
object model with an additional, standards-based API to Domino data.
Language bindings to these APIs will be available in all currently
supported languages, including LotusScript, COM, and Java, empowering
a broad set of developers to leverage the Domino platform using their
existing tools and skills.
101
Easy access to the tools developers need. Lotus will include XML
Parsers (the software component that interprets XML tags for processing)
and the LotusXSL processor (a component that maps XML between
differing XML schema, or to HTML or SGML) in the rich set of standard
tools on the Domino Server.
3.4.5.2 Notes client
The 5.02 Notes client also includes DXL; an XML vocabulary for Domino; and
a "readView entries" URL, which exposes NSF files to XML. DXL captures the
exact content of a Domino database, and is accessible through HTTP and
Domino/Notes APIs.
3.4.5.3 Domino designer
Domino Designer provides a medium for writing XML and then serving the
XML data to a parser. Domino Designer is a powerful development
environment that provides the layers of security needed to protect data,
including database access control and field encryption.
You can integrate XML into a Domino application to do any of the following:
Create forms and pages that use XML
Create a view that displays XML data
Embed the view into a page
Apply an XSL stylesheet to XML data
Use agents to access data in other Domino databases
3.4.6 Tivoli Cross-Site

Tivoli Cross-Site is an integrated suite of collaborative management
applications designed to help organizations manage their mission-critical
e-business activities. This is accomplished through the combination of one or
more Tivoli Cross-Site management servers communicating with other Tivoli
Cross-Site management servers and Tivoli Cross-Site managed clients over
secure, Web-based transport protocols as shown in Figure 19.
102
Managed Clients
App
Client
App
Client
App
Client
Client core services
Management
Server
XML specifications
Management Servers
HTTP
App
App
App
Server Server Server
Management
Server
Server core
services
SSL
ISP
Internet
Managed Clients
ISP
App
Client
XML specifications
Management
Console
HTTP
SSL
Management
Server
App
Client
App
Client
Client core services
RDBMS
XML specifications
HTTP
Server
HTTP
SSL
Figure 19. Tivoli Cross-Site architecture
The management server is the Tivoli Cross-Site server-based component that

comprises core services and management application elements. The
management server consolidates and stores information from managed
clients or other management servers. In addition, it initiates operations on
managed resources in the Tivoli Cross-Site environment.
The managed client is the Tivoli Cross-Site client-based component that
comprises core services and management application elements. Managed
clients monitor resources, collect information, and perform tasks locally.
Managed clients transfer information from and send events to management
servers. They also receive and act on commands from management servers.
Each managed client is controlled by a principal management server.
However, it can also be authorized to communicate with other management
servers. Communication between managed clients and management servers
uses HTTP and HTTPS, which is HTTP running over Secure Sockets Layer
(SSL). Managed clients send messages encoded in Extensible Markup
Language (XML) to management servers. Managed clients can communicate
with management servers locally at the same site or remotely over the
Internet.
103
3.5 Summary
This chapter demonstrated the engagement of IBM in XML technology, and
its commitment to the XML standards. It also described tools and products
that IBM develops to help customers to design, develop, and deploy
104
Part 2. Designing B2C and B2B e-business applications using XML

This part of the book describes business-to-customer (B2C) and
business-to-business (B2B) e-business models in detail, concentrating
on the role of XML during the design and implementation of these types
of applications. It is for intended for people who are involved in the
design of these applications, to help them understand the e-business
architecture, technology choices, and design issues related to XML
adaptation.
Chapter 4, Patterns for B2C and B2B applications on page 107
introduces the common architectural concepts in this kind of
e-business applications, including a detailed architecture and
application of XML technologies. We also cover general design issues
related to XML fields like design, performance, and security.
Chapter 5, B2C applications using XML on page 139 explains the
details of business-to-consumer applications. It gives a detailed
description of customer services, enterprise portals, and
personalization based on the XML technology and the IBM product
offerings. We present an outline solution and application example
based on the WebSphere product family to build business-to-consumer
applications.
Chapter 6, B2B applications using XML on page 177 deals with
business-to-business applications, and shows the role that XML can
play in this particular application context. Business-to-business is
positioned as one of the best opportunities of the emerging business
integration IT challenge for the coming years, and what IBM is doing to
help companies in this field is presented. The standard proposal of the
Trading Partners Agreement Markup Language (tpaML) and the
Business-to-business Protocol Framework (BPF), both proposed by
IBM, are described in detail. These technologies are the basic building
blocks of IBM WebSphere B2B Integrator, the B2B XML-based
framework announced by IBM. At the end of the chapter we offer an
outline solution to build Trading Partners Agreements by using the IBM
XML Visual Builder tool.
105
106
Chapter 4. Patterns for B2C and B2B applications

In this chapter, we introduce the two classes of applications this book is
dealing with, namely, business-to-consumer (B2C) and business-to-business
(B2B) applications, as described in 1.1.3.2, Inter-business applications on
page 11. Then we cover established patterns for general business
applications, explained in 2.2.3, Patterns for e-business on page 51.
However, in the scope of this book we are only interested in user-to-business,
user-to-online buying, and business-to-business patterns, because these can
be used to develop inter-business applications, covered in 1.1.3, A simplified
classification schema for e-business applications on page 8. We can
associate these business patterns with both classes of e-business
applications: the user-to-business and user-to-online buying patterns are
applicable for business-to-consumer (B2C) applications, while the
business-to-business pattern obviously is for business-to-business (B2B)
applications.
We also extract the logical patterns (application and runtime topologies) and
physical patterns (product mappings) from the Patterns for e-business Web
site for B2B, and document some draft proposed B2B patterns which will
appear on the Web site in the future. Finally, we consider the place of XML
technology in B2C and B2B applications, covering general design issues
related to the implementation of such applications when XML is used.
4.1 Definitions
This section presents definitions of terms to be used later, in 4.2, e-business
patterns for B2C applications on page 110, and 4.3, e-business patterns for
B2B applications on page 117.
4.1.1 Logical and physical patterns

At this point we recall the logical and physical patterns already discussed in
2.2.3, Patterns for e-business on page 51.
The Patterns for e-business aim to communicate in a highly accessible
fashion the business pattern, systems architecture (application and runtime
topologies), and product mappings required for different classes of
applications. They are particularly focused upon addressing common
business application problems and providing answers to frequent
architecture, design, and implementation questions.
107
Patterns for e-business can be used in a number of ways, according to your

needs:
As a starting point for an end-to-end system architecture
As a detailed example and prescriptive approach, following the product
mappings and guidance provided
As a way to design more complex, multi-channel systems, when several
patterns are used together
The application topologies use logical nodes to illustrate various ways to
configure the interaction between users, applications, and data. The chosen
application topology is later mapped to a runtime topology by mapping the
logical nodes to runtime nodes. An application topology shows the principal
layout of the application, focusing on the shape of the application, the
application logic, and the associated data. It does not show middleware or the
files or databases where Web pages may be stored.
The runtime topologies use nodes to group functional and operational
components. The nodes are interconnected to solve a business problem.
The physical patterns provide runtime product mappings together with
guidelines for the design, development and management of the application.
4.1.2 Runtime topology nodes

This section gives a short description of the functional nodes broadly used
when we explain the runtime topologies in 4.2, e-business patterns for B2C
applications on page 110, and 4.3, e-business patterns for B2B
applications on page 117.
Database server node provides a persistent data storage and retrieval
service in support of the user-to-business transactional interaction. The data
stored is relevant to the specific business interaction, for example, bank
balance, insurance information, current purchase by the user, and so forth.
Directory and security services node supplies information on the location,
capabilities and various attributes (including userid/password pairs and
certificates) of resources and users, known to this Web Application System.
The node may supply information for various security services
(authentication, authorization) and may also perform the actual security
processing, for example, to verify certificates. The authentication in most
current designs validates the access to the Web application server part of the
Web server, but it can also authenticate for access to the database server.
108
Domain name server (DNS) node assists in determining the physical

network address associated with the symbolic address (URL) of the
requested information. The DNS on the node diagram is that of the Internet
service provider, although DNS is implemented on the accessed site also.
Existing application and data nodes include all existing applications
running and maintained on nodes which are installed in the internal network.
These applications provide for business logic that uses data maintained in the
internal network. The number and topology of these existing application and
data nodes is dependent on the particular configuration used by these legacy
systems.
Protocol firewall and domain firewall nodes provide services which can be
used to control access from a less trusted network to a more trusted network.
Traditional implementations of firewall services include:
Screening routers (the protocol firewall in this design)
Application gateways (the domain firewall)
The pair of firewall nodes provide increasing levels of protection at the
expense of increasing computing resource requirements. The protocol
firewall is typically implemented as an IP Router, while the domain firewall as
a dedicated server node.
Public key infrastructure (PKI) is a collection of standards based
technologies and commercial services to support the secure interaction of
two unrelated entities over the Internet such as public user and corporate.
Public key infrastructure (PKI) in the context of runtime topologies, supports
the authentication of one distributed applications to another using the SSL
protocol.
User node is most frequently a personal computing device, such as a PC,
supporting a commercial browser, for example, Netscape Navigator, or
Internet Explorer. The level of the browser is expected to support SSL and
some level of DHTML. Increasingly, designers should also consider that this
node may be a pervasive computing device, such as a PDA.
Virtual private network (VPN) node is an extension of an enterprise's
private Internet across the Internet, or other public network. It creates a
secure private tunnel through the Internet to the other partner.
Web application server node is an application server that includes an HTTP
server (also known as a Web Server) and is typically designed for access by
HTTP clients and to host both presentation and business logic.
109
4.2 e-business patterns for B2C applications

This is, by far, the most common type of e-business application. Activities are
driven by the consumer and, usually, based around the Internet. The
consumer is outside of the organization using the service. This service could
take the form of goods or information. There is also widespread use of the
term Enterprise Portals to refer to the set of Web-based applications that
enable companies to connect customers to their information systems, and
that provide a single gateway to personalized information needed to make
business decisions. There are two patterns for e-business related to B2C
applications: user-to-business and user-to-online buying.
XML plays key roles in building business-to-customer applications: it is a
highly flexible data format with strong data description capabilities, it
enhances delivery and representation, and it can be used as a standard
document exchange format.
As a source format for content, XML allows:
The abstract description of documents using metadata
Enhanced search and filtering capabilities using metadata information
Automatic document validation
Managing smaller, reusable fragments of documents
Multiple presentation formats for different delivery types, like Web, paper
or CD-ROM
As a document exchange format, XML helps in:
Flexible interchange of documents and metadata between applications
Standardized interchange to support wide range of applications
Integration of data from other sources, for example, from databases
Transferring complex, application-specific data in business-to-customer
applications
As a document delivery technology, XML has these advantages:
It integrates to client applications without the need for manual editing or
presentation transformation.
It allows rich presentation formats that can be individually tailored to
customers needs.
Using XML, data can be processed at the client side controlled by the
customer for maximum flexibility.
110
For a more complete coverage of user-to-business topologies, we

recommend the IBM Redbook Patterns for e-business: User to Business
Patterns for Topology 1 and 2 using WebSphere Advanced Edition ,
SG24-586400.
4.2.1 B2C logical patterns for e-business

This section addresses the Web applications built from scratch, called
Web-up applications. It concentrates on two of the Web-up specific
application topologies for the user-to-business pattern:
Topology 1, for use when no legacy or third-party applications are
required.
Topology 2, for use when the access to legacy and/or third-party
applications is required.
Web-up is used to represent both an attitude of mind (Web-centric) and the
consequent implementation of new Web browser centric applications. The
data may be acquired by replication from existing sources or typed in by new
users from the Web.
4.2.1.1 Web-up topology 1
This topology describes the situation where you are planning a new
application or extending a current Web publishing capability, with an
e-commerce capability and no back-end integration (a classic Web-up
strategy). For example, it allows businesses to provide consumers with
read-only access to marketing and sales literature via the Web. Furthermore,
consumers can make business transactions that update a database within
the new application.
This topology is sufficient if you do not have any legacy or third party systems
to integrate with, or at least do not have this need at this point in time. This
topology can be easily extended to topology 2 in the future to include access
to existing applications such as inventory management, or third party
applications such as a credit check.
Application topology
Figure 20 outlines the application topology 1. In this topology, we replaces the
monolithic fat client design with a layered approach. This architecture uses a
thin client with application business logic on the second tier. The second tier
can access a local database maintaining the application data. It aims to
address the scalability problems of client/server and at the same time provide
reuse of the business logic and data by all styles of Web browsers or
pervasive computing devices.
111
T h in c lie n t
(P re s e n ta tio n
lo g ic )
s yn c
a n a p p lica tio n n o d e w h ic h c o n ta in s n e w o r
m o d ifie d c o m p o n e n ts
A p p lic a tio n
(B u s in e s s lo g ic )
re a d /w rite d a ta
Figure 20. Application topology: Web-up topology 1
You should consider that a Web application server may implement both tiers
of the layered design, but developers should exercise caution. Many vendors
promote ease of development by mixing scripting and components, paying
little attention to engineering the application with separate presentation and
business logic layers. This combined approach should be avoided, as
separation promotes the effective use of discrete skill sets and code reuse.
Failing to separate the layers can lead to code that is hard to maintain and
extend. Also, be aware that you may incur significant departmental system
management costs when the business logic and data are held outside the IT
organization.
Runtime topology
For the Web-up application topology 1, more than one runtime topology are
possible. We chose to only explain the simplest one. Other runtime
topologies are well described in the IBM Redbook Patterns for e-business:
User to Business Patterns for Topology 1 and 2 using WebSphere Advanced
Edition, SG24-5864-00.
The chosen runtime topology, shown in Figure 21, aims to provide an initial
implementation with an entry level footprint. Or, Start simply, grow fast.
112
D e m ilita riz e d Z o n e
(D M Z )
D o m a in e
N am e
S erv er
I
N
T
E
R
N
E
T
W eb
A p p lic a tio n
S erve r
I n te rn a l n e t w o rk
Domain Firewall
P u b lic K e y
In fr a s tr u c tu r e
Protocol Firewall
O u t s id e w o rld
D ire c to r y a n d
S e c u r ity
S e rv ic e s
D a ta b a s e
U ser
Figure 21. Runtime topology: Web-up topology 1
This runtime topology is the most basic one you could associate with the
application topology 1 of the Web-up model:
1. The Web application server (where the Web server and the application
Server are running on the same machine) is in the demilitarized zone
(DMZ).
2. The business logic is implemented on the Web application server.
3. User information, needed for authentication and authorization, is stored in
the directory and security services node behind the domain firewall in the
internal network.
4. The data to be accessed from the business logic is behind the domain
firewall in the internal network.
These are some variations applicable to this runtime topology:
1. Add Web application servers to serve a larger number of users. This, in
turn, has some consequences:
a. A load balancer is used to distribute the incoming requests to the Web
application servers.
b. A shared file system may be installed in the internal network. This file
system provides for shared access to information needed by all Web
2. Move the Web application server behind the DMZ to provide more
security. In order to achieve this, this topology:
a. Leaves the Web server in the DMZ.
b. Moves the application server from the DMZ to behind the domain
firewall where it is more secure.
113
c. Uses a Web server redirector to forward the requests from the Web
server to the application server.
3. Add an additional application server behind the DMZ to provide more
security. A Web application server within the DMZ is used for presentation
logic, but all business logic is implemented within the application server
behind the DMZ.
4.2.1.2 Web-up topology 2
Application topology 2 allows for one or more point-to-point connections to
back-end legacy applications or databases. This is a very common
requirement for businesses delivering goods and services over the Web. For
example, an e-commerce application can be integrated with existing
back-end applications such as inventory management.
Often this topology is used to extend existing application topology 1 solutions
to integrate with legacy or third-party systems, for example, inventory
management or credit card checking.
Application topology
Application topology 2 for user-to-business is shown in Figure 22. It allows
the second tiers new application business logic to access existing
applications or data, or third party applications. These applications reside on
a third tier elsewhere in the network.
Thin client
(Presentation)
sync
Application
(Business logic)
an application node which contains new or

modified components
an application node which contains
existing components with no need for
modification or which cannot be
changed
App2
sync/async
App1
read/write data
Figure 22. Application topology: Web-up topology 2
Application topology 2 has the same logical application nodes known from
application topology 1 and at least one additional node, making it a logical
3-tier architecture. Depending on the requirements, this additional logical
layer contains new, modified, or unmodified components, and resides in the
third tier.
114
If the developer needs to provide access to many applications on the third

tier, an advanced application topology may be more appropriate. You should
consider an application topology that exploits a hub-and-spoke architecture
between the second and third tiers.
You should consider how this topology will be deployed to avoid systems
management complexity. Complexity arises when updated corporate data
resides on more than one tier, with the second and third tiers both within the
same organization but physically distributed. For example, synchronization of
backups may be cumbersome.
If there are different IT organizations developing the new application and
maintaining or changing the existing systems, the development might be
difficult to coordinate, especially if the interfaces between the new and the
existing systems are not properly defined and documented.
As stated before, the new application might require changes to existing
production systems. This is always a critical task, especially when the
back-end systems or third-party applications are mission critical. Another
problem might be in having skilled resources that can change the third tier
application. Often these are quite old applications, and finding someone who
understands them well enough to change them may be difficult.
Runtime topology
Application topology 2 also can have more than one possible runtime
topology. We chose to only explain the simplest one shown on Figure 23. The
chosen runtime topology providing an extension of runtime topology 1 to
integrate legacy or third-party systems.
Domaine
Name
Server
I
N
T
E
R
N
E
T
Internal network
Directory and
Security
Services
Web
Application
Server
Domain Firewall
Public Key
Infrastructure
Demilitarized Zone (DMZ)
Protocol Firewall
Outside world
Existing
applications
and data
User
Figure 23. Runtime topology: Web-up topology 2
115
This simple runtime topology suits the application topology 2 of the Web-up
model:
1. The Web application server (where the Web server and the application
server are running on the same machine) is in the demilitarized zone
(DMZ).
2. The business logic is implemented on both the Web application server and
existing applications in the internal network.
3. User information, needed for authentication and authorization, is stored in
the directory and security services node behind the domain firewall in the
internal network.
4. The existing applications and data to be accessed from the business logic
are behind the domain firewall in the internal network.
This topology uses the same nodes as the runtime topology 1 excepted the
existing application and data node.
These are some variations suitable to this runtime topology:
1. You can add Web application servers to serve a larger number of users.
This, in turn, has some consequences:
a. A load balancer is used to distribute the incoming requests to the Web
b. A shared file system may be installed in the internal network. This file
system provides for shared access to information needed by all Web
2. You can move the Web application server behind the DMZ to provide more
security. It order to achieve this, this topology:
a. Leaves the Web server in the DMZ.
b. Moves the application server from the DMZ to behind the domain
firewall where it is more secure.
c. Uses a Web server redirector to forward the requests from the Web
server to the application server.
3. You can add an additional application server behind the DMZ to provide
more security. A Web application server within the DMZ is used for
presentation logic, but all business logic is implemented within the
application server behind the DMZ.
116
4.3 e-business patterns for B2B applications

These types of applications focus on using the Internet and/or extranet to
improve business-to-business partnerships and transform
inter-organizational relationships. Companies can cut the cost of operations
and production, improve business processes, and deliver more value to
market by leveraging e-business enhanced partnerships.
The benefits of XML involve the efficient use of data transfer. In
business-to-business situations, there are several ways to communicate
data, but many still require some sort of reentry process. For example, you
might send a fax to a vendor stating you need to reorder a certain item or that
a certain item needs to be sent directly to the customer. Once the fax is
received, someone in that company and department may retype the
information in their system in order to process the information. The problem is
that the data did not change in any meaningful way when it was reentered.
This process of reentering data is needless in most situations.
In order to transfer the data, both sides of the transfer have to agree on what
the data means and how it is presented (via XML markup). XML is that
standard. Once both companies agreed to the information meaning and XML
markup, a parser can be created to easily move the data without having to
reenter the data. The parser can even be so smart as to apply business rules
to manipulate the data pre- or post-transfer.
The concept of data transfer efficiency is not a new one. It has been
implemented and re-implemented in most large organizations. The problem is
that because there was not a standard, most implementations are proprietary.
XML removes the need to re-engineer the transfer process between the
different companies you deal with.
4.3.1 B2B logical patterns for e-business

This section describes application and runtime topologies for five business
models covering most business-to-business applications:
Document exchange
Direct exchange with adaptor/bridge
Message brokers
Business protocol managed applications
Jointly managed applications
117
4.3.1.1 Document exchange

Two partners can use this topology to maximize the performance of the
interaction, particularly by batching requests, but at the expense of flexibility.
Often the factor driving this topology is a large Electronic Data Interchange
(EDI) user placing a requirement on its partners to use EDI over a particular
Value Added Network (VAN). A VAN is a networking service that leases
communication lines to subscribers and adds extra services or capability
such as security, error detection, guaranteed message delivery, and a
message buffer.
The application topology shown in Figure 24 represents the essential current
practice in business-to-business interaction. Mutually agreed-upon
messages, such as EDI transaction sets, are exchanged via mechanisms that
allow the messages to be retrieved from a persistent buffer. The transmission
format of the data is translated into a format usable by the internal business
processes of the receiving organization.
App 1
Translator
Translator
App 2
1:1
async
available buffer
mutually agreed msgs
application node which contains new
or
modified components.
application node containing existing

components with no need
for modification or which cannot be
changed.
read/write storage unit
Figure 24. Application topology: document exchange
EDI is a well established standard, but it is deployed by only a small number

of companies. The need for flexibility in connecting to many partners, who
may have very different IT infrastructure capabilities, may make this topology
inappropriate for many businesses. It is most applicable to those that need to
participate in an existing EDI-based network.
Figure 25 depicts the VAN-document runtime topology for the document
exchange model which represents the current practice for EDI interactions
between businesses. Message interactions are mediated by a VAN service
provider that delivers messages to mail boxes.
118
Internal network
Internal network
Managed network
EDI
translation
package
Company A
V
A
N
VAN
Mail box
VAN access point
Existing
Applications
and data
VAN access point
VAN
Mail box
EDI
translation
package
Existing
Applications
and data
Company B
Figure 25. Runtime topology: VAN-document
Companies A and B have subscribed to a VAN. Users of a VAN send

messages to and retrieve messages from a mailbox. This service of the VAN
holds messages until the receiver requests them. VAN access point
represents the networking endpoint of a VAN. It is the company's connection
to the VAN. In its simplest form, an EDI translator converts EDI transaction
sets (EDI messages) to and from flat files of a format needed by an
enterprise's applications.
4.3.1.2 Direct exchange with adapter/bridge
This topology provides interaction with specific applications in a low complex
context. It is applicable when a more sophisticated agreement between the
partners is not necessary, or when this interaction is a specialized case of a
larger cooperation.
Figure 26 portrays a particular application topology available for use by
outside organizations. A message-based interaction is extended to include an
adapter or bridge that converts the mutually agreed to messages into API
calls to existing applications. In this way, an existing application can be
integrated across organizational boundaries. The types of interactions are
limited by the functions and restrictions embodied by this application.
119
App 2
App 1
N:1
async
server-specified m sgs
adaptor (msgs to API)
Figure 26. Application topology: Direct exchange with adapter/bridge
The message definitions should be made as general as possible in order to

promote some flexibility in changing the interface of the application without
affecting the agreed-upon message definitions. Still, even with this
abstraction, this topology is not easily generalizable to a more sophisticated
integration of business processes.
The connection of applications over message-oriented middleware is
represented in the Internet Direct Queue runtime topology. The connection
between partners is by a secure Virtual Private Network (VPN) as shown in
Figure 27.
internal netw ork

D ire c to ry a n d
S e c u rity
S e rvic e s
VPN end point
I
N
T
E
R
N
E
T
Protocol Firewall
Protocol Firewall
E x is tin g
a p p lica tio n s
a n d d a ta
Domain Firewall
Q ue ue
m ana ger
VPN end point
D ire c to ry a n d
S e c u rity
S e rvic e s
DMZ
D om ain n am e
s erv er
Domain Firewall
DMZ
in te rn a l n e tw o rk
Q ue ue
m ana ger
E x ist in g
a p p lic a tio n s
a n d d a ta
P ublic key
i nfra stru ctur e
C om pany A
E x tra n e t
C o m p any B
D M Z : D e m ilita riz e d Z o n e
Figure 27. Runtime topology: Internet direct queue
Messages are sent to and received from queues that are managed by a
queue manager. A queue manager provides a persistent message store and
additional services including transaction support, and routing of messages to
the proper queue. The receiver of a message can be an adapter that
120
transforms the message data into parameters on method or procedure calls

to a non-queue-based application.
In Figure 27, we show the VPN access point in the demilitarized zone (DMZ),
although configurations in which the VPN is access from behind the domain
fire wall is also possible.
4.3.1.3 Message broker
Message brokers and application adapters are common building blocks of
enterprise application integration. This topology leverages the investment
made in application integration to extend beyond the enterprise.
The application topology shown in Figure 28, embodies the concept of

exposing applications or sets of applications to an outside organization as a
set of services. Integral to this topology is a message broker that can route
and compose or decompose messages as appropriate for the application or
applications implementing a service, employing adapters as necessary. This
maximizes both isolation of business processes from the outside organization
and the flexibility to change the processes and the applications that
implement them.
Partner
Intermediate tier
Corporate tier
App 1
1:1
async
App 3
N:1
async
server-specified msgs
adaptor
comp/decomp
rules
1:1
async
App 2
Figure 28. Application topology: message broker
When enterprise integration approaches are extended outside of the

company, additional problems must be addressed, including the enforcement
of business-to-business protocols and specific agreements between the
partners.
121
Figure 29 illustrates the Internet brokered runtime topology supporting

message-oriented interactions via message broker. This broker handles
enterprise application integration and communicates over a VPN.
internal network
Directory and
Security
Services
VPN end point
I
N
T
E
R
N
E
T
Protocol Firewall
Protocol Firewall
Existing
applications
and data
Domain Firewall
Message
broker
VPN end point
Directory and
Security
Services
DMZ
Domain name
server
Domain Firewall
DMZ
internal network
Message
broker
Existing
applications
and data
Public key
infrastructure
Company A
Extranet
Company B
DMZ: Demilitarized Zone
Figure 29. Runtime topology: Internet brokered
A message broker is built on a queue manager and routes messages to

applications. A message broker can provide real-time, intelligent, rules-based
message routing and dynamic message content transformation and
formatting. In this runtime topology, the message broker allows multiple
applications to implement a published service with the broker providing
application integration.
A variation of this runtime topology could be to move both VPN end point and
message broker behind the domain firewall node.
4.3.1.4 Business protocol managed applications
This topology maximizes flexibility while providing assurance that contractual
agreements are being met. Like message broker topology, it leverages the
investment made in application integration to extend beyond the enterprise.
The use of an executable contract, while implying additional infrastructure,
addresses the business-to-business problems not addressed by the current
practice in enterprise application integration.
The business protocol managed application topology, illustrated in Figure 30,

combines the services and broker approach of the message broker topology
with management of the business protocol between the two trading partners.
It includes an executable contract, agreed to by the trading partners, that
122
mediates the business-to-business interactions. Implementations of service

interfaces use brokering to interact with internal business processes as in
message broker topology.
Intermediate tier
Partner
1:N
sync
App 3
Executable
contract
N:1
async
mutually agreed
msgs
Service
N:M
sync
async
Service
comp/decomp
rules
1:N
sync/
async
Corporate tier
App 2
App 1
Figure 30. Application topology: business protocol managed
The contract should be based on model contracts that correspond to

standardized business-to-business protocols, such as Open Buying on the
Internet (OBI) and Rossetta.Net, a protocol for IT supply chain management.
If a partner chooses not to deploy the infrastructure needed to support
executable contracts, that organization must hand-code all the protocol
interactions and assure that they meet the contract.
Figure 31 shows the internet managed runtime topology which is based on
emerging standards for Internet-based business-to-business interaction
named TPA described in section Trading Partner Agreements on page 185.
A business protocol framework (BPF) manager (see 6.2.2, The IBM
Business-to-business Protocol Framework on page 204) provides an
execution environment for externally exposed services and a means for
integration of the services with back-end business processes.
123
Domain name
server
internal network
Directory and
Security
Services
Web
application
server
Domain Firewall
I
N
T
E
R
N
E
T
Protocol Firewall
Existing
applications
and data
Domain Firewall
Directory and
Security
Services
Protocol Firewall
Demilitarized Zone
(DMZ)
internal network
BPF
manager
Existing
applications
and data
Public key
infrastructure
Company A
Extranet
Company B
Figure 31. Runtime topology: Internet managed
The Web application server, or transactional Web server, is a functional

extension of the well known informational Web server. In this topology, it runs
inside a demilitarized zone where it acts as a security and routing gateway to
the enterprise network, instead of its more traditional role as a manager of
hypermedia documents and related applications.
A BPF manager generally runs under a Web application server, but runs
inside the domain firewall. It manages the interactions between the trading
partners based on an executable contract. An example of such a contract is
the Trading Partner Agreement described in section 6.2.1, Trading Partner
Agreements on page 185.
The actions defined in the TPA are the service interfaces that a partner is
required to implement. Service implementations are started by an executable
version of the TPA and run in the Web application server. Service
implementations may use message brokering services to interact with
enterprise business processes. Such brokering can be provided by the BPF
manager or by a separate message brokering server.
The internet managed runtime topology can be adapted to accommodate
other types of partners. For example, in the VAN-Document runtime topology,
the BPF manager could replace an EDI translation package translator if a
partner is running an EDI system that employs a VAN to interact with outside
organizations.
In this way, the executable contract and services model of the business
protocol managed application topology can be leveraged to interact with
124
EDI-based partners. Another example, the runtime topology, is adapted to

accommodate a message-queuing client that expects to communicate with its
partners via a VPN. Once again, the executable contract and services model
of the application topology is leveraged to interact with a different type of
partner, in this case, one using message-oriented middleware with VPN
communications.
4.3.1.5 Jointly managed applications
Like business protocol managed topology, this topology maximizes flexibility
while providing assurance that contractual agreements are being met. This
jointly managed topology allows both parties to assure the contract and its
specified business protocol are being properly followed. Also like business
protocol managed topology, it leverages the investment made in application
integration to extend beyond the enterprise. While it requires infrastructure on
both sides of the interaction to support executable contracts, it provides a
comprehensive solution with a lesser investment in application development.
Figure 32 depicts the application topology in which the business protocol

managed topology is extended to include business-to-business protocol
mediation by both partners. The executable contract executes on both sides,
guiding both partners adherence to the protocol agreed to by the trading
partners.
125
Intermediate tier
Partner
N:1
sync
Service
Executable
contract
Service
sync/async
Corporate tier
Executable
contract
N:M
async
mutually agreed
msgs
comp/decomp
rules
sync/async
1:N
sync
Service
Service
sync/async
comp/decomp
rules
sync/async
App 4
App 3
App 2
App 1
Figure 32. Application topology: jointly managed
The contract should be based on model contracts that correspond to

standardized business-to-business protocols, such as Open Buying on the
Internet (OBI) and Rossetta.Net, a protocol for IT supply chain management.
The Internet jointly managed runtime topology shown in Figure 33, is based
on emerging standards for Internet-based business-to-business interaction
named TPA. Both partners employ a BPF manager to provide an execution
environment for externally exposed services and a means for integration of
the services with back-end business processes.
126
Existing
applications
and data
BPF
manager
Web
application
server
Protocol Firewall
Directory and
Security
Services
Domain Firewall
internal network
Domain name
server
Company A
T
NE
ER
T
IN
Public key
infrastructure
internal network
Web
application
server
Domain Firewall
Extranet
Protocol Firewall
Directory and
Security
Services
BPF
manager
Existing
applications
and data
Company B
Figure 33. Runtime topology: Internet jointly managed
4.3.2 Physical patterns for B2C and B2B runtime topologies

Physical patterns providing product mappings to populate the solution
defined by the logical patterns. Table 15 contains the IBM product mapping
for the various nodes used in the runtime topologies described in sections
4.2, e-business patterns for B2C applications on page 110 and 4.3,
e-business patterns for B2B applications on page 117. The product names
written in boldface include XML technology.
127
Table 15. Product mappings for AIX and Windows NT
128
Nodes
Products
Application server
WebSphere Application Server

Advanced Edition including:
- XML Enabler
- LotusXSL
- XSL
- WebSphere Transcoding Publisher
JDK
DB2 UDB/XML Extender
BPF manager
WebSphere B2B integrator
Database
Domain name server
non applicable
EDI translation package
DataInterchange
Load balancer
Network Dispatcher
Directory and security services
SecureWay Directory
Message broker
MQSeries Integrator
Protocol firewall and domain firewall
secureWay Firewall
eNetworkFirewall 3.2
User
directDOM
lotusXSL
VAN mailbox
non applicable
Value added network
IBM Global Network EDI Service
VPN end point
non applicable
Web application server
IBM HTTP Server

Advanced Edition including :
- XML Enabler
- LotusXSL
- XSL
JDK(JAXP)
DB2 UDB/ XML Extender
DB2 Client Application Enabler
Nodes
Products
Web server redirector
IBM HTTP Server

Advanced Edition
JDK(JAXP, XML parsers)
As you can see, XML technology plays a large part in the implementation of
both B2C and B2B solutions.
4.4 Implementation considerations for XML

Even though the XML specification was derived with both simplicity and
extensive capability in mind, it can still be confusing. Additionally, with or
without XML, the exchange of information often involves excess baggage.
Trying to address the granular technology issues of information exchange,
APIs, and messages can quickly erode your enterprise vision, and can bury
you in detail.
However, the design and prototyping of XML message schemes can go a
long way in building effective enterprise application integration solutions. If
your roots are also in design and modeling, you are familiar with powerful
tools such as Rational Rose, PowerDesigner, and ERwin and are probably
comfortable with their functionality and the benefits they provide. You can
draw a picture, abstract, or prototype, and you can refine and generate
solutions.
The current XML specification is easy to wade through, and there are
numerous publications, books, and white papers on the topic. However, the
practical application of XML is like any other technology: You need to develop
a strong understanding before you can make it work.
To meet your needs, you have probably needed to design, develop,
prototype, and test many different and somewhat creative XML-based
structures and documents. For the most part, XML is coded as simple,
human-readable text. Using a text editor to develop XML DTDs and
documents, then parsing and validating the resulting script, is a tedious task
that can result in numerous iterations. But something as easy to use and as
powerful as an object or data modeling tool can help you find the perfect
XML design software.
129
However, no singular XML design solution can be found. Of course, there are
some great products in the XML server and the Java/XML arenas, and many
include companion XML design and authoring tools. But many developers
need to know the intricate details of XML to get their solutions to work.
Still, you can find a few useful tools (see 3.2, IBM XML development tools
and utilities on page 63). Many of these are new and do not really leverage
the concept of integrated development environment.
This section intends to give you some considerations about the usage of XML
and also some ideas to take advantages from this technology.
We also recommend reading the IBM Redbook The XML Files: Using XML
and XSL with IBM WebSphere 3.0, SG24-5479-00. This book shows several
different ways of how and where XML can be used in a B2B and B2C
environment.
4.4.1 Applications that benefit from using XML

Any applications could probably use XML, at least in a Web environment, but
there are certain applications that really benefit from it:
Any Web application where you need to format database information into
a table, form, combo box, or similar structure, especially with integrated
filtering and sorting.
Any Web site where you may have a fixed format but different content
depending upon password permissions, localizations, or browser capacity.
Any Web application where you need to transmit large quantities of
structured information between the browser and the server.
Any time that you need to create navigation into a hierarchical structure
that is not necessarily system dependent (for example, a table of contents
of information for files that may be located in different folders than
expected (or even different machines).
Places where you wish to persist data in a stateless environment.
Places where you need to develop a low level messaging system between
client and server, and do not want to introduce highly complex
components to do it.
Therefore, you should use XML in places where the data load is not huge, but
moves beyond a few bytes, as a transport protocol. You should use it in
places where you need to be able to easily change views of your data,
without complex queries. XML is not a terribly good database, but it is a
superb data transport language, and a better data transformation language.
130
One of the reasons that XML has taken off so extensively in the database
world is that it gives you a system-agnostic way of exchanging data. If you
can get your data into an XML form, then you can send it across the Internet
to your customers and they can use XML to retrieve that information into their
own database system, regardless of which system is being used. The key to
this capability comes from the transformation language XSL (Extensible
Stylesheet Language), which can convert XML from one form (or schema) to
another. That way, you can build a way for your customers to query your
database without compromising the integrity or security of your data.
4.4.2 Typical design for applications using XML

If you make the decision to use XML technologies for your Web application,
youve got a starting point to implement it. You know you need to create:
1. XML DTDs to model the types and structures of your data, such as
purchase order or subscription form
2. XML documents which are instances of the defined types
3. XSL stylesheets to specify the way to render the data in a client devices
4. Java servlets to handle and serve client requests
At runtime, the servlets use XML parsers (SAX or DOM) to validate (or not)
XML documents and extract information from them. Then they make some
queries to a database to get data required to serve client request. The XSL
processor generates HTML streams based on the information collected by
the servlet (XML documents, query results) which are sent back to the Web
application by the servlet. This is only a starting point; certainly the solution
will be more complicated, but it is better to have something than nothing.
Figure 34 summarizes the general design and sequence of the tasks to be
implemented for a Web application that uses XML and is not
browser-dependent.
131
XSL/XSLT
processor
database
legacy
7
6
XML DOM
Java Servlet
2
1
HTML
Client
HTM L
XML DOM
XML
DOM
XML Parser
XSL
stylesheets
XML
Docum ents
HTML
XML DTDs
Web
application
server
9
Figure 34. Typical design for a Web application with XML
4.4.3 A sample of an architecture for XML applications

Object-orientation is one of the best known way to describe the structure and
behavior of complex software systems. You probably know that the structure
of a particular XML application is governed by a Document Type Definition,
an external file that specifies the tags and their relationship to each other. For
instance, a DTD specifying HTML would say that a list item tag can only occur
within a pair of tags specifying the list as ordered or unordered.
Crafting a DTD is similar to mapping an object-oriented design into a
relational database schema. While it's not hard to write a schema for a simple
object, it's hard to write a good one for a large or extensible object model.
And while there is no tools that help you create a DTD, there are proposals
for extensions or replacements of the DTD specification, such as the SOX
proposal (www.w3.org./TR/NOTE-SOX). SOX allows you to express an XML data
set using established object-oriented terminology and, further, allows you to
place a more detailed set of constraints on the specified XML elements.
Even after you've crafted the schema for your own object model, you're still
not ready to unleash XML. Most XML applications are built to leverage one of
132
the panoply of XML-based standards for well, just about everything having
to do with data manipulation, transformation, and presentation.
Extensible Stylesheet Language, or XSL, is most interesting. XSL addresses
the fundamental problems of the servlet programmer-how to design a site
that is simultaneously dynamic, maintainable, attractive, and inclusive to all
browsers. Simultaneously, because XSL addresses the issue of presentation
of data in a browser, just as HTML does, it makes a good introduction to XML
applications.
XSL is great for rendering; unfortunately, according to browserwatch.com,
less than 20% of users are using IE 5, the only XSL-enabled browser on the
market. Coming to your rescue are the Open Source programmers of the
Java Apache Project, in particular the server-side XSL transformation engine
called Cocoon (see 3.2.1.1, Cocoon XML-based Web publishing on page
66).
Figure 35 shows how simple is to use Cocoon; for example, placing the
Cocoon, parser, and processor .jar files in the classpath, making the Cocoon
servlet available in your servlet server (which varies between servlet servers,
of course), and telling your Web server that when a file with an xml
extension is requested, the org.apache.cocoon.Cocoon servlet should be called.
The Cocoon servlet takes care of transforming the XML and XSL into a
well-formed HTML document, which is sent to the client.
133
database
XSL stylesheets
myDoc.xsl
Java servlets
Cocoon
servlet
XML Parser SAX
XSL/XSLT
myDoc.xml
myDoc.xml
Client
myDoc.html
XML Documents
myDoc.xml
myDoc.html
Web
application
server
XML DTDs
myDoc.dtd
text/xml -> servlet/org.apache.cocoon.Cocoon
OO design
approach
Figure 35. Architecture of XML application with Cocoon
The real excitement, though, is when your XML file contains multiple XSL
style tags like this:
<?xml version="1.0">
<?xml-stylesheet href="postlist.xsl" type="text/xsl">
<?xml-stylesheet href="postlist.tables.xsl" type="text/xsl"
media="netscape">
Cocoon matches the user-agent HTTP parameter with a map defined in the
Cocoon initialization file to choose between different XSL stylesheets. This
solves what we are tempted to call the problem of Web design support for
multiple, incompatible browsers. As anyone who designs Web sites knows,
it's not hard to create a page that works in Browser X or Y, it is hard to create
one that works in both X and Y. The promise that the domain content could be
kept in a database, and that presentation logic could be kept in individualized
transformation files tailored to the browser is close to the ideal dynamic Web
site architecture.
XML and XSL do not address the issue of domain behavior. You do not want
to place such behavior in the XSL transform pages, because then you've
134
fallen right back into the trap of combining presentation and domain aspects.
Rather, domain behavior is the role of server-side Java components. How are
method calls triggered? That's the role of SAX, the Simple API for XML, not to
be confused with SOX. Ideally, the XML dataset would be created by some
kind of dynamic database query. The resulting dataset would be transformed
by your server-side Java components, and the resulting dataset would be
transformed for presentation by the XSL processor.
4.4.4 Composing Java object with XML

You are probably familiar with runtime object composition adding object
instances to each other to form graphs of related objects. For example,
writing a GUI without using builder tools. You construct a frame object, a
menu bar object, several menu objects, some menu items, some edit fields,
some buttons, and so forth. Then you add your objects to each other menu
items to menus, menus to menu bar, menu bar to the frame, and buttons and
edit fields to the content pane of the frame.
Every design with classes that allows nested composition must answer the
same question: Where is this composition defined? Very often it is in the
program. You simply hard-code calls to constructors and add/set methods to
build the desired graph. In other cases, the composition comes from some
sort of a configuration file or registry. In that case, build a program that makes
sense of what's inside the file or registry and builds the graph.
This approach to composing Java objects using XML and Java Reflection
APIs builds a program to interpret an XML document as a series of calls to
constructors and get/add methods of the objects being constructed. You feed
this interpreter an XML definition, and it composes your objects for you.
When you need to rearrange your objects, change the XML definition and
rerun the interpreter. No recompiling is required, not even when you add or
modify the classes of which you compose your objects; all you need to do is
reflect your change in the XML definition.
This technique may often come in handy. A server can send XML definitions
of GUI frames to an extra-thin client, which interprets them to build screen
objects. When the server-side definitions change, end users see them without
having to download any new client code.
4.4.5 XML filtering with Java servlets

Web forms are ideal for presenting the question and answer sessions
required in a testing scenario. Thanks to ubiquitous Web browsers, users can
take the test from anywhere, but the automation presented here can also
135
grade the test and provide feedback to readers after they've answered the
questions. In principle this is all very easy to do, especially if you pick the
right technologies XML and servlets. The key strength in XML is that it was
designed to represent arbitrary, hierarchical data, lending structure to an
otherwise potentially undistinguished piece of information. We're going to use
XML to represent questions in an online test.
By using an XML parser to build a Document Object Model and using that
model to construct dynamically generated HTML, we can provide access to a
variety of information without having to create more elaborate representations
on separate Web pages.
4.4.6 XML/XSL as inputs for a Web application generator

XML/XSL can be used as inputs for a Web application generator. You would
take the XML pages and process each one using an XSL stylesheet, saving
the resulting HTML back to your Web server. For this, you need to know the
names of the XML pages, which you define by creating an XML file containing
the list of page names. You also need to know the stylesheets to use, so you
could use an XML processing instruction (PI) to indicate the stylesheet name.
You would process PI to extract the name. Finally, you could use the same
file name as the XML file, but with a .htm extension.
Using XML and XSL to separate the page layout from the data becomes even
more valuable for bigger Web sites.
Here are some tricks and tips:
Make sure that the XML page that is being returned has the mime type of
text/xml. You can do this by configuring your server or by making the page
return a Content-Type HTTP header of text/xml.
Test both the XSL and XML page by viewing them in Internet Explorer 5.0.
This will make sure that they parse correctly.
4.4.7 Performance
XML does nothing to speed up the data transfer. It instead adds an element
of performance loss. Consider that the information could have been sent in a
single file as HTML with all the formatting contained in that file. The two trips
to the server would have been reduced to one, and the client-side processing
would have been eliminated. Processing an XML file results in significant
additional server load, and contributes to delays in file downloading at a time
when research indicates fast downloads are a usability priority.
136
4.4.8 Security
One of the problems with XML is that the markup language does not provide
for both secure and open transfer in the standard. Once the information is in
XML format, anyone can use a parser to dump the information into a
database. But if the same information were to be presented in HTML, it would
be more difficult to move the information to a database. This is because the
HTML formatting does not need to be exact in order for the browser to
represent the information. While dealing with business partners, it could be
more convenient to present information in XML for data transfer. Even though
this doesnt mean security, the same information could be presented in HTML
to others, this would increase the difficulty level for them to use the data.
IBM has unveiled the first security scheme for XML that takes advantage of
its ability to define and protect individual elements on a page. The XML
Security Suite from IBM puts tools into the hands of developers for encrypting
specific fields of a business form, such as the amount of a salary or contract,
while the remainder of the form is transmitted in unencrypted text. In a
Web-based transaction, the buyer's credit-card number is encrypted on an
XML form, while the rest is unchanged.
The IBM suite of XML security tools includes XML Digital Signature, which
can verify that a document was sent by a given party, and a hashing algorithm
that lets an XML document check if the contents were tampered with.
4.5 Summary
This chapter gave you the basic information you will need in preparation for
developing B2C and B2B applications. Here is a suggested course of action:
1. Find an application topology for your application.
2. Choose a runtime topology according the application topology your
application matches.
3. Reuse existing solutions or tools for the runtime topology nodes (product
mapping).
4. Take advantage of the combination JAVA (portable code) and XML
(portable data) to code your application.
At the end of this chapter we explained some interesting points that may help
you to implement your Web application with XML.
137
138
Chapter 5. B2C applications using XML

Business-to-customer (B2C) applications are, by far, the most common types
of e-businesses. These applications serve customers needs as they
exchange information, goods, and services over the Internet. In this chapter
we describe the model, architecture, and components of B2C applications,
and present IBM solutions to implement these systems.
5.1 The B2C application model

Until now, B2C was usually referred to as electronic commerce
(e-commerce), or electronic retail (e-retail), or business-to-consumer
applications. However, these categories do not cover all types of e-business
systems. In Chapter 1, XML and e-business applications on page 3, we
gave a general definition of B2C e-business applications. In the sections
below, we revise this definition and give more precise definitions of
B2C-related terms.
We introduce the B2C market, its applications, and a general model. We also
give a detailed description of the most common B2C application: the
enterprise Web portal.
5.1.1 The field of business-customer interaction

The user-to-business area covers all activities between users (internal or
external); and companies, including marketing, providing product information,
sales, product support, customer help desk, training, and others. Some of
these activities are already partly done over the Internet using, for example,
the World Wide Web or e-mail.
The B2C e-business field realizes these activities using Internet technology.
For example, e-commerce is a subfield of this market that deals with selling
and purchasing goods and services over the Internet.
The main activities in the B2C field are:
Providing company, marketing, product, and service information
Online trading (e-commerce), including electronic payment
Customer service, product support, help desk, online training
Companies have already started to offer B2C e-business services to their
customers, for example, Web sites with product and company information,
product support via e-mail, and online purchasing via the World Wide Web.
139
The World Wide Web, as a unified communication and user interface method,
provides key technologies for B2C applications. Companies establish Web
sites (called portals), design client- and server-side Web applications, and
connect these Web systems to their internal information infrastructure to
implement B2C services.
However, immature Web technologies and proprietary company information
management and data exchange solutions are causing several problems in
todays B2C solutions. The main technical problems are the following:
It is difficult to access company data, applications, and people, due to
differences in application interfaces and management software used at
different companies, or even within the same company.
Company applications use different data representations and access
methods, and the information contents of data files are not self-describing
(other, application-specific information is required to interpret them).
The costs of maintaining customer relations over the Internet are high due
to the poor data representational formats, proprietary application
interfaces, and low automation level of these tasks.
The provided services are limited they do not utilize the full possibilities
of todays company information systems, because of the previously
mentioned application interface and data representation problems.
There are already several initiatives to solve these problems. Application
providers started to develop new interfaces and modules for their applications
to enhance the integration with Web and other internet technologies. XML
can also help in the solution. On one hand, it is a new Web document format
that enhances document representation, access and presentation. On the
other hand, it promises application-independent, self-describing data
exchange for greater flexibility and interoperability.
In the following sections we examine the B2C application model, architecture,
typical components, and the role of XML in these areas.
5.1.2 Application models, architectures and components

The general model of business-to-customer applications can be divided into
three main layers:
Client applications provide local functionality for customers. These
applications establish communication links to the company, propagate
user requests to the company, and present the received information to the
customer. They can also provide client-side encryption and authentication.
A typical customer client software is a Web browser.
140
Front end servers handle customers connections and sessions. These

servers recognize customers, manage their resources, handle their
requests, and present information or manage the required transactions.
They also include server-side encryption and authentication. A typical
front end is a Web server with several additional modules enhanced
functionality.
Back end servers support front end servers with business information.
These servers hold company information about products, customers,
services, shipping and payment methods and status, workflow, business
rules and others. They also process customer transactions received
through the front end layer (for example, buying a product over the
Internet). Typical back end servers are workflow management, product
data management, enterprise resource planning, and other enterprise
information systems.
Figure 36 shows these layers and typical components of clients, front end
and back end servers.
Client side
Web
browser
back end
other
client
applications
applications
Front end
Web server
back
other end
applications
front
end
applications
back end
back
end
applications
applications
Back end
company
database
Figure 36. The main areas of business-to-customer systems
141
These layers are connected to each-other using application interfaces and

communications protocols.
The interface between clients and front-end servers is based on Internet
technology, most commonly on the World Wide Web. Standard-based
protocols and Web documents make it possible to use general clients for
different companies, reducing costs both for companies and their clients.
The typical communication methods are HTTP and its secure version,
HTTPs, typical document formats are HTML, PDF, simple text.
Front and back end servers can be connected to each other in several
ways. They can use standard interfaces and protocols, build a distributed
component system, or use proprietary, company-based solutions. Typical
solutions are based on database connectivity (ODBC), component broker
architecture (ORB), or general intranet protocols.
Figure 37 shows the main interfaces between B2C areas and typical
standards used in the implementation of these interfaces.
back end
other
client
applications
applications
Web
browser
Client side
HTTP
back
other end
applications
front
end
applications
Web server
Front end
ODBC/JDBC
ORB
back end
back
end
applications
applications
Back end
company
database
Figure 37. Interfaces between the main areas of B2C systems
142
Other API
ORB
Other API
B2C applications use two methods to start transactions or disseminate

information to users (clients).
The client pulls the information from the server. In this way, the client
requests a document (or starts a transaction) and the server handles this
request.
The server pushes the information to the client. In this case, the server
periodically (or occasionally) broadcasts documents to customers (for
example, a newsletter sent once a month to the companys clients).
The typical method is the client pull, where the transaction is initiated by the
client. The client sends a request to the front end server, which processes the
query, obtains the required information, or performs the required action using
the back end servers, generates the results, and sends them back to the
client.
From our point of view, client-side applications and back end servers are
mainly out of scope. Client applications should be standardized (probably
de facto ) software applications, that have uniform interfaces to the front end
servers. Back end servers, mainly independent from the B2C area, are driven
by the companys internal requirements and needs. However, application
providers may want to introduce new modules to facilitate e-business
connections between the applications. Communication interfaces are also
beyond the reach of B2C applications: they are based on standardized
Internet and Intranet technologies.
In the following chapters we will examine closely the middle layer, the front
end servers, namely the Web portal technology, that connects customers to
company business servers. But first, we start with identifying the areas where
XML can help in designing and implementing B2C applications.
5.1.3 XML powers the B2C interaction

XML plays key roles in building business-to-customer applications: it is a
highly flexible data format with strong data description capabilities, it
enhances delivery and representation, and it can be used as a standard
document exchange format.
As a source format for content, XML allows:
The abstract description of documents using metadata.
Enhanced search and filtering capabilities using metadata information.
Automatic document validation.
Managing smaller, reusable fragments of documents.
143
Multiple presentation formats for different delivery types, like Web, paper
or CD-ROM.
As a document exchange format, XML helps in:
Flexible interchange of documents and metadata between applications
Standardized interchange to support wide range of applications
Integration of data from other sources, for example, from databases
Transferring complex, application-specific data in business-to-customer
applications
As a document delivery technology, XML has these advantages:
It integrates to client application without need for manual editing or
presentation transformation.
It allows rich presentation formats that can be individually tailored to
customers needs.
Using XML, data can be processed at the client side controlled by the
customer for maximum flexibility.
The following sections will introduce enterprise portals, todays products to
connect costumers to companies over the Internet. We will identify the main
components and the roles XML plays (or can play) in these systems.
5.2 Enterprise portals

Enterprise portals (EPs) are Web-based applications that enable companies
to connect internal and external users to their information systems, and
provide a single gateway to personalized information needed to make
business decisions. They play a key role in business-to-customer integration.
Enterprise portals connect people (both customers and employee), data and
applications together (see Figure 38).
144
access and integration
data
back end
applications
applications
people
Figure 38. Enterprise portals connect data, applications and people together
While EP applications share a common infrastructure and features, they can

be divided into several categories, depending on the targeted users and the
primary role of the portal. Based on the targeted users, we can divide portals
into two categories: internal and external portals.
Internal portals are typical business-to-employee (B2E) e-business
applications. They link employees to internal information resources of
different kinds, like product information for sales or support, customer
data, calendar of events, discussion forums, and others.
External portals allow customers to access company data and applications
according to their needs and company regulations, and they help in
managing transactions like electronic buying, product support, help desk,
and others.
Based on the provided functionality, portals can be information providers,
collaborative applications, knowledge (or expertise) portals, and e-commerce
trading systems.
Information portals organize information by subject or theme, publish
news, events, product, service and company information, and so on. They
rely on information and data management systems to achieve these goals.
Knowledge portals are specialized information systems, that store
companys knowledge about products, services, their use, and provide
solutions to typical problems. They also use additional techniques than
information portals, typically knowledge management tools.
145
Collaborative portals enable teams of users to establish virtual

communities to manage their work, projects and contacts. These systems
use special applications for project and contact management, discussion
boards, and other tasks.
e-commerce portals are trading applications that establish Web-based
product and service stores to allow users to browse catalogs, collect
information, and buy goods over the Internet. They use product
management tools, online ordering, electronic payment and other
applications to create virtual storehouses of goods and services.
In a real world situation, it is usually hard to define the exact type of a portal,
since it may provide several services from the above categories at the same
time. From the customers point of view, it is clear that the best portal
integrates everything, and has a unified presentation and access. From the
designers perspective, however, it is worth distinguishing between the
different portal types.
The XML technology plays a key role in these areas as we will present it in
the following chapters. It can enhance almost all fields in portal applications
like data exchange, representation and presentation, application
interoperability, and customization.
5.2.1 Data and application integration

The key element in establishing business portals is the integration of
company data, services and processes into a common portal framework.
The integration should be done in three areas:
Data integration means retrieving company data from databases and
applications. This can be done through application interfaces for data
access, or using advanced data and text mining tools.
Service integration means providing access through the portal to
company services, like product information, sales, support, and others.
Process integration makes possible to initiate transactions (for example,
buying a product or service) over the enterprise portal.
The integration can reach different levels depending on the covered areas of
applications, services and users (see Figure 39):
Internet data and application integration is the lowest, most typical level,
where company data and applications are accessible from the Internet.
146
Internet and Intranet integration means providing access for both internal
and external users, maintaining different access options, content and
services.
Integrating different front end portals means that the company builds a
solid, unified Web portal from its independent portal services (like sales,
support, and so on).
The highest level of portal solutions is, for example, an application service
provider, who integrates different companies portals into a common
frame, and resells their services and products to customers.
Internet
Internet
client
Intranet
client
portal
client
portal
back end
back end
Internet portal
Internet and Intranet portal
client
client
portal
portal
portal
portal
portal
Company A
back end
back end
Integrated portal
portal
portal
Company C
Company B
Service provider for portals
Figure 39. Integrating clients, applications, and portals
Data and application integration is the primary area where XML can help in
building B2C applications. As a document exchange format, it can
standardize the data exchange between front and back end servers, making
147
more legacy data and applications accessible from e-business applications.

Using XML technologies (especially style sheets and XML-based
transcoding), client applications receive documents in more appropriate
format from enterprise portals, and they also can perform more complex
tasks and integrate client applications in more flexible way. As a document
description format, XML allows greater flexibility, richer set of tools for content
generation, automated maintenance and update, and more powerful
personalization services.
In the following section we examine closely the content management
subsystem of an enterprise portal, which is responsible for collecting,
managing, maintaining and enterprise data for portal users.
5.2.2 Content management

Content management takes place between a documents creation and it use
in the portal by organizing unstructured data into a structured information
collection that can be shared, searched, manipulated, analyzed and
maintained. The content of a portal can be created automatically using
company information sources, or after manual data collection and document
authoring. It is undoubted that the automation of these systems greatly helps
companies by reducing costs, shortening publication times, and increasing
portal information completeness. Content management can greatly help in
keeping the enterprise portal up-to-date, enabling personalization according
to users need, and reducing human resource and time costs.
Content management systems perform several tasks in portals. Figure 40
shows the general architecture of a content management system.
Data retrieval from several sources is the first step in content
management. On one hand, this means the automatic retrieval of data
from company back end applications, converting these information into the
portals representational format, storing meta information about the
retrieved data, and inserting the data into the structured portal content. On
the other hand, it could also mean the manual authoring of portal content.
In some cases, the content is only stored in the portals content database
as a reference to the original data (for example, product availability, price
information, and similar data can be obtained directly from back end
applications).
Document storage and management is responsible for maintaining the
portals information repository. This includes handling metadata
information about the documents (for example, author, topics, format,
source, contacts, subscription information, and others). The document
management system is also responsible for managing relations between
148
documents, creating compound documents, controlling document

propagation, tracking versions of documents, and performing the
necessary update when source data has changed.
Security and access services are responsible for maintaining information
about document access rights, and controlling document access by users.
This is done by identifying individual users, maintaining document access
information, and performing the necessary filtering on the presented
documents. In simple cases, this means granting or denying access to
certain documents. In more advanced systems, this can be based on the
structure of the documents, and presented documents can be filtered
according to the users access rights.
Personalization of content management services is a very important
service in enterprise portals. It means the tailoring of the information
content and presentation format according to individual user needs. The
content management system is responsible for assembling the information
in the way the user wants it. This is based on the recognition of the user,
but it is also necessary to maintain a profile for each user (called user
profile), or categories of users.
retrieved
data
back end
back
end
applications
applications
displayed
data
portal
user
Content
manager
company
database
Content
by
reference
Portal
content
User
data
Figure 40. Content management general architecture
Todays Web and data exchange technologies do not really help in building
automated content management systems. HTML, the main Web document
149
format only concentrates on the presentation, and company applications lack

a common, self-descriptive data representation. XML can play a significant
role in content management in several fields.
XML is a unified data format for representing metadata and structured
documents. It can be used in the portal to define the content description
language, that helps in structuring the portal content. Based on this
technology more advanced search and filtering capabilities can be used
using metadata and structure information. It also allows the automatic
validation of documents that can greatly help in maintaining the content.
As a structured document format, XML helps in managing smaller,
reusable fragments of documents, and making composition of these
fragments to create new documents.
The XSL and XSLT standards can be used to search and filter information
in XML documents. However, as query and search tools, they have rather
limited capabilities. XML Query Tools help in building advanced query and
search facilities. As the SQL language in databases system, a similar
language in XML will enhance and standardize the document query
description and processing. Currently, however, there are no standards for
building such tools. See 1.2.11, XML query languages on page 25 for
more details about current initiatives and proposals.
XML is a unified data exchange format, since more and more vendors
implement XML interfaces in their applications (see 3.4, XML extensions
to IBM products on page 89 for details about XML support in IBM
products). Data retrieval from different kinds of applications can be done
in a uniform way using XML. This allows the mapping between many data
descriptions and a single document type convention used by the
information portal. It also helps in transferring complex, self-describing
data structures from back end to front end applications.
XML can also be used in security and personalization services as a
document format for describing resources and users. See the sections
5.2.3, Controlled access to structured information on page 151, and
5.2.4, Customer relations, recognition, and personalization on page 152
for more details.
XML is the future Web document format. As more and more browser
vendors implement XML support in their products, XML becomes the new
standard document format in Web client applications as well. Along with
other technologies (like XSL for formatting and filtering, or XPointer, XPath
and XLink for addressing and linking XML documents) it allows more
complex client tasks to be performed than todays browsers.
Figure 41 shows how XML fits into the content management architecture.
150
retrieved
data
XML
back end
back
end
applications
applications
XML
displayed
data
Content
manager
XML
portal
user
XML
company
database
XML
XML
Content
by
reference
Portal
content
User
data
Figure 41. Content management using XML
5.2.3 Controlled access to structured information

Authorization and security are main issues in networked environments,
especially on the Internet. Most of these topics are beyond the scope of this
book. However, it is worth to discuss new issues the XML technology
introduces in securing XML-based Web portals.
In a structured document it is possible to assign access rights to users based
on the structure of the document. For example, a document describing a
customer may have different access rights to company sales personnel, to
the customer itself, and to other customers; different parts of the profile may
be accessible for different types of users. This kind of policy can be based on
the document type definition. However, the DTD is not always available, since
it is not required for XML documents. XML documents are also inter-linked,
they could contain information from other documents. This is also true for
DTDs. These links may or may not be visible for users (based on access
rights), that also complicates the access right resolution.
Moreover, the population of XML documents changes dynamically, and the
document types cannot be known a priori, during the time of establishing
access policies. Due to this nature of XML document bases, it is not possible
to create fixed access rights. Instead, it requires a dynamic, credential-based
document access management.
151
So far, there is no support or common solution for this kind of access control
in XML-based document management systems. Current applications use
document-based access restrictions, which are also in used in the World
Wide Web environment.
5.2.4 Customer relations, recognition, and personalization

Personalization at enterprise portals allows highly customizable access to the
portal by providing tools and methods to compose personalized collections,
user interface, and preferences. This feature helps customers to tune
company interfaces to their needs, and to obtain information and services in
the way they like. It also helps companies to understand customers needs
and tailor the information content and services of their portals. Using
personalization techniques, a portal site becomes more attractive and more
productive.
These are requirements for portal systems when they establish personalized
services:
They maintain user profiles that contain all required user information to
provide personalized services and maintain customer relations.
Security services are needed to allow customer identification, access
control, and ensure customer privacy.
Dynamic content creation is required to compose documents dynamically,
according to the users preferences. This is based on some kind of
matching/search technology.
Personalization tools are needed to allow the user to set his/her
preferences, and to provide feedback to the company about the portal
services.
Figure 42 shows the general architecture for personalization and maintaining
user data in portals.
152
client side
back end
front end
Request
handling
input processing
user identification
My Personalized Page
Sugge sted items of i nte rest:
New f inancing options announced
My fa vorite
links
Business
logic
Business
applications
content retrieval
personalization
document assembly
Appl icat ions I am autho rized t o use :

Enter orders
Credit status
Co m pany poli cy m anuals I have access t o :

Vacation
Healt h pl an
Services and content
User and
profile
database
Output
generation
transcoding
output generation
Figure 42. Personalization in enterprise portals
The customization and the quality of dynamic content generation is they key
element in personalization. There are several approaches to build
profile-based content generation. The content presented to the user can be
created in different ways from the master content of the portal:
Simple filtering displays the content by filtering the master content
according to the users profile and the actual information shown. For
example, if a user is a customer, and currently visits a customer support
Web site, the portal may want to show links to customer-related support
sites within the company.
Rule-based content generation generates content according to rules and
information from the users profile. Rule-based content generators make
simple decisions based on available information. For example, if a
153
customer bought product X and he is visiting the customer support site,

then show links to support sites for X.
Collaborative filtering also uses information from other portal users to
enhance the content for a user. It takes into consideration similarities
between users and other users actions and preferences to generate a
more appropriate content for a certain situation. For example, customers
may receive recommendations based on product evaluation of users with
similar interest profile.
Statistical methods try to make inferences based on previous history data.
They can use different methods, for example, neural networks or
probability vectors to model the users preferences. For example, a portal
site may keep track the actions of a user (visited places, owned products,
and so on), and it can make a weighted prediction about what product the
person would buy next time.
Advanced user modeling techniques build complex models of users to
simulate and predict their behavior. They may also model the information
and services available in the portal application. This model is called
domain model. Based on domain and user models they can simulate the
users behavior, and optimize the behavior (services, features, content) of
the portal.
User profiles that store information about the user can be created in different
ways:
Explicit profiling asks the users directly about their interests. This can be
done, for example, by completing a short questionnaire or by some other
explicit action. This method has the advantage of letting the customer tell
the site directly what they want to see. However, site visitors are often
cautious when supplying information and may decline to complete long
questionnaires. They may not want to spend several minutes on filling out
forms and answering questions. This step may be broken into several
parts. The first part, for example, during registration of the users, only
identifies the key priorities. Later, for example, when the user intends to
buy a product, the profile management may want to collect more
information about the user by asking questions about product features.
The implicit profiling method collect information about the user without
asking direct questions. The system instead monitors the actions of a site
visitor (pages viewed, items purchased, and so on) and infers from these
actions the interests of the user. This has the advantage of not requiring
the site visitor to complete a questionnaire. Interests inferred from click
stream patterns may not always be as accurate as those gathered from
explicit site visitor input.
154
Many companies have a rich source of profile information in their legacy

systems in the form of credit applications, previous purchases and so
forth. For existing customers and known visitors, use of legacy data often
provides the richest source of profile information.
While user modeling plays an important role in portal applications, in most
cases it remains at a simple level, usually as part of a simple filtering module,
or a rule-based solution. However, more complex solutions can present in
certain business-to-customer situations, for example, in product
recommendations and knowledge-based product support.
XML technologies play several roles in customization and personalization of
enterprise portals. As a structured content description format, it allows the
customization (filtering) of document content according to the clients needs
and access rights. (See 5.2.3, Controlled access to structured information
on page 151 for more details about controlling access to XML documents.)
Parts of documents can be selected for viewing, or can be combined with
other document parts to dynamically create new documents. The structured
format and the additional metadata information can greatly enhance search
capabilities of enterprise portals.
XML-related representation standards, like XSL and XSLT, enrich the
presentational capabilities of current Web applications. On the server side, it
is possible to generate different output document formats for different client
needs. This makes possible different media types at the same time from the
same data source. These media types can be paper, CD-ROM, or online Web
presentation. XML styling can also help in the automatic transcoding of
documents into the clients preferred format. Based on the Web browser
operating environment, display capabilities, and connection speed, the portal
can be displayed with high resolution images, in text-only format, or in a more
compact way for wireless applications.
Finally, XML can also be used as a standard for describing customer data
that can be easily interchanged between applications and companies. This
method can be combined with database technologies for greater flexibility
and access. Two examples for this field are the DSML and CPEX standard
proposals.
The Directory Services Markup Language (DSML, http://www.dsml.org) is an
industry proposal for representing directory services in XML format. Directory
services provide an optimal way of naming, describing, finding and retrieving
information and resources, and managing relations between them. Typically,
these services maintain user information, hardware and software resources,
and company processes. The main aim of the DSML standard is to provide
155
XML-based applications with directory information in their native environment

and data format. It specifies a standard schema for representing this kind of
meta data in XML documents. It also allows easy and standardized data
transfers between companies.
Another example is the Customer Profile Exchange (CPEX,
http://www.oasis-open.org/cover/cpex.html) initiative, which is an industry
organization dedicated to developing an open standard to facilitate the
exchange of privacy-enabled customer information across enterprise
applications. The CPEX standard integrates online and offline customer data
in an XML-based data model for use within various enterprise applications
both on and off the Web.
5.2.5 Business intelligence and enterprise portals

So far we considered enterprise portals as information provides that collect
data from enterprise applications, store this data as documents in the content
database, and present these documents to users according to their profiles
and access rights. However, enterprise portals can also provide interface to
business intelligence to report on-line business information.
Querying business information is already a growing market in the enterprise
portal segment. It is a typical example of business-to-employee applications.
Portals are becoming business desktops for querying (and also for managing)
business information. These systems provide information for company users
as simple reports (for example, monthly sales statistics), for more
professional business users as sophisticated ad hoc queries (like what are
the top five product categories sold to insurance companies), for business
analyst as OLAP viewers, and for power users as data mining services.
Query reporting products used to present aggregated data from company
sources upon request or subscription. Metadata, or information about the
data, provides business users information about data and information objects
they can access. There are two types of metadata: technical and business.
Technical metadata provides the technical description that includes source
format, creation and modification date, availability, and so on. This
information can be used to extract, filter, transform, maintain, and update
source data. Business metadata is used by business analysts and end users
and provides a business description of the data, and helps in locating,
understanding and analyzing it.
Business intelligence systems can utilize the XML technology as a metadata
description and exchange format, and to integrate and structure different data
into content documents. The XMI (XML Metadata Interchange) specification
156
by OMG specifies an open information interchange model that is intended to

give developers an industry standard for combining the benefits of the
Web-based XML standard for defining, validating, and sharing document
formats on the Web with the benefits of the object-oriented Unified Modeling
Language (UML) that provides application developers a common language
for specifying, visualizing, constructing, and documenting distributed objects
and business models.
5.2.6 Connection to e-commerce

e-commerce (seller-to-buyer) is the exchange of goods and services between
vendors and consumers over the Internet. This market is also referred az
electronic retail, or e-retail. These application are usually based on Web
technology, they use Web servers and browsers to connect vendors and
consumers together. This area is part of both B2B and B2C applications,
since companies also buy products and services from each-other.
A traditional e-commerce system generally includes a Web browser at the
clients side with possible applications for electronic payment (for example,
an e-wallet), a front end Web server, and back end business applications at
the merchants side. The back end applications include a database server for
storing product information (specifications, price, availability, and so on), and
an application that manages trading transactions. In some cases, a third party
is involved in the transactions to perform on-line payment transactions.
Usually, the merchants Web server performs several queries to the database
and builds HTML pages dynamically to present the actual offerings to the
customer. Then the customer selects products and places them into a virtual
shopping cart, which is a part of the back end business logic application.
Finally, the customer proceeds to the checkout and orders the products that
are in the cart. After the order, the customer can select a payment method, or
pay for the goods online.
Behind the scenes there are server side applications running and performing
database operations. These applications can be purchased as complete
packages from e-retail application vendors, or they can be created using core
technology elements and software development kits from e-retail software
vendors.
Security has always been a central issue in these systems. Sending data (for
example, credit card information) over the Internet concerns many
customers. On the other hand, the security of merchant servers (for example,
that store customer data) also becoming an important issue in these
157
applications. For the previous problem, the secure HTTP protocol (HTTPs),
and the Secure Socket Layers (SSL) technologies provide solutions.
Customization is also a key issue in e-commerce applications. Providing
customizable services to buyers became a standardized part in most of these
applications, software vendors already include these features in their
applications. Merchants also try to collect more and more information about
their users, and build more sophisticated user models, to enhance their
services.
Tomorrows Web will use the XML to encode information about products and
services with meaningful structure and semantics that can be used to build
more precise search and matching algorithms. Vendors can use the XML
format to describe and publish information about their products and services
in a way that other companies, merchants and customers applications
understand. This eliminates the need for custom product interfaces between
vendors, merchants and customers. It also makes electronic commerce
applications ready to automate, to use by customers software agents that
collect and compare information automatically. However, merchants might
initially dread that XML-encoded information makes too easy for customers to
compare specifications and prices with competitors.
XML, as a meta language makes it possible to create specialized markup
languages (vocabularies) for selling and buying goods and services. The
main areas for XML in e-commerce are metadata descriptions of products
and services, and information exchange between companies. XML RDF
(Resource Description Framework) and XMI (XML Metadata Interchange) are
typical base standards that enable higher level specifications to be
developed. See 1.2.7, Metadata (RDF and PICS) on page 21 for more
details about these base standards.
To maintain the interoperability between various vendor systems, there is a
need for standardized XML vocabularies. There are several initiatives to
solve this problem. IBM is working with the industry to develop standards for
e-commerce. There is a tremendous amount of activity within IBM and across
the industry in using XML for commerce standards. There are numerous uses
for XML, but the following proposed standards relate to commerce and reflect
IBM's participation. Although these initiatives primary concentrate on the
business-to-business part of e-commerce, some parts also refer to the
business-to-customer relation.
Product Information Exchange (PIX) is a set of protocols that support
catalog interoperability on the Internet through defined guidelines for
158
content, communication, format and presentation of product data. PIX is

under development by CommerceNet members ( http://www.commerce.net).
Information and Content Exchange (ICE, http://www.w3.org/TR/NOTE-ice) is
a proposal of content providers like CNET, News Corp., Vignette and
others to create and manage networked relationships, such as syndicate
publishing networks, Web superstores, and online reseller channels.
The Open Trading Protocol (OTP, http://www.otp.org) is a specification of
a banking, payment and technology companies. It specifies offers for sale,
agreements to purchase, payment (by using existing payment protocols,
such as SET Secure Electronic Transaction), the transfer of goods and
services, delivery, receipts for purchases, multiple methods of payment;
and support for problem resolution. OTP is focused on interchange
between consumers, merchants and support services. OTP is being
developed by the "Trade" working group of the Internet Engineering Task
Force (IETF).
Open Buying on the Internet (OBI, http://www.openbuy.org) is an initiative
launched by American Express and major buying and selling
organizations. It automates the large-scale corporate procurement of
office and maintenance supplies.
Open Financial Exchange (OFX, http://www.ofx.net) is proposed by
CheckFree, Intuit and Microsoft. It describes the electronic exchange of
financial statements among consumers, small businesses, and financial
institutions. It supports on-line banking, bill payment, investment, and
financial planning activities.
The Platform for Privacy Preferences Project (P3P) provides a framework
for informed online interactions. The goal of P3P is to enable users to
exercise preferences over Web sites' privacy practices. P3P applications
will allow users to be informed about Web site practices, delegate
decisions to their computer agent when they wish, and tailor relationships
with specific sites. P3P is a project under W3C.
XML/EDI (http://www.xmledi.com) is a specification of a group of
CommerceNet, ANSI X12, and Graphics Communication Association. It
defines how traditional X12 EDI business data elements can be
represented using XML.
RosettaNet ( http://www.rosettanet.org) is a PC industry initiative. It
defines how PC product catalogs and transactions should be described
among manufacturers, distributors and resellers.
Commerce One's Common Business Library (xCBL,
http://www.commerceone.com/xml/cbl/) is a set of common semantics,
common syntax, and message packaging for information held by and
159
exchanged among Internet commerce transaction partners and market

participants. Business documents include product descriptions, purchase
orders, invoices, and shipping schedules.
Commerce Extensible Markup Language (cXML, http://www.cxml.org)
aims to standardize a single open language for communication between
buyers, suppliers, aggregators, and intermediaries.
See also 6.1.3, XML B2B frameworks and standards on page 180.
In addition to being involved in several standardization and industrial
movements, IBM also develops product lines to facilitate e-commerce
solutions. The main product line is the WebSphere Commerce Suite (formerly
Net.Commerce), which is a full e-commerce solution for both B2B and B2C
markets. See 5.3, IBM products and tools in B2C applications on page 165
for a more detailed description.
5.2.7 New presentation devices

As new presentation devices, such as mobile phones and personal digital
assistant (PDA), appear on the market, the wireless Web becomes an
everyday technology. Display and bandwidth characteristics of these devices
require different representation and presentation techniques that in normal
Web applications.
The most known wireless Internet access service environment is the WAE, or
Wireless Application Environment, for mobile phones. The WAP Forum
(http://www.wapforum.org), originally founded by Ericsson, Motorola, Nokia,
and Unwired PlanetWML was formed to create the global wireless protocol
specification that works across differing wireless network technology types,
for adoption by appropriate industry standards bodies. The Wireless
Application Protocol (WAP) is a result of this work. The XML technology is
extensively used in the Wireless Application Environment.
The Wireless Application Environment Specification (WAE,
http://www.wapforum.org) contains several documents that describe the
application environment. The World Wide Web Consortium (W3C,

http://www.w3.org) works together with the WAP Forum to provide protocols
and specifications for wireless Web applications. The Composite
Capability/Preference Profiles (CC/PP, http://www.w3.org/TR/NOTE-CCPP)
based on XML and RDF is a W3C specification proposal (W3C Note) to
describe capabilities and user preferences at the client side. See 1.2.9, XML
in wireless applications on page 23 for more details about these
specifications.
160
The W3C Mobile Access Activity describes a system based on the CC/PP for
Web applications. They propose that CC/PP could be used in Web
applications to provide standardized descriptions of the clients. When a client
device makes a request for a Web document, it sends an URL to its resource
description (along with the URL to the requested document). This URL goes
straight to the CC/PP database. This means that the profile of the device will
become available to the Web server. On this bases the server can create the
appropriate content for the device (and user).
There are several ways to create different content for different profiles. There
could be previously created content files for different devices. There could be
a mechanism for creating these pages on the fly by transcoding other
documents. Figure 43 shows an example transcoding architecture from an
earlier ibm.com site architecture.
Figure 43. Transcoding XML documents on-the-fly
There is also a way to describe the same content and associate to it different
ways of presentation. According to W3C activities, XHTML is being designed
161
as a series of modules associated with different functionality: text, tables,

forms, images, and so on. If a content provider wants information to be
available for different devices, different versions of that content can be
generated with simple version perhaps using on the basic text modules,
graduating to full graphics with scripting, and so on. The document thus
specifies the expected capabilities of the browser in terms of HTML support,
style sheet support and so on, in different document profiles. These profiles
then could be matched with device profiles to select the best document for
the viewer.
5.2.8 IBM portal examples

There are several IBM initiatives to create different kinds of portals for public
use. IBM as a company has its own business-to-customer applications to
provide information and services for customers, developers and the Internet
community.
IBM home page

As part of maintaining its home page (http://www.ibm.com) IBM introduced
XML in the production environment. It uses a variety of XML-related
technologies, including XSL, XML Fragments, XLinks, and XPointers.
The ibm.com Web site is one of the busiest on the Web, receiving an average
of 8 to 10 million hits a day. It is the entry point to IBMs Internet presence.
Currently it manages more than 2 gigabytes of information. Obviously, with
such a large site, content management is a constant problem. In addition to
the normal problems involved with managing an enormous Web site, ibm.com
undergoes a major redesign twice a year.
XML plays several roles in addressing these problems:
It provides a useful, manageable set of metadata about each page on the
site.
It uses XML to combine content and navigation.
It uses XSL stylesheets to minimize the impact of redesigns.
It uses XML to manage content more effectively.
The site introduced a set of XML DTDs to describe the site content. The news
vocabulary is used to describe a news article (Figure 44). For each article,
there is a simple set of tags that describe both the content and information
about the content. The shop DTD is designed to standardize the description
of all products orderable through ibm.com. Encoding product descriptions
using this DTD makes it easy to retrieve information about IBM products, and
it makes comparing similar products easier as well. The search results DTD
162
was written to simplify searches across the ibm.com site. When a user asks for
information, the results of that request are marked up using our search
results DTD. This makes it easy for the user to find further information or
related information, based on their original search. The product navigation
DTD allows to define a class of documents to find specifications, support
information, press releases, and other information more easily.
Figure 44. Sample News DTD from ibm.com
There are several prototype systems to deliver XML content to the client. The
first prototype used the client to process XML markup. The second prototype
IBMs XML Enabler, a Java servlet that processes XML documents and XSL
stylesheets to generate HTML documents dynamically. Finally, the third
prototype (Figure 45), which is used in production at the time writing this
book, converts the XML documents into the various HTML pages before any
client requests were processed. It uses XSL to format the pages into the
output presentation format. When requests come in, it can quickly determine
which preprocessed XML document matches the request, then return that
document to the user. Because XML- and XSL-enabled browsers are
beginning to appear on the market, there is also a caching mechanism to
serve the original XML and XSL documents to browsers capable of rendering
them. This allows the client machine to provide additional function, such as
163
an XML source view, not possible with the generated HTML file. This latest
approach is scalable to the traffic volumes used by ibm.com.
Figure 45. Prototype architecture for ibm.com
Patent Server
The IBM Intellectual Property Network (http://www.patents.ibm.com) is a
premier Web site for searching, viewing, and analyzing patent documents.
The IPN provides free access to a wide variety of data collections and patent
information including...
United States patents

European patents and patent applications
PCT application data from the World Intellectual Property Office
Patent Abstracts of Japan
IBM Technical Disclosure Bulletins
It provides several different search interfaces. If you already know the patent
number, a simple query will return the essential information for that patent.
More complex searching interfaces provide free-form searches that can
include all of the patent office bibliographic data fields, and the claims.
164
It uses IBM's Net.Data program ( http://www.ibm.com/software/data/net.data)

to interface to the DB2 Common Server database to store and retrieve 24
Gigabytes of patent text information. All systems are running on IBM RS/6000
and SP servers using the AIX operating system. The content is delivered to
the Internet via the IBM Global Network.
Developer portal
The developerWorks portal (http://www.developer.ibm.com) is a part of the
IBM Partnerworld for Developers worldwide program supporting developers
who build solutions using IBM technologies.
The portals new data model design is based on XML. The site designers
created DTDs for developer-related content (standards, news stories, case
studies, tool descriptions, and so on). They facilitate XSL translations to
possible share the content with other developer-related Web sites, and to
distinguish the presentation from the information content. The current version
uses a Domino server for storing and serving documents. The new version
(Phase 2) will rely on DB2 and XML Extender technologies for better
performance. Depending on the clients needs, the content will server in
HTML, or using XML/XSL.
My dW, as part of the portal services, provides personalization support for the
site. Phase 2 uses Lotus Domino R5 as the Web application server that
organizes and manages user profiles, developerWorks content, and
personalization rules. The user profile information is stored in a DB2
database, and the rule manipulations and content associations are also done
in DB2. A Java servlet establishes the link between Domino and DB2
databases loads data from Domino databases into the right DB2 structures.
The rules are executed in DB2, and the Java servlet returns the results.
Domino publishes the targeted content on the personalized My dW site.
5.3 IBM products and tools in B2C applications

This section introduces the main IBM product suites to build
business-to-consumer applications. We give a short introduction to each
product and describe how XML fits into them. The last section describes how
IBM tools and products fit into various areas of enterprise portals. For more
information about IBM e-business frameworks and products, see the sections
2.2, IBM Application Framework for e-business on page 37, and 3.4, XML
extensions to IBM products on page 89.
165
The IBM e-business strategy covers all business-to-customer areas. IBM

product suites integrate applications, data, and people together into a
coherent system (Figure 46).
Development
Development
Access
Access and
and integration
integration
Information
Information
EIP
Applications
Applications
People
People
Websphere
Raven
Figure 46. IBM product suites in business-to-customer integration
5.3.1 Enterprise Information Portal

IBM and Lotus have begun the launch of a unified e-business portal strategy
including initial offerings and a partnership initiative. The IBM Enterprise
Information Portal is a solution to build and manage enterprise portal
applications (see Figure 47).
166
Custom Portal Applications
IBM Enterprise Information Portal (EIP)

Information
Connectors
Scanned
Documents,
Compoter
Output
Federated
Search
Intranet &
Internet
Sites
Intelligent
Mining
DB2 IMS
VSAM
Oracle
Sybase
Workflow
Collaborative
Document
Library
ERP
System
Content
...
Business
Intelligence
Connectors
Rich
Media
Repository
Figure 47. IBM Enterprise Information Portal architecture
5.3.1.1 Content Manager

The IBM Enterprise Information Portal has connectors to IBM Content
Manager product thus enabling the handling of several media types:
Scanned documents, photos, and check images.

Computer-generated output, such as Advanced Function Print and PDF.
Rich media, such as audio and streaming video.
Documents with version control from Lotus SmartSuite and MS Office.
IBM Content Manager helps customers to manage all types of digital
information with a single product. IBM Content Manager V6.1 is a solution for
storage, management, and distribution of all types of digital content, including
text, images, audio, and video. This new integrated offering combines the
strengths of EDMSuite ImagePlus VisualInfo and DB2 Digital Library to
provide a comprehensive approach to all aspects of digital information
processing.
167
Content Manager integrates functions and technologies that, combined

together:
Provide a single solution to manage a full range of digital content to
leverage business and other information including, but not limited to:
Images, PC files, Business documents, Video and audio clips, XML and
HTML structured documents, and Computer-generated output.
Enable exploitation of multimedia content in e-business environments and
across traditional client applications Provide highly scalable capture and
indexing of documents, with optimized storage management, for
enterprise-wide capability
5.3.2 Lotus Raven suite

Lotus Raven is a new knowledge management suite. It includes two main
parts: a portal solution, and a knowledge discovery engine. It has several
components like application integration, content tracking and analysis, user
profiles, and expertise locators. These components are integrated into a
portal to manage personal and community information and activity.
"Raven" Knowledge Portal
Custom Portal
"Raven" Discovery Engine

Expertise
Locator
File
System
Web
Sites
Content
Catalog
Domino
Databases
Document
Library
other
Figure 48. Lotus Raven knowledge portal architecture
Figure 48 shows the general architecture of the Lotus Raven suite. The portal
organizes assets by community, interest, task or job focus. The discovery
168
engine locates, retrieves, and categorizes content and organizational

expertise into a browseable and searchable catalog.
Raven's knowledge portal organizes all information for a user. These
information include applications and contacts by community, interest, task or
job focus. Users can personalize the portal by selecting pre-defined elements
(called Knowledge Windows) from a list. Typical elements are mail,
calendars, to do lists, Teamrooms, Web sites, and discussions. These
Knowledge Windows are extensible and can support any Domino or
non-Domino application. The relation between Raven and EIP can be seen in
Figure 49.
"Raven" Knowledge Portal
Custom Portal Applications
IBM Enterprise Information Portal (EIP)

Information
Connectors
Federated
Search
Intelligent
Mining
Workflow
Bus Intelligence
Connections
...
"Raven" Discovery Engine
File
System
Web Site
Domino
Databases
Document
Library
ERP
RDBMS
Rich Media
Repository
Figure 49. Integrating Lotus Raven and IBM Enterprise Information Portal
The Discovery Engine crawls documents and creates a browseable catalog

content and expertise. The catalog is a "table of contents" of all the written
information and internal expertise that exists within an organization.The
engine constantly refreshes the catalog by tracking user characteristics and
usage activity. The result is a system that reflects much about an organization
in terms of where things are, who knows what, what is important, and what
subjects generate the most interest and interactivity.
The Discovery Engine has two main components: the Expertise Locator and
the Content Catalog. The Expertise Locator builds and maintains profiles in a
169
repository that can be queried directly by users to locate experts by skill,

experience, project, education, job type and many other attributes. The
Content Catalog crawls text sources to identify topics, and groups similar
content into browseable categories, called content maps. It also derives
people's skills from content they have authored or read, and maps them to
the categories alongside documents.
By subscribing to specific categories that interest them, users can direct their
knowledge portals to deliver to them relevant information about news,
projects, people, and organizational structure. Raven uses IBM's DB2
Universal Database as the underlying technology to manage the catalog and
the complex analyses processes.
Figure 50 shows a sample screenshot from a Raven portal application.
Figure 50. A sample screenshot of a Lotus Raven portal
170
5.3.3 IBM WebSphere

The WebSphere product family provides a comprehensive basis for
developing custom e-business applications. It provides a full scale of services
for different types of tasks like e-commerce, personalization, transcoding, and
others.
The WebSphere HTTP Application profile isolates business logic, and
presentation. It defines an architecture for integrating applications, and data
into business-to-customer applications (see Figure 51).
Servlets
access to data
EIP
Interaction
control
JSPs
Command beans
access to information
Page
construction
WCM
portal services
clients
Digital
Library
EAB
Commands
CICS
MQSeries
SAP
others
MQ
metadata handling
resource definitions
user definitions
personalization
rules
Figure 51. WebSphere integrates users, data, applications; offers portal services
171
WebSphere Commerce Suite (Net.Commerce)

IBM WebSphere Commerce Suite (formerly Net.Commerce) is a full solution
to e-commerce applications. It is among the most widely used Web
applications in this market. It supports both B2B and B2C applications.
The product contains a rule-based personalization framework. It includes a
flexible rule processor that can perform simple rule evaluations as well as
more complex inference procedures.
WebSphere Commerce Studio is a large array of tools in the Commerce
Suite. These tools provide all functionality for administrative, technical, and
business management, as well as tools for design, development, deployment,
and maintenance.
Transcoding
The IBM Transcoding Technology contains a set of basic content
transformations for modifying Web data, such as HTML pages, GIF or JPEG
images, and XML documents. It uses standards-based technologies for the
data transformation, including Java, XML, XSL, Wireless Application Protocol
(WAP), and Wireless Markup Language (WML). It uses JImage, a
standards-based IBM Research technology, to transcode images, photos,
and graphics.The initial content transformation mechanisms can be extended
by IBM, independent software vendors (ISVs), or customers using plug-ins.
The WebSphere Transcoding Publisher contains a set of transcoder plug-ins
that transform Web content:
Modify HTML documents, such as convert images to links to retrieve
images; convert simple tables to bulleted lists.
Remove features not supported by a device (such as JavaScript, applets,
or Shockwave files); remove references to image types not supported by a
device; and remove comments.
Transcode GIF and JPEG images by reducing scale, color level, or both to
make images smaller, easier to transfer, and quicker to render on
constrained devices.
Convert JPEG images to GIF images for devices that support only GIF
images.
Transform XML documents by selecting and applying the right stylesheet
for the current request based on information in the relevant profiles.
Define profiles for preferred transcoding services for an initial set of
devices, such as the 3COM Palm Pilot III using versions of HandWEB,
172
handheld Windows CE devices using Pocket Internet Explorer, and

WAP-enabled phones using WML viewers.
The transcoding architecture is highly customizable (see Figure 52). It is a
pluggable framework, that contains a set of transcoder plug-ins. New
transcoders can be added and can interact with existing transcoders.
Combining the extensible WBI intermediary backbone with the transcoding
mechanisms produces a Web proxy that can be used to transform images
and text according to user, network, and device preferences.
modifying existing
developing new
Developer
toolkit
device profile
application profile
user profile
network preferences
Profiles
Transformation plug-ins
customer-provided
transformation
readily available transformation plug-ins
Image
Text
XML
Transcoding framework
...
custom
common transformation rules

framework for plug-in interoperability
Administration
framework configuration
registration of stylesheets
Figure 52. WebSphere transcoding customization
The Publisher also has a developers toolkit for building custom transcoding
plug-ins, and administration services to control the configuration and
preference profiles.
WebSphere personalization
WebSphere provides several components to deploy personalized solutions. It
handles user profiles, allow the definition and management of rules for
personalization, and has a content model that stores attributes and hierarchy
of documents. The WebSphere product family also offers development tools
to build personalized Web applications.
WebSphere User Profile is an Enterprise Java Bean that implements the
WebSphere Resource class. It can be mapped to an existing database, to
other data sources, and a new database can also be created during the
definition of the user profile. WebSphere Rules class describe actions in
173
certain situations in Web applications. They fill out information in a page, or

classify the situation. RuleImplementator is a Java class that implements the
algorithm of a rule. This algorithm may test for several conditions, perform
actions according to the conditions, and can interface with other components
or applications.
WebSphere Studio allows the development of applications with
personalization rule support. The Rule Editor helps in developing business
rules for selection (for example, picking cross-sell products), classification
(the user is a VIP), and action (e-mail). These rules can be used in pages,
servlets, beans, and EJBs. The User and Content Definition Tool defines user
and content attributes, hierarchy, and generates management HTML pages
and servlets.
5.3.4 IBM products and tools in portals

In Table 16 we summarized the main IBM products and tools in each field of
enterprise portal applications described in 5.2, Enterprise portals on page
144.
Table 16. IBM products and tools in building enterprise portals
174
Area
IBM Products and tools
Content management
DB2 KnowledgeX,
DB2 Intelligent Miner for Text, Intelligent Miner for Data
Visual Warehouse, DB2 OLAP Server
DB2 Digital Library, Content Server
Clever, Domino (extended search)
Lotus LearningSpace
Security and
access control
ODS, SecureWay, Domino, WebSphere

WebSphere Commerce Suite (Net.Commerce),
XSpan, IRA, e-suite, B2B server, Tivoli
Personalization,
user task management
WebSphere, ODS, Content Connect, Lotus Raven, Xspan,

e-suite
Collaboration
Lotus Notes/Domino, Same Time, QuickPlace
Workflow and
business intelligence
MQ Series, BIS, Domino

B2B Server, Flowmark
WebSphere Commerce Suite (Net.Commerce),
Visual Warehouse
Client side support
ODS, ISMS, SDP (Transcoding)
Complete solutions
EIP, Knowledge Portal, Lotus Raven
E-commerce
WebSphere Commerce Suite (Net.Commerce)
5.4 Summary
This chapter introduced business-to-customer applications, and gave a
detailed description of enterprise portals that are the most common B2C
applications.
We characterized what roles XML can play in building B2C applications. As a
source data description format, it can help in metadata description, structured
data representation, automatic document validation, document management,
and different presentation. As a document exchange format, it standardizes
application data exchange, integrates data from different sources, and
transfers complex application data in an application-independent way. As a
document delivery technology, it enhances client presentation, integrates with
other client applications, and advances data processing at the client side.
Enterprise portals, as a mainstream technology for business-to-customer
e-business, share a common, layered architecture, and have several
important features and components such as data and application integration
with users, content management, user recognition, and personalization. We
showed how XML can help in improving these areas.
At the end of the chapter we presented IBM portal initiatives, B2C product
offerings, and tools for building enterprise portals.
175
176
Chapter 6. B2B applications using XML

The aim of this chapter is to help the reader to understand the role that XML
can play in the business-to-business application context, as well as what IBM
is doing in helping companies in this particular field. Business-to-business will
be positioned as one of the best opportunities of the emerging business
integration IT challenge for the next years.
Inter-company business integration technologies that can support the next
business models, such as Trading Partner Agreements (TPAs) and the
Business-to-business Protocol Framework (BPF), both proposed by IBM.
These technologies are the basic building blocks of IBM WebSphere B2B
Integrator, the B2B XML-based framework announced by IBM.
At the end of the chapter we present an outline solution to build Trading
Partner Agreements by using the IBM XML Visual Builder tool.
6.1 The B2B application model

B2B applications focus on using the Internet and/or extranets to improve
business-to-business partnerships and transform inter-organizational
relationships. B2B trade may be conducted between a company/organization
and its supply chain, as well as between a company/organization and other
company/organization end-customers. Trading can be conducted directly
between buyers and sellers and/or supported by a third party (an
intermediary) within an eMarketPlace.
In the following sections we revise the B2B field, with its opportunities and
issues. We also provide a description of the emerging B2B XML framework,
which are comprehensive set of tools based on XML that are enablers for
ease of specification, configuration, plug-in, customization, and execution
business transactions between business partners over a generic digital
medium.
6.1.1 B2B: a major business opportunity of business integration

New business opportunities and strategies make the integration of business
applications both new and existing more and more critical for a
competitive business. The challenge is to achieve integration in the diverse
computing environments that is universal in business today.
177
The benefits of business integration are most obvious in the context of the
following major business opportunities. However, the benefits of such
solutions reach well beyond these areas:
Business to business integration
Merger and acquisition integration
Supply chain integration
Customer relationship management integration
Enterprise resource planning (ERP) packaged application integration
Straight-through processing
Web integration
Each business scenario offers tremendous opportunities for cost savings and
winning a competitive advantage. And, each requires the integration of
business strategy with IT strategy business integration.
In each scenario, what is needed is the unification of an improved or changed
business model with the supporting information technology.
Business integration can provide significant value to a company; for example:
Uniting diverse businesses so it is possible to deliver products to market
faster
Deriving a single customer view so customers needs can be better served
Cross-selling products and services through a better understanding of
customers buying patterns
Linking the Web to the company business strategy to reach new
customers and provide new services to existing customers
Revitalizing the supply chain to reduce costs and get company products to
market faster
Responding faster to business change
In the business integration prospective, the opportunity of the inter-company
integration (business-to-business) appears to have the much more impact on
the emerging new economy.
In fact, in the new economy, market dynamics will dictate a business model
that provides for the integration of different partners in a value chain. Using a
variety of IT technologies, this model can enable highly coordinated trading
communities, each with the ability to operate like a "virtual enterprise".
178
New business environments demand dynamic and flexible integration

between partners in the value chain. While new technologies will be needed
to enable such integration, these will need to be able to work seamlessly with
existing inter-company business processes (for example, EDI).
As we will see in this chapter, IBM is currently developing new technologies
designed precisely to support this type of business-to-business integration
mainly based on standard technologies such as XML. Business-to-business
is probably the hottest application area of XML.
This chapter describes these technologies, which are a key component of
IBM's Application Framework for e-business, and focus on the strategic role
that XML plays in building such kinds of infrastructures.
6.1.2 General issues in business-to-business electronic interactions

Several issues have to be faced in designing B2B systems. These issues are
concerned with privacy, autonomy, heterogeneity in software and platforms,
and more importantly, managing complexity of interactions.
Some of these issues, for example, the heterogeneity of programming
languages and platforms in which the application components are developed,
are also addressed in the automation of business internal processes and
integrating application components. Total knowledge and control in the
design of the business process within an organization make this a
manageable task.
Component architectures such as CORBA and Enterprise Java Beans
provide middleware for integrating application components written in different
languages. For the purpose of interaction, an application component needs to
know only the interfaces to other components written in a suitable middleware
integration language (for example, the Interface Definition Language or IDL in
CORBA). In such environments, typically, the applications are executed as
short ACID transactions (ACID stands for atomicity, consistency, isolation,
durability). The underlying middleware provides necessary runtime services,
for instance, naming, transaction, resource allocation.
Methodologies that automate internal processes of individual businesses, are
not directly applicable when automating the B2B interactions. First of all, no
common shared underlying middleware can be assumed for distributed
applications spanning organizational boundaries and using a public network
such as Internet. Setting up such a common software bus requires tight
coupling of the business partners' software platforms (for example, consider
the issues on security, naming, component registration).
179
Even if such a software bus can be established, ACID and/or complex

extended transaction models of stateful interactions are not appropriate for
such B2B interactions. First, implementation of such protocols necessitates
tight coupling of operational states across business applications, which is
highly undesirable. The application components in one organization may hold
locks and resources in other organizations for an extended period of time,
resulting in loss of autonomy. Rollback and/or compensation of application
steps is no longer under the control of a single organization. Finally, in
real-world business operations, the operational states always move forward,
and explicit recourse actions are taken by business partners to move to a
more desirable operational state. An example is cancellation of a prior
purchase or reservation.
The invocation of application components across organizational boundaries
needs to be controlled and monitored. First, without rigorous testing and
cooperation in software development across organizations, the correct
execution of such complex distributed applications cannot be assumed.
Second, in such automated interactions, trust becomes an overarching
concern. During runtime, explicit checks are necessary to ensure that
business partners are not violating any policy constraints (for instance,
cancellation of a reservation must be within the allowable time window).
As we will see in Section 6.2, IBM WebSphere B2B Integrator on page 184,
IBM proposed technology addresses all of the above issues by setting up a
B2B interaction via a composable interaction stack based on an electronic
Trading Partner Agreements. The automated process of setting up this
interaction from an unambiguous formal specification and enforcing
contractual agreements is termed an executable Trading Partner Agreement.
These activities are complemented by providing additional services for
supporting long running applications, for example, application development,
asynchronous event driven execution, compensation framework, maintaining
correlation of conversations, logging, and querying the activity on a
conversation.
6.1.3 XML B2B frameworks and standards

A B2B framework is a comprehensive set of tools that are enablers for ease
of specification, configuration, plug-in, customization, and execution business
transactions between business partners over a generic digital medium. It is
the gateway, coordinator, and control point of choice across inter-company
processes (for example, between the buy/sell component of a local business,
the remote businesses, and the back-end systems).
180
Such kinds of facilities, such as Electronic Data Interchange (EDI), have

successfully provided electronic document interchange between companies
and their suppliers for a number of years. EDI has been widely used in
industries like finance and manufacturing since the 1970s. In the USA, ANSI
defined X.12, a messaging standard for various industries. In Europe,
EDIFACT is the standard for EDI.
In its long history, EDI has greatly contributed to automating
business-to-business transactions. However, EDIs high cost and inflexible
structure has always proved a barrier to adoption by all but the largest
enterprises. While EDI will continue to evolve, utilizing pervasive networks
such as the Internet to reduce costs, complementary technologies are
emerging, able to provide some of the key capabilities necessary to enable
dynamic business process integration. In this new context, small companies,
by using the ubiquitous Internet, also want to do B2B transactions with their
partners using inexpensive off-the-shelf software. Even for a large company
who already has an EDI system, B2B on the Internet should be a good
opportunity for inviting new small partners to join and connect to their own
infrastructure.
A generic B2B framework is based on:
A common language that can be employed by existing or potential trading
partners to specify how they will interact (for example, an EDI specific
language)
An electronic contract a Trading Partner Agreement (TPA) that
employs this common language in order to define and enforce the
interaction protocols with which they will do business.
XML B2B frameworks are B2B frameworks which are based on the standard
XML technology. During recent months, these facilities have been receiving
the most public attention, since they offer the most potential for business
integration in the inter-company context. In particular, XML B2B frameworks
use TPA protocols expressed in XML. These are registered to a specialized
software component, usually known as a B2B server, along with the internal
business processes for setting up such B2B interactions.
Currently, many XML B2B framework specification initiatives have been
started and are in various stages of development or still in the planning stage.
These initiatives are usually sponsored by independent organizations (and
this is the path followed by IBM), such as the Organization for the
Advancement of Structured Information Standards (OASIS) Consortium
( http://www.oasis-open.org) through the XML.org, the XML Industry Portal
initiative ( http://www.xml.org), and jointly with the United Nations body for
181
Trade Facilitation and Electronic Business (UN/CEFACT) through the ebXML

project ( http://www.ebxml.org). The eCo framework specification produced by
the CommerceNet's eCo Working group ( eco.commerce.net). In other cases,
XML B2B framework standardization activities are promoted by specific
companies, for example, the Microsoft BizTalk ( http://www.biztalk.org), with
the aim to accelerate the rapid adoption of XML in the B2B market.
Table 17 provides a list of the main XML B2B framework standardization
initiatives:
Table 17. XML B2B framework initiatives
XML B2B Framework
Description
XML.org
XML.ORG is an industry Web portal operated by the Organization for the

Advancement of Structured Information Standards (OASIS). Funded by
a group of companies committed to establishing an open, distributed
system for enabling the use of XML in electronic commerce and other
industrial applications, XML.ORG is designed to provide a credible
source of accurate, timely information about the application of XML in
industrial and commercial settings and to serve as a reference repository
for XML specifications such as vocabularies, DTDs, schemas, and
namespaces.
Web Address:
http://www.xml.org
ebXML project
Web Address:
http://www.ebxml.org
Commerce XML (cXML)

Web Address:
http://www.cxml.org
Distributed Management
Task Force
Web Address:
http://www.dmtf.org
182
The United Nations body for Trade Facilitation and Electronic Business
(UN/CEFACT) and the Organization for the Advancement of Structured
Information Standards (OASIS) have joined forces to initiate a worldwide
project to standardize XML business specifications. UN/CEFACT and
OASIS have established the Electronic Business XML initiative to
develop a technical framework that will enable XML to be utilized in a
consistent manner for the exchange of all electronic business data.
Industry groups currently working on XML specifications have been
invited to participate in the 18-month project.
cXML is an open XML-based standard created to facilitate e-commerce
within trading communities. The Commerce XML initiative started by
Ariba Technologies includes among other 40 leading companies in the
B2B and B2B fields. cXML is a suite of lightweight XML Document Type
Definitions (DTDs) and their associated processes that define the
exchange of catalog content and transaction information between buyers
and suppliers.
The DMTF is the industry organization that is leading the development,
adoption and unification of management standards and initiatives for
desktop, enterprise and Internet environments. DMTF has taken on
enterprise focused industry initiatives and standards such as the Web
Based Enterprise Management (WBEM) initiative, the Directory Enabled
Networks (DEN) initiative and pioneered the use of XML as the transport
encoding for WBEM.
XML B2B Framework
Description
eCo Specification
The eCo Specification is an architectural framework that enables

businesses to discover each other on the World Wide Web and determine
how they can do business. The eCo framework is a product of
CommerceNet's eCo Working Group, an industry-neutral group
consisting of experts from over 35 companies and organizations
throughout the world and is mainly based on XML.
Web Address:
eco.commerce.net
Open Applications Group

Web Address:
http://www.openapplic
ations.org
BizTalk
Web Address:
http://www.biztalk.or
g
RosettaNet
Web Address:
http://www.rosettanet
.org
XML/EDI Group
Web Address:
http://www.xmledi.com
Open Applications Group (OAG) is a non-profit consortium focusing on

easier business software interoperability and is the largest publisher of
XML content for business software interoperability in the world. Among
the other things OAG defined the Integration Specification (OAGIS) which
is a model for business software application component interoperability.
Introduced by Microsoft in March 1999, the BizTalk framework makes it
easy for businesses to exchange information between software
applications and conduct business over the Internet with trading partners
and customers. The BizTalk framework includes a design framework for
implementing an XML schema and a set of XML tags used in messages
sent between applications. Microsoft, other software companies and
industry standards bodies will use the BizTalk framework to produce XML
schemas in a consistent manner to enable integration across industries
and between business systems, regardless of platform, operating system
or underlying technology.
RosettaNet is an independent, self-funded, non-profit consortium
dedicated to the development and deployment of standard electronic
business interfaces to align the processes between supply chain partners
on a global basis. Launched in June 1998, RosettaNet is currently in the
pilot phase of its implementation cycle.
The XML/EDI Group was founded in July 1997 in response to President
Clinton's call for industries' support in dealing with Internet-based
commerce issues, and the emergence in time and space of pivotal
technologies that allowed this to be realized through the fusion of XML
and EDI. XML/EDI Group is an ad hoc group of professionals and
volunteers in various industries dedicated to promoting and guiding the
future of XML/EDI standards and products by donating their time and
energy.
In parallel with the general XML B2B framework initiatives, the development
of a large set of vertical market vocabularies (connected to a specific
industry sector or cross-industry) has been started during recent years. For a
list of organizations known to be producing industry-specific or cross-industry
XML Specifications see, for example, the XML.org XML Catalog:
http://www.xml.org/xmlorg_registry/index.shtml.
183
These vertical protocols cover particular industrial business transactions that

should be used within B2B frameworks. They sometimes have the problem of
defining overlapping or conflicting situations, especially in cases where
different working groups are active in the same business. Some industry
groups are beginning to resolve these differences by promoting protocol
merging initiatives. For example, in the travel industry, the Open Travel
Alliance (OTA) decided to incorporate much of the Hotel Electronic
Distribution Network Association specification in the first version of its
standards.
In the next section, we provide more detailed information on the IBM XML
B2B framework initiative.
6.2 IBM WebSphere B2B Integrator

IBM is an active partner in all almost of the above standardization initiatives
and is contributing to expanding the general XML B2B framework
standardization basis through the development of flexible electronic
documents termed Trading Partner Agreements (TPAs). These TPAs operate
within a specific Business-to-business Protocol Framework (BPF) that
provides a comprehensive tool set for the specification, configuration,
customization, and execution of electronic contracts between business
partners.
At the time this redbook was written (April 2000) IBM was activating many
initiatives in the B2B arena. Several alliances with leading companies in the
B2B area were set up, such as the one with i2 Technologies, Inc.
( http://www.i2.com) and Ariba Inc. (http://www.ariba.com) within which the
three companies will offer advanced open solutions to meet three critical
aspects of accelerating the B2B economy:
Full-service marketplaces
Integrated supply chain
Range of open services
IBM has also announced the introduction of WebSphere B2B Integrator
software which will be built on IBM's WebSphere Application Server and
MQSeries messaging software, tpaML, and will supply the BPF functionality.
In the following sections we will describe the revision of the fundamental
building blocks on which WebSphere B2B Integrator will be based: Trading
Partner Agreements (TPAs) and the IBM Business-to-Business Protocol
Framework (BPF).
184
Most of the remaining sections are based on the recent tpaML language
standard proposal that IBM has submitted to the OASIS Consortium, the
vendor-neutral organization for XML interoperability, within the XML.ORG
initiative at the end of January 2000. The tpaML has been submitted as a
draft to OASIS for potential ratification as a standard. This means that the
specification will be subject to change as the standardization process
progresses. This draft material is highly recommended for more complete
reading and can be downloaded at the following Web address:
http://www.xml.org/xmlorg_resources
6.2.1 Trading Partner Agreements

IBM has recently submitted its Trading Partner Agreement Markup Language
(tpaML) for standardization within the OASIS XML.ORG initiative. The tpaML
specification uses XML to define and implement electronic contracts: Trading
Partner Agreements.
The foundation of tpaML is the TPA, which defines how trading partners will
interact at the transport, document exchange and business protocol layers. A
TPA contains participant roles (buyers, sellers), communication and security
protocols and business processes (valid actions, sequencing rules, and so
on). XML-based TPA documents capture the essential information upon
which trading partners must agree in order for their applications and business
processes to communicate.
A business uses a TPA document to define the agreed model of interaction
with a specific trading partner. The TPA represents a single long-running
conversation, consisting of a set of related interaction steps, distributed over
time but comprising a single Unit of Business (UOB).
For example, in the context of a conversation between a traveller and a travel
agent to arrange an itinerary, a TPA can be used to define and model
allowable interactions between the two actors. That is, a TPA can include
information concerning making reservations, modifying or cancelling them,
issuing tickets and confirmations, making payments.
One TPA can be used for many independent UOBs between the same
trading partners either serially or concurrently. A single TPA can include
definitions for multiple interaction sequences and multiple message formats,
any of which can occur in a UOB instantiated from it. Effectively, a TPA acts
as the control centre for all system-mediated interactions with an external
entity.
185
Over time, the accumulation of TPAs can become an effective repository of

enterprise inter-business process descriptions, providing a major tool for
enabling processes enhancements.
tpaML is a complementary technology to specific business protocol
standardization projects such as ebXML, the Electronic Business XML
initiative, which is a joint effort of the United Nations/CEFACT and OASIS to
establish a global framework for the exchange of electronic business data.
Multiple software vendors and solution providers including CommerceQuest,
DataChannel, Extricity, Geac/JBA, Harbinger, JDA, Infinium, Intelisys,
Mincom, PeopleSoft, Sterling Commerce and Synquest have endorsed tpaML
for potential use with their customers.
6.2.1.1 Principles of B2B electronic Trading Partner Agreements
Contracts describe legally enforceable terms and conditions in all kinds of
interactions between people and organizations. Examples of interactions are
marriage, employment, real estate purchases, and industrial supply
arrangements. In business-to-business applications, there is a need to agree
not only on the traditional terms and conditions but also on IT procedures
from communication protocols to business protocols. Today, such contracts
are generally written in human languages and then turned into code by
programmers.
B2B will be given considerable impetus by expressing the IT terms and

conditions as electronic TPAs from which the code to perform the terms and
conditions can be automatically generated at each party's B2B server. This
will speed up the reduction of the terms and conditions to code and ensure
that the code at each business partner's site will accurately embody the
desired terms and conditions. In the longer term, electronic TPAs will also
facilitate electronic negotiation of terms and conditions, at least for the
simpler situations which need not involve extensive legal negotiation.
Electronic negotiation in turn opens the possibility for spontaneous electronic
commerce, that is quick and easy setup of business to business deals on the
Internet.
The purpose of the electronic TPA is to express the IT terms and conditions to
which the parties to the TPA must agree in a form in which configuration
information and the interaction rules which must be executable can be
automatically generated from the TPA in each party's system.
The information in the TPA is not a complete description of the application but
only a description of the interactions between the parties. The application
must be designed and programmed in the usual manner. A basic principle
which governs the TPA definition is the ability to ensure that each party
186
maintains complete independence from the other party both as to the

details of the implementations and as to the nature of the business processes
and back-end functions (database, transaction monitors, ERP functions, and
so on) used.
As a simple example, the TPA may define requests such as "reserve hotel".
The "reserve hotel" function must be designed, coded, and installed on the
hotel server. That function may, in turn, invoke various site-specific functions
and back-end processes whose details are completely invisible to the other
party to the TPA. Concerning the independence principle, the TPA neither
requires, nor provides the means for, ACID transactions involving both parties
that govern the specific party internal unit of work.
In B2B applications parties act according to the traditional client/server
model: a client requests services of a server. In the B2B simplest
applications, there may be two parties, one of which is a always a server and
the other, always a client. An example is a travel application involving a travel
agency (client) and airline company (server). Even in such a simple case,
however, the parties may exchange roles. For example, the airline company
may issue requests to the travel agency for more information about the
traveler or itinerary. Therefore, a much more complete B2B model envisions
applications in which a given party may play both server and client roles at
different times. In other words, a party may both request services of the other
party and receive service requests from the other party.
To respond to this last requirement, a TPA is represented at each party which
acts as a server by an object, called a TPA object or (or equivalent code for
non-object-oriented implementations), which performs rule checking and
translation of the request messages from the form defined in the TPA to the
actual method calls at the parties which act as servers. A similar TPA object,
generated at each party which can act as a client to other party, performs the
inverse translation, from local method calls to the request messages, as
defined in the TPA, which are sent to the other party. A party which can act as
both a client and as a server has both kinds of TPA object.
Figure 53 positions TPAs role within the Business-to-business XML
frameworks.
187
Trading partner
BP
BP
N o shared middleware
Long running transactions
Trading partner
BP
BP
Back-end integration
Passive network
Applications
Business
Applications Process
Applications
Business
Process
Applications
W orkflow
Back-end integration
Applications
Applications
XML
W orkflow
TPAs
Figure 53. TPAs within B2B XML frameworks
6.2.1.2 The TPA structure

A TPA represents a single long-term running conversation, which is a set of
related interactions, dispersed in time, that comprises a single unit of
business (UOB).
For example, in a travel application, the TPA might define the interactions
between the travel agent and a hotel company starting with making the
different reservations needed by the traveler, to the check-in processes
during the trip, and ending when the traveler checks out at the last stop. This
sequence of steps is a single long-running conversation.
A UOB is performed under the TPA by instantiating the TPA as a long-running
conversation. To perform many UOB, the TPA may be instantiated as many
long-running conversations as is appropriate to the application and the
processing capabilities of the parties' systems.
Figure 54 shows the main information that a TPA contains.
188
overall properties
identification
security properties
error handling
Information flow
TPA
cancelling
rules
roles
communication
propeties
sequencing rules
actions
Figure 54. The TPA structure
A TPA document contains the following information:

Overall properties: This includes TPA name, starting dates, and possibly
ending dates for validity of the agreement and other global parameters.
Role and identification : This identifies the parties to the TPA as logical
roles such as buyer, seller, airline, hotel and so on. Specific organization
names and contact information such as e-mail and postal service
addresses are then provided for each role. The allowable actions under a
TPA are organized by role making it easy to modify an existing TPA to
specify identical interaction rules but with a different partner. An optional
role is that of external arbiter for use in resolving disputes.
Communication and security: These attributes specify communication
and interaction protocols to be used. The specification is layered into
transport, message handling and higher level conversational sections.
Protocol choices and parameters for addressing security including
authentication, certificate handling and non-repudiation are included.
Actions : For each identified role, this is a menu of the actions that can be
performed on request from the partner. A signature is specified for each
action defining the parameters and their data types. Sequencing rules
specify constraints on the order in which actions can be requested.
Example actions in the case of the travel agent process interacting with a
hotel would be requests to make a room reservation and subsequently to
modify it.
189
Error handling : Error handling rules manage error conditions (for

example, be the maximum waiting time for the response to a request).
Commentary : This refers to the text that can be added to the TPA to
cover other negotiated but not processed issues.
Conceptually, a TPA may be considered to be implemented by a B2B server
at each party's site. The B2B server provides the code for the services
needed to support the TPA including the middleware which supports
communication with the other party, execution of the functions specified in the
TPA, interfacing to each party's back-end processes, and logging the
interactions between the parties for purposes such as audit and recovery.
The middleware might support the concept of a long-running conversation as
the embodiment of a single UOB between the parties.
6.2.1.3 The tpaML language
A TPA is an XML document from which code is generated at each computer
systems of the trading partners and it includes, typically, the list of information
proposed in Figure 54 on page 189. tpaML is the specific mark-up language
that can be used to write TPA documents.
Note
Although this book contains extensive details from tpaML, the tpaML
definition is still evolving, and many changes will be made, taking into
account comments coming from the XML.org working group and other
sources. Therefore, the reader is strongly recommended to use the
information reported here along with the tpaML specification that will be
updated next future. The tpaML specification on which we based the
information proposed here is the 1.0.3.
An XML B2B framework that supports TPA typically has to provide a graphic
TPA-authoring tool that understands both the semantics of the TPA definition
and the XML syntax. IBM, for example, is developing the IBM XML Visual
XML Builder, which is an XML visual tool including several specialized editing
features that can be effectively used to build TPAs. In Section 6.2.4, Using
the IBM Visual XML Builder for a specific OBI TPA on page 216, for example,
we will show in practical terms how to build a TPA by using the IBM XML
Visual Builder tool.
As tpaML has specified, this makes it feasible to automatically generate, at
each party's site, the code needed to execute the TPA, enforce its rules, and
invoke the application-specific programs. Many fields in the TPA are the
same in most TPAs; the authoring tools and TPA templates can supply these
190
fields. Where appropriate, the tool can supply default values for many fields;
these only need to be stated when values other than the defaults are desired.
The TPA document is described by an XML Document Type Definition or
XML-Schema file, which defines the tree structure of the TPA tags and some
XML syntactic rules but not rules defining specific values of the tags or the
semantic interrelations among the tags. These semantics are defined by a
textual design document and are embodied in rules, understood by the
authoring tool, which aid in the creation of a valid TPA.
Overall XML document structure

In this section we describe the overall XML structure of the tpaML language.
Subsequent sections will describe each of the functions provided by the TPA.
Each of these tags is the top level of a sub-tree of tags (sub-elements). We
will illustrate the following discussion with snippets of XML.
Following is the overall structure of the TPA, expressed in XML.
<TPA>
<TPAInfo>

... 
</TPAInfo>
<Transport>
... 
</Transport>
<DocExchange>
... 
</DocExchange>
<BusinessProtocol>
... 
</BusinessProtocol>
<Comment>

</Comment>
</TPA>
The <BusinessProtocol>, <DocExchange>, and <Transport> sections describe the

processing of a unit of business (UOB) conversation. These sections form a
layered structure somewhat analogous to a layered communication model.
Business protocol layer defines the heart of the business agreement
between the trading partners: the services (actions) which the parties to
the TPA can request of each other, and sequencing rules that determine
the order of requests. The Business-Protocol layer is the interface
191
between the TPA-defined actions and the business-application functions

that actually perform the actions.
Document exchange layer accepts a business document from the
Business Protocol layer, optionally encrypts it, optionally adds a digital
signature for non-repudiation, and passes it to the transport layer for
transmission to the other party. The options selected for the Document
Exchange layer depend on those selected for the Transport layer. For
example, if message security is desired and the selected transport
protocol does not provide message encryption then it must be specified at
the Document-Exchange layer.
Transport layer is responsible for message delivery using the selected
transport protocol. The selected protocol affects the choices selected for
the Document-Exchange layer. For example, some transport layer
protocols may provide encryption and authentication while others have no
such facility. Optional functions selected for the Document-Exchange layer
must take into account the nature of the transport layer.
The TPA preamble ( <TPAInfo>) contains those definitions that are
independent of instantiation, such as TPA name, role definitions, party
names, and TPA duration. In particular, when a given TPA can be repeatedly
reused for different groups of parties, a prototype TPA or template can be
written in terms of role parameters rather than specific party names. The
authoring tool can then generate a specific TPA by substituting party names
for the role parameters and filling in specifics of those parties such as their
electronic addresses. The role definitions are included under the <TPAInfo>
tag. Each <RoleDefn> tag supplies a pair of role parameter and actual name
The <RoleName> tag defines the name of each role. The <RolePlayer> tag has
a blank value in a TPA template and the name of an actual party in a specific
TPA. Here is the XML for the role definitions for a TPA between an arbitrary
airline ( @airline) and an arbitrary hotel ( @hotel). In this example, the tags
under <Role> particularize the TPA to an agreement specifically between
Hotelco and Airlineco.
<Role>
<RoleDefn> 
<RoleName>@hotel</RoleName>
<RolePlayer>Hotelco</RolePlayer
</RoleDefn>
<RoleDefn>
<RoleName>@airline</RoleName>
<RolePlayer>Airlineco</RolePlayer>
</RoleDefn>
</Role>
192
When the authoring tool replaces the role parameters by actual party names,
it either asks the author for party-specific information or finds this information
in a previously-built database.
The optional comment section ( <Comment> ) may contain any reference text
that must be included in the TPA.
Note
A TPA may exist at several different levels of abstraction:

An abstract description, as it is described in the tpaML specification
document, from which any TPA among any parties for any purpose
could be derived.
A prototype TPA (template) between two or more parties for a specific
purpose. This template can be tailored as needed, resulting in a
particular TPA. In the template, one or more parties can be represented
by role parameters, such as name, to be replaced by specific parties in
a particular TPA as proposed in the previous example.
An actual TPA among a specific set of parties.
Instantiation of the TPA among a specific set of parties for a particular
long-running conversation.
TPA Preamble
The preamble identifies the TPA and its participants and defines some
invocation-independent properties such as the valid duration. The preamble
is defined by the information under the < TPAInfo> tag.
Table 18 lists all types of information that be arranged under the TPA
preamble section.
Table 18. The TPA Preamble section
Sub-Section Name
XML Tag
Description
Identification
<TPAName>
The TPA is given a unique identification

string, such as IT14442869
TPA Type
<TPAType>
This tag provides information about the

general type of TPA where the TPA is
based on a defined standard business-level
protocol such as OBI. It is optional. It
includes the following information: business
protocol, protocol version, and protocol
type, stored into specific sub-tags.
Sub-tags:
<Protocol>
<Version>
<Type>
193
Sub-Section Name
XML Tag
Description
Role Definitions
<Role>
A TPA may be between specific parties or

between some combination of specific
parties and arbitrary parties (roles). This tag
defines the relationships between roles and
actual parties. It is optional and should be
omitted if roles are not used. A TPA
containing one or more roles is referred to
as a prototype TPA or a reusable TPA. The
resulting TPA, with the roles replaced by
specific parties, is called a fully qualified
TPA.
Sub-tags:
<RoleDefn> <RoleName>
<RolePlayer>
Participants
<Participants>
Sub-tags:
<Member>
<PartyName>
<CompanyTelephone>
<Address>
<AddressType>
<AddressLine>
<City>
<State>state_name</State>
<Zip>
<Country>
<Contact>
<LastName>
<FirstName>
<MiddleName>
<Title>
<ContactTelephone>
<Email>
<Fax>
<Arbitrator>
TPA Lifetime
<Duration>
Sub-tags:
<Start>
<End>
<Date>
<Time>
194
This section of the TPA describes all of the

parameters needed for person-to-person
communication between parties to the TPA
(for example, mailing address, email
address and so on). It should be noted that
the email address is only for person to
person communications. Specific forms of
address are defined in the communication
section for each of the access protocols.
This tag specifies the valid duration of the

TPA.
Sub-Section Name
XML Tag
Description
Invocation Limit
<InvocationLimit>
This tag specifies the total number of times

the TPA can be instantiated (conversations
created) before having to renegotiate it. If
the tag is not stated,there is no limit to the
number of invocations. The value of this tag
is a positive numeric string.
Concurrent Conversations
<ConcurrentConversations>
This tag defines the maximum number of

conversations under this TPA that may be
open at any time. If this tag is omitted, there
is no defined limit though a given server
may have an implementation-based limit
and may reject a new conversation if this
limit would be exceeded. The value of this
tag is a positive numeric string.
Conversation Instantiation,
Closure, and Lifetime
<ConversationLife>
<TerminateConversation>
A conversation represents a unit of

business (UOB) defined by the business
application. Therefore, the business
application determines when the
conversation is instantiated and closed.
From the viewpoint of a TPA between
party1 and party2, instantiation takes place
at party1 when party1 sends the first action
request to party2. At party2, the
conversation is instantiated when it
receives the first request of the UOB from
party1. Closure of a conversation takes
place when the parties have completed the
UOB. The application may use the
service-interface tag
<TerminateConversation> to indicate
one or more actions whose completion
terminates the conversation.
Following is the preamble section syntax:

<TPAInfo>
<TPAName>TPA name</TPAName>

<TPAType>
...
</TPAType>
<Role>
...
195
</Role>
<Participants>
...
</Participants>
<Duration>

...
</Duration>
<InvocationLimit>number</InvocationLimit>

<ConcurrentConversations>number</ConcurrentConversations>

<ConversationLife>time</ConversationLife>

</TPAInfo>
Transport layer
The transport section defines communication protocol, encoding, and
transport security information. Specific forms of address are defined for each
of the access protocols. The overall structure of the transport section is:
<Transport>
<Communication>
</Communication>
<TransportEncoding>encode</TransportEncoding>
<TransportSecurity>
</TransportSecurity>
</Transport>
The communication properties section ( <Communication> tag) defines the

details of the system-to-system communication used in the application.
These include the protocol to be used by both parties (for example, HTTP,
SMTP, MQSeries and so on), each party's address parameters, maximum
allowed network delay, and other parameters.
The tpaML specification document details a set of wide transport protocols
including HTTP and HTTPS (for secure Internet interactions) and reliable
messaging such as that provided by IBMs MQSeries. It is possible to specify
the version of the protocol by using a specific tag.
196
Following is a list of all communication protocols currently supported or to be

supported by the tpaML specification (version 1.0.3):
HTTP
MQSeries
VAN-EDI
SMTP (*)
(*) The XML tags for the SMTP are to be determined.

For each protocol, a specific syntax has been defined to compose the
<communication> section. We direct the reader to the tpaML specification
document for details concerning the <communication> section syntax that has
to be used to code information about the various communication protocols.

In the following paragraphs, we propose a portion of a TPA XML document
that uses the HTTP communication protocol between parties and the general
syntax for HTTP.
For HTTP, each party is individuated by an URL address. Depending on the
application, there may be one or more URLs, whose use is determined by the
application. Each <URL> tag provides one URL. The <URL> tag has a required
attribute, URLName, whose value identifies the purpose of the URL.
Following are the values of the URLName attribute:
The " logOnURL" identifies the URL used for the initial connection between
client and server.s
The " requestURL" identifies the URL used for receiving requests.
The " responseURL" identifies the URL used for receiving response
messages.
The default for URLName is "requestURL".
For example:
<HTTPAddress>
<URL URLName="logOnURL">https://www.a.xxx.com</URL>
<URL URLName="requestURL">https://www.b.xxx.com</URL>
<URL URLName="responseURL">https://www.c.xxx.com</URL>
</HTTPAddress>
197
Following is the syntax for HTTP:

<Communication>
<HTTP>
<Version>version</Version>
<HTTPNode> 
<OrgName Partyname=name/>
<HTTPAddress>
<URL URLName=type>url</URL>

</HTTP>
</Communication>
The optional <Version> tag identifies a specific version of the protocol. The
value of this tag is a character string.
The <...Node> tag identifies each party and its communication addressing
information. The name of the node tag is specific to each protocol, in the
example above since the HTTP protocol is used the <HTTPNode> tag is
specified. There is one <...Node> tag for each party. It identifies the party
name using the <OrgName> tag that contains an ID reference attribute
pointing to the corresponding <PartyName> tag under <Participants> (see the
previous section). All parties must be represented the <Communication>
section including the <Arbitrator>. Under the <...Node> tag is also the
unique electronic address of the party: the URL address in our case. This
address is contacted for creating an information-delivery channel. The form of
address differs for each communication protocol. Finally, the <NetworkDelay>
tag defines the expected worst-case round trip network delay for any
message and its response. This delay excludes service time at the recipient
of a message prior to its sending a response. Other tags in other parts of the
TPA define the service time. There is a unique communication address tag for
each protocol.
The last subparts of the <Transport> section: <TransportEncoding> and
<TransportSecurity> sections specify, respectively, how the transport level
encodes messages for transmission (currently, BASE64 is the only choice)
and the security specifications for the transport layer of the TPA. This second
tag may be omitted if transport security will not be used for this TPA. Unless
otherwise specified below, transport security applies to messages in both
directions.
198
Document exchange layer

Information encompassed in the document-exchange layer includes the
name of the protocol, such as OBI protocol, the message-encoding choice
(example: BASE64), whether or not duplicate messages should be detected,
and the message-security definition.
Message security may be either or both of the following:
Digital-envelope (secret-key encryption using certificate-based encryption
to exchange the secret keys)
Certificate-based non-repudiation
The section syntax is:
<DocExchange>
<DocExchangeProtocol>protocol</DocExchangeProtocol>
<MessageEncoding>encoding</MessageEncoding>

<MessageIdempotency>choice</MessageIdempotency>

<MessageSecurity>
</MessageSecurity>
</DocExchange>
The <DocExchangeProtocol> tag specifies the business protocol that defines

the detailed message formats. Examples are OBI and VAN-EDI.
The <MessageEncoding> tag specifies how the messages are encoded by the
document-exchange level for transmission. Currently, BASE64 is the only
choice. Either <MessageEncoding> or <TransportEncoding> can be specified,
but not both.
The <MessageIdempotency> tag specifies whether all messages sent under the
TPA are subject to an idem potency test (detection and discard of duplicate
messages) in the document exchange layer. If the value of the tag is yes, all
messages are subject to the test; otherwise, none have to be specified.
Finally, the <MessageSecurity> tag provides the security specifications for the
document exchange function. It may be omitted if message security will not
be used for this TPA. Message security may be either non-repudiation or
digital envelope or both.
199
Business protocol layer

The <BusinessProtocol> tag defines the TPA layer which contains all the
business-protocol definitions that support the business application.
Under the <BusinessProtocol> tag is the service interface definition for each
party that can act as a server. Each service interface contains some overall
parameters and the action menu, which includes the set of definitions of the
actions that this party will accept as service requests. The syntax is:
<BusinessProtocol>
<ServiceInterface> 
... 
</ServiceInterface>
</BusinessProtocol>
The <ServiceInterface> tag defines the services provided by a party that acts
as a server and the characteristics of the party that is a client. As we will see
in the following paragraphs, these services include the list of actions provided
by that server, their characteristics, and the actions permitted initially. The
TPA contains a separate service interface definition for each party that acts
as a server.
Note
For some applications, each party may have both server and client
characteristics, that is, each party may issue requests to the other party.
The <ServiceInterface> tag has one attribute, InterfaceId. The value of this
attribute is an alphanumeric string that contains an identifier for this service
interface. Each service interface must have an ID that is unique within the
TPA. An example is: InterfaceId="SERVER01".
The <ServiceInterface> section syntax is:
<ServiceInterface InterfaceId=id>

<Client>
<OrgName Partyname=party/>

</Client>
<TaskName>name</TaskName> 
<ActionMenu> 
<Action> 
...
200
</Action>
</ActionMenu>
<ServerServiceTime> 
...
</ServerServiceTime>
<StartEnabled>
<RequestName>action_name</RequestName>

</StartEnabled>
<TerminateConversation> 
</TerminateConversation>
<ServiceSecurity>option</ServiceSecurity>

</ServiceInterface>
As shown in the syntax above, the <ServiceInterface> tag includes several

subsections. All subsections are intended to address the following basic
questions:
1. Who is playing the server part within this service interface? (See the
<orgName> tag)
2. Who is on the client side? (See the <Client> tag)
3. Which is the overall task name solved by this service interface? (See the
<TaskName> tag)
4. Which is the list of actions that are supported by the server provider? (See
the <ActionMenu> tag)
5. Which are the actions that can be invoked initially? (See the
<StartEnabled> tag)
6. Which is the action or the action cause the current conversation to be
terminated? (See the <TerminateConversation> tag)
7. Which is the security level that both server and client sides have to adopt
for exchanging document? (See the <ServiceSecurity> tag)
Among all subsections defined within the <ServiceInterface> tag, the most
important one is the Action Menu subsection (the <ActionMenu> tag) whose
content answers to the question 4 above. We detail the Action Menu in the
following section, and refer you to the tpaML specification document for all
others.
201
Actions
For each party to the TPA which can act as a server, there is an action menu
which identifies the permissible action requests and their characteristics.
Each action is a unit of work defined in the TPA. It consists of a request for
service and associated information (for example, maximum expected
response time for the action). An action may be associated with multiple
message flows. Some actions can be revoked by corresponding cancel
actions defined in the TPA.
Each action is invoked via a request message. During the long execution
period, the service provider can send one or more informative messages,
followed by a final reply message. A completed action can be canceled
according only to the tpaML specification. An action description also specifies
handling of failures.
We discuss the main elements of an action definition using the following
Open Buying on the Internet (OBI) protocol buyer action definition. See
Section 6.2.3, A sample application TPA on page 212 for a short description
of the OBI protocol.
<Action>
<Request>
<RequestName>processOBIPOR</RequestName>
<RequestMessage>OBIPOR</RequestMessage>

</Request>
<Response>
<ResponseName>handleOBIPO</ResponseName>
<ResponseMessage>OBIPO</ResponseMessage>
<ResponseServiceTime>
<ServiceTime>3600</ServiceTime>

</ResponseServiceTime>
</Response>
</Action>
The <Request> tag within the action section defines the name of an action, the
input information, and the result information. In the example above, the
request name is processOBIPOR, that is, the action transmits a purchase-order
request to the OBI buyer.
202
The response to a request is normally by means of one or more

asynchronous reply messages defined by <Response> as in the example
above. If <Response> is not provided and for synchronous reply, the client
uses an application-defined query action to obtain the results. The client must
issue a query at a later time to obtain the results. The query is an
application-defined action that the client application invokes on the server on
which it invoked the original action. The query request may be dependent on
the specifics of the action request that it supports. A query request to be used
to obtain action results is synchronous.
In the example above, the <Response> tag indicates that the response is by
means of an asynchronous message from the OBI seller server to the OBI
buyer server and that the response causes the handleOBIPO method to be
invoked at the issuer of the action (here, the OBI seller server). The response
transmits a completed purchase order ( OBIPO).
The <ResponseServiceTime> tag specifies the worst-case service time for the
server (in this case, the OBI seller server) until the response is returned.
Here, it is 3600 seconds, that is 1 hour. If the specified time is exceeded, it is
up to the requester's application logic to decide what to do next.
In general, within a single conversation, actions on a given service interface
are performed sequentially (this is the default behavior). One action may not
be invoked until the prior action is completed. An exception is actions with the
attribute type="concurrent". These actions may be invoked concurrently with
other actions in the same conversation.
Sequencing rules are used to specify the permissible order of action
invocations on a given server. The permissible initial action or actions is
specified as follows, specified under the <ServiceInterface> general section
under the <StartEnabled> tag.
<StartEnabled>

</StartEnabled>
There is one <StartEnabled> tag for each party which can act as a server.
Only one of the actions whose names are specified under <StartEnabled>
may be invoked as the first action in a given conversation on that server.
203
Within each action definition, a sequencing rule specifies which actions can
no longer be invoked following the completion of the particular action, and
which actions become permissible following the particular action. The
specification is as follows:
<Sequencing>
<Enable> 
<RequestName>name_of_action</RequestName>
...
</Enable>
<Disable> 
<RequestName>name_of_action</RequestName>
...
</Disable>
</Sequencing>
The <Enable> tag specifies which actions are permissible following the action
whose definition contains the <Sequencing> tag. The <Disable> tag specifies
which actions are no longer permitted after this action.
The rules in <Sequencing> are effective only if the action succeeded. If the
action did not succeed, the lists of actions allowed and not allowed are
unchanged.
6.2.2 The IBM Business-to-business Protocol Framework

Business-to-business Protocol Framework (BPF) is the IBM implementation
environment where TPAs can operate.
BPF includes a suite of tools to support the TPA lifecycle, including the
preparation, setup, and generation of new TPA documents, and the
generation of interaction processing from them. It can be viewed as the
gateway, coordinator, and control-point of choice across inter-enterprise
processes, for example, between the buy/sell component of a local business,
the remote businesses, and the back-end systems (see Figure 55).
204
B2
B1
B3
BPF
BPF
selling
purchasing
Backend
Systems
Backend
Systems
Figure 55. The control point role of BPF in inter-enterprise business processes
In BPF, business protocols are expressed as an electronic TPA in XML using

a higher level authoring tool, and are registered to the BPF server along with
the internal business processes for setting up such B2B interactions.
BPF architecture supplies a general mechanism to support various current
standard business protocols and B2B processes, such as the Open Buying
on the internet (OBI) (see Section 6.2.3, A sample application TPA on page
212), Commerce XML (cXML) and so on, as well as their future
enhancements. In the BPF architecture, this is accomplished by creating a
personality for a business protocol, based on the specification of a protocol
TPA.
Additionally, typical B2B processes, such as Request For Quote (RFQ),
Request For Information (RFI), and other processes, are similar across
various B2B protocols and can be implemented by the same framework.
205
These other processes can be implemented largely by changing the TPA.

Tie-in to back-end systems is provided by invoking an extensibility framework
from the business logic interface which is triggered by incoming requests.
Figure 56 illustrates the generality of BPF for different kinds of business
protocols. Using OBI as an example (see Section 6.2.3, A sample
application TPA on page 212 for a short description concerning the OBI
protocol), the middle node in the figure could be a business sell-side OBI
server, with requests coming from the requisitioner (top left); the server on
the left of the picture would then be the OBI buy-side server, and the server
on the top right would be the payment gateway. The local business process at
the (middle) sell-side node could be the fulfillment process, which is invoked
using the BPF framework.
As another example, this figure could be the case of an RFQ process in which
the buyer (node at the lower left) could submit an RFQ request to the
seller/supplier (middle node). The seller would invoke its local business
process to determine whether to respond to the RFQ; this may, in turn,
involve requests to remote suppliers (on the right), which would be done
using BPF. The seller could then send a response to the RFQ to the buyer.
The buyer, in turn, could select from the responses received and send a
purchase order (PO) to the selected seller.
206
TPA
TPA
OBI Buyer..............
......Payment Gateway
OBI Seller
Seller-Supplier ......Remote Supplier
Service Provider ......Sub-contractor
......Service Provider
Agency
......Payment
Merchant
......
Consolidator
Figure 56. General process flow for BPF
Besides providing the essential services for reliable and secure exchange of
documents between business partners based on their agreements, BPF
provides many other services to the applications for handling complex
interactions.
For example, consider a TPA between a buying organization and a selling
organization. The selling organization may initiate separate conversations,
based on separate TPAs, with each of its suppliers for handling service
requests from its clients. Not only does each conversation have to follow its
associated TPA, but also, there is also a need for coordination of multiple
conversations with different business partners under different TPAs. For
example, a service request (such as a Travel Plan) can be satisfied only if all
the sub-components can be obtained from different business partners (a
hotel, a rental car and so on). A BPF application can express such logic in a
simple manner. Each service request can be handled synchronously or
asynchronously, depending on the agreement level. An asynchronous
request may have response time constraints, and associated error handling
requirements upon time-out.
207
An important characteristic of BPF is that it does not require that all partners
to a given TPA must also use BPF. This independence is essential for doing
business over an open medium such as the Internet. One should not dictate
to others which technology to use to send and receive messages. Because
BPF is technology neutral, it is ideal for setting up loosely-coupled trading
agreements in which, for example, a business is free to replace suppliers by
others without having to make a large IT investment to support the new
supplier. As long as the business protocol, and hence the TPA, does not
fundamentally change, replacing business partners by others is practical.
The following sections provide a short overview of the basic BPF components
and the main data flows.
6.2.2.1 BPF components and data flow
The functionality provided by the Business-to-business Protocol Framework
is layered, as shown in Figure 57, in order to provide different levels of
abstraction for the business data flow. Furthermore, the layering, along with
well-defined inter-layer APIs, minimizes the spread of specialized code
across the framework. The business data flow through the layers, for any
particular type of business data, is driven by the Trading Partner Agreement
that governs that particular protocol.
208
Business logic
Web application programming environment
TPA
overall properties
roles
identification
communication properties
security properties
actions
error handling
commentary
sequencing checks
responsiveness checks
business logic interface
Document exchange
message data mapping
non-repudation
time-stamping
logging and audit
BPF Layering
Business protocol
Transport
network
security
Figure 57. BPF functional layers
The lowest level of the BPF stack is the Transport Layer, which contains
protocol-specific modules that allow the business processes to communicate
with the external world using any of the supported communication protocols,
with communication-related security like authentication and encryption. The
Transport Layer interfaces with the Document Exchange layer, which
supports the abstraction of a business document (for example, an EDI
document).
The Document exchange layer provides common document-related
functionality such as message data mapping, non-repudiation, time-stamping,
logging, and audit-trail. The Document exchange layer interfaces with the
Business Protocol layer, which provides document-type and trading-partner
specific data handling functionality. The Business Protocol layer, in turn,
provides the business-logic interface.
The BPF components can be broadly categorized as those related to setting
up the BPF environment and those related to runtime operations for business
209
to business interactions. Figure 58 shows in a simplified way the BPF

component building block architecture and the two component categories:
Set up and generation and Run time.
Set up and generation
Local Processes
(a)
XML
Registration
Database
Authoring Tool
(c)
Workflow
ERP
packages
Business
Applicaiton
Generation Tool
Application
Interfaces
Executable Files
Parsers
Security
Handlers
Interface Code
Registration Tools
Document
Repository
Rules Code
(b)
Encoders
Document
Exchanget
Logging
BPF Manager
HTTPS
Transport
SMTP
Run Time
MQSeries
Network
EDI
Runtime
Services
INbound request/replies
Network
Sub
Contractors
OUTbound request/replies
Figure 58. BPF set up environment and runtime operations
Concerning the first category, BPF includes a suite of tools to support the
TPA life cycle, including preparation, setup, and generation of new TPA
documents and the generation of interaction processing from them:
Authoring tools assist the creation of new TPAs. In many cases, it may be
convenient to construct a new TPA by combining elements from those
previously deployed, tailoring the result for the new target interaction. The
authoring tools for TPA include modelling and template functions to
simplify TPA assembly from pre-existing parts.
Registration tools are used to populate a registration database with
interface information identifying the user application logic to be bound into
210
the business to business interactions, and user provided helper functions

such as specialized parsers security handlers and encoders
Code generation tools use the TPA and information from the registration
database to generate program objects (executables) which, together with
the runtime BPF support, implement the required business-to-business
interaction processing.
Hence, starting from a TPA authored with the tools described above, and
using a combination of generated and runtime logic, BPF provides a complete
implementation of all message and interaction logic needed for a particular
trading partner interaction. As TPAs are XML based, the strong syntactic
checking available within advanced XML editors can be used in these tools to
diagnose and warn of inconsistencies.
At runtime, the BPF Manager uses the data in the registration database and
the generated program objects to manage information flow through the
system and control execution of the business rules in the TPA. In addition,
functions such as event handling, security services, and logging are handled
by BPFs Runtime Services. The BPF generated code enables
inter-enterprise integration, alleviating the need to develop custom programs
to manage networking, business event handling, message processing and
sequencing.
Generating interaction code from TPAs allows appropriate security validation
and message logging steps to be added systematically. Hence, the level of
security is adjusted to the communication context of each business partner
connection, providing appropriate protection for secure interactions across a
publicly accessible network. BPF generated checks for responsiveness of the
partner and valid message sequences improve reliability further.
As noted earlier, to provide an effective single point of consolidation for
interactions, a business-to-business infrastructure needs to provide a broad
range of connectivity options. In addition, it is important to provide services
for defining, parsing and manipulating XML messages, together with facilities
for importing other message libraries and services. This can simplify the
mapping of other existing application and message formats both into, and out
of, XML messages.
BPF provides many different services to the business applications running on
this platform. In addition to the basic TPA service, BPF provides services like
time-stamped logging, recovery services, public-private key cryptography,
reliable document exchange, and document repository.
211
A version of BPF is built on top of an Enterprise Java Beans server and

employs a diverse set of technologies for providing various functions and
services. For the initial product, WebSphere is used as the EJB server,
although there is no specific dependency on WebSphere. A business may
communicate with its partners using one of several protocols: HTTP, SMTP,
FTP, VAN, or IBM MQSeries. It may even use different protocols for different
sets of actions on a per-TPA basis.
Security technologies include transport security (SSL), authentication using
digital certificates, as well as digital signatures for non-repudiation (using
MD5, SHA-1). Various data formats include EDI, XML-EDI or other XML
formats. Appropriate message parsers or message generators are provided
for converting these documents into an internal format. Independent software
components providing many of these technologies can be plugged in to the
BPF framework via a vendor-neutral open API, thus allowing developers to
customize solutions of their choice.
6.2.3 A sample application TPA

This section describes an example of the TPA and the server structure for an
existing public protocol: Open Buying on the InternetTM (OBI). OBI is a
protocol for business-to-business Internet commerce. It was designed by the
Internet Purchasing Roundtable and is supported by the OBI Consortium
( http://www.openbuy.org).
OBI defines the procedures for the high-volume, low-dollar purchasing
transactions that make up most of an organization's purchasing activity. In
this section, we describe OBI, how it can be described by a TPA, and a
schematic view of a possible implementation. Figure 59 illustrates the
participants in an OBI transaction and the basic information flows.
212
Requisitioner
View
Purchasing Homepage
Buying
Organization
Query Status
Catalog
Browsing
t
ues
q
e
R
O
PO
ed P
t
e
l
p
Com
Invoice
Selling
Organization
Check
Payment
Payment
Authority
Figure 59. OBI Participants and flows
The requisitioner is a member of the buying organization (for example, an

employee of a company) and is permitted to place orders directly with the
selling organization's merchant server. The requisitioner can browse a
catalog and place an order with the selling organization using a browser.
When the requisitioner has placed an order, the selling organization's server
sends a partial purchase order (purchase order request) to the buying
organization's server. The buying organization validates the purchase order
request and transforms it into a complete purchase order which it returns to
the selling organization. The selling organization then prepares an invoice or
otherwise arranges for payment and ships the ordered merchandise.
The payment authority is an optional part of the system. Its purpose is to
handle electronic payments. Using the browser, the requisitioner can also
view and update various information at the buying organization server such
as the requisitioner's profile, outstanding requests and so on. The
requisitioner can also check the status of an order at the selling organization.
An additional possibility is that the buying organization can send an
"unsolicited" purchase order to the selling organization without a prior request
and partial purchase order initiated by a requisitioner. This mode might be
used, for example, when a purchasing department purchases large volumes
to supply a stock room.
213
In a one possible implementation of OBI, there is a TPA between the buying

organization and the selling organization, each of which has a business to
business server. In OBI terms, the TPA is a trading partner agreement (TPA).
The payment authority, if present, is outside the scope of the 2-party TPA
between buying organization and selling organization. It may interact with the
buying organization and the selling organization in a variety of ways. The
interaction may be through separate 2-party TPAs between the payment
authority and the buyer and seller organizations. It may also be simply
through application programs.
Following are the main functions included in the OBI TPA:
Organization names of the parties to the TPA.
Communication protocol definition. In this case it is HTTP, and includes
the specific URLs of the buyer and seller.
Security information such as the protocol (SSL in this case) and various
certificate parameters.
Action menus for the buyer and the seller. The action list for the buyer
consists of one action, "Process OBI Purchase Order Request". The
completed purchase order is returned to the seller by means of a callback.
The action list for the seller also consists of one action, "Process OBI
Unsolicited Purchase Order".
Figure 60 shows the basic system structure and flow of an implementation of
OBI. Shown in the figure are the TPA objects generated from the TPA at the
buyer and seller servers. These objects provide the interfaces between
various processes controlled by the TPA (in particular, the action requests)
and the application logic at each server.
214
Requisitioner
Selling
Organization
2. Redirected to
preferred supplier
catalog
1. Login
Catalog and
purchasing functions
Buying
Organization
Business-ToBusiness Manager
Request PO
l PO
Partia
Application
Logic
TPA
Object
d PO
plete
Com
4. Request
Approval
4'. Confirm
Gateway
5.
m
Co
et
pl
ed
PO
Partial PO
TPA
Object
Gateway
Completed PO
Gateway
Local Processes
3. Partial PO
Business-ToBusiness Manager
Local
Processes
Figure 60. The OBI Implementation
The process starts when a requisitioner contacts (1) the buyer server via a
browser and is redirected (2) to the URL for the seller server. The
requisitioner is shown the supplier catalog appropriate to the requisitioner's
organization.
When the requisitioner makes a selection, the request is communicated to
the TPA object. The TPA object communicates the purchase request to the
local business processes via one of the gateways shown at the far right in the
figure. A partial purchase order is returned to the TPA object via the gateway.
The TPA object then issues the processOBIPOR action request (3) to the buyer
server, sending a partial purchase order to the buyer server.
This request arrives at the buyer's TPA object, which evaluates the rules
defined in the TPA and then sends the partial purchase order to the buyer
application logic. In processing the partial purchase order, the application
logic communicates with local business processes, via the gateway shown at
the lower left in the figure, to request approval (4) of the purchase order.
215
If the purchase is approved (4'), the approval arrives at the application logic,
which completes the purchase order and passes the completed purchase
order to the buyer's TPA object. The TPA object then issues the callback (5),
sending the completed purchase order back to the seller.
The completed purchase order arrives at the seller's TPA object, which
passes it to the local processes via the gateway at the lower right. The local
processes handle fulfillment (for example, shipping) and invoicing/payment.
They also initiate a confirmation message to be returned to the requisitioner
via the browser (not shown in Figure 60).
In the following section we will build an OBI TPA XML document which
defines the OBI between two specific companies: Large Co, which plays the
buyer role, and Pens Are We, which plays the seller role, as proposed in the
tpaML specification document.
To construct this particular TPA we will use IBM XML Visual Builder tool which
is, as described in Section 3.2.3.3, Visual XML tools on page 69, an early
technology release for providing XML tooling in the IBM Application
Framework for e-Business and can be downloaded from IBM AlphaWorks site
( http://www.alphaworks.ibm.com).
6.2.4 Using the IBM Visual XML Builder for a specific OBI TPA
The IBM Visual XML Builder is a tool for constructing valid XML documents
from a DTD, and can be effectively used to build Trading Partner
Agreements. In general, by using the IBM Visual XML Builder, you can:
Create an XML model that conforms to a DTD.
Customize the XML model to add in additional semantic information such
as the data types of a field or default values of a field.
Define user-exits for specifying application specific processing logic.
Support re-use of other XML models.
Validate an XML document based on the DTD or additional semantic
information.
Generate the final XML document.
An important feature of the IBM Visual XML Builder is concerned with the
ability to promote the separation of roles and responsibilities in a large
organization. In particular, the tool can be used by people creating an XML
structure from scratch using a DTD, or it can be used by people customizing
an existing XML template/model by simply filling in the values. Different
216
services will be available to the user depending on what mode the tool is
invoked in.
This last feature is particular useful in the context of the TPA building process
since it is possible to foresee that within an organization/company there are
separate responsibilities and roles to define and handle TPAs. It is possible to
have separate roles and responsibilities which include the TPA XML model
developing process and the TPA XML document building process with a
specific partner. In the first case, a general TPA XML model can include some
types of relationships within a partner, such as a buyer to supplier, and some
business protocol. In the second case, a TPA model is customized to match
the agreements in place with a particular partner.
6.2.4.1 Getting started with the IBM XML Visual Builder
Each tool in the IBM XML Tools package operates through models. A model
encapsulates the tool state, or what is commonly known as meta-data,
concerning the particular object produced by that tool (a DTD, an XML, and
so on). For example, as a first step for creating an XML document, it is
necessary to have a model of the XML document that has to be created. An
XML model, for instance, contains additional meta-data that are not captured
by a DTD and are used by the Visual tool. An XML model is created from a
specific DTD. A DTD model has a .dtd.xmi extension. An XML model has an
.xml.xmi extension. IBM XML Tools use the undergoing XMI standard format
to externalize each tool's meta-model.
This operational approach of the IBM XML tools influences positively the TPA
building process. In particular, to build a specific TPA XML document by
using the IBM XML Visual Builder, these steps must be followed:
1. Generate a General TPA XML model (if not available) starting from the
tpaML specification DTD document. This model can be generated by
using, for example, the IBM Visual DTD tool also included in the package
or the specific wizard also included in the IBM XML Visual Builder tool.
2. Customize the General TPA XML model by building a specialized model,
the TPA XML model, which encapsulates the structure of the particular
TPA XML document that has to be built. The TPA XML model can also
include other sub-models (2a), define tags default values, and define
user-exits on tag attributes values for specifying an external application
specific processing logic that can be activated during the generation of
XML documents from that model (2b). The external processing logic
determines on-the-fly the particular tag attribute value to be set when the
XML document is generated.
217
3. Edit and generate a valid TPA XML document by using the TPA XML
model built and customized in step 2.
Figure 61 shows, schematically, the various products generated during the
TPA XML document building process within the IBM XML Visual Builder tool
environment.
2a.
Specific TPA XML

model
1.
General TPA XML

model
tpaML
DTD
3. TPA XML Documents
2b.
Other XML models

or sub-models
2c.
External
Processing Logic
Figure 61. TPA XML document building process within IBM Visual XML Builder
Figure 62 shows the wizard window that IBM Visual Builder tool presents to
the user when it is asked to create a new XML model. The figure proposes, in
particular, a moment at the beginning of step 2, where we are building the
specialized TPA model that will encapsulate the structure of the contract
between our two companies: Large Co and Pens We Are. We defined, in
particular, the TPA model name ( C:\IBMXMLTools\xmimodels\OBI.xml.xmi) and
specified to be used the general TPA XML model ( tpa.dtd.xmi) we built
starting from the tpaML DTD specification during step 1.
218
Figure 62. Creating a TPA XML model for the OBI TPA contract
By pushing the Next>> button on the window shown in Figure 62, Visual XML
Builder requires the user to specify the root element of the XML document
that has to be built (see Figure 63). All elements available in the tpaML.DTD
specification can be selected. For building a TPA XML model, the TPA
element has to be selected.
Another important feature of XML Visual Builder is that by getting a
sub-element from an existing TPA model (for example, Address,
Communication, and so on), another TPA model can be built using that
sub-element as a new root. As we will show in the following sections, we can
build models for each sub-part of a TPA contract (that is, sub-models; see
step 2b above) and after this, insert/include all sub-parts into a general TPA
XML model.
219
Figure 63. Selecting the XML document root element
Figure 64 shows the IBM XML Visual Builder main window after the specific
TPA XML model creation process, which reflects the fact that the OBI TPA
structure for our contract is completed (step 2a). On the left side of the
window, a tree view is displayed which shows a document structure reflecting
the basic tpaML.dtd encapsulated in the General TPA XML model.
We are now ready to use the editing facility provided by IBM XML Visual
Builder tool to customize the specific TPA XML model for building an
OBI-based TPA model that will supply the skeleton of the XML document
(contract) between our two companies. In particular, we will customize the
model according to our requirements by deleting unnecessary optional tags
and/or duplicating tags into the model.
220
Figure 64. TPA document structure
6.2.4.2 Customizing the TPA XML model

In this section we will customize the TPA XML model in other to reflect the
specific OBI agreement details between the Large Co and Pens We Are
companies. We will collect all need information by following the tpaML
specification minimal requirements.
To collect information and design the corresponding TPA XML model, we will
follow a step-by-step approach arranged around the basic TPA layers:
General Information layer, Transport layer, Document Exchange layer, and
Business protocol layer.
221
In the next section we will refine the TPA XML model by adding further
meta-data that are handled by the IBM XML Visual Builder which can help in
composing and generating the final TPA XML document.
Contract general information:
Start:
End:
Number of invocations:
Number of concurrent conversations:
Conversation Life:
01/01/1999, 00:00:00
01/01/2001, 00:00:00
100000
1
86400s
Buyer details:
Large Co
Tel. 914-945-3000
Address: Large Co
HQ Building
1 Main Street
SmallTown
NY
10000
USA
Address for billing:
Large Co
Accounting Department
100 Bean Counters Road
Any City
CT
06000
USA
Address for shipping
Large Co
Procurement Department
99 Purchase Road
Buy City
NY
10001
USA
Primary contact:
Smith L. John
Senior Buyer
Tel. 914-111-6789
Tel. 914-111-6790
email: jjsmith@largeco.com
email: http://www.largeco.com/procurement/jsmith.html
fax: 914-111-6780
Secondary Contact:
222
Blow J. Joe
Buyer
Tel. 914-111-6722
Tel. 914-111-6725
email: jblow@largeco.com
fax: 914-111-6780
Seller details:
Pens Are We
Tel. 945-123-1000
Address: Pens Are We
Building 001
123 High Street
EarthQuake City
CA
94567
USA
Contact: Doe E. Jane
Vice President of Internet Sales
Tel. 945-123-4567
Tel. 945-123-4570
email: janedoe@pensarewe.com
email: http://www.pensarewe.com/sales/jdoe.html
fax: 945-123-9999
Arbitrator details:
XYZArbitrator
Tel. 780-333-1111
Address: XYZArbitrator
Suite 3
77 Lawyers Blvd
ABC City
MA
01234
USA
Contact: Mr. Black K. Joe
Tel. 780-333-4040
Tel. 780-333-4045
email: jblack@xyzarbitrator.com
email: http://www.xyzarbitrator.com/jblack.html
fax: 780-333-5000
Figure 65 shows the proposed TPAinfo section of the TPA XML model for
coding the general information layer between Large Co and Pens We Are. As
you can see from this figure, the initial TPA XML model has been simplified by
deleting, in some cases, unnecessary elements (for example, the Role and
223
Comment tags), and by duplicating elements when needed in other cases.

We also added a new Member element in the Participants section, and
several AddressLines elements (not shown in the figure).
Figure 65. TPAInfo section of the TPA XML model for the two companies
Transport layer:
Type of transport layer: HTTPS
First HTTP node
Party Name LargeCo
URL
URLName:
requestURL
224
Address:
https://www.largeco.com/jackal/servlet/OBIBuy
Second HTTP node

Party Name PensAreWe
URL
URLName:
logOnURL
Address:
https://www.pensarewe.com/coyote/servlet/OBILogon
URL
URLName:
requestURL
Address:
https://www.pensarewe.com/coyote/servlet/OBIsell
URL
URLName:
responseURL
Address:
NetworkDelay:300s
Security:
Encryption
Protocol:
SSL
Version
3.0
Certificate:
X509.V3
KeyLength:
1024
Party Name:
LargeCo
Issuer Name:
VeriSign, Inc.
Issuer Certificate Source: http://www.verisign.com/certs
Party Name:
PensAreWe
Issuer Name:
GTE, Inc.
Issuer Certificate Source: http://www.gte.com/certs
Authentication
Protocol:
SSL
Version:
3.0
Certificate:
X509.V3
KeyLength:
1024
Party Name:
LargeCo
Issuer Name:
VeriSign, Inc.
Party Name:
PensAreWe
Issuer Name:
GTE, Inc.
Figure 66 shows the proposed Transport section of the TPA XML model for
coding the Transport and Security layer between Large Co and Pens We Are.
Also, as you can see from this figure, the initial TPA XML model has been
simplified by deleting, in some cases, unnecessary elements (for example,
225
the Transport Encoding tag), and by duplicating elements when needed in

other cases. We also added a new HTTPNode element in the HTTP section.
Figure 66. Transport section of the TPA XML model for the two companies
Document exchange layer:

Document exchange protocol: OBI
Message encoding:
BASE64
Message idempotency:
yes
MessageSecurity
Type:
Protocol:
226
Non Repudiation
Digital Signature
Hash Function: M
D5
Encryption Algorithm:RSA
Signature Algorithm: DSA
Certificate Type:
X509.V3
Key Length:
1024
Party Name:
LargeCo
Issuer Name:
VeriSign, Inc.
Party Name:
PensAreWe
Issuer Name:
GTE, Inc.
Figure 67 shows the proposed DocExchange section of the TPA XML model
for coding the Document exchange layer between Large Co and Pens We
Are. Also, as you can see from this figure, the initial TPA XML model has
been simplified by deleting, in some cases, unnecessary elements (for
example, the Digital Envelope tag in the Message Security tag), and by
duplicating elements when needed in other cases. We also added a new
Party element in the Certificate section.
227
Figure 67. Document Exchange of TPA XML model for the two companies
Business protocol layer:

Large Co Services (Pens We Are is acting as client)
Response Service Time: 3600s
Presume:
fail
Actions
Action 1.
Request Name:
Request Message:
Response Name:
Response Message:
putOPOR
OBIPOR
getOPO
OBIPO
Start Enabled Actions

RequestName: putOPOR
228
Pens Are We Services (Large Co is acting as client)

Response Service Time: 3600s
Presume:
fail
Actions
Action 1.
Request
Request
Action 2.
Request
Request
Name:
Message:
shop
shopMessage
Name:
Message:
putOPO
OBIPO
Figure 68 shows the proposed BusinessProtocol section of the TPA XML

model for coding the Business Protocol layer between Large Co and Pens We
Are. This section defines the services provided by a party that acts as a
server and the characteristics of the party that is a client. In our case, Large
Co plays the buyer role and Pens We Are plays the seller role, in the context
of the OBI application previously described.
Both parties expose services to the other side (one service from Large Co
and 2 services from Pens We Are, respectively). The initial TPA XML model
has been simplified by deleting, in some cases, unnecessary elements (for
example, the Responses tags in both Pens We Are action tags), and by
duplicating elements when needed in other cases. We also added a new
ServiceInterface element in the BusinessProtocol section just for coding in
this TPA both services sides.
229
Figure 68. Service Interface section of TPA XML model for the two companies
230
6.2.4.3 Adding further meta-data to the TPA XML model

In this section we will refine the basic TPA XML model built in the previous
one by adding further meta-data that are handled by the IBM XML Visual
Builder which can help in composing and generating the final OBI TPA XML
document.
IBM XML Visual builder supplies several meta-data facilities. In particular, we
can add to the basic TPA XML model, as additional semantic information
and/or services, any of the following:
Define data types of a field or default values of a field.
Define user-exits on specific fields for specifying application specific
processing logic.
Reuse of other TPA XML sub-models.
A certain role separation support can characterize the XML TPA building
process within IBM XML Visual Builder, as mentioned at the end of Section
6.2.4, Using the IBM Visual XML Builder for a specific OBI TPA on page
216. According to this role separation, once a TPA XML model is created, we
have a very informative skeleton for building, not only a specific TPA XML
document, but rather a class of TPA XML documents that can differ from
each other for specific parameter/attribute contents.
In our case, for example, our main initial aim was to build a specific TPA XML
document between Large Co and Pens We Are companies implementing the
OBI protocol. However, if we imagine that this activity were carried out, for
instance, by Large Co IT experts, it is foreseen that once the TPA XML model
is built, it can be used to generate new similar TPA contracts between Large
Co and other seller companies implementing the same business protocol.
Thus, in the Large Co company, two groups of people with different roles can
work on the TPA authoring process: the TPA XML model authors and the TPA
XML document authors. The second group has only the responsibility to take
the results of the first group, a TPA XML model, fill in specific values, and
generate TPA XML documents. The second group of people is not concerned
with changing the structure of a model, it only provides data to the model so
that a final TPA XML document can be generated.
IBM XML Visual Builder tool is architected in such a way that it can be run
according to these two different roles. It can run in a Non-Restricted mode,
and in this way, users can change the TPA XML model; or in a Restricted
mode, which supplies a restricted editing facility.
231
Figure 69 shows that in the TPA XML model, we have associated to the
Date element in the Start contract section, some meta-data information
the Date Type, in this case.
Figure 69. Associating meta-data to a TPA field
Figure 70 shows the usage of the user-exit facility supplied by IBM XML
Visual Builder. Users can add to the tool specific plug-in mechanisms,
encapsulated into JAVA classes, for generating specific field values. User-exit
functions will be called before the actual XML document is generated. In the
case of TPA, IBM XML Visual Builder supplies a specific JAVA class
( com.ibm.b2b.vxml.tpa.TPAMemberId) which calculates automatically the
MemberId field value when the final TPA XML document will be generated.
Additionally, in the IdCodeType field, we put the special value ZZ and defined
it in the tpaML specification which denotes any mutually agreed identifier. In
this case, the identifiers are defined by the parties for the purpose of the TPA,
but do not come from any industry-standard registry, such us the Dun and
Bradstreet registry.
232
Figure 70. Using the user-exit function in IBM XML Visual Builder environment
6.2.4.4 Editing and generating the OBI TPA XML document

Last step in the TPA building process consists in filling in all TPA XML model
elements with specific contract values and generating the final TPA XML
document. In doing this operation we can open, with the IBM XML Visual
Builder, the TPA XML Model created in the previous sections in the Restricted
mode and for each field proposed in the model, fill in the specific value.
233
As Figure 71 shows, IBM XML Visual Builder supplies a simplified editing

facility that speeds up the TPA XML document filling process. In this figure,
IBM XML Visual Builder is using specific meta-data we associated to the
Participants section in the TPA XML model for driving the section filling
process. All Participants section sub-elements are shown as a group rather
than as individual fields for the data entry. Editing the sub-elements as a
group is like form-filling.
Figure 71. Group editing facility of the IBM XML Visual Builder environment
Figure 72 shows another editing facility supplied by IBM XML Visual Builder,
in this case for filling the Date type fields: it is possible to use a specialized
calendar editing window.
234
Figure 72. Calendar editing facility of the IBM XML Visual Builder environment
Once all fields have been filled in, we can generate and validate the final TPA
XML document. Figure 73 shows a portion of the OBI TPA XML source
document. Appendix A, An example of a OBI TPA XML document on page
281, lists the full OBI TPA XML document.
235
Figure 73. TPA XML document source code
6.3 Summary
In this chapter, we have given an overview of the role that XML can play in
the business-to-business application context, as well as what IBM is doing in
helping companies in this particular field.
B2B applications have been positioned as one of the best opportunities of the
emerging business integration IT field in the inter-enterprise e-business
application area.
Two key IBM technologies, recently introduced, that can support the B2B
business models have been extensively described: the standard language
proposal tpaML and the Business-to-business Protocol Framework (BPF).
236
These technologies are the basic building blocks of IBM WebSphere B2B
Integrator, the B2B XML-based framework announced by IBM.
tpaML is the standard mark-up language proposed by IBM for writing Trading
Partner Agreements (TPAs). A TPA is an XML document that contains the
general contract terms and conditions, participant roles (buyers, sellers),
communication and security protocols and business processes, (valid
actions, sequencing rules, etc.). TPA documents capture the essential
information upon which trading partners must agree in order for their
applications and business processes to communicate.
BPF provides a comprehensive set of tools and enablers for ease of
specification, configuration, plug-in, customization, and execution of a set of
TPAs between business partners. It is the gateway, coordinator, and control
point of choice across inter-enterprise processes. Examples of usage of TPA
and TPA authoring tools have been also provided.
237
238
Part 3. B2B eMarketPlaces

In this last part of the book, we provide a case study, which is an
example of an XML-based e-business application that covers both the
business-to-business and business-to-consumer application areas.
This case study is in the emerging B2B eMarketPlace field.
This part is designed to help information technology specialists and
developers understand what issues need to be considered during the
implementation of an e-business system, as well as how to implement
the main components using XML technology and, when available, IBM
products.
Chapter 7, B2B eMarketPlaces: a case study on page 241 proposes a
new project called B2B eMarketPlace intermediary (or E-broker) that
can intermediate on the Internet between trading partners such as
buyers and sellers operating in a common eMarketPlace. The online
intermediary establishes businesses between buyers and sellers by
combining services and data dynamically and appropriately according
to specific intermediary business models. We introduce the case study
in detail, giving an overview of the B2B eMarketPlace business area
and proposed services, and we also characterize the main features of
the application.
The chapter presents the architecture of E-broker, identifying the main
components, relations between them, and the interfaces of the system.
It shows what roles XML technologies play in the application, what key
issues should be considered during the design of the system, and what
IBM products can be used to implement the application.
239
240
Chapter 7.
B2B eMarketPlaces: a case study

In this chapter we propose a new project called B2B eMarketPlace
intermediary (or E-broker) that can intermediate on the Internet between
trading partners, such as buyers and sellers, operating in a common
eMarketPlace. The online intermediary establishes businesses between
buyers and sellers by combining services and data dynamically and
appropriately according to specific intermediary business models. We
introduce the case study in detail, giving an overview of the B2B
eMarketPlace business area and proposed services, and we also
characterize the main features of the application.
This chapter presents the architecture of E-broker, identifying the main
components, relations between them, and the interfaces of the system. It
shows what roles XML technologies play in the application, what key issues
should be considered during the design of the system, and what IBM
products can be used to implement the application.
7.1 Why the B2B eMarketPlace application?

B2B eMarketPlace intermediaries are strongly emerging in the B2B market to
complement and empower the traditional B2B model centered around the
buyer-seller transaction paradigm. B2B eMarketPlace intermediaries
mediate among buyers and sellers by facilitating the business transaction
process and, in some cases, by supplying value-added function to the
business transaction chain. B2B eMarketPlace intermediaries define a
business-to-marketplace-to-business (B2M2B) model which extends B2B
applications and technology. The M represents the eMarketPlace
intermediary or online trading communities which assists multiple buyers and
suppliers to exchange information and transactions.
We decided to select the B2B eMarketPlace field, as the main B2B case
study of this book, since it encompasses and at the same time extends all
traditional B2B (but also B2C) related issues. B2B eMarketPlace applications
offer many interesting aspects to analyze and discuss from both the project
and the design point of view, as well as the role that XML plays in these types
of systems. In particular, this type of application gives you a chance to
understand in practical terms many more elements in applying XML than
simply analyzing a traditional B2B or B2C application example.
241
7.2 eMarketPlaces and online intermediaries

The traditional B2B model, centered around the buyer-seller transaction
paradigm, is showing its limitations: it is definite in scale and displays only
partially efficiency in terms of market economics. Recently, to overcome
these limitations, a new Internet business model appeared which supports
B2M2B and leverages existing B2B applications and technology. The M
represents the eMarketPlace or online trading communities which assists
multiple buyers and suppliers to exchange information and transactions.
eMarketPlace are Internet based hubs that focus on specific industry verticals
or specific industry processes and use various market making mechanisms
(auctions, exchanges, aggregation) to mediate any-to-any transactions
among businesses.
Through the eMarketPlace hubs, buyers and sellers can trade electronically
with established partners and at the same time get access to new markets
and new parts of the supply chain. eMarketPlaces can be public, where all
members participate in an open, interactive buying and selling community, or
private, which are invitation-only communities whose members participate in
special pricing arrangements and/or product and service offerings.
eMarketPlaces have the potential to create excellent and efficient markets.
Usually, an eMarketPlace is hosted by an online intermediary
company/organization, which is a third party that combines enabling B2B
technology along with market-specific or process specific expertise to
facilitate trade. B2B eMarketPlace offerings are being built and operated by a
number of different parties, including:
Major industry players: For example, Ford, General Motors and
DaimlerChrysler in the automotive sector recently announced plans to
launch a B2B procurement systems mega market for suppliers. Sears and
Carrefour a French retailer and one of the world's largest are
establishing an eMarketPlace to handle ordering, inventory and eventually
the entire purchasing process. Sabre Holdings Corp. announced an
Internet-based, businesses-to-business trade exchange for the travel and
transportation industry. Boeing, Lockheed Martin, Raytheon, and British
Aerospace will form an eMarketPlace in the Aerospace sector aiming to
connect a massive number of suppliers and buyers in that industry, and
allowing them to buy and sell parts and conduct business over the
Internet.
Industry associations: For example, the Association of Unit Trusts and
Investment Funds (AUTIF) in UK funded the industrys electronic trading
initiative, EMX, to manage a new electronic commerce services.
242
Systems integrators: For example, IBM Global Services launched

Component Knowledge which is a B2B hub for the electronic components
market.
Software providers: For example, Commerce One, Ariba, and
Systemcare. Ariba proposes an Internet Business Exchange service which
is a hosted Internet service that enables corporations and Net market
makers to quickly build electronic marketplaces powered by the Ariba
Network platform, without installing or maintaining their own eCommerce
infrastructures.
The general aim of B2B eMarketPlace is to resolve the concerns that
e-commerce poses for buyers and sellers coming together with no previous
transaction history. The role of the intermediary comprehends areas of
communication, commerce, and content, and includes:
Bringing together buyers and sellers within a common eMarketPlace
Providing methods for transactions to take place, for example, through an
auction and standard contracts in order for them to be cleared.
Characterizing buyers and sellers; for buyers, they provide assurance that
sellers have suitable goods, by tracking levels of service quality; for
sellers, they provide assurance that the buyers are capable of making
payments
Aggregating third party content
Creating original content through aggregating trading data and user data
Providing value added services such as insurance, logistics, and financing
through partnerships with third parties
Targeted communication through offering e-mail, alarms and alerts and
personalization of advertising and content
Supporting buyers and sellers in accessing to the eMarketPlace
Figure 74 shows the eMarketPlace formed by online intermediaries and
typical mediation roles.
Chapter 7. B2B eMarketPlaces: a case study
243
Buyer
Buyer
Directories
Auctions
Added value services
MarketPlace
Business Models
Buyer
B2B
intermediary
Exchanges
Aggregations
Seller
Seller
Seller
Figure 74. The eMarketPlace and the online intermediary business models
In the following section, we revise some typical business models which are
adopted by B2B online intermediaries.
7.2.1 B2B online intermediary business trading models

B2B online intermediaries make use of a number of business models to
enable trade among parties to the eMarketPlace. The most common business
models are the following:
Directories
The Directory mechanisms are very similar to the well known yellow pages
service. By using this service buyers and sellers have the chance to
promote themselves in the eMarketPlace and, at the same time, to expose
the list of services and the types of contracts that they accepts. Business
transactions can take place between buyer and seller pairs independently
from the intermediary.
244
Auctions
Auctions provide mechanisms which temporary match buyers and sellers
and prices to levels of supply and demand. Auction services are typically
delivered as: Bulletin boards (sellers post offers and buyers bid on these
offers the bidding period is not defined: offers and bid are valid until are
removed from the bulletin board and bidders are not aware of other
peoples bids), Reverse auctions (traditional auction mechanism in which
buyers post requests to purchase in a structured format, and sellers to bid
for supply of the goods or services), Regular auctions (traditional auction
mechanism in which sellers post an offer and buyers to bid on this).
Exchange
This model allows both buyers and sellers to make bids and offers for
some underlying commodity. These exchanges replicate what has been
developed in industry specific financial exchanges and in the physical
market (buyers, trade houses, exporters, producers). Differently from
auctions, offers can be made at any time and can often be withdrawn or
revised.
Aggregation
In this intermediary business model intermediaries play an active role by
aggregating requests coming from the various parties. In particular, we
can distinguish the aggregation model into three forms:
Selling aggregation. Intermediaries aggregate, standardize and index

suppliers catalogues or content and make these available in a centralized
location to buyers.
Buying aggregation. Buyers requests for quotes (RFQs) are aggregated
and linked into a pool of suppliers who can make bids.
Content aggregation . Online intermediary publishers aggregate and filter
third party content and combine this with proprietary content to attract
communities of industry professionals.
Added value services
The last and much more specialized intermediation business model see
intermediaries playing an active role in the business process transaction.
Intermediaries provide in this case value added services that complement
or complete the business transactions between parties.
Typical value-added services range from Finance (managing transaction
processing systems), Fraud services, Credit Checking Services, Bill
presentation and payment, Logistic, Export control services.
245
In the following sections, we propose the project of an B2B eMarketPlace

online intermediary: E-broker, which targets some of the intermediation areas
and business models introduced above.
7.3 The E-broker application

This section focuses on the general requirements and the macro-design of
the E-broker B2B online intermediary. E-broker is to be thought of as the main
IT XML-based backbone that can support B2B vertical eMarketPlace hubs.
Thus, the design and project considerations explained below need not be
restricted to a particular application domain (automotive, chemical, foods,
and so on); rather, the main E-broker building blocks can belong to and
characterize any type of B2B online intermediary.
E-brokers main aims are the following:
Qualify and bring together buyers and sellers within a common
eMarketPlace
Provide a set of business models for transactions to take place between
eMarketPlace parties
Aggregate third party offering
Support buyers and sellers in accessing to the eMarketPlace
E-broker is intended to operate as a pure and independent intermediary and,
from the functionality point of view, should not privilege either the buyer-side
or the seller-side. Typical scenarios that we foresee for building and operating
a B2B vertical eMarketPlace hub that uses the E-broker IT infrastructure
include any of the following:
Spin-offs from existing industry players, or start-ups with expertise in a
particular industry segment (insurance, finance, foods, and so on)
Service and outsourcing IT providers, for example, Application Service
Providers (ASPs) or large IT service providers that want to create new and
domain-oriented business models
Independent industry associations that can leverage the quantity and the
quality of trading operations between their associates
There are several alternatives that one can follow to design and implement
the E-broker architecture. Using an XML-based infrastructure is just one
possibility; it may even be the best one! Nevertheless, our main aim in doing
this case study has not been to show how to project and design this particular
e-business application, but to check the feasibility of using XML in such an
246
e-business infrastructure. Thus, our prerequisites in designing E-broker are

the usage of XML standards, emerging business integration technologies
(such us TPA/BPF), and XML tools (for example, DB2 XML Extenders).
In the next section, we revise some of the main business models supported
by E-broker, and in the following section we analyze the impact of XML in
designing the E-broker IT infrastructure.
7.3.1 E-broker business models

E-broker implements some of the general business models supported by
online intermediaries and described in Section 7.2.1, B2B online
intermediary business trading models on page 244. In particular, we imagine
that the E-broker IT infrastructure that implements the intermediary business
models will be appropriately customized for operating into a specific vertical
eMarketPlace, and from an abstract point of view, the basic business models
can be arranged into the IT infrastructure in approximately the same way
across the various vertical domains.
E-broker supports the following B2B intermediary business models:
Advanced B2B directory service
Auctions
A simplified aggregation model
Additionally, along with the pure intermediation activity, E-broker provides
specialized eMarketPlace Information Portal and Customer Support services.
The eMarketPlace Information Portal delivers specific market and community
news and analysis, general and personalized information, and so on, to the
trading community. Through the Web, Customer Support services facilitate
the community traders in accessing to the eMarketPlace for example,
through help desk or call center facilities.
In the following example, B2B intermediary business models are described in
detail. Figure 75 depicts the E-broker eMarketPlace. As this figure shows, the
eMarketPlace is accessed not only by traders (buyers and sellers) but also
from other eMarketPlaces and E-broker partners (banks, logistic companies,
and so on) that can supply value-added services to the trading community.
247
Buyer
Buyer
Buyer
Internet
B2B Directory
Service
Aggregations
Aucions
E-broker
other eMarketPlaces
eMarket Information
Portal
Customer support
E-broker partners
(banks, logistic,
etc.)
services
Seller
Seller
Seller
Figure 75. The E-broker eMarketPlace
Advanced B2B directory service

According to the first business model, E-broker handles the list of all
parties that have access to the eMarketPlace. It is responsible to accept
online subscriptions, and to monitor and qualify the parties that enter into
the eMarketPlace.
For each party that gains access to the E-broker space, E-broker stores a
party profile. The party profile consists of two main sub-sections: a
general business information section and a specialized business profile
section.
- The first section includes the party identification details, the partys
business classification, and the catalogue of services or goods of
interest, and so on.
- The business profile section includes relevant information on how to
compose standard Trading Partner Agreements. These agreements
will rule how transactions will take place. The business profile incudes,
among other things, the party security profile, the preferred arbitrator,
248
the preferred transport, document-exchange, and business-protocol

layers, as well as the set of standard TPAs accepted.
E-broker supplies appropriate Web-based facilities to query the directory
content and navigate through the party information according to several
searching criteria.
Additionally, we envision the directory service integrated with an advanced
TPA authoring tool. This TPA authoring tool supplies to a party that would
activate a specific trading partnership with a candidate trading partner a
remote facility to select a candidate trading partner standard TPA and/or
TPA requirements defined in the party business profile and compose new
and specific contracts.
Once contracts are generated (E-broker can also generate the specific
TPA runtime code), these can be downloaded in the partys site, and
business transactions can take place according to the contracts between
the IT systems of the parties involved in a contract without the E-broker
intermediation or, in case it is not possible to have a direct connection
between parties, through the E-broker IT infrastructure. In this last case,
E-broker can also supply value-added services (for example, a translation
of the message flow) to the two parties.
Figure 76 shows the interactions that are activated during the initial
subscription process and during a trader profile update activity. A trader
(labeled Trader in the figure) connects to the E-broker and sends a
subscription request (1). All subscription requests are evaluated by the
E-broker operators (2 and 3), and eventually a communication of
acceptance is returned (4). Once accepted, a trader can update and/or
complete his profile (5).
249
1. Subscription
Req.
E-broker
2. Subscription Req.
Directory
Service
3. Confirm Subscription
Adminstrator
Party Profile
4. Confirm
Subscription
Trader
5. Profile
Update
Identification
name
Business
segment
catalogue
5. Profile Update
Business Profile
standard TPA
accepted
standard
conditions
accepted
Party
Profiles
Figure 76. Interactions between Traders and the E-broker Directory Service
Figure 77 shows interactions that are activated during the online building
process of new TPAs. A trader (Trader A in the figure) connects to the
E-broker Directory service and query the trading partners repository
(1 and 2). Once a trading partner (the Trading Partner B in the figure) is
found, the trader starts to compose the new TPA by using information coming
from its business profile, from the candidate trading partner business profile
and from the TPA standard repository handled centrally by E-broker (3). Once
the new TPA is finished, the trader can download it (the XML document or a
TPA runtime version) (4) and start a B2B transaction with the new trading
partner (5).
250
Directory
Service:
remote TPA
autoring tool
1. Browsing
Directory and
selectiong
partners
2. Query
E-broker
Standard TPA
4. Download
TPA
3. Composing
a new TPA
Party
Profiles
Business Profile
Trader A
5. B2B Transaction
Trader A
Standard
TPA repository
Business Profile
Trader B
Trading Partner B
Figure 77. TPA online building process
Auctions
E-broker supplies a set of auction mechanisms. In particular, all three
basic auction modalities reviewed in Section 7.3.1, E-broker business
models on page 247 are provided.
Auction services are delivered through any of the following:
- A bulletin board service where sellers can post offers, and buyers can
bid on these offers. The bidding period is not defined: offers and bids
are valid until they are removed from the bulletin board, and bidders
are not aware of other peoples bids.
- A reverse auctions service where buyers can post requests to
purchase in a structured and controlled format, and sellers will bid for
supply of the goods or services.
251
- Regular auctions service where sellers can post an offer and buyers
can bid on it.
E-broker plays an active role in the auction process. Buyers and sellers
have to sign specific Trading Partner Agreements with E-broker and
submit bids or offers by appropriately connecting their IT infrastructures
with the E-broker IT infrastructure according to the TPA. Also, in this case,
E-broker provides advanced TPA authoring tools (wizards) that will be
used by the parties that would have access to the auctions.
Evidently, the usage of TPA supplies a means to fully automatize the
entire Offer-Bid auction cycle.
Figure 78 shows a typical information flow that is set up for the bulletin
board auction mechanism. Sellers (labeled Seller in the figure) post offers
on the bulletin board (1), and these remain on the bulletin board until a
specific (6) remove action is invoked. E-broker, eventually, can invite
interested buyers to formulate bids (2). Buyers (labeled Buyer in the
figure) can browse and post bids for the offers currently opened (3),
asking for offer details in the case the offer is accepted (4). Once offer
details are received from the buyer, a B2B transaction is activated and
completed between the parties (5). At the end of the transaction, the seller
can require the buyer to remove the Offer from the bulletin board (6).
252
E-broker
Open Offers
......................
......................
......................
......................
......................
1. Post an
Offer on the
Bulleting
Board
Auctions:
Bullettin
Board
6. Remove
an Offer
4. Receive
Offer Details
Seller
5. B2B Transaction
2. Req. for Bid
3. Browse and/or
trig open offers
and Bid specific
offers
Buyer
Figure 78. The bulletin board auction information flow
Figure 79 shows a typical reverse auction information flow. Buyers

(labeled Buyer in the figure) post requests for purchase to the E-broker
reverse auction service (1). E-broker arranges auctions on the buyers
requests by temporary inviting interested sellers to formulate bids (2).
Buyers browse the offers and post bids (3). Once a bid is accepted, this is
officially acknowledged to the seller (4), who can activate a B2B
transaction with the Buyer (5).
Please note that, in this case, the seller role could be played, not only by a
single company/organization, but also, a seller could include multiple
buyers (for example, a group of SMEs) that club together to negotiate, for
example, large discounts. E-broker could be interfaced in this case by
other online intermediary entities which operate other eMarketPlaces, for
example, intermediaries which aggregate homogeneously only a group of
buyers or sellers in a given area.
253
E-broker
Requests of
Purchase
......................
......................
......................
......................
......................
1. Post a
request to
purchase
2. Req. for Bid
Reverse
Auctions
3. Bid specific
requests
4. Bid
Accepted
Buyer
5. B2B Transaction
Seller
Figure 79. The reverse auction information flow
Figure 80 shows the typical information flow of the last auction modality
supported by E-broker: regular auctions. This modality is similar to the
previous one, with seller and buyer roles interchanged. In this case,
sellers (labeled Seller in the figure) post offers to the E-broker auction
service (1), which organizes auctions on these offers by temporary inviting
interested buyers (labeled Buyer in the figure) to formulate bids (2).
Buyers post bids on the offer, and once a bid is accepted, this is officially
acknowledged to the buyer (4), who can activate a B2B transaction with
the seller (5).
254
E-broker
Offers
......................
......................
......................
......................
......................
2. Req. for Bid
Regular
Auctions
1. Post Offers
3. Bid specific
Offers
4. Bid
Accepted
Seller
5. B2B Transaction
Buyer
Figure 80. The regular auction information flow
A simplified aggregation model

As we have said, E-broker is intended to operate as a pure and
independent intermediary and not, from the functionality point of view, to
privilege the buyer-side or the seller-side. Thus, pure Selling or Buying
aggregations (as described in Section 7.3.1, E-broker business models
on page 247) will not supplied. From the aggregation point of view,
E-broker handles only the catalogue of all goods and/or services traded
within the eMarketPlace. The catalogue will be made available in a
centralized location, and it will be provided cross-references between
buyers and sellers interested in particular goods or/and services and
between the general catalogue and the specific trader catalogue stored in
the Party Profile.
Additionally, E-broker supplies a set of services for managing the
centralized catalogue and navigating through the cross-references.
Parties will be able to activate specific business transactions, for example,
255
to send an RFQ to all sellers, for a specific good and/or service, by directly
interfacing the IT E-broker infrastructure. As usual, this service will
supplied on the basis of Trading Partner Agreements that parties will
subscribe with E-broker.
Figure 81 shows one of the possible aggregation services supplied by
E-broker. In this case, a buyer (labeled Buyer in the figure) sends a
multiple Request For Quote (RFQ) to the aggregation service of E-broker
for specific goods or services present in the centralized catalogue (1).
E-broker forwards the RFQ to all sellers who sell the object of the request
(2) and collects all Quotation responses (3) which are returned to the
buyer (4) who, finally, can activate a B2B transaction with the seller (5).
The E-brokers value-added, in this case, lies in the ability to appropriately
aggregate sellers catalogues, and to recognize and qualify, for a given
RFQ, the sellers that are able to supply the requested goods and/or
services.
E-broker
2. Req. for RFQ
Aggregation
Service
4. Quotaion
responses
1. Browse the
centralized catalogue
and send RFQ
Buyer
3. Quotaion
response
5. B2B Transaction
Figure 81. The multiple Request For Quotation aggregation service
256
Seller
7.3.2 Considerations on the impact of XML on the architecture

There are several roles XML and related technologies can play in
implementing the E-broker application. It is clear that most of these tasks can
be designed and implemented using different techniques and tools.
Nevertheless, our main aim in doing this case study has not been to show
how to design an e-business application in general, but to verify if XML and
its related technologies can be used during the design and implementation,
and what advantages or disadvantages these technologies bring.
This section reviews the E-broker business models, and shows, for each
main architectural component, the advantages and the disadvantages of
using XML based technology. We will focus on a variety of areas where XML
can be used, and show how these areas affect the E-broker system.
XML as a data representation and exchange format

As a source data format for information about companies, products, services
and Trading Partner Agreements (contracts), XML has several advantages.
First of all, as a structured data format, it allows flexible and efficient data
description. Since meta information about the data is also stored (both in
documents and DTDs), it is possible to interpret and validate data
automatically, without any other information. This is a basic requirement for
building the E-broker. XML also allows the management of smaller pieces of
documents, and the creation of compound documents based on several other
documents. For example, the aggregation service would require a feature like
this. It would also benefit from the fact that XML documents are
well-structured, the data is stored in a hierarchical structure.
Probably, the most important role that XML can play in the E-broker
application concerns the usage of standardized XML-based data exchange
formats between trading partners, and between traders and E-broker. To
realize Trading Partner Agreements in the application we can effectively use
the Trading Partner Agreements Markup Language (tpaML). See Section
6.2.1, Trading Partner Agreements on page 185).
There are also proposals for describing company and user profile information
according to various purposes, including identification, security, and
personalization. These areas can be implemented using XML, but traditional,
database oriented methods probably would reach the required level of
functionality with less complexity. However, these information needs to be
exchanged between companies and the E-broker. For this purpose, XML, as
an application-independent data format, could provide good solutions.
257
For example, the Platform for Privacy Preferences Project (P3P) developed
by W3C, provides a general framework for informed online interactions. The
goal of P3P is to enable users to exercise preferences over Web sites'
privacy practices. P3P applications will allow users to be informed about Web
site practices, delegate decisions to their computer agent when they wish,
and tailor relationships with specific sites.
The Directory Services Markup Language (DSML, www.dsml.org) is a new
proposal by several industrial companies (and IBM) for representing directory
service information (that is store, for example, in LDAP servers) in XML
format. DSML would provide this directory information to XML-based
applications in their native environment and data format. This would allow for
the E-broker applications to retrieve company, product, service and customer
data over the Internet described in a standard format, DSML.
As another example, the Customer Profile Exchange (CPEX) initiative is an
industry organization dedicated to developing an open standard to facilitate
the exchange of privacy-enabled customer information across enterprise
applications. The CPEX standard integrates online and offline customer data
in an XML-based data model for use within various enterprise applications
both on and off the Web.
XML as a metadata standard

Metadata, or data about data, provides information about data objects. This
information can be used to label, catalog, locate and understand data, for
example, goods and services. Using metadata the productivity of the data
management process can be greatly increased.
As we reviewed in Section 1.2.7, Metadata (RDF and PICS) on page 21,
XML has several metadata initiatives. The Resource Description Framework
(RDF) and the Platform for Internet Content Selection (PICS) are two main
examples of application domain independent metadata specifications. Both
standards are developed by the W3C, primary for Web use.
E-broker traders can describe their products and services in an XML
language for metadata description. This language can be especially designed
for this purpose. On one hand, this facilitates the interchange of this kind of
data between traders and the E-broker, allowing automatic data incorporation
independently from the particular companys information system. On the
other hand, it allows a very flexible and homogenous categorization of
product and services.
258
A business example is the Product Information Exchange (PIX) protocol set

that support catalog interoperability on the Internet through defined
guidelines for content, communication, format and presentation of product
data. PIX is under development by CommerceNet members
(www.commerce.net).
Metadata information can also be used to describe queries. The user who
wants to retrieve information about a particular service or good can specify
certain parts of a query document based on the metadata definition used by
the E-broker. The E-broker search engine can match this query document to
its stored product and service descriptions. XML query languages are still
immature, but there are already candidates that can be used in a working
system (see Section 1.2.11, XML query languages on page 25).
XML-based data processing

XML tools allow the creation, modification, and handling of XML documents
automatically. Standard programming interfaces, like the Document Object
Model (DOM), or the Simple API for XML (SAX) provide programmable
access to XML documents from applications (see Section 1.2.12, Processing
XML documents on page 25 for more details about these technologies, and
Section 3.2, IBM XML development tools and utilities on page 63 about IBM
products and tools). XML extensions in data management applications, like
the XML Extender for DB2, provide XML-based interfaces to legacy and XML
data (see Section 3.4, XML extensions to IBM products on page 89). This
allows you to develop custom applications that operate on XML data (even
using legacy sources).
The hierarchical nature of XML documents allows dynamic composition and
decomposition. Parts of XML documents can be identified, addressed,
extracted, and combined with parts of other documents runtime, according to
the actual set-up and required information. This allows the building of
complex data from small data fragments. This feature is useful for creating
catalogs, complex product and service descriptions, and to combine services
and products together.
The heart of the E-broker architecture is the Advance B2B Directory Service
which includes information concerning traders, goods and services
catalogues as well as party trading rules. This information is mostly in text
format, and it needs to be efficiently accessed in different ways for different
purposes. Some of this data could be arranged into database structures, but
it is hard to pre-define all kinds of tables for describing all kinds of information
present in these documents. XML provides efficient tools for organizing and
handling this information. While the back end storage still can be a database,
an XML front end (or database module) provides a more flexible way to store
259
and access the information. Document type definitions can help in automatic
categorization of documents, and queries and indexing can be built based on
this information.
XML also allows more complex queries than conventional database
technology. XML query standards and tools are still in development phase,
but it is expected that they could bring powerful solutions to the E-broker
architecture.
XML translators can transform documents between different XML
vocabularies. This allows automatic conversions between business document
models used by different traders and the E-broker. The XSLT specification
describes how to transform one XML document into another, and an XML
vocabulary specifies formatting semantics. Tools based upon this technology
can automate tasks during the acquisition of business data from companies.
XML and presentation

XML as a Web technology has strong support for presentation. The
Extensible Style Language (XSL) is a specification for applying formatting to
XML documents in a standard way. It is primary designed for Web use, and
also has document manipulation capabilities beyond styling. Using XSL and
XSLT (that describes the transformation of XML documents) different kinds of
presentation formats can be used to deliver XML documents to the users.
XML transcoding techniques help in transforming documents into the required
format. There are a wide variety of available formats, and new output formats
can also be described and used. Typical formats are paper-based, PDF and
HTML. The transformation can be done automatically according to
transformation rules. The best transformation format can also be selected
based on the capabilities of the output device.
WebSphere Transcoding is a typical product solution to this task. It allows the
modification of Web data, such as HTML pages, GIF or JPEG images, and
XML documents. It uses standards-based technologies for the data
transformation, including Java, XML, XSL, Wireless Application Protocol
(WAP), and Wireless Markup Language (WML). The initial content
transformation mechanisms can be extended by IBM, independent software
vendors (ISVs), or customers using plug-ins.
E-broker can effectively utilize this technology within the eMarketPlace
information portal layer and in the customer support service to provide
content in the right format according to their output devices, like personal
computers or mobile phones.
260
XML and personalization

Personalization is a critical feature of e-business application. It means the
automatic modification of presentation and content according to a users
profile. Usually, this applies to individual users, but companies would also
benefit from this kind of service.
On one hand, using personalization services a trader could tailor the content
available for the E-broker. It can select typical trading partners, and receive
only required information, monitor these selected company services,
changes, and so on. On the other hand, traders could specify data formats
they like to receive form E-broker. This means the selection of XML
vocabularies, and level of details they would like to receive from E-broker. For
human browsing, it would be also necessary to describe presentation
preferences based on the capabilities of presentation device and users
settings.
7.3.3 A building block architecture

From a functional point of view, E-broker consists of a set of integrated
components arranged within three main functional layers: the basic IT
infrastructure layer (network components, security, policy accesses rules,
and so on); the B2C service layer (delivering of specific and personalized
market and community news and analysis, customer support services, and so
on); and the B2B service layer, which handles the specific brokerage
activities (B2B Directory and catalogue manager, auction manager, and so
on). The first layer could be considered roughly durable in time, unlike the
second and third layers, which are architected in a flexible way for accepting
new services according to a plug-and-play modality.
E-broker basic infrastructure will be connected to the parties through a
secure Internet connection. Figure 82 shows the two E-broker functional
layers giving also prominence to the main components constituting each
layer. The figure depicts also the entities that have access to the E-broker
eMarketPlaces: traders (buyers and sellers) and E-broker partners (banks,
logistic companies, and so an) that can supply value-added services to the
trading community.
261
Community
Traders
E-broker
Partners
Internet
E-broker
Security
Access
Manager
Customer Support
Services
B2B Integration
Middleware
eMarketPlace
Information Portal
B2B Directory
Service
Contracts
Manager
Auctions
Service
Aggregation
Service
Basic
infrastructure
layer
B2C service
layer
B2B online
service layer
Figure 82. E-broker functional layers and main applications components
Basic infrastructure layer

This layer includes all those components that support the E-broker basic IT
infrastructure. Basic infrastructure layer components are the following:
Security
The security component supplies a set of standard level functionality
which protect E-broker infrastructure from unauthorized accesses coming
from Internet. It should handle a set of security issues such as, the firewall
protocol, intrusion protection, access control.
Access Manager
This component manage the Community Trader accesses to E-Broker. It
supplies the services to manage the traders access policy and their online
registration process as well as the trader profile.
262
B2B integration middleware

This is the runtime B2B integration middleware that will supply the
front-end door for accessing and interacting traders IT with the E-broker
services. This middleware will based on BPF/TPA.
B2C Basic service layer
This layer includes all those components that handle the specific brokerage
activities.
eMarketPlace Information Portal
The eMarketPlace Information Portal delivers specific market and
community news and analysis, general and personalized information, and
so on to the trader community.
Customer Support Services
This component aims to supply the necessary functionality to support and
facilitate through the Web the community traders in accessing to the
eMarketPlace. E-broker will play an active role in the eMarketPlace giving
not only technical support to the community members (for example,
through help desk or call center facilities), but also it will deliver specific
Market news and information.
B2B Basic service layer
This layer includes all those components that handle the specific brokerage
activities.
B2B Directory Service
This component handles the B2B advanced directory service business
model.
Auctions Service
This component handles the auctions business model.
Aggregation Service
This component handles the aggregation business model.
Contracts Manager
This component handles online contract authoring tools and standard
contract repository.
The following section provides a set of Patterns for e-business that can be
used to model the E-broker architecture.
263
7.3.4 E-broker application functional decomposition

This section analyzes the E-broker functionality by using the Pattern for
e-business modelling approach introduced in Chapter 4, Patterns for B2C
and B2B applications on page 107. In particular, we will follow a bottom-up
approach in analyzing E-broker functionality. First, we will identify the logical
Patterns for e-business (application topologies) for all basic E-broker
application services (E-broker access and directory service, auction service,
aggregation service, customer support services and so on) and customizing
these Patterns by obtaining a specific functional application decomposition.
Thus, we will merge all basic customized application topology patterns into a
general application topology which encompasses the whole E-broker
application. Finally, we will provide the runtime topology of the whole
E-broker application.
The following are the application topologies for all E-broker basic application
services.
E-broker access and directory service
This service can be modelled through the B2C Web-up topology 1. The
architecture provides, in this case, a Web Client which is used to build the
front-end application that supplies E-broker online subscribing facility,
directory browsing and remote TPA authoring tools. The Web Client
interacts with an application module that implements the Directory Service
business logic on the second tier. This last tier accesses, among other
things, to the Parties Profile database on which are maintained mostly of
the application data. Figure 83 shows the application topology diagram for
the E-broker access and directory service.
264
Client
E-broker tier
async/sync
Web Client
Directory
Service
Figure 83. Directory service: application topology
Auction service
Figure 84 shows the application topology diagram for the E-broker auction
service. The auction service is based on the Jointly Managed three-tier
B2B pattern. Traders interact with the E-broker by using executable
contracts which encode all business integration services related to the
auction processes. There are three kind of contracts that model the
interaction process between trader (buyer and seller) IT infrastructures
and the E-broker; one for each type of auction modality, although in the
figure, just a generic Auction Contract is shown. Contracts describe a set
of services that are available on both trader-side and on the E-broker-side.
E-broker auction services are arranged on an intermediary tier which is
connected with a back-end application that manages all auction services.
Connections between tiers can be synchronous or asynchronous.
265
Trader A
Auction
Executable
Contract
E-broker tier
Auction
Executable
Contract
Auction
Services
Trader B
Auction
Services
Auction
manager
Trader App
Auction
Services
1:N
sync
Auction
Executable
Contract
Auction
Executable
Contract
Auction
Services
N:1
sync
N:M
async
mutually agreed
msgs
Trader App
Figure 84. Auction service: application topology
Multiple RFQ aggregation service

Figure 85 shows the application topology diagram for the E-broker multiple
RFQ aggregation service. This service has been modelled by using a
combination of two B2B patterns: the Business Protocol Managed and the
Jointly Managed. The first pattern is used to model the buyer/E-broker
interaction (Partner A in the figure) and the second to model the
seller/E-broker interaction (Partner B in the figure). Also in this case
between E-broker and Traders holds an electronic contract which encodes
all business integration services related to the aggregation processes. The
E-broker aggregation service is arranged on an intermediary tier which is
connected with a back-end application that manages the aggregation
266
application. Connections between tiers can be synchronous or

asynchronous.
E-broker tier
Partner A
Buyer
App
N:1
async
mutually agreed
msgs
Aggregation
Executable
Contract
1:N
sync
Partner B
Post an
RFQ
N:M
async server-specified
msgs / sync
Aggregation
manager
1:N
sync
Aggregation
Executable
Contract
Aggregation
Executable
Contract
N:M
async
mutually agreed
msgs
N:1
sync
Aggregation
Services
1:N
sync
Seller
App
Figure 85. Aggregation service: application topology
eMarketPlace Information Portal and the Customer Support service

The eMarketPlace Information Portal and the Customer support service
are a set of components that facilitate the trading community to access the
E-broker services through the Web. E-broker plays an active role in the
eMarketPlace giving not only technical support to the community members
(for example, through help desk or call center facilities), but also it delivers
to the Traders personalized market news and information. The
architecture provides, in this case, a Web Client which is used to build the
front-end application for accessing to all customer support services. The
Web Client interacts with an application module that implements the
customer support services business logic on the second tier. This last tier
accesses, among other things to various databases on which are
maintained the application data. Figure 86 shows the application topology
diagram for the customer support services.
267
Client
E-broker tier
async/sync
Web Client
Customer
Support
Services
eMarketPlace
Information
Portal
Figure 86. Customer support service: application topology
Figure 87 shows the general application topology of E-broker. All application

topologies of the various E-broker services previously proposed have been
merged to form the E-broker application topology.
268
Trader
E-broker tier
Aggregation
Executable
Contract
Auction
Executable
Contract
Aggregation
Executable
Contract
Auction
Executable
Contract
Aggregation
Services
Auction
Services
Aggregation
Services
Auction
Services
Auction
manager
Aggregation
manager
1:N
sync
Trader App
N:1
sync
N:M
async
mutually agreed
msgs
Directory
Service
Web Client
Customer
Support
Services
eMarketPlace
Information
Portal
Figure 87. The application topology of E-broker
Figure 88 shows the runtime topology of E-broker.
269
Auction &
Aggregation
manager
and data
Directory
and
Security
Services
B2B
middleware
manger
Web
application
server
Protocol Firewall
Existing
applications
and data
Domain Firewall
internal network
Domain name
server
Web
Client
internal network
T
NE
ER
T
IN

Public key
infrastructure
Web
application
server
Web
application
server
Domain Firewall
Protocol Firewall
Trader
Directory
and
Security
Services
B2B
middleware
manger
Back-end
Customer
Support and
eMIP App
Auction &
Aggregation
manager
and data
E-Broker
Figure 88. Runtime topology of E-broker
Table 19 provides the product mapping between the E-broker runtime

topology nodes depicted in Figure 88 above. We found in the IBM catalogue
all necessary products fitting the E-broker IT infrastructure. Evidently, in
some cases, when a standard product is not available or it does not cover the
application requirements, a specific developing process is assumed.
Table 19. Product mappings for the E-broker runtime topology
270
Nodes
Products
B2B middleware manager
WebSphere B2B integrator

Specific Development

Nodes
Products
Domain name server
Non-applicable
eMarketPlace Information Portal (eMIP)
IBM Enterprise Information Portal

Lotus Notes
Customer Support Service
Tivoli Service Desk
B2B Services
Directory and security services
SecureWay Directory
Protocol firewall and domain firewall
secureWay Firewall
eNetworkFirewall 3.2
User
Web Browser
Web application server
IBM HTTP Server

WebSphere Application Server Advanced
Edition including among other things:
- XML Enabler
- Apache Cocoon
7.4 Initial E-broker design activities

The design and implementation of the E-broker project is well beyond the
purpose of this book it requires several months of work by application
domain and IT experts to be finished! In this section, we propose some initial
design activities, mainly concerned with the adoption of XML in modelling the
various E-broker services, that we believe are in line with the aims of this
book: to show in practical terms possible usages of XML in developing B2C
or and B2B applications.
As we have said, the usage of XML is pervasive in designing an e-business
application; thus, selecting which part of the project to design has been
difficult. Incidentally, we decided to show you the usage of XML under two
different, but also interrelated aspects: to write the E-broker access TPA
contracts that trading partners can use to access to the E-broker services,
and to project the data structure needed to implement the directory service.
271
7.4.1 E-broker access service TPAs

This section proposes some TPA models defining business transactions
between Traders and E-broker four basic TPA templates corresponding to
the four kinds of intermediation services supplied by E-broker:
Bulletin board auction

Regular auction
Reverse auction
Aggregation service
We describe the Business Protocol layer of each TPA, laying out details
concerning other TPA layers.
Bulletin board auction
E-broker services with the Seller acting as a client
Actions
Action 1.
Request Name:
postOffer
Request Message: postOfferMessage
Enable:
removeOffer
Action 2.
Request Name:
removeOffer
Request Message: removeOfferMessage
Response Name:
confirmOfferDeletion
Response Message: confirmOfferDeletionMessage
RequestName: postOffer
E-broker services with the Buyer acting as a client
Actions
Action 1.
Request Name:
postABid
Request Message: postAMessage
Response Name:
offerrDetails
Response Message: offerrDetailsMessage
Action 2.
Request Name:
requestNewOffers
Request Message: requestNewOffersMessage
Response Name:
newOffers
Response Message: newOffersMessage
RequestName: requestNewOffers
Buyer services with the E-broker acting as a client
Actions
Action 1.
272
Request Name:
requestForABid
Request Message: requestForBidAMessage
RequestName: requestForBid
Seller services with the Buyer acting as a client

Actions
Action 1.
Request Name:
purchaseOrder
Request Message: purchaseOrderMessage
Regular auction
Actions
Action 1.
Request Name:
postOffer
Request Message: postOfferMessage
Actions
Action 1.
Request Name:
postABid
Request Message: postAMessage
Response Name:
offerrDetails
Response Message: offerrDetailsMessage
Buyer services with the E-broker acting as a client
Actions
Action 1.
Request Name:
requestForABid
Actions
Action 1.
Request Name:
purchaseOrder
Reverse auction
Actions
Action 1.
Request Name:
postRequestOfPurchase
Request Message: postRequestOfPurchaseMessage
273
Actions
Action 1.
Request Name:
Request Message:
Response Name:
Response Message:
postABid
postAMessage
requestOfPurchaseDetails
requestOfPurchaseDetailsMessage
Seller services with the E-broker acting as a client

Actions
Action 1.
Request Name:
requestForABid
Buyer services with the Seller acting as a client
Actions
Action 1.
Request Name:
purchaseOrder
Aggregation Service
Actions
Action 1.
Request Name:
postAMultipleRFQ
Request Message: postAMultipleRFQMessage
Response Name:
QuotationsDetails
Response Message: QuotationsDetailsMessage
Seller services with the E-broker acting as a client
Actions
Action 1.
Request Name:
RFQ
Request Message: RFQMessage
Response Name:
QuotationDetails
Response Message: QuotationDetailsMessage
Actions
Action 1.
Request Name:
purchaseOrder
7.4.2 The directory service data model in DB2 XML Extender

The E-broker B2B directory service in principle is very similar to a well-known
Yellow Pages service. By using this service, buyers and sellers have the
274
chance to promote themselves in the eMarketPlace and, at the same time, to

expose the list of services and the types of contracts that they accept.
The E-broker directory service stores information about companies. This
information includes general data (name, address, contact persons, Web
address, and so on), and TPAs accepted by that company. For storing TPAs,
we used the standard Document Type Definition for TPA (tpa.dtd). We also
developed a sample DTD for storing general company-related information
(com_info.dtd), and business-related information (com_biz.dtd). The final
company DTD (eb_com.dtd) is a composition of these DTDs.
The following is a simple company information DTD:
<!ELEMENT CompanyInfo
(CompanyName,CompanyAbout+,ContactPerson+,Location+,InternetLocation+)>
<!ELEMENT CompanyName (FullName,ShortName+)>
<!ELEMENT ShortName (#PCDATA)>
<!ELEMENT FullName (#PCDATA)>
<!ELEMENT CompanyAbout (#PCDATA)>
<!ELEMENT ContactPerson (PersonName,EMail+,ContactInfo?)>
<!ELEMENT PersonName (#PCDATA)>
<!ELEMENT ContactInfo (#PCDATA)>
<!ELEMENT Location (Street,City,State?,Country,ZIP)>
<!ELEMENT Street (#PCDATA)>
<!ELEMENT ZIP (#PCDATA)>
<!ELEMENT InternetLocation (WebAddress?,EMail?)>
<!ELEMENT WebAddress (#PCDATA)>
The next DTD describes a companys TPA collection and usual TPA subparts:
<!ELEMENT BusinessProfile (TPASubparts,TPACollection)>
<!ENTITY % TPA SYSTEM "c:\db2\xml\samples\ebroker\tpa.dtd">
<!ELEMENT TPASubparts (TPA)+>
<!ELEMENT TPACollection (TPA)+>
%TPA;
The final company DTD is the following coding:

<!ELEMENT Company (CompanyInfo,BusinessProfile)>
<!ATTLIST Company
identifier ID #REQUIRED
>
<!ENTITY % BusinessProfile SYSTEM
"c:\db2\xml\samples\ebroker\com_biz.dtd">
<!ENTITY % CompanyInfo SYSTEM "c:\db2\xml\samples\ebroker\com_info.dtd">
%BusinessProfile;
%CompanyInfo;
275
Company data can be described in XML format using these DTDs. The
following listing shows the first part of a simple company XML file:
<?xml version='1.0'?>
<!DOCTYPE Company SYSTEM "C:\db2\xml\samples\ebroker\eb_com.dtd">
<Company identifier="a0">
<CompanyInfo>
<CompanyName>
<FullName>Almaden Mining Co.</FullName>
<ShortName>AMC</ShortName>
<ShortName>AlMine</ShortName>
</CompanyName>
<CompanyAbout>This is a sample company for E-broker</CompanyAbout>
<ContactPerson>
<PersonName>Mr. Pres Ident</PersonName>
<EMail Type="primary">president@amc.com</EMail>
<EMail Type="secondary">pre@mail.com</EMail>
<ContactInfo>President of AMC</ContactInfo>
</ContactPerson>
<Location>
<Street>203 Almaden Expressway</Street>
<City>San Jose</City>
<State>CA</State>
<Country>US</Country>
<ZIP>95120</ZIP>
</Location>
<InternetLocation>
<WebAddress>http://www.amc.com</WebAddress>
<EMail Type="primary">mail@amc.co</EMail>
</InternetLocation>
</CompanyInfo>
<BusinessProfile>
<TPASubparts>
<TPA>
...
</TPA>
</TPASubparts>
<TPACollection>
<TPA>
...
</TPA>
<TPA>
...
</TPA>
</TPACollection>
</BusinessProfile>
</Company>
276
To store XML files in DB2 Universal Database, we utilize the XML Extender
interface. We developed a simple database model that reflects the
information described in these DTDs. This model is the EB_DB database
(Figure 89).
E-broker database: EB_DB
company_tab
company information
name
address
contact persons
...
tpa_side_tab
tpa_tab
TPA information
complete TPAs
TPA elements
Figure 89. Simple database model of a company
The EB_DB has three main tables to describe companies and their TPAs.
The company_tab contains basic information about a company. This
information is defined by the com_info.dtd. This table contains data in a
database-centered way that helps in using this information for non-XML
applications. The tpa_tab table contains complete TPA documents (XML
documents), while the tpa_side_tab contains some elements from TPA
documents.
To establish the mapping between the XML data and database entries, we
specified document access definition (DAD) files. There are two different
ways of storing XML data in DB2 using the XML Extender: we can store
complete XML files, or we can associate database elements with XML data.
Basic information about a company could also be useful for other
applications, therefore we store this data in database columns in the
company_tab table, and compose the XML files from these tables. This is
called an XML collection. XML collections are useful when the data is
accessed both using XML and database techniques, and it is stored in
several database tables.
277
TPAs, on the other hand, are used as entities, and can be stored intact in
DB2 tables. This is the XML column storage method. XML columns work well
for archiving XML documents. Elements and attributes of these XML
documents can also be mapped to database tables (so called side tables) to
help indexing and structural search. We defined a tpa_side_tab table for this
purpose.
To set up the DB2 XML Extender, we followed the steps described in the DB2
XML Extender Administration and Programming guide (Version 7), Chapter 2,
Getting started with XML Extender.
The following sample shows a part of the DAD file that describes the relation
between XML documents based on com_info.dtd and database table
company_tab.
<?xml version="1.0"?>
<!DOCTYPE DAD SYSTEM "c:\db2/xml/dtd/dad.dtd">
<DAD>
<validation>NO</validation>
<Xcollection>
<SQL_stmt>SELECT company_name, key FROM company_tab</SQL_stmt>
<prolog>?xml version="1.0"?</prolog>
<doctype>!DOCTYPE CompanyInfo SYSTEM
"c:\db2\xml\samples\ebroker\com_info.dtd"
</doctype>
<root_node>
<element_node name="CompanyInfo">
<attribute_node name="key">
<column name="key"/>
</attribute_node>
<element_node name="CompanyName">
<element_node name="FullName">
<text_node><colum name="CompanyName"/></text_node>
</element_node>
...
</element_node>
...
</element_node>
</root_node>
</XCollection>
</DAD>
The following DAD file describes the relation between TPA elements and the
tpa_side_tab table.
278
<!DOCTYPE DAD SYSTEM "c:\db2/xml/dtd/dad.dtd">
<DAD>
<dtdid>c:\db2/xml/samples/ebroker/tpa.dtd</dtdid>
<validation>YES</validation>
<Xcolumn>
<table name="tpa_side_tab">
<column name="tpa_party"
type="varchar(80)"
path="/TPA/TPAInfo/Participants/Member/PartyName"
multi_occurence="NO"/>
</table>
</Xcolumn>
</DAD>
7.5 Summary
In this chapter we presented a short overview of the B2B eMarketPlace
intermediation field and outlined a new project case study, called E-broker, in
this particular domain. We selected the B2B eMarketPlace intermediation
field since it encompasses and, at the same time, extends all traditional B2B
(but also B2C) related issues.
B2B eMarketPlace applications offer many interesting aspects to analyze and
discuss from both the project and the design point of view, as well as what
affects the role that XML plays in these types of systems. In particular, this
type of application helps you understand in practical terms many more
elements in applying XML than simply analyzing a traditional B2B or B2C
application example. B2B eMarketPlace intermediaries are strongly emerging
in the B2B market to complement and empower the traditional B2B model
centered around the buyer-seller transaction paradigm. B2B eMarketPlace
intermediaries mediate among buyers and sellers by facilitating the business
transaction process and, in some cases, by supplying value-added function to
the business transaction chain.
The chapter ends with the description of some design activities of the
E-broker project.
279
280
Appendix A. An example of a OBI TPA XML document

This appendix proposes the full OBI TPA XML document between the Large
Co and Pens We Are companies, as generated by the IBM XML Visual
Builder tool. It was developed in Section 6.2.4, Using the IBM Visual XML
Builder for a specific OBI TPA on page 216 .
A.1 The OBI TPA between Large Co and Pens We Are

<!DOCTYPE TPA SYSTEM "C:\IBMXMLTools\samples\TPA\tpa.dtd">
<TPA xmlns="tpa.xsd">
<TPAInfo>
<TPAName>
OBITPA
</TPAName>
<TPAType>
<Protocol>
OBI
</Protocol>
<Version>
1.0
</Version>
<Type>
SS
</Type>
</TPAType>
<Participants>
<Member MemberId="MemberId17" IdCodeType="ZZ">
<PartyName Partyname="LargeCo">
</PartyName>
<CompanyTelephone>
914-945-3000
</CompanyTelephone>
<Address>
<AddressType>
location
</AddressType>
<AddressLine>
Large Co
</AddressLine>
<AddressLine>
HQ Building
</AddressLine>
281
<AddressLine>
1 Main Street
</AddressLine>
<City>
SmallTown
</City>
<State>
NY
</State>
<Zip>
10000
</Zip>
<Country>
USA
</Country>
</Address>
<Address>
<AddressType>
billing
</AddressType>
<AddressLine>
Large Co
</AddressLine>
<AddressLine>
Accounting Department
</AddressLine>
<AddressLine>
100 Bean Counters Road
</AddressLine>
<City>
Any City
</City>
<State>
CT
</State>
<Zip>
06000
</Zip>
<Country>
USA
</Country>
</Address>
<Address>
<AddressType>
shipping
</AddressType>
<AddressLine>
282
Large Co
</AddressLine>
<AddressLine>
Procurement Department
</AddressLine>
<AddressLine>
99 Purchase Road
</AddressLine>
<City>
Buy City
</City>
<State>
NY
</State>
<Zip>
10001
</Zip>
<Country>
USA
</Country>
</Address>
<Contact Type="primary">
<LastName>
Smith
</LastName>
<FirstName>
John
</FirstName>
<MiddleName>
L.
</MiddleName>
<Title>
Mr
</Title>
<ContactTelephone Type="primary">
914-111-6789
</ContactTelephone>
914-111-6790
</ContactTelephone>
<EMail Type="primary">
jjsmith@largeco.com
</EMail>
<Fax>
914-111-6780
</Fax>
</Contact>
283
<LastName>
Blow
</LastName>
<FirstName>
Joe
</FirstName>
<MiddleName>
J.
</MiddleName>
<Title>
Buyer
</Title>
914-111-6722
</ContactTelephone>
jblow@largeco.com
</EMail>
<Fax>
914-111-6780
</Fax>
</Contact>
</Member>
<Member MemberId="MemberId18" IdCodeType="ZZ">
<PartyName Partyname="PensWeAre">
</PartyName>
<CompanyTelephone>
945-123-1000
</CompanyTelephone>
<Address>
<AddressType>
location
</AddressType>
<AddressLine>
Pens Are We
</AddressLine>
<AddressLine>
Building 001
</AddressLine>
<AddressLine>
123 High Street
</AddressLine>
<City>
EarthQuake City
</City>
284
<State>
CA
</State>
<Zip>
94567
</Zip>
<Country>
USA
</Country>
</Address>
<LastName>
Doe
</LastName>
<FirstName>
Jane
</FirstName>
<MiddleName>
E.
</MiddleName>
<Title>
Vice President of Internet Sales
</Title>
945-123-4567
</ContactTelephone>
janedoe@pensarewe.com
</EMail>
<Fax>
945-123-9999
</Fax>
</Contact>
</Member>
<Arbitrator MemberId="attr3" IdCodeType="attr4">
<PartyName Partyname="XYZArbitrator">
</PartyName>
<CompanyTelephone>
780-333-1111
</CompanyTelephone>
<Address>
<AddressType>
XYZArbitrator
</AddressType>
<AddressLine>
Suite 3
285
</AddressLine>
<AddressLine>
77 Lawyers Blvd
</AddressLine>
<City>
ABC City
</City>
<State>
MA
</State>
<Zip>
01234
</Zip>
<Country>
USA
</Country>
</Address>
<LastName>
Black
</LastName>
<FirstName>
Joe
</FirstName>
<MiddleName>
K.
</MiddleName>
<Title>
</Title>
780-333-4040
</ContactTelephone>
jblack@xyzarbitrator.com
</EMail>
<Fax>
780-333-5000
</Fax>
</Contact>
</Arbitrator>
</Participants>
<Duration>
<Start>
<Date>
April 6, 2000
</Date>
<Time>
286
00:00:00
</Time>
</Start>
<End>
<Date>
April 6, 2001
</Date>
<Time>
00:00:00
</Time>
</End>
</Duration>
<InvocationLimit>
1000000
</InvocationLimit>
<ConcurrentConversations>
1
</ConcurrentConversations>
<ConversationLife>
86400
</ConversationLife>
</TPAInfo>
<Transport>
<Communication>
<HTTP>
<HTTPNode>
<OrgName Partyname="LargeCo">
</OrgName>
<HTTPAddress>
<URL URLName="requestURL">
https://www.largeco.com/jackal/servlet/OBIBuy
</URL>
</HTTPAddress>
</HTTPNode>
<HTTPNode>
<OrgName Partyname="PensWeAre">
</OrgName>
<HTTPAddress>
<URL URLName="logOnURL">
https://www.pensarewe.com/coyote/servlet/OBILogon
</URL>
<URL URLName="requestURL">
</URL>
<URL URLName="responseURL">
287
</URL>
</HTTPAddress>
</HTTPNode>
<NetworkDelay>
300
</NetworkDelay>
</HTTP>
</Communication>
<TransportSecurity>
<Encryption>
<Protocol>
SSL
</Protocol>
<Version>
3.0
</Version>
<Certificate>
<CertType>
X509.V3
</CertType>
<KeyLength>
1024
</KeyLength>
<Party>
</OrgName>
<IssuerOrgName>
VeriSign, Inc.
</IssuerOrgName>
<IssuerCertSource>
http://www.verisign.com/certs
</IssuerCertSource>
</Party>
<Party>
</OrgName>
<IssuerOrgName>
GTE, Inc.
</IssuerOrgName>
<IssuerCertSource>
http://www.gte.com/certs
</IssuerCertSource>
</Party>
</Certificate>
288
</Encryption>
<Authentication>
<CertificateAuthen>
<Protocol>
SSL
</Protocol>
<Version>
3.0
</Version>
<Certificate>
<CertType>
X509.V3
</CertType>
<KeyLength>
1024
</KeyLength>
<Party>
</OrgName>
<OrgCertSource>
</OrgCertSource>
<IssuerOrgName>
VeriSign, Inc.
</IssuerOrgName>
<IssuerCertSource>
</IssuerCertSource>
</Party>
<Party>
</OrgName>
<OrgCertSource>
</OrgCertSource>
<IssuerOrgName>
GTE, Inc.
</IssuerOrgName>
<IssuerCertSource>
</IssuerCertSource>
</Party>
</Certificate>
</CertificateAuthen>
</Authentication>
289
</TransportSecurity>
</Transport>
<DocExchange>
<DocExchangeProtocol>
OBI
</DocExchangeProtocol>
<MessageEncoding>
BASE64
</MessageEncoding>
<MessageIdempotency>
yes
</MessageIdempotency>
<MessageSecurity>
<NonRepudiation>
<Protocol>
Digital Signature
</Protocol>
<HashFunction>
D5
</HashFunction>
<EncryptionAlgorithm>
RSA
</EncryptionAlgorithm>
<SignatureAlgorithm>
DSA
</SignatureAlgorithm>
<Certificate>
<CertType>
X509.V3
</CertType>
<KeyLength>
1024
</KeyLength>
<Party>
</OrgName>
<IssuerOrgName>
VeriSign, Inc.
</IssuerOrgName>
<IssuerCertSource>
</IssuerCertSource>
</Party>
<Party>
290
</OrgName>
<IssuerOrgName>
GTE, Inc.
</IssuerOrgName>
<IssuerCertSource>
</IssuerCertSource>
</Party>
</Certificate>
</NonRepudiation>
</MessageSecurity>
</DocExchange>
<BusinessProtocol>
<ServiceInterface InterfaceId="attr6">
</OrgName>
<Client>
</OrgName>
</Client>
<ActionMenu>
<Action ActionId="attr7" Type="basic"
Invocation="asyncOnly">
<Request>
<RequestName>
putOPOR
</RequestName>
<RequestMessage>
OBIPOR
</RequestMessage>
</Request>
<Response>
<ResponseName>
getOPO
</ResponseName>
<ResponseMessage>
OBIPO
</ResponseMessage>
</Response>
</Action>
</ActionMenu>
<ServerServiceTime>
<ServiceTime>
3600s
</ServiceTime>
291
<Presume>
fail
</Presume>
<StartEnabled>
<RequestName>
putOPOR
</RequestName>
</StartEnabled>
</ServiceInterface>
<ServiceInterface InterfaceId="attr17">
</OrgName>
<Client>
</OrgName>
</Client>
<ActionMenu>
<Request>
<RequestName>
shop
</RequestName>
<RequestMessage>
shopMessage
</RequestMessage>
</Request>
</Action>
<Request>
<RequestName>
putOPO
</RequestName>
<RequestMessage>
OBIPO
</RequestMessage>
</Request>
</Action>
</ActionMenu>
<ServerServiceTime>
<ServiceTime>
3600
</ServiceTime>
292
<Presume>
fail
</Presume>
</ServiceInterface>
</BusinessProtocol>
</TPA>
293
294
Appendix B. Using the additional material

This redbook also contains additional material in CD-ROM or diskette format,
and/or Web material. See the appropriate section below for instructions on
using or downloading each type of material.
B.1 Locating the additional material on the Internet

The material associated with this redbook is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246104
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redbook form number.
B.2 Using the Web material

The additional Web material that accompanies this redbook includes the
following:
File name
SG246104.zip
Description
Zipped Code Samples
Files contained in the zip file:

com_biz.dad Document Access Definition file for com_biz.dtd
com_biz.dtd E-broker company business information DTD
com_info.dad Document Access Definition file for com_info.dtd
com_info.dtd E-broker company general information DTD
db2_prep.cmd preparing DB2 and XML extender for demonstration
eb_com.dtd E-broker company DTD
eb_sam.xml a sample company file
295
eb_sam.xml a skeleton company file

tpa.dtd TPA DTD
tpa.dtd.xmi XMI model of TPA DTD
OBITPA.xml the OBI TPA between Large Co and Pens we Are companies
proposed in chapter 6
OBITPA.dtd.xmi XML model of the OBI TPA between Large Co and Pens We
Are companies proposed in chapter 6
B.2.1 How to use the Web material

Create a subdirectory (folder) on your workstation and copy the contents of
the Web material into this folder.
296
Appendix C. Special notices

This publication is intended to help technical professionals who are involved
in the design of B2B and B2C applications using XML.The information in this
publication is not intended as the specification of any programming interfaces
that are discussed in this document. See the PUBLICATIONS section of the
IBM Programming Announcement for any IBM products mentioned in this
document for more information about what publications are considered to be
product documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBM's product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBM's
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the
equipment specified, and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the IBM
Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY
10504-1785.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and
conditions, including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been
reviewed by IBM for accuracy in a specific situation, there is no guarantee
that the same or similar results will be obtained elsewhere. Customers
297
attempting to adapt these techniques to their own environments do so at their

own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
400
AIX
AlphaWorks
AS/400
AT
CICS
Cross-SIte
CT
Current
DB2
DB2 Extenders
DB2 OLAP Server
DB2 Universal Database
DirectDOM
Domino
EDMSuite
IBM
IBM Global Network
ImagePlus
Intelligent Miner
KnowledgeX
Learning Space
Lotus
Lotus Notes
Lotus SmartSuite
Manage, Anything, Anywhere

MQSeries
Net.Data
Netfinity
NetView
Notes
OS/2
OS/390
Quickplace
RS/6000
S/390
SecureWay
SmartSuite
SP
System/390
TeamConnection
Tivoli
Tivoli Certified
Tivoli Ready
TME
Visual Warehouse
VisualAge
VisualInfo
WebSphere
Wizard
Redbooks
Redbooks Logo
The following terms are trademarks of other companies:

Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.
Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet
Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli
Systems Inc., an IBM company, in the United States, other countries, or both.
In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli
A/S.
298
C-bus is a trademark of Corollary, Inc. in the United States and/or other

countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United
States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries
licensed exclusively through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks
owned by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service
marks of others.
Appendix C. Special notices
299
300
Appendix D. Related publications

The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
D.1 IBM Redbooks

For information on ordering these publications see How to get IBM
Redbooks on page 305.
The XML Files: Using XML and XSL with IBM WebSphere V3.0,
SG24-5479
Patterns for e-business: User-to-Business Patterns for Topology 1 and 2
using WebSphere Advanced Edition, SG24-5864
WebSphere Application Servers: Standard and Advanced Editions,
SG24-5460
IBM WebSphere and VisualAge for Java Database Integration with DB2,
Oracle, and SQL Server, SG24-5471
Developing an e-Business Application for the IBM WebSphere Application
Server, SG24-5423
Enterprise JavaBeans Development using VisualAge for Java , SG24-5429
VisualAge for Java Enterprise Version 2: Data Access Beans - Servlets CICS Connector, SG24-5265
Using VisualAge for Java Enterprise Edition Version 2 to Develop CORBA
EJB Applications, SG24-5276
Programming with VisualAge for Java Version 2, SG24-5264
IBM WebSphere Performance Pack Usage and Administration,
SG24-5233
Connecting the Enterprise to the Internet with MQSeries and Visual Age
for Java, SG24-2144
301
D.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at ibm.com/redbooks for information about all the CD-ROMs offered,
updates and formats.
CD-ROM Title
Collection Kit
Number
IBM System/390 Redbooks Collection
SK2T-2177
IBM Networking Redbooks Collection
SK2T-6022
IBM Transaction Processing and Data Management Redbooks CollectionSK2T-8038
IBM Lotus Redbooks Collection
SK2T-8039
Tivoli Redbooks Collection
SK2T-8044
IBM AS/400 Redbooks Collection
SK2T-2849
IBM Netfinity Hardware and Software Redbooks Collection
SK2T-8046
IBM RS/6000 Redbooks Collection (PDF Format)
SK2T-8043
IBM Application Development Redbooks Collection
SK2T-8037
IBM Enterprise Storage and Systems Management Solutions
SK3T-3694
D.3 Referenced Web sites

These Web sites are also relevant as further information sources:
http://www.ibm.com/redbooks
http://www.ibm.com/e-business
http://www.w3.org/TR/xhtml1
http://www.oasis-open.org/cover/cpex.html
http://www.hytime.org
http://www.jclark.com/dsssl
http://www.unicode.org
http://www.ibm.com/developer/xml
http://www.commercenet.com
http://www.oasis-open.org
http://www.pyxie.org
http://www.openapplications.org
http://www.opentravel.com
http://www.rosettanet.org
http://www.biztalk.org
http://www.w3.org/TR/xmlquery-req
302
http://www.w3.org/TR/NOTE-xml-ql
http://www.w3.org/Style/XSL/Group/1998/09/XQL-proposal.h
http://www.w3.org/Mobile/Activity
http://www.w3.org/TR/wbxml
http://www.wapforum.org
http://www.w3.org/RDF
http://www.w3.org/PICS
http://www.research.ibm.com/journal/sj38-1.html
http://www.unece.org/cefact
http://www.ebxml.org
http://java.sun.com/products/jsp/index.html
http://www.apache.org
http://www.voicexml.org
http://xml.apache.org
http://www.alphaworks.ibm.com/tech/DAV4J
http://www.ietf.org
http://www.w3.org/TR/NOTE-CCPP
http://www.patents.ibm.com
http://www.otp.org
http://www.ibm.com/software/data/net.data
http://www.ofx.net
http://www.developer.ibm.com
http://www.w3.org/TR/NOTE-ice
http://www.xmledi.com
http://www.openbuy.org
http://www.commerceone.com/xml/cbl
http://www.cxml.org
http://www.dsml.org
http://www.commerce.net
http://www.i2.com
http://www.ariba.com
http://www.xml.org
http://www.xml.org/xmlorg_registry/index.shtml
Appendix D. Related publications
303
http://www.xml.org/xmlorg_resources
http://www.gte.com
http://www.verisign.com
http://www.dmtf.org
http://www.amc.com
http://w3.itso.ibm.com
http://w3.ibm.com
http://www.elink.ibmlink.ibm.com/pbl/pbl
304
How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
Redbooks Web Site ibm.com/redbooks
Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site.
Also read redpieces and download additional materials (code samples or diskette/CD-ROM images)
from this Redbooks site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
E-mail Orders
Send orders by e-mail including information from the IBM Redbooks fax order form to:
In United States
Outside North America
e-mail address
pubscan@us.ibm.com
Contact information is in the How to Order section at this site:
Telephone Orders
United States (toll free)
Canada (toll free)
1-800-879-2755
1-800-IBM-4YOU
Country coordinator phone number is in the How to Order
section at this site:
Fax Orders
United States (toll free)
Canada
1-800-445-9269
1-403-267-4455
Fax phone number is in the How to Order section at this site:
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the Redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and Redbooks by accessing
the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.
Look in the Materials repository for workshops, presentations, papers, and Web pages developed
and written by the ITSO technical professionals; click the Additional Materials button. Employees
may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
305
IBM Redbooks fax order form

Please send me the following:
Title
Order Number
First name
Quantity
Last name
Company
Address
City
Postal code
Country
Telephone number
Telefax number
VAT number
Card issued to
Signature
Invoice to customer number

Credit card number
Credit card expiration date
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
306
Glossary
Application Service Provider (ASP) An ASP is
an agent or broker that aggregates, facilitates
and brokers IT services to deliver IT-enabled
business solutions across a network via
subscription-based pricing.
attribute In XML, a name="value" pair that can
be placed in the start tag of an element. The
value must be quoted with single or double
quotes.
Cascading Style Sheet (CSS) CSS defines a
stylesheet language for HTML 4.0. CSS allows
a Web page designer to separately specify style
elements of a Web page, such as colors, fonts
and font styles.
case-sensitive Indicates whether an
application, processor, or operating system
distinguishes between upper and lower case. If
it does, it is case-sensitive. XML tags are
case-sensitive, but HTML tags are not.
Customer relationship management (CRM)
CRM includes the systems and infrastructure
required to analyze, capture and share all parts
of the customers relationship with the
enterprise. From a strategy perspective, it
represents a process to measure and allocate
organizational resources to those activities that
have the greatest return and impact on
profitable customer relationships.
content model In XML, the expression
specifying what elements and data are allowed
within an element.
Document Object Model ( DOM) This allows
the representation and manipulation of an XML
document in memory as a programming object.
DOM is defined by the World-Wide Web
Consortium.
DOM (see Document Object Model).
DOM Tree A DOM Tree is an in-memory
representation of an XML Document.
Document Type Definition (DTD) A DTD is a
definition of which Elements and Attributes are
acceptable in a specific XML file. The DTD
therefore defines a subset of XML which may be

used for a particular application.
EBNF Extended Backus-Naur Form. A formal

set of production rules that comprise a grammar
defining another language, such as XML.
Electronic data interchange The automatic
machine-to-machine transfer of trading
documents (e.g., invoices and purchase orders)
using electronic networks such as the internet.
Originally conducted only through value-added
networks, EDI is gradually moving to the
Internet.
element In XML, a start tag and its end tag, plus
the content between the tags. An empty tag is
also an element.
empty declaration In XML, the DTD declaration
for an empty tag. For example, if <foo/> is an
empty tag, the empty declaration looks like:
<!ELEMENT foo EMPTY>.
empty tag In XML, a start and end tag
combined in one tag. The tag has a trailing
slash, so an XML parser can immediately
recognize it as an empty tag and not bother
looking for a matching end tag. For example, if
foo is an empty tag, it looks like <foo/>.
entity In XML, an entity declaration provides the
ability to have constants or replacement strings,
which are expanded by a pre-processor. An
entity declaration maps some token to a
replacement string. Later the token can be
prefixed with the & character and the
replacement string is put in its place.
Enterprise JavaBeans (EJB) The Enterprise
JavaBeans specification defines a way of
building transactionally aware business objects
in Java.
Java Server Page (JSP) Java Server Pages
are Web pages that include dynamic tags which
are executed on the server. JSPs are the
presentation layer for Web-based applications
built in Java.
307
Servlets Servlets are Java objects which execute

on the server in response to a browser request.
They can either generate HTML or XML directly,
or call a JSP to produce the output.
Supply Chain Management (SCM) The process
of optimizing delivery of goods, services and
information from supplier to customer. SCM is a
set of business processes that incorporate a
trading-partner community engaged in a common
goal of satisfying the end customer.DTD.
Trading Communities Trading communities
bring together buyers and sellers in a central
online location to trade, using various online
mechanisms including auctions and exchanges,
in addition to industry content and application
services. Trading communities are owned and
operated by both large industry players in closed
trading networks and by neutral parties in more
fragmented open communities.
TAB, NEWLINE, and CARRIAGE-RETURN

characters.
XSL Stylesheet The eXtensible Stylesheet

Language defines stylesheets for XML
Documents. It is composed of two parts: the
formatting objects, and XSLT (see below). XSL is
defined by the WorldWide Web Consortium.
XSLT eXtensible Stylesheet Language
Transformations This defines the part of the
XSL specification which allows the stylesheet to
reformat and reorganize the XML data. It is most
often used to transform XML into XSL.
URI/URL A Uniform Resource Identifier (URI)

and Uniform Resource Locator (URL) uniquely
defines a location on the Web. URLs are familiar
to anyone who browses the Web (for example
http://www.ibm.com), and the term URI is a
more general term which also incorporates other
schemes for identifying resources.
valid An XML document is valid if its content
conforms to the rules in its DTD.
WAP Wireless Application Protocol. Offers
internet browsing from wireless handsets
Web Application A WebSphere Web application
is a collection of static pages, JSPs and Servlets
that share a common URL prefix, and together
make a complete application.
well-formed An XML document is well-formed if
there is one root element, and all its child
elements are properly nested within each other.
Start tags must have end tags, and each empty
tag must be designated as such with a trailing
slash. Also, all attributes must be quoted, and all
entities must be declared.
white-space In XML, characters that are not
visible, but used in formatting documents or
programs. These characters include the SPACE,
308
Index
A
Aggregation 245
Application Framework for e-business 179
Application Service Providers 246
Auctions 245
B
B2B online intermediary 239
B2B server 190
B2B XML framework 177
B2C 139
B2C application model 140
Back end servers 141
BizTalk 30, 183
BPF 177, 204
BPF components 208
business integration 177
Business-to-business Protocol Framework 177,
184, 204, 208
business-to-consumer 139
Business-to-customer 139
business-to-employee 145
C
CC/PP 23, 160
client pull 143
Collaborative portal 146
Commerce Extensible Markup Language 160
Commerce XML (cXML) 182, 205
CommerceNet 30
Common Business Library 159
Composite Capability/Preference Profiles 23, 160
content generation 153
Content management 148
CORBA 179
CPEX 156
Customer Profile Exchange 156
Customization 158
cXML 160
Distributed Management Task Force 182

Document Object Model 27
Document Style Semantics and Specification Language 24
Document Type Definition 21
document type definition 18
Document Type Definitions 21
DOM 27, 28, 29
DOM Level 2 28
DOM Level1 28
DSML 155
DSSSL 24, 29
DTD 18, 21, 22
DTD repositories 22
Dublin Core 22
E
ebXML project 182
eCo Specification 183
e-commerce 139, 157
e-commerce portal 146
electronic commerce 139
Electronic Data Interchange 181
electronic retail 139, 157
eMarketPlace 239, 241
eMarketPlace Information Portal 267
eMarketPlaces 241
Enterprise Java Beans 179, 212
Enterprise portal 144
enterprise portal 156
Enterprise Portals 11, 110
e-retail 139, 157
Exchange 245
Extensible HyperText Markup Language 23
Extensible Markup Language 17
Extensible Style Language 24, 260
F
Front end servers 141
G
D
DB2 XML Extender 29
developerWorks portal 165
Directory Services Markup Language 155
Generalized Markup Language 16

GML 16
309
H
HTML 16, 17, 19
HTTP 16, 196
Hypertext Markup Language 17
HyTime 29
I
IBM Content Manager 167
IBM Enterprise Information Portal 166
IBM Intellectual Property Network 164
IBM Visual XML Builder 216
IBM WebSphere B2B Integrat 177
IBM XML Parser for Java 26
IBM XML Tools 217
ICE 159
Information and Content Exchange 159
Information portal 145
International Standards Organization 29
ISO 29
J
Java API for XML Parsing 29
JAXP 29
Open Buying on the Internet 23, 159, 212

Open Buying on the internet 205
Open Buying on the Internet (OBI) 202
Open Financial Exchange 159
Open Trading Protocol 159
Open Travel Alliance 23
Organization for the Advancement of Structured Information Standards 30
OTP 159
P
P3P 159, 258
PDA 160
personal digital assistans 160
Personalization 149, 152
PICS 22
PIX 158
Platform for Internet Content Selection 22, 258
Platform for Privacy Preferences Project 159, 258
Product Information Exchange 158, 259
Pyxie 29
Q
Query reporting 156
K
knowledge management 168
Knowledge portal 145
L
Lotus Raven 168
M
markup language 18
MathML 30
Metadata 21, 156
MQSeries 196
R
RDF 22, 158
RDF Schema 22
RDF Schemas 22
Resource Description Framework 19, 22, 158
RosettaNet 23, 159, 183
Namespaces 30
Net.Commerce 160, 172
SAX 26, 28
SAX API 26
search engine 19
server push 143
SGML 17, 29
Simple API for XML 26
SMTP 196
Standard Generalized Markup Language 16
OASIS 30, 182, 185

OBI 159
OFX 159
Open Applications Group 23, 183
tag 18
TPA 177
tpaML 23, 184, 185, 190
Trading Partner Agreement Markup Language 185
310
Trading Partner Agreement markup language 23

Trading Partner Agreements 177, 184
Transcoding 172
transcoding 24
U
UML 157
UN/CEFACT 182
Unicode 29
Unified Modeling Language 157
Uniform Resource Identifier 20
Uniform Resource Locator 20
Unit of Business 185
unit of business 188
URI 20
URL 20
User profile 154
user profile 152
User to Business 139
V
VAN-EDI 197
W3C 17, 19, 29

W3C Mobile Access Activity 161
W3C Technical Reports 20
WAE 24, 160
WAP 25, 160
WAP Binary XML Content Format 24
WAP Forum 160
WBXML 24
Web portal 143
WebSphere 25, 171
WebSphere B2B Integrator 184
WebSphere Commerce Studio 172
WebSphere Commerce Suite 160, 172
WebSphere Studio 174
WebSphere Transcoding 25
WebSphere Transcoding Publisher 172
WebSphere User Profile 173
Wireless Application Environment 24, 160
Wireless Application Protocol 160, 260
Wireless Markup Language 24, 260
Wireless Telephony Application Specification 24
WML 24
WMLScript 24
World Wide Web Consortium 17, 29
X
xCBL 159
Xerces 26
XHTML 23, 161
XLink 20, 150
XLinks 162
XMI 156, 158, 217
XML 17, 18 , 19, 30
XML B2B framework 181
XML DTD 162
XML Enabler 163
XML Fragments 162
XML Linking Language 20
XML Metadata Interchange 156 , 158
XML Namespaces 21, 22, 28
XML parser 25
XML Path Language 21
XML Pointer Language 21
XML Query Tools 150
XML Schema 21
XML.ORG 185
XML.org 182
XML/EDI 159
XML/EDI Group 183
XPath 21, 30, 150
XPointer 21, 150
XPointers 162
XSL 24, 30, 150, 155, 162, 260
XSL stylesheet 24
XSL stylesheets 162
XSL Transformations 24
XSLT 24, 150, 155
311
312
IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where a
Redbook "made the difference" in a task or problem you encountered. Using one of the following
methods, please review the Redbook, addressing value, subject matter, structure, depth and
quality as appropriate.
Use the online Contact us review redbook form found at ibm.com/redbooks
Fax this form to: USA International Access Code + 1 914 432 8264
Send your comments in an Internet note to redbook@us.ibm.com
Document Number
Redbook Title
SG24-6104-00
The XML Files: Using XML for Business-to-Business and
Business-to-Consumer Applications
Review
What other subjects would you

like to see IBM Redbooks
address?
Please rate your overall

satisfaction:
O Very Good
Please identify yourself as

belonging to one of the
following groups:
O Customer
O Business Partner
O IBM, Lotus or Tivoli Employee
O None of the above
Your email address:

The data you provide here may
be used to provide you with
information from IBM or our
business partners about our
products, services or activities.
O Please do not use the information collected here for future

marketing or promotional contacts or other communications beyond
the scope of this transaction.
Questions about IBMs privacy

policy?
The following link explains how we protect your personal information.

ibm.com/privacy/yourprivacy/
O Good
O Average
O Poor
O Solution Developer
313
(0.5 spine)
0.475<->0.875
250 <-> 459 pages
The XML Files:

and Business-to-Consumer
Applications
XML in IBMs
Application
Framework for
e-business
Patterns for B2B and
B2C Applications
Learn about
TPA-Trading Partner
Agreements
By reading this IBM Redbook, customers, IBM sales people, IT

architects, and IT specialists will have the opportunity to
understand how the marriage between XML technology and
the IBM Application Framework for e-business can help to
leverage e-business applications, particularly those based on
business-to-business (B2B), and business-to-consumer
(B2C) models.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
This redbook presents the emergence and the impacts of XML

in the e-business world. Topics include:
- The e-business market: what is going on, trends, and
directions.
- The added value of XML technology to help to solve issues,
and some challenges that arise through e-business
applications such as data exchange, portal services, and
pervasive device support.
- How IBM cuts XML and related technologies down to size in
its application Framework for e-business, including details
of the IBM offering in terms of architecture and tools to
design, develop, deploy, and run complex B2B and B2C
models.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks
SG24-6104-00
ISBN 0738418102

The XML Files

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The XML Files

Uploaded by

Copyright:

Available Formats

The XML Files:

Using XML for Business-to-Business

XML in IBMs Application Framework

International Technical Support Organization

First Edition (September 2000)

Chapter 2. Introduction to IBM e-business solutions.

Copyright IBM Corp. 2000

Chapter 3. XML in the IBM Application Framework for e-business .

Chapter 5. B2C applications using XML . . . . . . . . . . . . . . .

Chapter 6. B2B applications using XML . . . . . . . . . . . . . . . . . . . . . . . 177

7.3.4 E-broker application functional decomposition . . . . . . . .

Appendix A. An example of a OBI TPA XML document . . . . . . . . . . . . 281

Appendix C. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

The e-business adoption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Copyright IBM Corp. 2000

Content management using XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Auction service: application topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Relationship between XML Features and e-business applications . . . . . . 33

Copyright IBM Corp. 2000

Copyright IBM Corp. 2000

The team that wrote this redbook

Thanks to the following people for their invaluable contributions to this

Part 1. Introduction to e-business and XML

Copyright IBM Corp. 2000

Chapter 1. XML and e-business applications

1.1 About e-business

Copyright IBM Corp. 2000

Communication and other transactions are instantaneous.

In summary, an e-business is an organization that connects critical business

1.1.1 Business transformation and innovation

Chapter 1. XML and e-business applications

Use the Establish

Figure 1. The e-business adoption process

1.1.2 Which is the e-business value?

Chapter 1. XML and e-business applications

As a consequence of the fact that markets are becoming increasingly

1.1.3 A simplified classification schema for e-business applications

One could argue that sometimes the boundary between an intra-business

Classification of e-business activities, or business processes, is described in

Chapter 1. XML and e-business applications

1.1.3.1 Intra-business applications

Using the latest e-business technologies, this intelligence can then be

Business-to-consumer applications (B2C)

Chapter 1. XML and e-business applications

Customer self-service includes queries from customers (consumers or

Bill Payment (Transaction/Dynamic) includes online payment and

Source: Forrester, Morgan Stanley Dean Witter, Giga, IBM Analysis

Figure 3. Growth of the business-to-consumer sector

Business-to-business applications (B2B)

Chapter 1. XML and e-business applications

Source: Forrester, Morgan Stanley Dean Witter, Giga, IBM Analysis

Figure 4. Growth of the business-to-business sector

1.2 The Extensible Markup Language (XML)

Chapter 1. XML and e-business applications

1.2.1 World Wide Web document standards

1.2.2 A brief history of XML

XML shall be straightforwardly usable over the Internet.

Chapter 1. XML and e-business applications

1.2.3 XML a universal data format

1.2.4 A short comparison of XML and HTML

Chapter 1. XML and e-business applications

domain specific standards

resource description standards